AI ファースト開発、コーディングガードレール、使い捨て前提のアーキテクチャを探求します。
すべてのコンパイラはコードをツリーとして見ているが、エディタは生のテキストを編集させる。構造化編集が実際にどう見えるか、なぜ普及しなかったか、そしてツールを変えずにその利点を取り入れる方法を解説する。
すべてのプログラミング言語には正式な文法がある。コンパイラはそれを読み取り、parse tree を構築し、合わないものをすべて拒否する。エディタは文法を完全に無視して、ユーザーが何でも入力できるようにしている。 その乖離は、驚くほど多くの摩擦の源だ。Autocomplete は文脈的に意味をなさない…
Literate programmingは、コードは人間のために先に書かれ、機械のために次に書かれるべきだと約束した。40年後、ほとんど誰もそのように書いていない。なぜソフトウェア文書化における最もエレガントなアイデアが、私たちの働き方を変えられなかったのか。
1984年、Donald Knuthは根本的な転換を提案する論文を発表した。プログラムはコンパイラのために書き、人間のために注釈をつけるべきではない。プログラムは人間のための文学として書かれ、そこからコンパイラが実行可能な部分を抽出すべきだ。彼はこれをliterate…
ほとんどのチームは欠陥を修正して先に進む。同じ欠陥が戻ってくる。フェイガン検査の中で因果分析を実行し、同じバグを二度書かないようにする方法を解説する。
どのチームにも、何度も繰り返し出現する欠陥がある。ページネーションのオフバイワン。認証ミドルウェアの欠落したnullチェック。三スプリント前に誰かが「修正した」チェックアウトの競合状態。 同じバグを三回書いたわけではない。同じ原因を持つ三つの異なるバグを書いたのだ。修正は症状に対処した。原因は隠れたままだった。…
IBM、AT&T、HP、Microsoftを対象とした複数の研究により、非公式なコードレビューが欠陥の約4分の1を検出することが確認されている。データが実際に示していること、その数値が低い理由、そして改善方法を解説する。
非公式なコードレビューは、レビュー対象コードに存在する欠陥の15〜30%を検出する。これは意見ではない。40年以上、複数の企業、数十の研究を通じて再現された知見だ。…
大半のレビューチェックリストは、善意のコピペリストに過ぎない。Fagan inspectionスタイルの構造化チェックリストは、実際の欠陥データから構築され、特定のアーティファクトタイプを対象とし、個人の準備段階で使用される。機能するチェックリストの構築方法は以下の通りだ。
チームにコードレビューのチェックリストがあるなら、誰も開かないWikiページに埋もれている可能性が高い。おそらく「check for off-by-one errors」や「verify error handling」といった内容が書かれている。これらは真実だ。しかし、行動を変えるにはあまりにも曖昧すぎる。…
フェイガン査読は250行をレビューするのに4〜6人と2時間を要する。大規模言語モデルは準備作業とチェックリストの遵守を担うことでそのコストを削減できるが、最も高価な欠陥を見つける人間の役割は代替できない。
本格的なフェイガン査読には、進行役、読み手、2〜4人の査読者、そして著者が必要だ。チームは1時間あたり125行のペースで、おおむね250行のコードを2時間かけてレビューする。小さな変更でも、8〜12人時の工数がかかるのだ。…
IBMでMichael Faganが開発した構造化レビュー・プロセスは、コードがコンパイラに到達する前にほぼすべての欠陥を捉えていた。しかし、その代償として総プロジェクト工数の15〜20%を消費していた。ソフトウェア史上もっとも効果的だったこのレビュー手法がなぜ消えたのか、そしてチームが実際に失ったものは何か。
1976年、Michael FaganはIBM Systems Journalに論文を発表した。そこに記されたレビュー・プロセスは、ソフトウェア品質のゴールドスタンダードとなるほど効果的だった。Fagan…
シニアエンジニアであっても、非構造化のレビューで欠陥のごく一部しか検出できない。Michael Fagan のIBMにおける研究がその理由を示し、構造化されたインスペクションプロセスを構築して修正した。
二人のシニアエンジニアが同じプルリクエストをレビューする。片方が欠落している null チェックを指摘する。もう片方がクリーンアップパスでの競合状態を発見する。どちらも両方を見つけられない。…
非公式なコードレビューは欠陥の15〜30%を見つける。50年前に確立された構造化プロセスであるFagan Inspectionは、一貫して60〜90%の除去率を報告している。その仕組み、チームが避ける理由、そして軽量版の実行方法を解説する。
ほとんどのコードレビューは、本来見つけるべき欠陥の15〜30%しか捉えられない。これは憶測ではない。IBMが1970年代に測定し、AT&T、HP、Microsoftでの研究が何十年にもわたって同じ範囲を確認している。…
AutoVerusはLLMエージェントのネットワークを用いてRustコードのVerus正しさ証明を生成し、SMTソルバーのフィードバックによって駆動される生成・修復・ dischargeループにより、90%以上の証明義務を自動化する。
形式的検証で最も難しいのは、検証器そのものではない。証明を書くことだ。 熟練のRustエンジニアにMicrosoft…