プリンシプル オブ プログラミング で学んだ「原則」について。
はじめに
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
で解説されていた 「原則」 について学んだことをここに残す。
KISS
英:Keep It Simple, Stupid.
日:シンプルにしておけ、愚か者よ。
という意味を持った原則です。
コードをシンプルに保つ
コードを書く時、最優先の価値を 「単純性」「簡潔性」 に置きます。
シンプルなコードの特徴
・読みやすい
・理解しやすい
・修正が容易
シンプルなコードは、各要素の責務が明確なので、テストもしやすいです。
コードに余計なことをしない
シンプルをプログラミングの羅針盤としましょう。
コードから、余計なこと、過剰なことを可能な限り排除します。
プログラミングを書いてる時、動作させるために、もっともシンプルなものは何か と常に自問自答します。
クレバーにならない
私:クレバーとは?
LLM:「クレバー」とは、英語の “clever” に由来する言葉で、「頭の回転が速い」「賢い」「要領が良い」 といった意味を表す形容詞です。物事を効率的にこなし、的確な判断を下せる人や行動を指す際に用いられます。
コードは、頭の良さをアピールする場ではありません。ユーザーに価値を提供するものです。クレバーになってはいけません。
コードがシンプルであり続けることに 「愚直」 に取り組んでください。
将来の必要に備えない
「今」不要なら、「今」書くべきではありません。
必要になった時、必要な分だけ書くようにして、シンプル を保ちましょう。
DRY
英:Don't Repeat Yourself.
日:繰り返すな。
という意味を持った原則です。
重複を避ける
同じコードを重複して書いてはいけません。
コードが改善できなくなる
コードに重複があると、デバッグや機能追加など、コードを改善していくことが困難になります。
具体的に以下の困難が発生します。
-
コードを読む作業が難しくなる
同じようなコードが複数あると、量的に「より多く」なり、質的に「より複雑」になります。そのため、単純にコードを読む作業が難しくなります。 -
コードを修正する作業が難しくなる
同じようなコードが複数あると、その複数箇所を正確に修正しなければ、全体として整合が取れません。慎重に作業しないと、修正漏れの危険性があります。
コードを抽象化する
コードを 「抽象化」 することによって、重複を排除しましょう。
処理のまとまりに名前を付けて、「関数化」 「モジュール化」 します。
データであれば、それに名前を付けて 「定数」 として定義します。
- 抽象化により得られるメリット
- コードの量が減り、読む量を減らせる
- ロジックやデータに「名前」が付くので、コードが読みやすくなります。
- 同じコードが1箇所に集約され、修正箇所が1箇所で済むので、コードの修正が容易になり、品質が担保しやすくなります。
- 抽象化した部分は、再利用性が高まります。新機能を追加する際、コードの再利用によって、より速く、より品質良く、プログラミングを完了できます。
「抽象化」は面倒な作業ですが、重複が良くないということには、もはや議論の余地はありません。 重複を避けておくと、長い目で見ると有利になる。というのが歴史の結論です。
YAGNI
英:You Aren't Going no Need It.
日:それはきっと必要にならない。
という意味を持った原則です。
コードは必要最低限
コードは「多分、必要になるだろう」「必要になるかもしれない」で書いてはいけません。
本当に必要になった時、必要なものだけを書く、という方針で臨みます。
ソフトウェアの変化を予測して、先回りしたコードを書くのは不可能なので、
割り切って、今必要なコードだけを書くようにします。
コードは「今」必要なものだけを
汎用性よりも、単純性を考えましょう。
汎用性のもたらす再利用性や拡張性よりも、まず 「使えること」 に価値を置くようにしましょう。
PIE
英:Program Intently and Expressively.
日:意図を表現してプログラミングせよ
という意味を持った原則です。
コードの意図を伝える
コードを書く時に大切なことは、意図を明確に表現するように書くということです。
「このソフトウェアはどう動くものなのか?」 ということを、コードの読み手にストレートに伝わるようにコードを書きましょう。
コードが唯一の手がかり
コードだけが、ソフトウェアの動作を 「正確に」「完全に」 知るための手がかり です。
ソフトウェアの動作を把握するためには、コードを読むしかありません。
分かりやすいコードを書いて、コードで意図を伝えるしかないのです。
コードは読みやすさが最優先
コードを書く時には、「書きやすさ」より 「読みやすさ」を重視しましょう。
コードは、「書く時間」より「読む時間」の方がずっと多いものです。今、自分が書いてるコードですら、それを自分で読んでる時間の方が多いかもしれません。
よって、コードは「書く効率」より「読む効率」が優先されます。読みやすければ、書く時の効率が多少落ちたとしても、それに見合う価値があります。
コメントは書く
コードはどこまで行っても 「What」 と 「How」 です。
つまり 「何をしているのか」「どのようにやっているか」 までしか表現できません。
「Why」
つまり 「なぜそれをしているのか」 を表現するには、コメントを使用する必要があります。
コメントで説明しなくてもよい、分かりやすいコードを目指しつつ、それでも表現できない部分にはコメントを書く。 というバランスを持ったコードを書くようにしましょう。
さいごに
これらの原則を意識しながら開発を進めることで、実際にコードに手を入れる時間を最適化でき、最終的にはより高品質なソフトウェアを生み出せます。コードの「何を」「どのように」実行しているかだけでなく、「なぜそのコードが存在しているのか」という意図まで含めて表現することを心がけたいです。
Discussion