プログラミングの101個の原理原則『プリンシプル オブ プログラミング』

プログラミングを行うときに意識するべきことや役に立つことを101個の原理原則としてまとめています。 今までに先人たちが提唱してきたアドバイスやメソッドをわかりやすく紹介した本です。

プリンシプルとしてまとまっていますので1つ1つが薄くなっている場合もあります。詳細な意味や内容が気になる場合は出典も読むといいです。出典書籍の情報や関連書籍がしっかり掲載されているので、気になったものはそちらをチェックして掘り下げましょう。巻末にはindexもあり、気になったものを検索することもできます。

プリンシプル オブ プログラミングという名前の通り、プログラミングを行う際のテクニックが多いです。もっと考え方や態度など、技術以外のエンジニアの心がけが知りたい場合はベタープログラマ ―優れたプログラマになるための38の考え方とテクニックという本がおすすめです。以下の記事でも紹介しています。
【おすすめ読書】ベタープログラマ

これからプログラミングを始めるという人には、【実践技術書】独学プログラマーなど、入門の本を先に読みましょう。プリンシプル オブ プログラミングについては、ひとまずプロダクトを作ってみてから読むのがおすすめです。

プリンシプル オブ プログラミングを読んで、「こんな経験したなあ」とか「昔見たけど忘れていたな」というものを思い出すきっかけになります。 この記事では、WEBエンジニアの私が重要だと感じたものを取り上げて紹介します。

みなさんも自分なりのプリンシプル オブ プログラミングをつくってみてはいかがでしょうか。 まとめて机に貼っておくか、デスクトップ用の壁紙にでもして思い出せるようにするといいですよ。

Don’t repeat yourself

DRY（ドライ）と言われる有名な原則です。 ざっくりとは同じコードを重複して書いてはいけないということです。コピペ禁止です。 あちこちにコピペした結果、修正や変更の際に全部の箇所に手を入れなくてはいけません。これはあくまでも一例で、コードの改善が難しくなってしまうことはありがちな問題です。

関数化やモジュール化などを検討して、コードを抽象化することで回避できます。時間がなくて急いでいるときほどコピペしがちです。忙しくて問題が起きてほしくないときに限って問題が発生する印象があります。ですので、常に落ち着いて対処することを心がけましょう。

実際の現場ではすでに実装されている箇所への影響を防ぐために、コピペで作ろうという判断もありました。今思えば議論の余地はなく修正を行うべきだったのではないかとも思います。 長い目で見れば損を産んでしまうので、忙しい時でもリファクタリングして重複を取り除くことができればよかったです。 これから実装するものだけでなく、すでに実装されているものに対しても積極的に修正・リファクタリングを行っていくべきです。

プログラミングにおいてこのDRYはかなり重要な原則です。「おやっ」と思うことがあれば必ず直すべきと思ってもいいくらい強いものだと思います。 予めユニットテストを準備しておくことや、リファクタリングの時間を予めスケジュールすることなどができれば、快適にこの原則を守れそうです。

ちなみに、DRYはプログラミング以外のことにも役立つと思います。テストであったりデプロイなどの作業についても、何度も繰り返しやることになります。日々のメールによる報告とかもそうでしょうか。 早いうちに自動化を検討して、繰り返し行わなくていいようにしましょう。

ブルックスの法則

「人月の神話」にて出てくる言葉です。 プロジェクトの進捗が悪いために新たに人員を追加すると、火に油を注ぐ形となりさらなる遅延につながります。

工数の見積もりには人月を使います。人×月なのですが、実は「人」と「月」は交換不可能になっています。 すなわち2×6と6×2ではどちらも12人月なのですが、現実では同じにはなりません。

依存関係のオーバーヘッドであったり、新しく参加するに当たっての教育や共有などに時間がかかるため、この現象が発生します。 リスケジュールしたり、機能に優先度をつけて一部のみ開発するなどの機能面での対応が望ましいです。それらの相談は勇気が必要ですが、それをできるかどうかが良いエンジニアを分けるのではないかと思います。良いエンジニアはプログラミング以外のところで強さを発揮すると思います。プログラミングの技術やスピードだけが良いエンジニアとは限りません。コミュニケーション力や調整力など、さまざまな技能が必要なようです。

割れた窓の法則

割れた窓を放っておくと、そばにある他の窓も割られていくというものです。割れた窓は見つけ次第直せ！ということです。

どこかで悪い・汚いコードを見つけると、他の部分もどうせそうだろうと思い同じようなレベルでコードを書いてしまうというものです。 人間には他人の行動を真似る特性があり、悪いコードも無意識に真似してしまいます。 自分は流されずに綺麗なコードを書くこと、悪いコードを放置せず見つけ次第直すことが求められます。

直すのには時間もかかるし、動いているものを修正するのはめんどくさいことも多々あります。それでも時間を取って、積極的に書き直していくことで美しいシステムが守られます。ただし勝手に書き直すと余計なバグを生む原因にもなります。周りのメンバーや上司と相談する機会を設けて、足並みをそろえながら取り組みましょう。こういった文化づくりも美しいシステムを維持するために重要になります。

おわりに

他にもたくさんの原理原則があり、どれも重要と感じるものばかりです。プリンシプル オブ プログラミングというタイトル通りです。なんせ101個もあるので全部は紹介できません。プログラミングをしていく中でこれら以外のものと出会うこともあります。 実際にプログラミングでものをつくる、納品していく中で嫌でも身にしみて覚えていくと思います。

現場や文化、作っているシステムの性質などによっても変わることがあります。できれば原則に従うことが大切だと思いますが、現場のルールや方針によってはそれに従わないという選択をする場合もあります。
原則に背くことになったとしても、それによって何を得られて何を失うのかといったことを考えておくことが重要です。
大概の場合は未来の時間を消費しています。現時点では何が起こるか、未来にどうなっているのかは正確にはわからないので、この点はしっかり抑えておきたいです。「あの時こうしておけばなあ」と感じることが合ったらしっかり覚えておいたほうがよいです。次の機会では同じことをしないように気をつけることができるようになります。

私はシステムに関する原則は他の仕事や実際の生活にも当てはまるなあと思っています。とくにDRYの原則なんかとてもそう思います。 ここでは紹介しませんでしたがYAGNI（You Aren't Going to Need It）とかKISS（Keep It Simple,Stupid. Keep it Short and Simple.）なども、なんにでも当てはまるのではないかと思っています。 Less is more.なんかも素敵です。いい言葉ですね。

また機会があれば紹介します。