-
Makefile効果に対する認識
- Makefile効果とは、複雑だったり不慣れだったりするツールを最初から書かず、以前うまく動いたサンプルをコピーして修正する現象を指す。
- この効果は、さまざまなエンジニアが Make のようなツールを使う際によく現れる。
- 過去に似た作業が行われていた場合、エンジニアは以前の Makefile をコピーし、新しい状況に合わせて修正する。
-
問題点と影響
- 設計段階での問題: ツールが複雑すぎる、または最初から使うのが面倒である。
- CI/CD 構成: GitHub Actions や GitLab CI/CD で YAML 設定をコピーして修正することが多い。
- リンターおよびフォーマッターの設定: 基本ルールセットをプロジェクト間でコピーし、必要に応じて厳しくしたり緩めたりする。
- ビルドシステム: 自明でないものはすべて、以前のビルドシステムに似たものになっていく。
-
この現象が重要な理由
- 診断およびデバッグ支援の不足: ツールを繰り返し実行する必要があり、提供される情報も少ない。
- 学習の阻害: 一部の専門家だけがツールをよく理解し、他の人は最小限の知識でコピーして修正する。
- セキュリティの問題: セキュリティ作業には深い知識が必要であり、Makefile効果のあるシステムはコードとデータの混同を招く可能性がある。
-
ツール設計時の考慮事項
- ツールが 設定可能 であるべきかどうか。
- 独自の文法 が必要かどうか。
- 既存の文法 やイディオムを再利用できるかどうか。
- コピー＆ペースト が頻繁に発生するかどうか。
-
Makefile効果に似た現象
- カーゴカルト や 逸脱の正常化 に似ているが、Makefile効果は特定の設計の結果に関するものだ。
- Makefile効果は本質的に非効率だったり悪いものだったりするわけではない。ツールやシステムを設計する際に認識しておくべき事項である。
1件のコメント
Hacker Newsの意見
複雑なシステムは単純なシステムから発展していくことが多い。最初から複雑に設計されたシステムはうまく動作せず、単純なシステムから始めるべきである
MakeとMakefileは、autoconfで自動生成されない限り非常に単純である。autoconfで生成された場合は修正せず、可能であればautoconfを使わないほうがよい。コードを少し書くかコピーしてプロジェクトで使い、必要に応じて改善する。その後、別のプロジェクトでそのコードをコピーして修正し、元のプロジェクトに変更を反映する。複数のプロジェクトを通じてライブラリとして抽出し、オープンソースとして公開できる
開発者の約10%は、最初から何かを始める能力を持っている。40%はコードのコピー＆ペーストで作業を行い、50%はLeetCodeのパズル以外はよく分かっていない。多くのMakefileはコピー＆ペーストで構成されている
Cargo Cult Developmentは、技術の原理を理解せず表面的なものだけを模倣する開発方式を意味する。コピー、貼り付け、試行、調整などを通じて動くことを期待するやり方である
Makefileは不適切なたとえかもしれない。多くのコードがWebからコピーされ、使われていない部分が多い。不要な部分を削除するのは良い習慣である
開発者が相互作用しなければならないツールやシステムは、日常的に学ぶ価値が低いと認識されがちである。CI設定などは「設定したら忘れるもの」と見なされ、複雑な部分は別のチームが処理する。適切なツールとドキュメントを提供して、開発者が簡単にアクセスできるようにする必要がある
LaTeXのようなツールは使用頻度が低いため、コピー＆ペーストから始めることが多い。使用頻度の低いツールは覚えにくい
Makeは十分に文書化されており、ユーザーがドキュメントを読めば簡単に理解できる。しかし、多くのツールは文書化が不十分で、ユーザーがツールを理解しにくくしている
複雑なツールは必要だが、単純なアプリケーションでMakefile効果が現れるなら、そのツールは複雑すぎることを意味する。小さなプロジェクトにはMakefileが適しているかもしれない
「Copy-Pasta Driven Development」は、コードのコピー＆ペーストによって発生する問題を指摘している。Copilotのようなツールは、こうした問題を悪化させる可能性がある