- 2007年、2000行のコード

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• 1982年初頭、Lisaソフトウェアチームは、今後6か月以内にソフトウェアをリリースするための最終段階の作業に集中していた。

• 管理職の一部は、各エンジニアが毎週書いたコード量を追跡するのは良い考えだと思い、毎週金曜日に提出しなければならない書式を作成した。その書式には、その週に書いたコード行数を記入する欄が含まれていた。

• Quickdrawの作者であり、主要なユーザーインターフェースデザイナーでもあったBill Atkinsonは、コード行数はソフトウェアの生産性を測る愚かな方法だと考えており、それはただ雑然として水増しされた、バグのあるコードを書くことを助長するだけだと思っていた。

• Atkinsonは最近、Quickdrawの領域計算機構を最適化する作業をしており、より単純で汎用的なアルゴリズムを使って領域エンジンを完全に書き直した。いくつかの調整の後、この変更により領域処理はほぼ6倍高速になった。

• この書き直しの副次的な結果として、約2000行のコードを削減することにもなった。

• 最適化作業の仕上げ段階で、初めて管理書式を記入する時が来て、コード行数の欄に差しかかったとき、彼は少し考えたあと、-2000 という数字を記入した。

• 管理職たちがどう反応したのかは定かではないが、さらに数週間後、彼らはAtkinsonに書式の記入を求めるのをやめ、彼は喜んでそれに従った。

GN⁺の意見

• この記事は、ソフトウェア開発においてコード量が真の生産性を示すものではないという重要な教訓を与えている。コード行数を基準に成果を測ることは効率的でないだけでなく、ときには逆効果になり得ることを示している。
• Bill Atkinsonの例は、ソフトウェア最適化の重要性を強調している。より少ないコードでより高速な性能を達成することは、ソフトウェアエンジニアリングの中核原則の一つである。
• この話は、現代の開発プラクティス、特にアジャイル手法や継続的インテグレーション／デリバリー（CI/CD）のようなアプローチがなぜ重要なのかを理解する助けになる。これらの手法は、コード量よりも品質、保守性、そしてユーザー体験により大きな価値を置いている。
• 業界では、コード品質を測定し改善するためにさまざまなツールやメトリクスが使われている。たとえば、静的コード解析ツール、コードレビュープロセス、テストカバレッジの追跡などがある。
• この記事は開発者に対して、コード量よりも品質に集中し、不必要な複雑さを避け、性能を最適化することがどれほど重要かを改めて思い出させてくれる。

[GN⁺]

Hacker Newsの意見

• MicrosoftとIBMのコード行数をめぐる衝突

  • PBSのテレビシリーズ "Accidental Empires" には、スティーブ・バルマーがOS/2共同開発当時の経験を語る場面がある。Microsoftは小さな会社の姿勢で仕事を進めていた一方、IBMは内部的にコード行数（千行単位、KLoC）をプログラマーの生産性指標として重視していたという。バルマーは、IBMがコードの質より量にしか関心を持っていなかったと批判している。

• 過去の議論へのリンク

  • コード行数を生産性指標として使うことをめぐる議論はたびたび現れる。2010年から2022年までのさまざまな議論を示すリンクが提供されている。

• コード行数を生産指標にするのは非常に愚か

  • 1行のコードで20年来のバグを解決したり、order byで3年来のバグを解決した経験に触れ、1行のコードの影響をどう測れるのかという疑問を投げかけている。悪いプログラマーほど多くのコードを書くという経験も共有し、Microsoftの開発者がIBMの33,000文字のコードを220文字に書き直した事例を紹介している。その結果、Microsoftの仕事が「マイナス」と評価される状況が生まれたという。

• 単純な質問が時に最大の影響を持つ

  • ある機能をどう実装するかという単純な問い（「Xをどう扱うか？」）が、その機能を作らないという決定につながることがあり、それによって試すためのあらゆるコストを節約できる。こうした貢献は数値で測れず、時には敵を作ることさえあるが、それでもあえてそれを行う人々に敬意を表している。

• キャリア初期のコード最適化経験の共有

  • 10,000行を超えるCプログラムを500行未満に最適化した経験を共有している。前任の開発者は関数の使い方や、SQLクエリに変数データを渡す方法を知らなかったのではないかという単純な仮定のもと、同じSQL文を何度もインラインで書いていたことを発見したという。SQL呼び出しを関数呼び出しに書き換え、変更されるバインド値を配列から取得してループ内で関数を呼ぶ形にすることで、重複コードを置き換えた。

• プロジェクト開始時には明確な方向性が欠けることがある

  • プロジェクトを始める時点では正確な方向性が分からないことがあり、取り組むうちに問題と望ましい答えをより深く理解し、その結果として大きな部分を取り除いて、より小さく優れたものに置き換えられることがある。このような状況では、64KBのROMにすべてを収めなければならなかった開発者たちは、コードを小さくする強い圧力を受けていた。

• コード削除を指標にすることについての思考実験

  • 管理職がこの記事を読んで、単純に削除したコード行数を指標にすることを決めたら、状況は良くなるのか悪くなるのかという思考実験を提案している。

• ビル・アトキンソンのAtkinson Dither

  • ビル・アトキンソンと、彼のAtkinson Dither技法へのリンクが提供されている。

• コード行数に対する認識

  • コードを書く際に「追加した行数 - 削除した行数」を使うことへの疑問を呈している。同じ場所から始まり同じ場所で終わる10kmのランニングを0kmのランニングとは呼ばないように、コード行数も同じだという見解を示している。

• 従業員としての役割

  • たとえアインシュタイン並みに賢くても、依然として従業員であり、従業員としてやるべきことがあるという教訓を共有している。