プリンシプル オブ プログラミング で学んだ「原則」について。
はじめに
プリンシプル オブ プログラミング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