「無人化システム」とメンタル・モデル

no extension

先週のことで恐縮だが

という記事が公開されていて,これを読んで思い出したのが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世紀なコードはもうケッコウである。

ブックマーク


  1. 勿論ちゃんとしてる企業もあるよ。コードを1行修正するのにも2重3重のレビューを行って,変更申請書が受理されないと変更できない,みたいなガチガチの企業もあったな。 ↩︎

  2. 「コードはもっと文芸的であるべき」というのはクヌース博士のいわゆる「文芸的プログラミング(literate programming)」とはちょっと違う。ごめんペコン。 ↩︎

  3. というか,これからの時代はリファクタリングに厚い言語を選択すべき。 ↩︎