GitHub Copilotの新研究、「コード品質への下方圧力」を発見
(visualstudiomagazine.com)- GitClearの Coding on Copilot ホワイトペーパーは、AI支援コードが生産性を高める一方で、品質や保守性に負担を与え得るかをコード変更データから分析している
- 作成後2週間以内に差し戻しまたは修正される コードチャーン は、AI以前の2021年のベースラインと比べ、2024年には2倍になると予想されている
- Copilotの普及後、追加コード と コピー＆ペーストされたコード の割合が増え、移動されたコードの減少はリファクタリングと再利用の弱まりを示唆している
- GitHubの2022年の研究では、Copilot利用者は作業を 55%速く 完了したとされたが、GitClearは生産性よりも長期的な保守コストに焦点を当てている
- 2020年1月から2023年12月までに作成された 1億5,300万行 の変更コード分析は、技術リーダーがAI導入の効果をコード品質指標で評価すべきであることを示している
GitClearのホワイトペーパーが見たAI支援コードの性質
- Coding on Copilot ホワイトペーパーは、AI支援コードが人間が書いたであろうコードと比べて、品質 と 保守性 の面でどのような違いを示すかを調査している
- 中心となる問いは、AI支援コードが慎重に磨き込まれたシニア開発者の貢献に近いのか、それとも短期契約者による断片的な作業に近いのかという点である
- GitClearはクラウドベースの コードレビュー ツール を販売する企業であり、今回の研究はAI利用後にコード変更の構成がどのように変化するかに焦点を当てている
保守性に表れたネガティブな兆候
- GitClearは保守性の面で懸念される傾向を発見した
- コードチャーン は、作成後2週間以内に差し戻しまたは更新されるコード行の割合である
- この割合は、AI以前の2021年のベースラインと比べて、2024年には2倍になると予想されている
- 追加コード と コピー＆ペーストされたコード の割合は、修正・削除・移動されたコードに比べて増加している
- こうした変化により、AI生成コードは訪問先リポジトリのDRY原則を破りやすい巡回的なコントリビューターに似ていると評価されている
Copilotの普及と結び付いた3つの変化
- GitClearは、Copilot導入後の重要な変化として チャーン、移動されたコード、コピー＆ペーストされたコード を挙げている
-
増加するチャーン
- 「Copilotの利用」は、リポジトリに 誤ったコード がプッシュされることと強く相関していると見ている
- AI支援コードが急速に追加された後、短期間のうちに差し戻しまたは修正される流れと結び付いている
-
減少する移動コード
- 移動されたコードの減少は、リファクタリング と 再利用 の減少を示唆している
- コピー＆ペーストされたコードの増加と合わせて見ると、現在のAIアシスタント実装はコード再利用を十分に促していないと解釈される
- リファクタリングによってDRYなコードを作るよりも、既存コードを1回のキー入力で繰り返す誘惑を与えている
-
増加するコピー＆ペーストされたコード
- コピー＆ペーストされたコード は、長期的な保守性に大きな負担を与える要素と評価されている
- キーワードではなくコード行が繰り返される場合、以前の実装を評価する時間がなかったことのサインと解釈される
- コードを再利用せずに再び追加すると、その後の保守担当者は重複機能を実装した並列のコードパスを統合しなければならない
生産性研究との対比
- GitHubの2022年の研究では、Copilotを使用した開発者は、使用しなかった開発者よりも作業を 55%速く 完了したとされた
- 同じ研究では、生産性以外にも開発者満足度と精神的エネルギーの温存におけるポジティブな効果が測定された
- GitClearのホワイトペーパーは、こうした生産性の結果とは異なり、AI利用時のコード変更の構成と保守性面の変化を中心に分析している
関連研究が示した入り混じった評価
- Exploring the Verifiability of Code Generated by GitHub Copilot: Copilotは強力なツールだが、単独で「飛行機を操縦」すべきではないという既存文献の合意に沿う証拠を見いだした
- Assessing the Quality of GitHub Copilot's Code Generation: 実証分析の結果、Copilotは有望なツールだが、今後さらに包括的な評価が必要である
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: 生成AIへのプロンプト作成に熟達するにつれ、人間とAIの間に独特で切り離しにくい結び付きが形成される
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: 観察された異質な効果は、AIペアプログラマーが人々のソフトウェア開発キャリアへの転向を助ける可能性を示している
- Study of software developers' experience using the Github Copilot Tool in the software development process: 開発者の意見は分かれ、態度は概ね肯定的だったが、実際の利用意向は高くなく、セキュリティ問題が懸念として表れた
分析範囲と残された問い
- GitClearは、2020年1月から2023年12月までに作成された 1億5,300万行 の変更コードを収集・分析した
- AI人気の急上昇により、コード行がこれまで以上に速いペースで追加される時代に入ったという診断も併せて示されている
- 2024年の問いは、Copilotが開発者の意味をどう変えるかというより、その後に発生する整理作業を誰が担うのかに近い
1件のコメント
Hacker News の意見
2か月使って購読をやめた。大量に出てくるコードの吐しゃ物のミスを直す精神的コストが大きすぎたし、些細ではない作業や SQL 関連の作業では、スキーマ全体を先に入れてもほとんど役に立たなかった。
自分が何を書きたいのかは分かっているので、自分で書くほうがはるかに楽だったし、ボットのミスより自分のミスを直すほうが簡単だった。このゴミに埋もれるジュニアたちが心配だ。
Copilot の代わりに ChatGPT を使っているが、できることの多さには驚かされる。それでも「良いコード」と呼ぶのは難しい。JavaScript は読めるが、この14年間は iOS を専門にしてきたのでブラウザ側のベストプラクティスには詳しくなく、その用途で使っている。おおむね動くコードは得られるものの、悪い選択や変な点は見える。
現在の AI については、「もう終わった」でも「何でもない」でもない、両極端を避ける姿勢が正しいと思う。後者に対しては、「犬がジャグリングして、税務申告して、ケーキを焼いているのに、それができることに感心するより、ボールを落とした、数字を間違えた、レシピがいまいちだと文句を言っているようなもの」という比喩が必要だ。
Copilot は、予測しやすい文脈ベースのコードを書くときにタイピングを減らしてくれる自動補完ツールとして最も有用だ。あるウィンドウで enum class を書くと、別のウィンドウの使用箇所を文脈に基づいて自動補完できるし、単体テストのまとまりを書くときは Tab 1回で次のテストケースの骨組みを作ってくれる。
特に動的言語では、Copilot は IntelliSense をかなりうまく補完してくれる。
数か月前、声優業界がテキスト読み上げモデルに押し出されざるを得ない流れについて、組版、製本、楽譜浄書の例とあわせて書いたことがある: https://news.ycombinator.com/item?id=38491203
ただ、開発そのものがこのように空洞化した場合、最終状態が何なのかよく分からない。過去の置き換えを推し進めてきたのも開発者だったからだ。何らかの社会的衰退や崩壊という形も、まったく荒唐無稽とは思えない。
「この JSON をパースして、そのフィールドをデータベース内の適切な場所に入れて」は、Copilot で SQL を書かせるうえで素晴らしいユースケースだ。ORM プラグインやミドルウェアを使うこともできるが、MVP やモックアップでは、それは過剰な先行最適化だ。
一方で ChatGPT API はよく使っていて、かなり便利だ。数百万行に触れる SQL update を書いたとき、バッチ単位に分けて各バッチ後に状態ログを出すよう変えてほしいと頼んだし、Azure DevOps の nuget feed へのアクセスで 401 が出たときは、原因だけでなく修正用の yaml まで出してくれた。
どちらも少し調べれば自分でできることだが、その調査時間を使わなくて済むのが本当に良い。
GPT-4 のおかげで仕事の効率が大きく上がった。主に日常業務の問題を解決する単純な PHP CRUD アプリを作っていて、フレームワークや MVC 構造を使っていないので、明確な指示に基づいて GPT-4 が生成したコードは理解しやすく、たいていそのまま動く。
だいたい25行程度のコード片を変更して特定のレポート機能に合わせるよう依頼する形で、たとえばこのページで X によってグループ化し、Y を合計してと言うと、正確に反応してくれる。簡単な QA とテストを通せば終わりで、複雑度が低く指示が明確な作業では、状況を一変させるほど効果的だ。
このプロセスは、シニアプログラマーが作業を基本構成要素に分解してジュニアに任せるやり方に似ている。ここでは GPT-4 が月20ドルのジュニアプログラマーの役割を果たしてくれて、時間を節約してくれるので、喜んで自腹で払っている。
ただ、子どもの頃に「電卓があるのになぜ数学を学ばなければならないのか」と尋ねていたように、今ではなぜ基礎を学ぶ必要があるのか理解している。基礎がなければ効果的に使えない。自分が PHP を学んでいたときに GPT-4 があったら、今ほど基礎を理解していなかっただろう。ツールが出てくる前に学んだことの恩恵を受けている。
コード品質も特に低いとは感じず、むしろ時にはより洗練された結果を出すこともある。
批判の多くはまだ時期尚早だと思っていて、追加のインフラ支援を必要とするぎこちない前進に近いと見ている。コンパイルできない結果を出さないようにするリンター統合はどこにあるのか、難易度の低いエラーを自動で見つけて直す機能はどこにあるのか、と思う。
生成 AI 開発環境においてテストはどのような形であるべきで、どう変わるべきなのかも未解決だ。TDD や BDD のような手続き的アプローチのうち、利益を最大化しコストを下げる、より良い方法があるかもしれない。
この1〜2年は、大きな技術変化が既存のワークフローにそのまま放り込まれた時期だった。どんなツールでも、ツール自体の能力と使う人の経験が合わさって結果が生まれる。
業界が開発に生成 AIを統合する経験と知見をもっと積まなければ、実際の純価値はつかめない。技術の適応のためではなく、人が適応するのに時間がかかるため、少なくともあと2〜3年は必要だと思う。
すでに、自分が作った基本的な CRUD フレームワークの上に、20代のチームがフルスタックのスパゲッティを山ほど生成しているのを見た。60秒で「MMO framework」を生成できるなら、TODO アプリを最初から作ってみる動機は減る。
12年前、リレーショナルの基礎を学ぶ前に Firebase を先に使い、基礎にたどり着くまで数年かかったのと似ている。
未来を正確に見通すことはできないが、品質を認識する方法は変わると信じている
EV、医療、IT、金融など、身の回りのあらゆる領域で、テクノロジーが重要な問題の救世主になるかのような空気がある。同時に、テクノロジーは主に市場、政府、国家などを大きくするために使われ、すでに漏れのある抽象化の上にさらに別の層を重ねる形で機能していることが、ますます明らかになっている。問題を解決するというより、症状だけを溶かそうとしているように感じる
品質には遅さが含まれており、対症療法には限界があり、人間がさらに多くの抽象化を重ね続けるやり方では課題に対処できないため、その遅さが必要になると見ている
もっと速くならなければならないという考えは間違っていると思う。人間として課題の基本を理解せず、表面的な利益のために解決しようとするやり方では、品質は生まれないと信じている
LLMは私たちの分野にとって災厄だ。本当の仕事をせずに目標へ到達したがる平均的な人間の誤りに迎合するからだ。本当の仕事とは、正しさに関する仮定を適用し、自分が本当に解決しようとしているものが何なのかを理解することだ
幸い、誰もがもっと速く進もうとしているわけではなく、基本を学び直し、慎重な判断を適用し、長く持ちこたえる品質を作るために思考と道具を磨いている人たちもいる
私の経験はむしろ逆に近い。ごちゃごちゃしたAPIやライブラリを漁る作業が難しい部分を邪魔する代わりに、LLMは意味のある作業において自分の思考が堅牢でないとき、それを痛いほどはっきり露呈させる
LLMで何かをするには書かなければならず、書くには考えなければならない。自分がやりたいことを注意深く文章化し、LLMに突かれ、その過程で思考の穴を見つけて明確にしたチャット履歴を後から見返せる点が、最も有益なことが多い
特にアプリの初期に形を作るとき、当時やるべきだと思っていたことを追跡し、後でそれがまだそうなのかを見直すのに非常に役立つ
クラブでプロの演奏を聴いて家に帰り、それをまねしようとするが、結局は基礎のない混乱した塊になってしまう。単純なことをすることに満足し、徐々により強い基礎を築くべきだと強調していた
この洞察は、AIが生成したコードを使うことにもほぼそのまま当てはまる
IKEAの家具が良い例だ。自分で家具を作ると、IKEAの段ボールのような物のそばにいるよりも、ずっと良い気分になる。だが人々の頭の中では、コスト、スピード、利便性が最も重要なもののように見える
AIモデルはその生得的な経験を奪い、最終結果のクリームだけを与える。実際の関係を築いて性に至る代わりにポルノを見るのに似ている
賢く使えば、Copilot系は役に立つ。ボイラープレートや退屈な部分を処理し、人間が重い思考に集中できるようにしてくれる
しかもまだ初期段階だ。判断を下すには早すぎるし、消えてなくなるとも思えない
方法論は、2023年のコミット活動を過去の年と比較し、そのうちどれだけにCopilotが関与していたかは分からないまま、変化を仮定として解釈しているように見える。かなり不安定なアプローチだ
また「2024年の予測は、OpenAIのgpt-4-1106-preview Assistantで既存データに2次回帰を実行した」とあるが、sklearn、R、Excelのような単純な回帰ツールではなく、GPTに4個のデータで回帰をさせたのか疑問だ。仮に適切にやっていたとしても、データ4個に加えて最初の懸念まで考えると、説得力は弱い
2次回帰と言うともっともらしく見えるが、データ点が2つなら、実質的には「線をそのまま延長する」だけだ。だから2024年の予測は、本質的にほとんど意味がない
元研究の著者です。多くの人が長期的なコード品質を気にかけているのを見るとうれしいです。2023年に churned code と重複、つまりコピペコードが増え、moved code が減ったことは、私たちの予想をも上回っていました
開発チームと AI Assistant の制作者が、新たに追加したコードよりも再利用したコードを促す測定指標やインセンティブを採用してくれることを望みます。特に、成果評価に LoC を入れるべきだと信じている管理職の下にいるチームは危険です。GitHub の調査によると約3分の1がそうで、現世代のコード支援ツールは Tab を押してコミットし、将来の技術的負債を植え付けることをあまりにも簡単にしてしまいます。Adam Tornhill が Twitter で述べたように、「AI 支援プログラミングの核心的な課題は、そもそも書くべきではないコードを大量生成することがあまりにも簡単になること」です
ただし、今回の研究の有意性には、AI が書いたコードを直接測定していないという限界があります。過去4年間のコード品質と AI Assistant の普及の相関関係を示しただけです。GitHub や他の AI Assistant 企業が追跡研究に協力し、「完全に AI が提案したコード」「AI の提案に人が修正を加えたコード」「最初から書いたコード」の品質差を直接測定できればよいと思います
次の研究では、AI の利用によってバグ頻度がどう変わるかも直接測定したいです。測定するとよさそうな他のアイデアがあれば提案してほしいです。約2か月ごとに新しい研究論文を出そうとしています
コード再利用は1つのコードベース内では強力な場合がありますが、コードベースをまたぐと混乱を生むのも見てきました。役に立つことも、不適切で混乱を招くこともあり、結果はおおむね判断力に左右されます
開発者はソフトウェアの成果で評価するほうがよいと思います。たとえば、リソース使用量に対する組織への影響、依存サービスやインフラに由来しないサービス障害などです
現代のプログラマーはコードだけに責任を負う存在ではなく、品質エンジニア/テスター、技術プロダクトマネージャー、プロジェクトマネージャー、プログラマー、パフォーマンスエンジニア、インフラエンジニアが意図的に混ざり合った存在です。研究自体を貶めたいわけではなく、コード品質を深く気にかけている人がいるのはうれしいですし、評価方法は違う形で考えるべきだと思います
変化したテクノロジー経済のような、他のあり得る説明をコントロールしたのかも気になります
この論文は実際のコードのリファクタリング作業で最も人気のある LLM の性能をベンチマークし、AI が機能的に正しいリファクタリングを提供したのは37%にすぎなかったと述べています
AI 支援コーディングは実際に有用ですが、熟練した人間を引き続きループ内に置き、マーケティングの誇張を超えた現実的な期待値を設定する必要があります
私の作業フローはたいてい、ドキュメントをざっと読み、プロトタイプを作り、コードを少し整え、テストを追加し、移動し、壊し、また作業し、ドキュメントを学び、さらにリファクタリングした後で、ようやく問題を十分に理解してコードの80%を取り除き、きちんと作り直す、というものです
Copilot がプロトタイプ段階で十分に動くコードを出してくれて、そのまま次へ進ませてしまうと、全体を正しく構造化できるほど理解が深まりません。作業フローの90%を飛ばせるようにしてくれますが、その代償はあります。もちろん開発の最後の段階では Copilot は非常に役立つことがあります
研究結果が正しいなら驚きません。悪いコードは理解不足から生まれ、Copilot は私が与えた以上の理解を持てません。平均的なプログラマーより良いコードを書けるとしても、結果は入力より良くはなり得ません。人々が「プロンプトエンジニアリング」にあれほど注力しているのに、VSCode の悪い「プロンプト」が悪い結果を生むことに、なぜ驚くのか分かりません
私の経験では、Copilot は着手を助けるのに優れています。コードは良いこともあれば、平凡だったり完全に壊れていたりすることもあります
それでも、考え始めさせてくれるという点で貴重です。使う前は、もっとずっと時間を無駄にしていました。私の脳の回路が特殊だからかもしれません
ジュニアで、VSCode に Codeium を入れているが、たいていの場合とても気が散る。なぜこれほど多くの人がこうした補助ツールを使うのか、よく理解できない
Phind のようなものは役に立つ。何か理解できないことが起きたとき、6割くらいは問題を理解する助けになる。疲れていたり、ぼんやりしていて見落とした小さなバグを見つける、といった具合
一方で Codeium は、フレームワークのボイラープレートを吐き出すときには役に立つかもしれないが、スクレイパーや簡単なデータパイプライン、素の JS+HTML/CSS を使う小さな経験では、提案を見送るのがとても煩わしい。特に動かないことが多く、引数が1つ足りないなど些細な理由でも、結局デバッグに時間を使うことになる
また JavaScript には、メソッドと匿名関数を延々とデイジーチェーンのようにつなげる一般的なスタイルがあるが、自分にはそれが本当にきつい。行を分け、関数や変数に名前を付けるほうが好きだ。コード提案もしばしばそのスタイルに従うが、訓練データがそうなのだと思う。Codeium はそれを学習するとは言っているし、実際にそうなることもある
一番心配なのは、ジュニアである自分がこうした補助ツールにコードを任せたら、いったいどうやって学ぶのかということ。Phind に文脈と質問を与えるのは学習の助けになったり、インターネットで自分で調べる方向を示してくれたりするが、Tab を押すだけでどう学べるのか分からない
数日前、多くの人、開発者も含めて、LLM を上達するための道具ではなく 努力の代替物 として使っていることに気づいた。会社に置き換えられるかどうかだけでなく、自己省察の問題としても恐ろしいことではないかと思う
コーディングが人生の情熱というわけではないが、好きではある。何かを起こせるし、複雑性を扱わせてくれるからだ。何が起きているのか理解していなければ何かを作ることもできないし、複雑性がいつ自分を食い尽くすかにも気づけない
そのまま続ければいいし、変えなければ良いところへ行けるはず。間違いなく正しい道の上にいる
重要なのは、キャリアの中で API 仕様をあまりにもたくさん手で書いてきたので、1) 問題をすぐに見つけられ、2) 追加の助けなしに直せたことだ。プロンプトを調整するより、モデルを手で直すほうが速かった
よく知っている領域では、午前中いっぱいかかる仕事を30秒でやってのけるのを見るのは驚きだ。ただし、自分ができないことを AI にやらせることはない。代わりに、作業中のものについてトレードオフや潜在的なセキュリティ問題などを AI とよく話す
自分が使っている言語について博士号を持つジュニアエンジニアのようなものだ。多くのことは理解していないが、理解していることは深く理解しているように見える
一部の開発者、特に JS 開発者は、1行に保てるという以外に何の得もないのにチェーンを好む。それは得ではない。今のまま続けて、この馬鹿げた慣用句に頭の中を汚染させなければいい
この技術が驚くべき瞬間は、自分のスタイルや好みに合わせてくれるときだ。自分が望むやり方で名前を付け、いま書いたばかりのメソッドを、重複実装の代わりにきちんと使ってくれる、といった具合
空のプロジェクトや小さなプロジェクトではあまり使ったことがないが、周囲の文脈をもとに自分がすでに使っているやり方へ強く寄せてくれないなら、ずっと理想的ではなく感じるだろう
AI 補助ツールの最大の用途は、テストの作成と、「これに似ているが少し違う」反復的な変更を速く行うことだった。IntelliJ + GitHub では、新しいパラメータを複数のメソッドやファイルに反映させる必要がある作業でも、最初の2、3パターンを自分で入力すれば、その後はたいてい enter + tab で処理できる。文脈が残りを埋めてくれる
VSCode の Codeium は、AI 自体もあまり十分ではなさそうで、プラグインも提案や受け入れキーがしばしば邪魔になるように作られているように思える。反復作業にはなお役立つが、目標を達成する方法を提示する面では劣る
ChatGPT で Django/Python ベースの Yourls クローン を作ってみることにした。カスタム短縮 URL を許可し、トラフィックも追跡するよう具体的に指示したが、ロジックやデータモデルでそれをきちんと考慮できていなかった。後で直すには、また具体的な指示を与える必要があった
AI ツールは仕事をしてくれるジュニア開発者に似ている。ただし、はるかに速い
自分が何をしているのか分かっていなければ、ミスをする速度だけが加速する
最近、SELECT 文のカラム alias にテーブル名の接頭辞を付ける必要があったが、そういう機能がなかったので、ChatGPT にスキーマ定義とクエリを渡し、40個ほどあるカラム選択リストを長く書いてもらった
複数の RDBMS でこうしたことを自動化する良い方法は見つからず、正規表現や他のテキスト操作でも可能ではあるが、問題を説明して必要な出力を受け取るやり方は、気持ちいいほど単純だった
それ以外では、LLM をオートコンプリートのように使っている。良い関数名を付けさせる効果もあり、その程度の情報だけでも LLM が妥当な出発点をくれることが多いからだ。特に、あまり使ったことのない API や言語で、自分が直面した問題がすでに何千回も解かれているような場合に役立つ。StackOverflow もほとんど使わなくなった
だから Copilot を買ったし、ChatGPT もよく使っている。LLM は IntelliSense のような優れたオートコンプリート、OpenAPI 仕様や EF/JPA コード生成、ER モデルに基づく DB マイグレーション/テーブル生成、コンテナ、JetBrains のような賢い IDE と並んで、自分のお気に入りの一つだ
企業はより多くのコードをより速く求めるだろうし、その渦の中で自分が何をしているのか本当に分かっている人は、さらに少なくなる気がする
論文全文はこちら: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
「AI」支援ツールが市場に出る前から、すでに DRY なコードへの反発はあり、残念ながら2019〜2022年に Twitter を使っていたころには大きくなっていた流れだった
一部の若い開発者は、私が学んできたものとは非常に異なるコード観を持っている。Gang of Four とデザインパターンをものすごく軽蔑していて、自分たちの好きなフレームワークがまさにそのパターンで満ちていることには気づいていないようだ。DRY、とくに SOLID のような原則を皮肉る
Twitter のような場所では、皮肉が強く、反対側を叩く言葉ほどエンゲージメントが増える。かなり不安な流れだ
企業のコードベースで起きていることには、私も強い軽蔑を感じる。SOLID のグルが何と言おうと、クラスで間接層を何重にも作るのはよくない。ベストプラクティス、DRY、SOLID は単なる言い訳として使われている
Java 的なオブジェクト指向思考から出てきた恣意的な原則リストを、ソフトウェアモデリングの真理のように扱うのに耐えられないということだ。SOLID をどう理解すべきかについての何度目かわからない議論にも飽きている
CAP 定理については人々はそこまで争わないが、それは格好いい頭字語を作るための恣意的なアイデアの寄せ集めではないからだ
DRY も乱用されうるし、人々が完璧なもののように扱う態度に反発しているだけだ
たとえば DRY の重要な原則は、コードを繰り返すなということではなく、アイデアを繰り返すなということだった。システム内のどんな概念についても、理想的には単一の真実の情報源があるべきで、その概念を扱うときに理解したり変更したりすべき場所も一つであるべきだ
だから、意味のある抽象化の代わりに少なからぬコードをコピー＆ペーストすることは、たいてい悪い。同時に、何らかのアイデアを繰り返した瞬間に、異なる表現を同期し続けなければならない継続的な負債が生まれる、という警告でもある。これはスキーマを定義する DB マイグレーションと別個の ORM クラス、バックエンド API とフロントエンドクライアント、retained mode UI のフォーム値と内部状態、型と単体テストの双方に表現されるデータモデルの不変条件にも当てはまる
異なるアイデアが偶然似た実装を持っているからといって無理に統合すると、後で保守上のリスクになると反対する人たちは間違っていなかった。ただし彼らは、DRY の本来の要点ではなかった藁人形を攻撃している
いま問題なのは、新しい開発者がこうした原則をどこで、いつ、きちんと学ぶのかということだ。専攻の背景がある人もいるが、全員がそうではないし、学術的な CS 課程が実務開発スキルを多く教えるべきというわけでもない
私が始めたころは、シニアがジュニアに実践的でかなり手厚い教育をしていたが、いまの頻繁な転職文化と、ジュニアを長期投資として採用するのをためらう雰囲気では、そうしたことはずっと減ったように思う。公式講座は個人にとっては高価だが、会社基準ではほとんどコストではないとしても、実際に会社が送り出す新人開発者はごく少ないだろう
読む価値のある本もあるが、2024年の20代が、切り倒された木片にインクで印刷された古い形式を進んで扱いたがるかはわからない。今日成長中の開発者は、ブログや YouTube からこうしたアイデアを多く学んでいるようで、そこにも優れた資料はあるが、きちんと理解されていなかったり、疑わしい形で包装されたゴミの中から見つけ出すのが常に問題だ
だから、心臓が一拍するほどの間に、とりあえず動く12行のコードを作り出す魔法のようなツールが登場したとき、若い開発者がそのコードのより深い問題をほとんど知らないまま素晴らしいと思うのも驚きではない。誰のせいだと言うのは難しいが、明らかな問題であり、どうすべきかわかればよいのだが