第104条
プログラミングは理論の構築である
プログラムの設計は作った人たちの頭の中にあり、コードや文書が運べるのはその一部だけだ。だから作った人たちがいなくなると、文書がそろっていても、変更を重ねるうちに設計が崩れやすい。
心得
理由を言える人がいるうちが、保守できるコードだ
どうするか
システムの担当が替わるときは、重なる期間を取る。新しい担当が実際に変更を加え、前のチームがそれをレビューする。設計に逆らうパッチを前のチームが見つけなくなったら、引き継ぎを終える。生成コードや外注のコードをマージする前に、それを持つことになる人に、なぜこういう形なのかを説明させる。誰も説明できないなら、持ち主のいないコードとして扱う。チームがいなくなったプログラムについて、Naur は古いプログラムを捨てて新しいチームに問題を解き直させるよう勧め、そのほうが復活させるより高くはつかないとした。書き直せないなら、何かを組み替える前に、実際の変更をペアで進めて理論を組み立て直す。
なぜ起きるか
Peter Naur は、プログラミングとは主にプログラマが対象についての理論を組み立てることだと論じた。プログラムが現実のどこに対応しているか、各部分がなぜそうなっているか、新しい要求をどこにどう収めるか。その知識は人に残り、文書は「補助的で二次的な産物」にすぎない。Naur が挙げる例では、コンパイラを拡張することになった別のグループが、完全な文書、注釈つきのプログラム、設計の議論を書いたもの、原作者からの直接の助言まで受け取っていた。それでも彼らが出した修正案は、元の構造の力と簡潔さを「事実上壊す」パッチで、原作者のグループはすぐにそれを見抜いた。その後、原作者の助言なしに別の人たちが手を入れ続け、約10年後には元の構造は「まだ見えるが、さまざまな種類の無定形な追加によってまったく役に立たなくなっていた」。Naur の結論は「プログラムの死は、その理論を持つプログラマのチームが解散したときに起きる」であり、文書だけから理論を立て直すのは「厳密に不可能」だとした。チームの誰も筋道を追っていない生成コードを受け入れると、最初からこの状態に近くなりやすい。
当てはまらなくなるとき
合理的な設計を装う：Parnas と Clements は、設計を合理的に導いたかのように書き残し、変更のたびにその記録を最新に保つべきだと論じた。そうすれば新しく入った人は古いメンバーだけに頼らずにすむ。人の入れ替わりが多い職場では、誰が残るかに賭けるより、保たれた記録のほうが確かだ。
出典
Peter Naur『Programming as Theory Building』(Microprocessing and Microprogramming, 1985)。プログラミングを "a certain kind of insight, a theory, of the matters at hand" を組み立てる活動とみる見方、コンパイラの例、"The death of a program happens when the programmer team possessing its theory is dissolved."、文書からの復活が "strictly impossible" だという主張の出典。対抗原理は David L. Parnas & Paul C. Clements『A Rational Design Process: How and Why to Fake It』(IEEE Transactions on Software Engineering, 1986) から。"When new programmers join the project they do not have to depend completely on the old staff for their information." の出典。
原典を読む引用するとき
Hammurabi『第104条 プログラミングは理論の構築である』 https://kanywst.github.io/hammurabi/ja/laws/programming-as-theory-building/
BibTeX
@misc{hammurabi-programming-as-theory-building,
title = {プログラミングは理論の構築である},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 104},
url = {https://kanywst.github.io/hammurabi/ja/laws/programming-as-theory-building/}
}コラムで読む
- AI がコードを書くとき コラムの次：自動化の皮肉
- 古いコードとつきあう コラムの次：ハイラムの法則