「無人化システム」とメンタル・モデル
先週のことで恐縮だが
という記事が公開されていて，これを読んで思い出したのが20世紀に参加した某プロジェクトでの世間話。
もう四半世紀前のうろ覚えでしかも
というわけで COBOL プログラマはきっと「まだだ！ まだ終わらんよ！」と思っているだろう（笑）
「無人化システム」
一方，上の記事が出る少し前に
というのが Zenn で公開されていて，あまりの納得感に
システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでいます。
無人化システムは「誰も詳細は知らないが、なぜか動いているシステム」です。
と定義しているようだ。
「傭兵」時代は「汎用機＋COBOL」からのリプレイス案件を時々受けていたが，何が困るって，ドキュメント化されない「誰も知らないコード」が平気で紛れ込んでいて1，しかもそのコードに手を出すとどんな影響が出るか予測できないという事態にホンマに困っていた（あと，どうやっても正規化できないデータベースとかw）。
まっ，要するに，時代や言語に関係なく，この手の話は割と普遍的に観測できるということなんだろう。
メンタル・モデル
2017年に公開された記事だが
というのを最近読んだ。 特に Go でコードを書く人はこの記事は必読だろう。
いくつか拾い読みしてみる。
A consistent use of value/pointer semantics, for a given type of data, is critical if you want to maintain integrity and readability throughout your software. Why? Because, if you are changing the semantics for a piece of data as it is passed between functions, you are making it difficult to maintain a clear and consistent mental model of the code. The larger the code base and the team becomes, the more bugs, data races and side effects will creep unseen into the code base.
Tom has also mentioned that a box of copy paper can hold 100k lines of code. Take a second to let that sink in. For what percentage of the code in that box could you maintain a mental model of?
“The hardest bugs are those where your mental model of the situation is just wrong, so you can’t see the problem at all” - Brian Kernighan
これ以降は Go をターゲットにした具体的な話に入っていくのだが，これが Go に限る話ではないということはお分かりいただけるだろう。
プログラマにとって最も信頼できるドキュメントは動いているプログラムコードである。 だからこそコードは「文芸的2」であるべきだし，プログラマは要件定義の段階から積極的にコードを書くべきだと思う。 リファクタリングは何時でもできるのだから3。
書いた人にしか分からない20世紀なコードはもうケッコウである。