読書メモ。2025年33冊目。
『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 』を読んでの感想となります。（2025/5/23記載）
本の概要
一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！
引用：
動機
- 前々から本書が気になっていたものの読む機会を掴めずにいた。
- 会社の３年目のエンジニアにおすすめ書籍があれば教えて欲しいと本書を紹介。
- どうせならチーム内で会話できればと自分や有志で読んで感想戦を！
感想
チームで開発をする上で、根底に持っておきたい考え方が凝縮された一冊でした。
9年前の書籍であるにもかかわらず、まったく古びていないのがすごいと思いました。
個人として改めて学び直す部分が多く、特にソースコードを書くことまでを設計として整理したり、ソースコードをコミュニケーションのためのドキュメントとして捉える視点は、もっと早くから意識すべきでした。
特にコミュニケーションについては、一人で開発することが多かったため、そうした観点をあまり意識してできえいなかったと感じました。
YAGNIやDRY原則、ヤクの毛刈りなど時々目にする言葉も改めて理解できてよかったです。
エンジニアとして3年目の段階でこの本の内容を充分に理解できなくても頭に置いておくことで、その後の成長に大きく影響するだろうと思える一冊でした。
若手エンジニアとの感想戦
本書を読んだ若手エンジニアとの対話がとても有意義だったため、その内容をメモとして残します。
若手エンジニアからコードが設計書であるのならば、一番最初に実装をやっても良いのではという疑問を頂きました。
我々のチームでは実装に入る前に受け入れテスト、結合テストの仕様書を書いていますが、それを省略しても良いのではという提案でした。
私からは、以下３点を伝えました。
・抽象度の高いPBIを対応するためには、実装に至る前に思考を整理する必要があること。
・思考の整理をドキュメント上で行うことにより、自分だけではなく第三者もその整理結果を見ることができること。
・作り方ではなく使われ方を先に考えることで、本来目指すべき実装の方向性を見失わずに済む。
ただし、現在のチームのドキュメントがその目的に対して完璧ではないかもしれないことや、必ずしもすべてのPBIに対して、思考を整理するプロセスが必要であるとは限らないことも併せて伝えました。
本で扱われている原則をもとにチーム内で建設的な議論で理解を深めることができました。
若手エンジニアが自分の学びからの発展を考えて議論してくれたことも嬉しかったです。
今後もこのような取り組みを継続していきたいです。
忘れたくないメモ
■プログラミングに銀の弾丸はない
ソフトウェアの本質は困難性ですが、その最たる要因は「複雑さ」にあります。ソフトウェア開発の歴史は、実は、複雑さとの戦いの歴史です。これまでに、複雑さに対抗する、様々なアイデアが生まれています。
偶有部分の改善の中で、特に大きな実績を上げてきたのが「自動化」です。テストやビルド、環境作成などを自動化して、作業効率や作業品質が大きく改善されました。 偶有的な部分を見つけたら、自動化して、本質的な部分にできるだけ時間を割けるようにしていきましょう。
「本質的な複雑性」と「偶有的な複雑性」について。
偶有的な複雑性による認知負荷を極力低減し避けることによって、本来向き合うべき本質的な複雑性に向き合える状態を作る。
■コードは設計書である
「基本設計」「詳細設計」「プログラミング」「テスト」「デバッグ」までが、設計という不可分な作業なら、それらの作業を分担するのは、うまいやり方ではないということです。つまり、プログラマ全員が仕様を作成し、コードを書かなければならないのです。設計図が自動でソフトウェアになるなら問題ありませんが、現実はそうなっていません。プログラミング言語に依存しない設計表記を、後で誰かにコードへ翻訳させるよりも、オリジナルの設計者がオリジナルのコードを書いた方がうまくいくのです。
設計書を書く人間と、実装を行う人間を分けてうまくいかなかった経験があります。
それは設計書というドキュメントからだけではものを作る上で考慮すべき仕様が充分には伝わらず、それが第三者にはドキュメントベースからでは受け取れないからだと思っています。
そして、一番重要なのはプログラムコードにユーザーが使いたいものが反映されることであり、そう考えるとオリジナルの設計者がオリジナルのコードを書いた方がうまくいくと思います。
■KISS
シンプルなコードは、構成する各要素がすべてシンプルで、各要素が担う責務が最小限に抑えられています。各要素同士の関連もシンプルです。よって、シンプルなコードは、読みやすく、理解しやすく、修正が容易です。各要素の責務が明確なので、テストもしやすくなります。コードを通じたプログラマ相互のコミュニケーションが楽になり、現実世界で余計な会話をしなくて済むので、コミュニケーションのコストも節約できます。開発速度を落とさずに、ソフトウェアの長期間に渡る保守が可能になります。
コードはドキュメントであり第三者が理解しやすいものであるべき。
チーム開発に必要なコミュニケーションは口頭でのコミュニケーションだけでなく、ドキュメントベースでのコミュニケーションも重視すべき。
■OCP
OCPの適用のポイントは、変更の内容を予測するというより、変化しそうな部分を予測することです
オープン・クローズドの原則(OCP)は、まだ作ることが決まっていない具体的な何かに対して行うのではなく、今後変化が想定される領域に対して適用されるべき。
■名前重要
名前は、コードを通じて、プログラマ同士がコミュニケーションするための最大の場となります。
コードを書いた人と読む人が同時にその場にいて、「リアルタイムの会話」ができることは稀です。たいていは「コードを通じての会話」となるので、名前が適切でないと、コード上の会話は成り立ちません。
このリアルタイムでないコミュニケーションを円滑にするため、名前には最大限の配慮がなされるべきです。
チームで共通認識を持って開発に取り組むためには認識を揃える必要がある。
具体のレベルから揃える。
■今いるところからチーム編成を調整する
ダイナミックリチーミングの大前提は、今いるところから始めることです。チームの構造を見える化しましょう。観察して、チームのことを知るようにしましょう。定期的にふりかえって、チームを調整することに合意しましょう。実験し、学習しましょう。それを踏まえて、チーム編成を調整します。チームを変えるツールとしてのレトロスペクティブについては、14章を参照してください。
チームを見える化し、調整できる状態を作ること。
そのうえで、レトロスペクティブで編成を調整していくこと。
改めて、スクラムはチームの共有モメンタムを醸成する仕組みであるとも理解しました。
■プログラミングセオリー
プログラミングセオリーは、コードの実装方法を選択する際、フォースとして使用されます。つまり、価値を「動機」とし、原則を「つなぎ」としながら、コードの実装方法を「解決策」として選択するのです。
TSKaigiでお聞きしたデザインパターンのお話もこれに当てはまる気がしました。
■コミュニケーション
コードで良好なコミュニケーションを取るには、コードを書いている時、他の人のことを考えるようにすることです。
最初は、どうしてもコンピュータに正しい処理を行わせることの方に意識が囚われてしまいます。そこで視点を切り替え、「他の人はこのコードを見てどう感じるだろうか?」と考えるようにします。すると、問題と解決策について、新たな視点から見直すことができます。
これは、コンピュータではなく、読む人のことを考えるという、いわば「思考の転回」です。コードには、「コンパイラやインタプリタへの入力である」という側面だけでなく、「人に見せる文章である」という側面があります。この後者を「コミュニケーション」として価値を置くようにしましょう。
使い方と使われ方と同じような話として理解しました。
プログラマーは機能を作ることばかりに集中すると、ユーザーがどう使うかの観点が希薄になってしまう。
なので、常にどう使われるかを意識して、開発を進める必要がある。
■宣言型の表現
宣言型のコードは、順序や条件分岐がありません。純然たる事実が宣言的に書かれているため、コードが読みやすくなります。
一方、命令型のコードは、常に「状態」と「制御」と「データのフロー」を頭に描かないと、事実を正確に理解できません。そのため、流れを追いながら読まなければならなくなります。
変数は最初に設定した値から変更するべきではないという話。
■コンテキスト
ソフトウェアがドメインから離れてしまったら、そのソフトウェアは、ドメインの 「問題を解決することができません。そもそもの存在意義がなくなってしまいます。それを避けるため、ドメインモデルの探求に全力を尽くし、できあがったドメインモデルからすべてを駆動していきます。そうすることで、ドメインを反映した、より価値の高いソフトウェアにすることができます。
どう作るか、よりも、何を何のために作るか、が重要。
副読資料
- 歴史上の賢者たちに学ぶ、開発者が“ともにつくる”ためのプリンシプル
- 工学の本質は“役に立つ”こと 共創型開発を実現するための6つのドクトリン
