序文
ステーション C のエキスパート サークル コミュニティで共有するように招待されました。以下は、この共有の全文です。
自己紹介
私の名前は Zheng Haohua で、フルスタック エンジニアです。csdn 名は Siege Lion Baiyu です。
私の専門的な経験と経験は、グループの専門家ほど豊富ではないからです。今日は、私自身の経験から始めて、あなたと話し合うための未解決の質問をします。今日専門家の皆さんと話したいのは、「プログラマーの成長の道 - 道教とテクニックについての考え」です。
始める前に、いくつかの名詞を定義したいと思います。1 つはコーダーで、もう 1 つはプログラマーです。コード ファーマーとは、コードを書く人のことです。プログラマーは考えることができるコーダーです。このディスカッションでは、道教から 2 つの概念、道と芸術を借りています。道は理論的な問題を解決するために使用され、方法論であり、芸術は技術的な問題を解決するために使用され、方法です。
成熟への道
プログラミングに触れ始めたのは大学生の頃で、C言語の始まり、シングルチップマイコン、組み込み、モノのインターネットのサーバー開発、単体Webサービス開発、マイクロサービス開発、そして同社のSaaSプラットフォーム開発に。途中、会社のプロジェクトのアーキテクチャ設計にも参加し、作業の過程でクラウドネイティブ関連の知識に手を出しました。このプロセスは、実際にはさまざまな技術を継続的に学習するプロセス、つまりスキルを蓄積するプロセスです。
長年の研究の結果、上位レベル (ここでいう上位レベルとは、コンピューター サービス アプリケーションのレイヤー化を指します) に行けば行くほど、テクノロジの更新の繰り返しが速くなり、学習能力と好奇心を維持する必要があることがわかりました。新鮮なものを受け入れるように。
ゆっくりと、これらの新しいものは、最終的な分析では、人とコンピューターに役立つツールであり、人々のコスト削減と効率向上のために提案されていることがわかりました。道具ですから、使うものです。道具はニュートラルで、善悪の区別はなく、中には手に合わないだけの武器もあります。これらは芸術です。つまり、ツールです。さらに、道具的思考も必要です。「遠方の救世主」のように、丁元英は道教と芸術についての議論で次のように述べています。
テクニックとツール
アートは方法であり、繰り返し学び、改善できるものです。したがって、アートは適切なツールを指します。改革初期の鄧小平おじいさんは、猫が黒くても白くても、ネズミを捕まえることができる猫は良い猫であると提案しました。アートは時間、場所、人、物によって変化するという事実を体現しています。
誰かがプログラミング言語の品質について議論しているのを見る前に、私はただ微笑んで何も言わなかった. うわー、フロントエンドの js は非常に低いですが、バックエンドの Java はもう少しハイエンドです。Python はおもちゃにすぎない、大規模なプロジェクトに使用する方法がない、Java は安定している、などなど。彼らは皆、自分の強みを利用して、他人の弱点を攻撃します。あまり客観的な理解はありません。
このため、プログラミング言語に縛られているプログラマーもいます。すべてのシナリオを実現する言語でなければならないと思います。もしくはフレームワークに縛られている 分散フレームワークを学んでからは、春のクラウドシステムが一番良く、オリジナルの単体アプリは低いと感じています。等々。これらはすべて、私が心に築いた、私を縛る壁です。私は自分が道具人間だとは思っていませんでした。ツールマン ツールマンとは、道具にさらわれた人ではなく、道具を使う人のことです。
しかし彼らは、それぞれのツールが特定の問題を解決するために発明されたことを忘れています。ツールが発明された当初の意図を忘れてください。
プログラマーとして、誰もが多かれ少なかれ繰り返し作業のシナリオを経験します. 現時点では、ツールを使用して自分の繰り返し作業を解決することを考えていますか? たとえば、既存のツールを見つけて効率を改善します。または、いくつかのスクリプトを作成して、繰り返しの作業から解放されます。大学時代は、学校の学務システムの期末試験の結果通知を率先して受け取ることができず、毎日見に行かなければなりませんでした。1年生の時、バカみたいに教務システムに数日おきにチェックに行っていました。プログラミングを学んだ後は、毎日教育行政システムのデータをクロールする Python スクリプトを作成し、データが更新されるたびに公式アカウントを通じて積極的に WeChat に情報をプッシュしていました。それ以来、彼はクラスで最初に結果を知った生徒になりました。
タオと思考
技法と道具の関係を論じ、現象を通して本質を見つめる 道具の裏には共通点があり、その裏にある共通点が「道」です。タオは、改善するために理解しなければならないものであり、領域であり、抽象的で、規則的で、比較的安定しています。ここで、タオは一種のツール思考だと思います。
たとえば、プログラミング言語はすべてコンピューターの原理に準拠しており、アルゴリズムやデータ構造の実装に使用でき、さまざまなプログラミング アーキテクチャに組み込むことができます。c/c++、golang、python、java のいずれであっても、本質的に人間が理解できる文法を使用して、マシンが必要な動作を理解して実行できるようにする言語を記述します。たとえば、サーバーのバックエンドを実行するなど、1 つのことを完了した後。4 つすべてを実現できますが、実現の難易度は同じではありません。使い方も違います。c/c++ が実現するリアルタイム サービスは、他の言語では真似できないため、ほとんどのオンライン ゲーム会社のサーバーは c/c++ で実装されています。もちろん、golang は Google が高度な並行性のために設計したサーバー言語であるため、一部の企業は徐々に golang に移行しています。しかし、これは、ゲームの完全なバックエンドが C/C++ であることを意味するものではありません. 完成したバックエンド サービスには、実際には、リアルタイム ゲームに加えて、ゲーム ソーシャルのものもあります. ゲーム ソーシャル バックの場合-サービスを終了するには、java OK を使用する必要があります。python も同様です。実際、それらは単なるツールです。
ドメイン駆動設計の DDD など、同じような例をもう 1 つ挙げると、かなりの数のプログラマーが DDD を一種の見栄っ張りなアプローチだと考えるでしょう. DDD を使用しても、コードが複雑になるだけで効果はありません. DDD は未熟で、成熟したフレームワークがなく、非常に仮想的なデザイン パターンです。
しかし、DDD (Domain Driven Design) は実際にはデザイン思考の手法であり、それが解決したい問題は、従来のソフトウェア設計手法におけるコミュニケーションのあいまいさによって引き起こされる問題です。
ドメイン駆動設計 (DDD) は、ソフトウェアを適切に作成する方法を教えてくれるだけでなく、オブジェクト指向テクノロジをより適切に使用する方法も教えてくれます。DDD はデザイン思考の方法、つまりTaoであり、ソフトウェアの設計と実装の方法論のセット全体を提供し、いわゆる「標準」がまったくないからです。これが、関連するソフトウェア フレームワークがない理由です。DDD の実装についての考え方は人それぞれであり、コードの分割も異なるためです。DDDの設計思想に沿う限り。一人一人の着地の具体的な方法が技の具現化です。つまり、タオに対する理解は人によって異なり、表示されるスキルも異なります。同時に、DDD 方法論では、着陸時の追跡とコード レビューの仕様に従う必要があります。これにより、チームのコラボレーションが向上し、より強力なシステムを構築できます。
あとがき
タオとは思想、考え方、方法論です。プログラミングの世界では、アルゴリズム、アーキテクチャ、およびデザイン パターンです。道は芸術を導き、芸術は道の担い手であり、方法論の具体的な実施方法です。最初に、学べば学ぶほど、テクノロジーの更新が反復的に高速であることがわかり、自分で学び続ける必要があると述べました。これは、アートが特定の方法であり、時間、場所、人、イベントによって変化するためです。実際、その背後にある設計パターンなどは、そう簡単に時代遅れになることはありません。
したがって、プログラミングの過程で要件に直面した場合、設計により多くの時間を費やし、この要件をどのように実現するかを考える必要があります。その後の拡張と高可用性に便利です。思いついたらすぐに手でコードを書くのではなく。一部の人々は、これは建築家が考慮すべきことではないかと言うでしょう。でも、もっと考えて損はないと思います。少なくとも、考えているときはコーダーではなく、プログラマーです。
上記はXiaoshengの謙虚な意見であり、他の人を引き付けるために使用されます。専門家も批判と修正を求められます。
後ろに書いてある
役に立つと思われる場合は、1 つのボタンと 3 つの連続したリンクでSiege Lion Baiyuをサポートし、この記事をより多くの友人と共有してください。あなたのシンプルなサポート、私の無限の創造力