『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則』を読んだ

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

この本について

• プログラマとしてチームで開発を行う際に、理解しておきたい「べきべからず集」のような内容。辞書的に読むのがよさそう。
• ひとつの原則に対してWhat, Why, Howの3段構成となっており、原則の背景、使いどころなどがわかりやすくまとまっている。
• 個人的には各原則に出典と関連書籍が記載されているのが嬉しい。気になる本はメモして、今後の読書キューに入れておく。

雑感

• プログラマでなくても、ソフトウェア開発に携わる者として読んでおいて損はない。
• ひとつひとつの原則にそこまで目新しさはないが、アイディアが言語化されて腹落ちしたものが多々あった。
• 単純な疑問として、世のプログラマーはどれほどこれらの原則が身に染み付いているのだろうか？
• 自分は職業プログラマーではないので何とも言えないのだが、これらの原則を常識レベルで身につけているメンバが集まれば、相当クオリティの高いソフトウェア開発ができるのではないか？と思う。ひとまずプログラマーであれば必携書になりそう。
• 設計やプログラミングで行き詰まった際に、アイディアをもらうための本として定期的に読み直したい。

メモ

第1章　前提〜プログラミングの変わらぬ真実〜

• プログラミングに銀の弾丸（Silver Bullet）はない
  • ソフトウェアは本質的に困難であるため、地道に複雑さを軽減するしかない
  • 出典書籍
    • 『人月の神話』Jr Frederick P.Brooks, 丸善出版(2014)
  • 関連書籍
    • 『ソフトウェア開発はなぜ難しいのか〜「人月の神話」を超えて』大槻繁, 技術評論社(2009)
    • 『ソフトウェア開発55の真実と10のウソ』ロバート・L・グラス, 日経BP出版センター(2004)

「銀の弾丸」はよく見かけるキーワードだが、出典を抑えられていなかった。後で読む本リストに追加。

• コードは設計書である
  • プログラミングは設計行為である。
    • 真のエンジニアリングのドキュメントと言えるものはコードだけ。
    • 設計行為の成果物であるコードは設計書である。
    • 一通りプログラミングが終わらないと上位の設計書が確定しないということは、プログラミングが設計のひとつであることを示している。
    • コードが設計なら、できるだけ早く書き始めるべき。コードを書かないと、不明確な部分だらけでいつまでも設計が終わらない。
  • 基本設計〜プログラミング〜テスト・デバッグまでが設計という不可分な作業であるため、これらを分担するのはうまいやり方ではない。
    • 優秀な設計者（＝プログラマ）が必要。
    • プログラマ全員が使用を作成し、コードを書かなければならない。
  • 出典書籍
    • 『アジャイルソフトウェア開発の奥義第2版オブジェクト指向開発の真髄と匠の技』ロバート・C・マーチン, SBクリエイティブ(2008)
  • 関連書籍
    • 『プログラマが知るべき97のこと』和田卓人他, オライリー・ジャパン(2010)

日本のSIerのSEにはクリティカルヒットするプリンシプル。コードを書けないなら「設計できる」とはいえないと言われているようでツライ。「設計〜プログラミング〜テスト」はすべて設計の枠組みのため、分担すべきでないという主張が出てくるが、これは大規模かつウォーターフォールの開発プロセスにおいても同じことが言えるのだろうか？出典書籍を見るにアジャイルを前提としているような気もするので、もう少し深掘りたい。

第2章　原則〜プログラミングのガイドライン〜

• YAGNI(You Aren’t Going to Need It)
  • コードは「たぶん必要になるだろう」「必要になるかもしれない」で書いてはいけない
  • 本当に必要になった時、必要なものだけを書く
  • 色々な事態に備えてコードを盛り込んでおても、結局利用されない
  • 結果、そのプログラミングの時間が無駄になる

これは頭の中ではなんとなく正しいと思っていたが、言語化されると納得感がある。一方で、改修を見据えてコードに拡張性をもたせるという考え方もあると思うので、そのバランスをどう取るべきかが気になった。少しググると「YAGNI 思考停止」とか出てくるので、そのあたりの解釈についての議論はありそう。

• PIE(Program Intently and Expressively)

  • コードは「書かれること」より「読まれること」の方がずっと多い。書くのは1回だが、その後たくさんの人が、たくさんの回数読むことになる。
  • よって、コードは「書く効率」より「読む効率」が優先される。読みやすければ、書くときの効率が多少落ちたとしても、それに見合う価値がある。
  • コメントには「Why」を書くこと。「What」と「How」はコードを読めばわかる（ようにする）。
  • 出典書籍
    • 『アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣』Venkat Subramaniam 他, オーム社(2007)
  • 関連書籍
    • 『プロジェクト・マネージャーが知るべき97のこと』神庭弘年他, オライリー・ジャパン(2011)

• タイトルに惹かれた読みたい本

  • 『プロダクティブ・プログラマープログラマのための生産性向上術』Neal Ford, オライリー・ジャパン(2009)
  • 『達人プログラマー—システム開発の職人から名匠への道』アンドリューハント他, ピアソンエデュケーション(2000)
  • 『まつもとゆきひろコードの世界.スーパー・プログラマになる14の思考法』まつもとゆきひろ, 日経BP社(2009)

第3章　思想〜プログラミングのイデオロギー〜

• アーキテクチャ非機能要件
  • ソフトウェアの目的は、機能を作ることではなくユーザが目的を果たせるようにすることであるため、非機能要件が大きな役割を占める

