効果的なマシンラーニングチーム

第8章 リファクタリングと技術的負債の管理 リファクタリングと技術的負債管理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

プログラミングは人間が読み取るために書かれ、マシンが実行するために付随的に書かれなければならない。

ハロルド・アベルソン『コンピュータ・プログラムの構造とインタプリタ』（MITプレス）

リファクタリングなしでは、ソフトウェアの内部設計（アーキテクチャ）は衰退する傾向にある。人々が短期的な目標を達成するためにコードを変更すると、多くの場合アーキテクチャを完全に理解しないまま、コードはその構造を失う［...］。コードの構造の喪失は、累積的な効果をもたらす。コードの設計が見えにくくなればなるほど、それを維持するのが難しくなり、より急速に衰退していく。定期的なコードのリファクタリングは、コードの形を保つのに役立つ。

マーチン・ファウラー、リファクタリング：既存のコードの設計を改善する (Addison-Wesley Professional)

MLの実務家として、我々はコードが厄介になることを知っている。通常、MLモデルをトレーニングするコードは、長いノートブックやスクリプトの中に半ボイラープレート的なコードをつなぎ合わせたものであり、print文、きれいな印刷のデータフレーム、データの視覚化など、副次的な効果がふんだんに使われている。

MLのプロセスを教えることを目的としたノートブックでは問題ないかもしれないが、実際のプロジェクトでは、メンテナンス不可能な混乱、認知的オーバーロード、進捗を止めてしまうほどの摩擦の元となる。悪いコーディングの習慣とデザインの欠如は、コードを理解しにくくし、その結果、変更するのが非常に難しくなる。そのため、機能開発やモデルの改良はますます難しくなり、エラーが起こりやすく、時間がかかるようになる。

ありがたいことに、もっと良い方法がある。この章では、問題が多く、厄介で、もろいコードベースを、読みやすく、テスト可能で、保守可能で、進化可能なソリューションにリファクタリングするためのテクニックを紹介する。この章では、"Learning by doing "の精神に則り、コード臭が充満しているMLトレーニングパイプラインから始まり、より良い解決策で終わるまで、実践的な例で説明する。最後に、あなたやあなたのチームが、効果的な技術的負債管理と製品デリバリのバランスをとるのに役立つプラクティスを共有する。

この章の目的は、デザインパターンを教えて、何の問題もなく完璧にデザインされたコードを書けるようにすることではない。それは物理的にも経験的にも不可能だ。そうではなく、技術的負債を抑え、持続可能なペースでアイデアを実行できるように、インクリメント的かつ定期的にソリューションを改善するスキルを、あなたとあなたのチームに身につけさせることが目的なのだ。

まず、技術的負債のコストと、テスト、デザイン、リファクタリングのテクニックを使って、チームが技術的負債をインクリメント的かつ定期的に返済する方法について説明する。

技術的負債：歯車の中の砂

もしあなたがMLを実践してしばらく経つなら、間違いなく、最初は簡単そうに見えたコーディング作業も、次のような理由で時間がかかってしまったことがあるはずだ：

• コードの品質に問題があり（例：変数名の付け方が悪い、100行以上に及ぶ長い関数）、コードを理解するのが困難だった。

• 設計が悪く（例：複数の責任を混同した関数）、コード変更の実装が難しかった。 ...