重複に関するサンディ・メッツ氏への返答

サンディ・メッツは最近、次のように宣言する記事を書きました。 重複は間違った抽象化よりもコストがかかりません。 この記事は、投機的一般化のコストについて貴重な論点を提起していますが、それらのコストを詳細に説明し、それを阻止する一連の記事の一部です。 今となっては、誰かが抽象化を批判するのを聞くのはもう古いはずですが、それでもミームは存続しています。
Sandi Metz の記事で私がこの投稿で答えたい点は、 考え方 それは、少なくともそれに最も反応した考え方を促進します。 この考え方はコメントでよく見られます。ただタスクを完了するだけで、それ以上は何もしません。 場合によっては、それが適切であり、取るべき正しいアプローチであることもありますが、ここでの問題は、抽象化のコスト、特にそれが間違っていた場合のコストは明白であり、「シンプルさ第一」の考え方のコストはそれほど明白ではないことです。 重複したコードの具体的なコストについてはすでによく知られているため、ここでは説明しません。 についてお話します 機会費用 – 学習の機会を逃した。
優れた開発者は常に学習し、常にスキルを磨く必要があります。 改善の余地は常にあります。 開発者にとって実践すべき最も重要なスキルは、有益な抽象化を認識することです。これを正しく行うには、磨かれた直感が必要となるためです。 コストが長期的に明らかになるのを確認する必要があり、間違いを犯すことも必要です。 開発者は、過去の決定を常に評価し、新しい決定に対してリスクを負う必要があります。
機会費用は、技術的負債の見落とされがちな側面です。 技術的負債を蓄積することが現時点でより安価な選択肢である理由は、解決策がすでにわかっている道をたどるからです。 学ぶことは何もありません。ハックを実装するだけです。 少量であれば問題ありませんが、コードベースについて学習したり、不足している抽象化を発見したり、問題の解決に役立つ概念的なツールを作成したりする機会が失われます。
したがって、Sandi Metz の例の開発者が行うべきだったのは、この特定の抽象化が利益よりもコストのほうが大きかったことに気づくことです。 それに気づくのは良いことです。それは貴重な学習経験です。 抽象化のどのような具体的な側面が開発を遅らせていたのでしょうか? どの部分が新しい開発者を混乱させ、事態をさらに悪化させたのでしょうか? これらは、開発者が経験から学ぶために自問すべき質問です。
私たちの開発チームには、「Tech Talks」と呼ばれる毎週の習慣があり、そこでは開発者がその週に学んだことや、本来よりも厄介なコードベースの一部などについて話します。 この実践は、成長マインドセットを促進するのに非常に貴重です。Mz 氏の状況は次のとおりです。 メッツ氏の記事は、取り上げるのに最適な例だろう。
開発者はコードを作成することだけに集中すべきではありません。 このように注意を制限している人は成長せず、すぐにより優れたツールに追い越されるでしょう。 代わりに、開発者の仕事は、どの抽象化がコードベースにとって価値があるかを理解することであることを認識する必要があります。 それを学ぶ唯一の方法は経験を通してです。