Ask HN: ソフトウェア設計を学ぶのに最適なコードベースは何ですか？
(news.ycombinator.com)- ソフトウェア設計力を高めようとしていて、既存のよく設計されたコードベースを研究してみるとよいと勧められた
- 公開でアクセス可能なコードベースのうち、ソフトウェア設計のゴールドスタンダードと見なされているものが何か気になっている
1. おすすめのコードベース
- 大規模・代表的プロジェクト
- Git, Postgres, CPython
- Linux Kernel の "lieutenants model"
- UNIX v6, BSDs
- フレームワーク・ライブラリ
- Spring Framework
- Laravel
- Rust の std ライブラリ
- Codemirror 6
- システム・サーバー
- ゲーム・特殊事例
- 教育用・学習資料
- xv6 (MIT の OS 授業)
- pytudes (Peter Norvig)
- その他
- Monocypher (暗号ライブラリ)
- Tcl 言語実装
2. コードを読むこと vs 文書・設計の学習
- コードだけでは限界がある
- コードベースは実装を見せてくれるが、設計意図やトレードオフは隠れている
- 設計文書の重要性
- ADR(Architectural Decision Records)、Rust RFCs、Python PEPs のような意思決定の記録は、設計学習においてはるかに有益
- 設計文書を書くこと自体が訓練になりうる
- 書籍・文献のおすすめ
- The Architecture of Open Source Applications
- Code Reading (Spinellis)
- Beautiful Code (O’Reilly, ISBN-10: 0596510047)
- Refactoring / Legacy Code 関連書籍
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)
- HN では同じテーマが何度も扱われている
コード vs 設計文書 (alphazard)
- コードベースは 実装の成果物 にすぎず、設計そのものではない
- 設計学習には 設計文書を書くこと のほうが効果的
- 文書は、他の人がそのまま実装できるほど明確であるべき
- 代替案を列挙し、なぜ除外したのかを記録すれば 設計上の検討を行った証拠 になる
- 良いデザイナーとは、より広い設計空間 を考慮し、適切な地点を選べる人のこと
システム全体の理解の重要性 (RossBencina)
- コードベース全体を理解する過程は非常に価値がある
- 単によく設計されたコードを見るだけでなく、システムの全体像 を捉える訓練にもなる
- UML などの図を使って関係を可視化すると役立つ
- 学習アプローチ:
- 自分が開発中のものに近いソフトウェアのコードを読むのが効果的
- すでによく知っているドメインのコード(Web フレームワーク、Web サーバー、Python 標準ライブラリ、VSCode など)を出発点にするのがおすすめ
- 最初は小さなプログラムや、馴染みのあるドメインから始めるのがよい
良い設計の基準 (mamcx)
- 良い設計とは 目標とアイデア であり、コードベースはその 実装の程度 を示す
- 良い設計は単に「速い、安全だ」といった形容ではなく、具体的な検討事項とトレードオフの記録 を含むべき
- 例: Erlang、初期 Pascal、多くの RDBMS 設計にそうした特徴が見られる
- Rust の std ライブラリ はセキュリティと一貫性を重視し、コードと文書がそれを忠実に反映しているため、良い学習資料である
目に見えない設計判断 (ben30)
- よく設計されたコードベースを見るとき、最も重要なのは目に見えない部分 である
- 複雑性の排除、不要な抽象化を避けること、特定パターンを採用しないことといった 不在の決定 が重要
- これを補うために ADR(Architectural Decision Records) を活用する
- 代替案とその不採用理由、選択根拠を記録して文脈を残す
- 将来のメンテナーや AI ツールの双方に大きく役立つ
- 学習時には、単なるコードだけでなく ADR・RFC・PEP などの設計意思決定文書が揃っているプロジェクト を見るのが効果的
5件のコメント
express.js を作った TJ Holowaychuk のコードベースは、Evan You（Vue.js、Vite の作者）がクリーンで美しく設計されているとインタビューで話していたので、何度かコードリーディングしてみた。全体像までは理解できなかったけれど、全体的にコードは複雑ではなく、すっきりしていて、本当に必要なロジックだけで書かれているという印象を強く受けた。
コメントも丁寧についていて、10年前のコードではあるものの、型推論や DTO のフォーマットを把握するのにとても良かった。
スパムコメントだらけのブログの2009年の記事を参考にするなんて..
Hacker Newsの意見
自分だけかもしれないが、実際に何度も問題にぶつかり、どう回避するかを自分で身につけていくやり方が一番効果的だと感じる。そうしていくうちに、今後どんな問題が起きそうかを頭の中で自然にシミュレーションできるようになり、結局デザインというのも、さまざまな将来の問題を事前に予測して避けること、どの問題をどれくらいの労力で回避するのか、1つのデザインで複数の問題を解決できるのかといったトレードオフを慎重に見極める判断なのだと思う
私も同じだ。「練習問題を解く」とか「コードベースを勉強する」といったやり方は自分には合わなかった。本当に興味のあるものを作っていく中で、手本に対して正確さと丁寧さを追求しながら自然に学んできた。ただ、まだ自分の実力が足りないと感じることもある。まるで本を読むようにコードをすらすら読めて、その動きが頭の中に描けるなら、勉強そのものももっと楽しくなるだろうと思う
何度も問題にぶつかりながら学ぶという話を聞いて感じるのは、ソフトウェア工学という分野がまだ成熟していないということだ。もし橋や家をそんなふうに建てるとしたらどうだろう、あるいは外科医がそんなふうに訓練されるとしたら、と想像するだけでも危うい。いずれ標準や規範が定着していくだろうが、今はまさに流動的な状況だ。ソフトウェアエンジニアを5人集めて問題を提示すれば、5つのまったく異なる解決策が出てくるだけでなく、どの方法が正しいかで強く対立することすらある。「良い解法は見ればわかる」という態度だけでは、まともなエンジニアリングにはならないと思う
私もこれまでずっとこのやり方で学び続けてきたし、これからもそうすると思う。実際のプロダクションコードから学ぶのは自分にとって新しい挑戦になりそうだ。どれほど価値があるかはわからないが、とにかく面白そうではある
それは、運転教習を最初に車に乗って事故を起こし、そのあと反省して次は事故を起こさないように運転してみる、というのに近いと思う。実際にはこの2つの方法がどちらも必要だ。一般道の運転では限界を超える状況がほとんどないのでそのまま応用しにくいが、レースのような場では、どこまで攻められるのかという限界線を正確に知っておくことが不可欠だ。もちろん自分たちの仕事を競技のように扱う必要はないと思う。だが本を読まず勉強もしなければ、文字どおり非常に長い時間がかかるだけでなく、事故や故障も絶えないだろう。だから私は、とにかく読んでまた読めと言いたい。その必要性を今すぐ感じなくても、後になって経験を積む中でその知識は必ずどこかで役に立つし、長い下り坂でエンジンブレーキを使うために低いギアへ落とす必要を初めて知ったときのように慌てずに済む
これこそが核心だ
この質問を聞いて最初に思い浮かぶのは「チームのコードベース」だ。実際の問題に対して、良い解法と悪い解法がそれぞれなぜ採用されたのかを深く理解すること以上に、ソフトウェアデザインを効果的に学ぶ道はない。ソフトウェアとは本質的に、ユーザー要求と機械の動作のあいだをつなぐ複雑な中間層そのものだ。もしこの混沌がなければ、すでに自動化されていて、ソフトウェア自体が不要になっていたはずだ。ソフトウェアでは、何らかの理想形だけを追い求めるとかえって悪い意思決定をしがちだ。実際には、「なぜこうした圧力によって特定の選択がなされたのか」を理解することで試行錯誤を減らせる。同時に、速く効果的に働くための実践的な方法論も身につけなければならない。現実で最大の課題は時間制約だ。これは理論的なソフトウェア設計ではほとんど扱われないが、現実には常にコードを早く出さなければならないという圧力の中で作業することになる。やりたい方法や最善のやり方に割ける時間が足りないことも多い。良いソフトウェアとは、ユーザーの実質的なニーズを解決するソフトウェアだ。これからも成功する実行をより多く生み出すデザイン解法は存在するだろうし、それを見つける最良の道は、自分が実際に書いているコードを深く見つめることだ
もし質問者が、自分のチームのソフトウェアがひどいと感じていて外部の助言を求めている場合はどうだろう？ あるいは単に大学生が質問しているだけなら？
実装に必要な時間もデザインの品質を判断する尺度になりうるというのは考えたことがなかったが、本当にもっともだと感じる。私も自分のチームのコードベースからものすごく多くを学んでいる。その大半は、優れた設計から良い点を学ぶことと、そうでない部分については自分でググりながら学び続けることだ
数年前の資料ではあるが、多くのオープンソースプロジェクトのリーダーたちが寄稿した「The Architecture of Open Source Applications」シリーズがあり、オンラインで無料で読める
https://aosabook.org/en/index.html
この質問はすでに何度も出ているので、参考になるリンクをまとめておく
Yanderedevのソースコード
正解を語れるほどの資格が自分にあるとは思わないが、15年ほど前に「Code Reading」という本をとても面白く読んだ。この話題にぴったりの本だ
https://www.spinellis.gr/codereading/
目次はこちら: https://www.spinellis.gr/codereading/toc.html
似た名前の本もあった気がするが、正確には覚えていない
実際のところ、コードベースに含まれているのはデザインより実装であることのほうが多い。たとえば別の言語へ全面的に書き直しても、デザイン自体は維持できるかもしれない。デザイン文書を書く練習を勧めたい。文書の見た目がどうあるべきかは気にしなくていいし、テンプレートに縛られる必要もない。何より重要なのは、その文書を受け取った別の人がそのまま実装できることだ。そしてその文書自体が「検討の記録」として機能しうる。どの方式を選び、どんな代替案があり、なぜそれを採用しなかったのかを明確に残せばいい。あらかじめ代替案を認めて比較しておくことで、読み手に十分に考え抜いたという信頼を与えられる。「良い」システム設計者がしていることは、他の人よりも広いデザイン空間を見渡し、一貫して良いポイントを見つけ出すことだ。問題を1つ選び、さまざまなデザイン空間を試し、その中でどれがより良いのかを理由付きで説明して記録すればよい
まず最初に「自分が解こうとしている問題は何か？」という問いから始めるべきだ。その問題を解決したコードベースを見つけて、実際にどう実装しているのかを集中的に分析する。良いデザインは特定のドメイン状況と非常に密接に結びついていることを忘れてはならない。WonhamのInternal Model Principleはコードにも当てはまると思う。たとえば、組み込みターゲット向けの単体テストの問題を解決したくて関連するオープンソースプロジェクトを分析し、それぞれのコードがなぜそのように書かれているのかを批判的に見てきた。自分自身のソリューションを作りながら、再び以前のコードを参照しつつ、自分のドメイン理解が深まるほどより多くを学べている
私の経験（ソフトウェア30年、アーキテクチャ実務25年、MITシステムアーキテクチャ修士）では、抽象的に「良い」デザインというものはそもそも存在しない。明らかに悪い設計（悪い結果を招くデザイン）はあるが、「良い」の基準は文脈によって変わる。何を作るのか、安全性やセキュリティなどの要件、そして何より実装するチームとその構造が最も大きく影響する。ジュニアだけのチームでは、精巧な設計を誤解して台無しにしてしまうかもしれない。Conwayの法則が示すように、開発チームの構造はそのままソフトウェアに反映されるのだと思う
ソフトウェアデザインを学ぶ中で確かに気づいたのは、万能の答えはないということだ。そんなものがあればどれほどいいかと思うが、さまざまなアーキテクチャやパラダイムの中から最適解を選ぶのはもどかしいこともある。それでも要件をきちんと反映すれば、選択肢はかなり絞られる。今は特に安全性が重要な組み込みシステムを扱っていて、この環境のせいで、ほかの状況ではまったく使わないような決定をしばしば下すことになる
結局のところ核心は、本当にひどい妥協案を避け、最悪の選択肢も広い視野で見れば避けていくことだ。現場でいつも感じるのは、最高のアーキテクチャを目指すというより、「根本的に悪い決定を避ける」ための絶え間ない戦いだという点だ
以前、とてもシンプルなおすすめリストを作ったことがあり、今でも有効だ
https://medium.com/@012parth/what-source-code-is-worth-studying-8755f88f8de5
途中に落とし穴が…。
YandereDevのソースコードですかね……ｗ