優れたプログラマーは、自分のスキルと常識を組み合わせることができる必要があります。それはすべて実用主義とあなたの問題に最適な解決策を選択するスキルについてです。ソフトウェア開発で問題に直面した場合、基本原則を使用して適切なアプローチを選択することができます。
このテキストは、開発者が知っておくべき一連の原則を提供し、定期的に更新する必要があります。それらをあなたの秘密のプログラミング兵器と考えてください。
これらの原則を一貫して適用すると、ミドルからシニアへの移行が容易になります。直感的に使用するもの（おそらく）があることに気付くかもしれません。
多くの原則があります。最も重要な7つに焦点を当てます。それらを使用すると、成長し、より優れたプログラマーになるのに役立ちます。
1.ヤグニ
あなたはそれを必要としないでしょうこの原則は単純で明白ですが、誰もがそれに従うわけではありません。コードを書いている場合は、それが必要になることを確認してください。後で役立つと思われる場合は、コードを記述しないでください。
この原則はリファクタリングに適用されます。メソッド、クラス、またはファイルをリファクタリングする場合は、不要なメソッドを削除することを恐れないでください。以前は便利でしたが、今では必要ありません。
それらが再び必要になる日が来るかもしれません-それからあなたはそれらを死から復活させるためにgitリポジトリを使うことができます。
2.ドライ
自分を繰り返さないでくださいこの概念は、AndyHuntとDaveThomasの著書ThePragmatic Programmer：The Journey from Apprentice toMasterで最初に明確にされました。
このアイデアは、信頼できる唯一の情報源（SSOT）を中心に展開しています。とにかくこれは何ですか？
情報システムの設計と理論では、信頼できる唯一の情報源（SSOT）は、情報モデルとデータスキーマを構造化する手法です。つまり、すべてのデータが1か所で処理（または編集）されます... SSOTは信頼性の高い関連性のある使用可能なデータ。
-ウィキペディア
SSOTを使用すると、より堅牢でわかりやすいコードベースが作成されます。
コードの複製は時間とリソースの無駄です。同じロジックを維持し、一度に2つの場所でコードをテストする必要があります。また、ある場所でコードを変更する場合は、別の場所でコードを変更する必要があります。
ほとんどの場合、コードの重複はシステムの無知が原因で発生します。何かを書く前に、実用的である：周りを見てください。おそらく、この関数はどこかに実装されています。おそらく、このビジネスロジックは他の場所に存在します。コードの再利用は常に賢明な決断です。
3.キス
シンプルで愚かなこの原則は、1960年に米海軍によって開発されました。この原則は、単純なシステムがより良く、より確実に機能することを示しています。
この原理は、1970年代に行われたホイールの再発明と多くの共通点があります。それからそれはビジネスと広告の比喩のように聞こえました。
ソフトウェア開発に関しては、次のことを意味します-問題に対して必要以上に複雑な解決策を考え出さないでください。
最も賢明な決定が最も単純であることが判明する場合があります。効率的で効率的でシンプルなコードを書くことは素晴らしいことです。
私たちの時代の最も一般的な間違いの1つは、新しいツールを使用することです。開発者は、最新のテクノロジーを使用するように動機付けられる必要があります。それが新しいからではなく、仕事に適しているからです。
4.事前の大きな設計
グローバルデザインファーストこのソフトウェア開発へのアプローチは非常に重要であり、見過ごされがちです。実装に進む前に、すべてがよく考えられていることを確認してください。
… . , . , . , BDUF, , . , .
—
多くの開発者は、コードを書かなければ進歩していないと信じています。これは間違ったアプローチです。計画を立てることで、最初から何度もやり直す手間を省くことができます。
アーキテクチャ開発の欠陥やプロセスに他の人が関与しなければならない場合があります。これらすべてについて話し合うのが早ければ早いほど、すべての人にとってより良いものになります。
非常に一般的な反論は、問題を解決するためのコストは、多くの場合、計画時間のコストよりも少ないということです。ユーザーが遭遇するエラーが少ないほど、エクスペリエンスは向上します。これらのエラーに対処する別の機会がない場合があります。
5.SOLID
これは、ソフトウェア開発の最もよく知られた原則です。Solidは次の略語です
。S）単一責任の原則
その重要性は強調しすぎることはありません。各オブジェクト、クラス、およびメソッドは、1つのことだけを担当する必要があります。オブジェクト/クラス/メソッドの機能が多すぎると、スパゲッティコードになってしまいます。次に例を示します。
const saveTodo = async () => {
try {
response = await saveTodoApi();
showSuccessPop('Success');
window.location.href = '/successPage';
} catch (error) {
showErrorPopup(`Error: ${error} `);
}
}
この方法は無害に見えますが、実際にはやりすぎです。
- オブジェクトを保存します
- UIで通知を処理します
- ナビゲーションを実行します
このコードのもう1つの副作用は、テストの問題です。複雑な機能をテストするのは困難です。
O）オープン–クローズド原則
プログラムオブジェクトは、拡張のためにオープンである必要がありますが、変更のためにクローズされている必要があります。重要なのは、メソッドやクラスをオーバーライドすることはできず、必要に応じて関数を追加するだけです。
この問題に対処する良い方法は、継承を使用することです。 JavaScriptは、コンポジションでこの問題を解決します。
簡単な経験則：エンティティを変更して拡張可能にすると、この原則に初めて違反することになります。
L）リスコフの置換原則
この原則は、上位クラスのオブジェクトはサブクラスのオブジェクトと置き換え可能であり、そのような置き換えが行われたときにアプリケーションは期待どおりに実行される必要があることを示しています。
I）インターフェイス分離の原則
この原則は、ロバート・マーチンがゼロックスに相談したときに策定されたものであり、明らかです。
オブジェクトは、使用しないインターフェースに依存してはなりません
ソフトウェアは独立した部分に分割する必要があります。独立性を確保するには、副作用を最小限に抑える必要があります。
オブジェクトに、必要のないメソッドを実装させないようにしてください。次に例を示します。
interface Animal {
eat: () => void;
walk: () => void;
fly: () => void;
swim: () => void;
}
すべての動物が飛んだり、歩いたり、泳いだりできるわけではないので、これらの方法はインターフェースの一部ではなく、オプションである必要があります。
D）依存性逆転の原則
この原則は強調しすぎることはありません。具体的な実装ではなく、抽象化に依存する必要があります。ソフトウェアコンポーネントは、凝集度が低く、一貫性が高い必要があります。
あなたは何かがどのように機能するかではなく、それがどのように機能するかについて心配する必要があります。簡単な例は、JavaScriptで日付を使用することです。あなたはそれらのためにあなた自身の抽象化レイヤーを書くことができます。次に、日付の取得元を変更する場合は、1000ではなく、1か所で変更する必要があります。
この抽象化レイヤーを追加するのに手間がかかることもありますが、最終的には効果があります。
例としてdate-ioを見てください 。このライブラリには、さまざまな日付ソースで使用できる抽象化レイヤーがあります。
6.時期尚早の最適化を避ける
時期尚早の最適化を回避するこのプラクティスは、最適化が必要であると証明される前に、開発者がコードを最適化することを奨励します。 KISSやYAGNIをフォローすれば、このフックに陥ることはないと思います。
正しく理解してください。何か悪いことが起こると予想するのは良いことです。ただし、実装の詳細に入る前に、これらの最適化が本当に役立つことを確認してください。
非常に簡単な例はスケーリングです。新しいアプリケーションが非常に人気になることを前提として、40台のサーバーを購入することはありません。必要に応じてサーバーを追加します。
最適化が時期尚早であると、コードの遅延が発生する可能性があるため、関数を市場に投入するために必要な時間が長くなります。
多くの人は、時期尚早の最適化がすべての悪の根源であると考えています。
7.オッカムの剃刀
Brithva Okkama（時にはLezvie Okkama）は、「不必要に物事を増やすべきではない」[1]（または「絶対に必要でない限り新しいエンティティを引き付けるべきではない」）と簡潔に述べる方法論の原則です。
-ウィキペディア
これはプログラミングの世界ではどういう意味ですか？不要なエンティティを不必要に作成しないでください。実用的である-コードベースを複雑にする可能性があるため、それらが必要かどうかを検討してください。
結論
これらの原則はそれほど難しくありません。実際、それらを美しくするのはシンプルさです。混乱している場合は、一度にすべてを適用しようとしないでください。意識を持って作業し、これらの原則をワークフローに徐々に組み込んでみてください。
基本的でありながら強力な原則を使用することで、より優れたプログラマーになり、なぜ何かをしているのかをより明確に理解できるようになります。
ほとんどの原則を直感的に適用している場合、特定の方法で何かをしている理由を考えて理解することは価値があります。
ではごきげんよう。
- コントローラーを機能的に分離したデュアル燃料エンジン用のロシア初のシリアル制御システム
- 現代の車では、コードの行数が...
- - Automotive, Aerospace, (50+)
- McKinsey: automotive
