ソフトウェア開発原則とは、美しく、明確で、保守可能なコードを書きたいなら、エンジニアがプログラム実装時に従うべき一連の特定のルールや推奨事項を指します。 変数、クラス、関数の寄せ集めを完璧なコードに変える魔法の杖はありませんが、エンジニアが正しいことをしているかどうかを判断するのに役立つ、いくつかのヒントやヒントがあります。 以下の原則のいくつかは Python 固有のものですが、ほとんどはそうではありません。
Measure twice and cut once
これはすべての原則の中で最も重要な原則だと考えています。 この投稿から 1 つだけ原則を学ぶとしたら、それはこの原則であるべきです。 私たち開発者、アーキテクト、マネージャーは、注意不足、愚かなミスや誤植、個人的な問題、悪い気分、冷たいコーヒーと格闘しています。 どれも関係ありません。問題は解決されなければならないのです。 エンジニアである私にとって、この原則は、問題に対する正しい解決策を選ぶこと、問題に対する正しいアプローチを選ぶこと、問題を解決するための正しいツールを選ぶこと、構築した解決策に自信を持つことを意味します。 ここでいう「選択」とは、必要なリソースを見つけ、適切なチームを編成し、デザインを考え、アプローチを考え、タスクを設定し、結果をコントロールし、その責任を負うという、何らかの考えを持つことを意味します。 これが「Engineering as is」です。
Don’t Repeat Yourself (DRY)
同じことを別の場所で繰り返すのは良くないという、シンプルですが非常に有用な原則です。 まず第一に、これはコードのさらなるサポートと修正の必要性に関連しています。 あるコード断片がプログラム内の複数の場所で重複している場合、2 つの破滅的な状況に陥る可能性が高くなります。
- ソースコードに小さな変更を加える場合でさえ、同じコードを数カ所で変更する必要があります。 これは、追加の時間、労力、注意を必要とします (多くの場合、それは簡単ではありません)。
- 最初の項目は、2 番目の項目に続いています。 あなたまたはあなたのチームの他の開発者は、誤って変更の 1 つを見逃し (vcs でブランチをマージすることで発生する可能性があります)、アプリケーションの後続のバグに直面する可能性があります。 これらのバグは、そのようなバグがすでに修正されたと聞いていたので、あなたにとってフラストレーションになる可能性があります。 これは一般的な推奨事項です。 実際、2 回目の繰り返しに遭遇した場合でも、別のメソッドを作成することを考えるべきです。
Occam’s Razor
これは、哲学からプログラミングにもたらされた、非常に一般的な考え方です。 この原則の名前は、イギリスの修道士ウィリアム・オブ・オークハムに由来しています。 この原則は、「エンティティは必要なしに増殖してはならない」というものです。 工学の世界では、この原則を次のように解釈している。「必要性のない不要な実体を作る必要はない」。 したがって、別の方法／クラス／ツール／プロセスなどを追加することの利点について、常に最初に考えるのがよいでしょう。 結局のところ、別のメソッド/クラス/ツール/プロセスなどを追加しても、複雑さが増す以外に利点がなければ、何の意味もありません。
Keep It Simple Stupid (KISS)
これは上記の原則と非常に似ていますが、少し意味が異なります。 この原則では、コードは複雑な構造ではなくできるだけ単純でなければならず、そうでなければコードのデバッグや保守を複雑にしてしまうと言っています。 また、他のプログラマーがコードのロジックを理解するのが難しくなり、その分、時間と労力が必要になります。 そのため、多数の分岐や深いネスト、過度なオーバーロードのあるクラス構造を避け、できるだけ問題を解決するシンプルな構造を使用するよう常に心がける必要があるのです。 そうすることで、自分も同僚も楽になります。なぜなら、複雑さはバグを発生させるからです。 ピーター・ヒンティエンスが言ったことを思い出してください。 「6096>
You Aren’t Gonna Need It (YAGNI)
多くのプログラマーが苦しんでいる問題です。 プロジェクトの最初から、必要な (そして、時には不要な) 機能をすべて一度に実装してしまおうという欲望です。 つまり、開発者が可能なすべてのメソッドを最初からクラスに追加して実装してしまうと、将来的にそれらを使うことがない可能性さえあります。 したがって、この勧告によれば、まず、必要なものだけを実装し、後で、必要であれば、機能を拡張する。 6096>
Big Design Up Front
機能開発を始める前に、まずアプリケーションアーキテクチャについて考え、システム全体を十分に細かいところまで設計し、それから初めて事前に定義した計画に従って実装に進むべきである。 原則は存在する権利がありますが、最近、それに対する批判がかなり多くなっています。 それはまず、設計や作業中に計画が陳腐化することと関係がある。 この関連で、その後の変更をまだ行う必要がある。 しかし、正しい設計をすれば、その後のデバッグやエラーの修正にかかるコストを大幅に削減できる、という利点もある。
Avoid Premature Optimization
“Premature optimization is the root of all evil (or at least most of it) in programming” – Donald Knuth
最適化は非常に正しく、プログラムを高速化し、システムのリソース消費を削減するのに必須のプロセスである。 しかし、何事にもその時期があります。 最適化が開発の初期段階で実施された場合、益となるよりも害となる可能性があります。 まず、最適化されたコードの開発には、開発やサポートに多くの時間と労力を要するという事実と関係があります。 この場合、最初に選択した開発手法の正しさを確認しなければならないことが結構あります。 そのため、最初はシンプルだが最適とは言えない方法を採用する方が得策である。 そして後で、このアプローチがアプリケーションの作業をどの程度遅くするかを見積もり、より速い、あるいはよりリソースを消費しないアルゴリズムに移行する。 また、最初に最適なアルゴリズムを実装している限り、要件が変わり、コードがゴミ箱行きになる可能性があります。
Principle Of Least Astonishment
この原則は、コードが直感的で明白であり、コードをレビューするときに他の開発者を驚かさないようにすることを意味します。 たとえば、メソッドが「クッキーを作る」と呼ばれているのに、結果としてジャガイモが得られるとしたら、そのコードは (明らかに) 悪いものです。 さらに、副作用を避けるようにし、避けられない場合は文書化する必要があります。
S.O.L.I.D.
「SOLID」は実際にはオブジェクト指向の設計原則のグループです。 SOLID “の各文字は原則の一つを表し、それは次のとおりである：
- Single responsibility states that every module or class should have responsibility for a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class;
- Open-closed states that software entities (classes, modules, functions, etc.).
- Interface segregation は、どのクライアントも使用していないメソッドに依存することを強制されるべきではないとする。
- Dependency inversion は、プログラマは実装レベルではなくインターフェースレベルで作業すべきであるとする。
これらの原則を一緒に適用すると、開発者が長期にわたって保守および拡張しやすいコードを作成するのに役立ちます。
Law of Demeter
この原則の基本的な考え方は、クラス間で責任範囲を分け、クラス、メソッドまたは構造内に論理をカプセル化することです。 この原則からいくつかの推奨事項を区別することができる：
- クラスまたはエンティティは独立しているべきである
- 異なるクラス間の接続（いわゆるカップリング）の数を減らすよう試みるべきである。
- 関連するクラスは、1 つのモジュール/パッケージ/ディレクトリ内になければなりません (結束とも呼ばれます。
これらの原則に従うと、アプリケーションはより柔軟になり、理解でき、保守が容易になります。
結論
開発者の仲間はエンジニアであろう! 有機的なモンスターを育てるのではなく、堅牢でよく実装されたシステムの設計と構築について考えようではありませんか。 列挙した原則は相関性が高く、本質的につながっている。 もちろん、私が作成したわけではありませんが、少なくとも私の記憶は完璧ではありません。
Recommended books
- Clean Code by Robert C. Martin
- Clean Architecture by Robert C. Martin