こちらも言われてみれば当たり前だが、経験上、機能要件に対して非機能要件は曖昧であったりスキが生まれやすい傾向にあるため、意識する必要があると再認識。

• 再利用性
  • ソフトウェア開発を効率よく、品質よくするためには「できる限り作らないこと」が重要。つまり、どこかから借りてくる。

便利なライブラリがあればそれを利用するという行為は通常無意識的に行っているが、効率・品質観点のメリットを考えるとより積極的にライブラリ活用を行なっていくべきだと思った。

• 7つの設計原理
  • 障害を作り込まないために考慮すべき、コード構造上の7つの核心観点のこと。
  • 以下の観点がある。
    • 単純原理
    • 同型原理
    • 対称原理
    • 線形原理
    • 明証原理
    • 安全原理
  • 出典書籍
    • 『ソフトウェア品質知識体系ガイド—SQuBOK Guide—(第2版)』SQuBOK策定部会, オーム社(2014)

コードレビューの観点としてある程度体系化されたものがあるというのは知らなかった。コードを書くときにも使えるので、頭の片隅に入れておきたい。

• UNIX思想
  • UNIX文化の中で育まれた、優れたプログラミングを行うための、経験に基づいた実践的な「技」の集合
  • 出典書籍
    • 『The Art of UNIX Programming』Eric S.Raymond, アスキー(2007)

初耳の概念だったが、読んでいる中で興味深いものがいくつかあったため、以下抜粋。

• 明確性の原則
  • コードを書くときにもっとも重要な観点は、コードを実行するコンピュータを相手にするのではなく、コードを読んで保守をするプログラマを相手にする。
  • コードは、人に対して読みやすく書かなければならない。
• 驚き最小の原則
  • インターフェースの設計では、意味もなく新奇なことをしたり、過度に巧妙なことをしたりすることは避ける。
  • 「一見似ているが微妙に異なる」ということを避ける。
• 経済性の原則
  • プログラマの時間を大切にする。ハードウェアが貧弱だったり、使用するソフトウェアに対して制限があったり、環境に関するルールや制限が厳しいとプログラマの時間を浪費してしまう。

よくあるのは、インターネットにおいて、開発に必要なサイトなのに、アクセスできない場合です。クラウドで稼働するソフトウェアが使用できないルールのところもあります。インターネット接続すら禁止されている場合もあります。しかし、そもそも、情報処理技術者から、情報を遮断してはいけません。

ハードウェアやソフトウェアの購入を抑制するのは、経費節減のためです。しかし、設備の費用とプログラマの費用は、比較にならないほど後者が高価です。設備に投資して、プログラマが効率よく、気持ちよく仕事ができれば、簡単に投資は回収できます。

なかなか面白い観点だし、日本の大企業のあるあるだったので深く頷きながら読んだ。

• 最適化の原則
  • 速いコードより正しいコード。正しく動作する前に最適化に走ることは、コードの設計を台無しにする。
  • 透明性や単純性が犠牲になったり、部分に対する半端な最適化が、全体最適化の妨げになる。
  • まず動かし、正しくしてから、速くする。
• データはテキスト
  • バイナリよりテキストファイルに保存する。
  • テキストファイルは、もっとも一般的で移植性が高い。人間がただちにデータを確認できる。ツールやコマンドが扱いやすい形式。

第4章　視点〜プログラマの観る角度〜

心に残った箇所は特になし

第5章　習慣〜プログラマのルーティーン〜

• プログラミングは急がば回れ

  • コスト削減のため、目的が適合しないのに既存システムをむりやり使う
    • 無理をしている以上、いずれ破綻する。作り直すコストを考えると、最初から正しい選択をすべき。

• 関連書籍

  • 『Java言語で学ぶリファクタリング入門』結城浩, SBクリエイティブ(2007)

第6章　手法〜プログラマの道具箱〜

心に残った箇所は特になし

第7章　法則〜プログラミングのアンチパターン〜

• ブルックスの法則
  • スケジュールが遅れているソフトウェア開発プロジェクトにおいて、遅れを取り戻すために後半に人を追加すると、さらなる遅延を招く
  • 「人」と「月」は交換不可能
    • 依存関係によるオーバーヘッド
    • 教育に時間をとられる
  • リスケジュールせよ

炎上プロジェクトあるあるそのまま。出典書籍の『人月の神話』は有名だけど未読。後で読む。

• コンウェイの法則
  • アーキテクチャは組織に従う
    • コンパイラを3チーム編成で作れば3パスの、4チーム編成で作れば4パスのコンパイラができあがる。
    • よいアーキテクチャを設計し、そのアーキテクチャに組織を合わせるようにするべき。

組織編成を先にしてしまいがちだが、アーキテクチャがある程度見えてから組織を編成すべきという話。

• 80-10-10の法則

  • ユーザの求めることの80%は驚くほど短時間で実現できる。
  • しかし、残りの20％のうち10％は相当な努力を必要とし、最後の10％は完全に実現が不可能
  • したがって、ユーザが100%を求めると開発が立ち往生してしまう。

• ジョシュアツリーの法則

  • 出典書籍
    • 『ノンデザイナーズ・デザインブック』Robin Williams, 毎日コミュニケーションズ(2008)
  • 関連書籍
    • 『教養としての聖書』橋爪大三郎, 光文社(2015)