- ソフトウェア設計力を高めようとしていて、既存のよく設計されたコードベースを研究してみるとよいと勧められた
- 公開でアクセス可能なコードベースのうち、ソフトウェア設計のゴールドスタンダードと見なされているものが何か気になっている
1. おすすめのコードベース
- 大規模・代表的プロジェクト
- Git, Postgres, CPython
- Linux Kernel の "lieutenants model"
- UNIX v6, BSDs
- フレームワーク・ライブラリ
- システム・サーバー
- ゲーム・特殊事例
- 教育用・学習資料
- その他
2. コードを読むこと vs 文書・設計の学習
- コードだけでは限界がある
- コードベースは実装を見せてくれるが、設計意図やトレードオフは隠れている
- 設計文書の重要性
- ADR(Architectural Decision Records)、Rust RFCs、Python PEPs のような意思決定の記録は、設計学習においてはるかに有益
- 設計文書を書くこと自体が訓練になりうる
- 書籍・文献のおすすめ
3. 実践中心の学習論
- 経験と試行錯誤
- 設計は、問題を繰り返し経験し、それを避ける方法を学ぶ中で身につくもの
- コードを読むだけでは学べず、自分で書いて失敗を解決する過程で学ぶ
- 興味ベースの学習
- 自分が興味を持てるプロジェクトを作ってこそ深く学べる
- 失敗コストが低いという特性
- ソフトウェアは物理エンジニアリングより失敗コストが低く、試行と失敗を通じた学習が効果的
4. ソフトウェアエンジニアリングの性格をめぐる論争
- 未成熟な工学だという見方
- 5人のエンジニアが集まれば5通りの異なる解法が出てくるのは、工学として未成熟である証拠だという見方
- 実験と相性がよいという見方
- ソフトウェアは制約が少なく多様な解法が存在し、物理工学のように正解が固定されていない
- 芸術と工学の境界
- 設計は美的要素を持つ芸術的行為でもあるが、機能要件を満たすという面では工学でもある
- ソフトウェアは芸術的な柔軟性とエンジニアリングの厳密さのあいだに位置している
5. 代替的な学習方法
- 悪いコードの分析
- よく設計されたコードだけでなく、質の低いコードベースを直してみることにも大きな学習効果がある
- 自分のコードベースから学ぶ
- チーム内部のコードベースこそ、最も多くを学べる資料として挙げられている
- ただし、チームのコードが粗い場合は外部事例も併用する必要がある
- ドメインに合わせた学習
- 自分が解きたい問題に近いコードベースを読むのが最も効果的
主なインサイト
- よく設計されたコードベースは役に立つが、学習は設計意図の理解と試行錯誤を並行して進める必要がある
- コードを読むこと自体より、設計文書と意思決定の記録が中核的な学習資料である
- 代表的な高品質プロジェクト(Git, Postgres, CPython, Rust std など) は学習価値が高い
- 良いコードだけでなく、質の低いコードや自分のコードから学ぶことのほうが長期的にはより実践的
主なコメントまとめ
代表的コードベースのおすすめ (CraigJPerry)
- Postfix mail server
- セキュリティ重視のアーキテクチャで、マイクロサービスという概念以前からすでに似た構造を示していた
- 現代のマイクロサービスが大規模組織の分散に重点を置くのに対し、Postfix は セキュリティと単純さ のために設計されている
- Spring Framework
- エンタープライズ環境の Java 開発者の要求を深く考慮した文化が反映されている
- ユーザー中心の設計アプローチを学べる
- Git
- オブジェクトデータベース(blob、tree、commit) と reference の概念を理解すれば、残りは段階的な拡張になっている
- 中核概念の一貫した拡張 が良い設計例として挙げられている
- Varnish
- 高性能なリバースプロキシでありながら、学習用ツールとして使えるほどよく構成されたコードベース
- Linux Kernel Lieutenants Model
- コードベースではないが、大規模ソフトウェア管理モデル として参考にする価値がある
- 単なる「よく設計されたコード」ではなく、設計上の意思決定が強い印象を残す事例として挙げられている
実務コードベース学習の強調 (crystal_revenge)
- 最も大きな学習価値は 自分のチームのコードベース から得られる
- 実際の要求と実装のあいだにある 混沌としたつながりの過程 で、良い選択と悪い選択の両方を経験できる
- 現実的な制約の中で最大の要素は 時間的プレッシャー であり、理想的な設計と現実のあいだでバランスを取ることを学ぶのが核心
- 良いソフトウェアとは ユーザー要求を解決すること であり、反復経験を通して成功確率を高める設計を学ぶことになる
過去の議論と資料リンク (sprobertson)
コード vs 設計文書 (alphazard)
- コードベースは 実装の成果物 にすぎず、設計そのものではない
- 設計学習には 設計文書を書くこと のほうが効果的
- 文書は、他の人がそのまま実装できるほど明確であるべき
- 代替案を列挙し、なぜ除外したのかを記録すれば 設計上の検討を行った証拠 になる
- 良いデザイナーとは、より広い設計空間 を考慮し、適切な地点を選べる人のこと
システム全体の理解の重要性 (RossBencina)
- コードベース全体を理解する過程は非常に価値がある
- 単によく設計されたコードを見るだけでなく、システムの全体像 を捉える訓練にもなる
- UML などの図を使って関係を可視化すると役立つ
- 学習アプローチ:
- 自分が開発中のものに近いソフトウェアのコードを読むのが効果的
- すでによく知っているドメインのコード(Web フレームワーク、Web サーバー、Python 標準ライブラリ、VSCode など)を出発点にするのがおすすめ
- 最初は小さなプログラムや、馴染みのあるドメインから始めるのがよい
良い設計の基準 (mamcx)
- 良い設計とは 目標とアイデア であり、コードベースはその 実装の程度 を示す
- 良い設計は単に「速い、安全だ」といった形容ではなく、具体的な検討事項とトレードオフの記録 を含むべき
- 例: Erlang、初期 Pascal、多くの RDBMS 設計にそうした特徴が見られる
- Rust の std ライブラリ はセキュリティと一貫性を重視し、コードと文書がそれを忠実に反映しているため、良い学習資料である
目に見えない設計判断 (ben30)
- よく設計されたコードベースを見るとき、最も重要なのは目に見えない部分 である
- 複雑性の排除、不要な抽象化を避けること、特定パターンを採用しないことといった 不在の決定 が重要
- これを補うために ADR(Architectural Decision Records) を活用する
- 代替案とその不採用理由、選択根拠を記録して文脈を残す
- 将来のメンテナーや AI ツールの双方に大きく役立つ
- 学習時には、単なるコードだけでなく ADR・RFC・PEP などの設計意思決定文書が揃っているプロジェクト を見るのが効果的
まだコメントはありません。