エンジニアの思考とエンジニアのリテラシー
卒業後にコーディングをしていると、学生時代の「ソフトウェア工学入門」を思い出すことが多いのですが、当時は正直、コーディング経験が少なかったり、コード量が少なかったりで、このコースを学んでいても、「ああ、この本に何が書いてあるんだろう？ と理解できませんでした！ しかし、アジャイル開発、カップリング、結合、単一責任などの用語も知っていますが、これらの単語については、私はいつも理解しているようです。私が理解していない理由は、おそらく私がシステムを構築する経験を持っていないためだと思います、通常はプログラムを書くアルゴリズムのレベルであり、コードの量は非常に小さいです。実際にシステムを構築してみると、このようなことはどこにでもあることです。ですから、ソフトウェア工学入門を学ぶには、小さなソフトウェアプロジェクトの構築に参加することが必要であり、そうすることで、よりスムーズに学ぶことができると思います。
マクロとミクロ ホリスティックとローカル
これはまた、問題の次元は、シニアプログラマに相対的なジュニアプログラマは時々悪いかもしれない次元は、シニアプログラマは、2つの次元の全体的な、局所的な次元から機能を考慮することができるビジョンは、実装の機能性だけでなく、プロジェクト全体の影響に属するモジュールにこの関数の影響を考慮します。
建築に対する認識
一般的に、エンジニアリング構造を定義するのはビジネスであることを知っている人たちは、アーキテクチャという言葉を好むかもしれません。この点については、「ソフトウェアアーキテクチャを語る」でも説明しましたが、アーキテクチャと構造は実際には同義語です。あらゆる種類のフレームワーク、コンポーネント、ミドルウェアを前にしたとき、どのように選択し、どのように設計するのでしょうか？どのようにコードの複雑さを減らすために適切なアーキテクチャを選択するには、マイクロサービスアーキテクチャ上のすべてではないのですか？ 多くの新参者のためかもしれないが、ソフトウェアアーキテクチャは、現在唯一のマイクロサービスであり、一部の人々はまた、SOAについて話すかもしれないが、私の個人的な意見では、SOAとマイクロサービスはあまり違いはありませんが、アーキテクチャの特定の種類のコンセンサスの形成のソフトウェアセッションです。
コード構造だけでなく、ビジネス構造も重要で、その両方が合致すればするほど、ソフトウェアはより活気づきます。
結合と結束の認識
カップリングとは何ですか？私はSpring Frameworkの学習、デカップリングの歴史から先生が最初に言い始めることを覚えて、実際には、私は恥ずかしながら、私は表面的な知識のカップリングにあったということですが、モジュールを変更すると、モジュールに影響を与えますが、私はこれは当然の問題ではないことを考えていた？ソフトウェアは、A、B、C、Dの3つのモジュールで構成されている場合は、その後、Aモジュールの変更は、B、C、Dと一緒に、これらの3つのモジュールは、明らかにコラボレーションとメンテナンスに資するものではありません変更しなければならないと仮定すると、しかし、後でゆっくりと高カップリングは、メンテナンスに資するものではないことを認識し、これらのモジュールは、単一の責任に十分ではありません。変更されたAモジュールは、B、C、Dモジュールも一緒に変更する必要がありますし、これらのモジュールは、物事の数を担当していることは明らかである、それらのAモジュールに加えて、具体的には、B、C、D機能、可能な限りAモジュールの機能と連携するために使用され、単一の責任、それは私がデザインパターンを思い出し、デザインパターンはまた、ほとんどの時間を疎結合に使用されますが、疎結合に疎結合に覚えていないか、またはビジネスニーズとシステムの位置決めからトリガされるように、期間を満たすために、システムのビジネスニーズを満たすために。同様に、システムポジショニングのトリガは、一定期間のシステムの開発ニーズを満たすためにすることができます。
変化をよく考えて
プログラマーは、その知性や論理的・分析的スキルで判断されるべきではなく、分析の包括性で判断されるべきです。--C言語プログラミングへの現代的アプローチ
建設業者が既存の100階建てのビルの下に小さな地下室を作ることはありません。しかし驚くことに、ソフトウェア・システムのユーザーは、同じような変更を要求することに二の足を踏むことはなく、単純なプログラミングの問題だと考えています。
皆さん、ソフトウェア開発の世界では、要求の変更は常に起こり、そのすべてが理にかなっているわけでも、すべてが理にかなっていないわけでもありません。実装者にとっては、変更の全体的な影響を評価する必要があり、小さな変更に見えても、システム全体に竜巻を巻き起こす可能性があります。
コーディングリテラシー
ポジショニングの問題
開発プロセスは、実際には、問題の多くの種類に遭遇しますが、問題に遭遇しないことは普通のことではありませんが、パニックにならない、写真を撮る、友人の輪を送信します。まず、問題がどこにあるかを見つける必要があり、その後、問題を定義し、それを解決することを考え始める必要があります。ほとんどの人は、問題の場所で立ち往生している可能性があり、ここで問題を定義し、私は通常、コードを書くことは非常に安定している、私はどのプロジェクトがより緊急であることを覚えて、SQLの非常に長い文字列は、構文の問題を報告し、私は長い時間が見つかりませんでした、私は行くために私たちの建築家に依頼しに行き、建築家は最初に私に言った：若者は、緊急事態に遭遇する不安になることはありません写真を撮って、友人の輪を送信します。その後、まだ少し位置決めの問題は、ここで完全に私はポイントを実現させるコードはパニックにならないように書くことです。
要約すると
これはこの時期の私のコーディングに対する認識でもあるのですが、業務実装ばかりに目を向けるようになり、システム全体の構造を考えるようになり、業務構造とコード構造を認識するようになり、変更点の導入による影響をよく考えるようになり、自分のコードを見直すようになり、他の人の問題解決に協力しようとするようになりました。これが私の考えるエンジニア思考であり、エンジニアリテラシーであり、雑感のようなものです。実はちょっと大きな話題なのですが、システムの構造的な性質など、汎用的であるべきことを論じているのであって、ソフトウェア分野だけに限ったことではないと思います。
