補完するのではなく、簡単に削除できるコードを書く

「すべてのコード行は理由もなく生まれ、脆弱性が続き、誤って削除されます」-ANSI CのJean-Paul Sartreプログラム



コードの新しい行ごとに、それをサポートする必要があるという形でコストがかかります。 大量のコードを扱うこのようなコストを回避するために、再利用に頼ります。 この方法を使用することの欠点は、将来何かを変更したい場合に干渉し始めることです。



APIのユーザーが多いほど、新しい変更を導入するためにより多くのコードを書き換える必要があります。 逆もまた真です。サードパーティのAPIに依存するほど、変更時に発生する問題が多くなります。 コードのさまざまな部分の相互作用と関係を合理化することは、大規模システムでは深刻な問題です。 そして、プロジェクトが発展するにつれて、この問題の規模は大きくなります。



この記事のロシア語への翻訳は、オンラインビジネス向けの支払いソリューションのプロバイダーであるPayOnlineによって作成されました 。

コードの行数を本当に数えたいのなら、「プロデュースされた行」ではなく、「使用済みの行」として見るべきだと言っています-E .ダイクストラ、 原稿1036 。

「コード行」を「使用済み」として扱う場合、それらを削除することにより、サポートのコストを削減できます。 再利用可能なプログラムを作成する代わりに、1回限りの使用プログラムを作成するよう努力する必要があります。 コードを削除する方がコードを書くよりもずっと楽しいことを説明する必要はないと思います。



簡単に削除できるコードを作成するには、一般的に依存関係を避け、できるだけ頻繁に依存関係を整理しないようにします。 コードを分解します。使いやすいAPIを作成し、使いやすいが一般的にはあまり便利ではないソリューションに基づいて作成します。 コードの最も複雑で最も揮発性のある部分を、プログラムコードの残りの部分や相互に分離して、コードを分離します。 考えられるすべてのケースに対してハード定義を作成しないでください。状況によっては、プログラムの実行中に選択を開いたままにしておくことをお勧めします。 このすべてを同時に実行しようとしないでください、あなたはまったくそんなに多くのコードを書くべきかどうかを検討してください。

ステップ0：コードを記述しない

コードの行数だけではあまり意味がありませんが、50、500、5,000、10,000、25,000行などの効果は大きく異なります。 100万行のモノリスは、1万行の構造よりも多くの神経を傷つけます。 あなたがそれを交換するために費やさなければならない時間、お金、努力について話せば、違いはより強く感じられるでしょう。

コードが多いほど、それを取り除くのは難しくなります。 ただし、1行のコードを保存しても、それ自体で結果は生成されません。 そのようなコードを削除する最も簡単な方法は、コードを書き始める前に拒否することです。

手順1：コピーと貼り付けを使用する

「再利用可能な」コードを書くことは、将来どのコードが必要になるかを評価するのではなく、いくつかの使用例を手元に置いて、後知恵ではるかに簡単です。 ただし、この方法のプラスの側面を自分で感じ、すでにファイルシステムを操作しているだけです。 したがって、コードを再利用すると、すべてが正常に動作しているように見えます。少しの冗長性はプログラムにのみ有効です。



コピーペーストを使用することは、ライブラリ関数を作成するよりも優れています。この関数があなたのケースでどのように動作するかを理解するためです。 つまり、コピーペーストではなく関数を記述する必要があるかどうかを慎重に検討する必要があります。作業をパブリックAPIに変えるとすぐに、後でそれらを変更するプロセスが難しくなるためです。



作成した関数は、意図された目的と、作成時に考えもしなかった他の目的の両方で呼び出されることを常に覚えておいてください。 それを使用するプログラマは、ドキュメントに書いたものではなく、自分の観察に依存します。 もちろん、関数自体よりも関数の内容を削除する方が簡単です。

手順2：コピーと貼り付けを使用しない

プログラムの一部を十分な回数コピーしたことに気付いたらすぐに、それを基にした関数を書く時が来たのかもしれません。 このステップでは、構成ファイルを開いたり、ハッシュテーブルを表示したり、ディレクトリを削除したりするなど、最も単純なことを単純化することについて話します。 状態を持たない、または環境変数などのグローバル情報をほとんど含まない関数は、一般に、名前に「util」という単語が含まれるファイルに表示されるすべてのものもこのカテゴリに分類されます。

小さな余談：util用の特別なディレクトリを作成し、各ユーティリティを個別のファイルに保存します。 1つのutil-fileを使用すると、最終的に巨大なサイズに成長し、それを個別の部分に分割することが非常に困難になるという事実につながります。 単一のutilファイルを維持することは悪い習慣であることを常に覚えておいてください。

このコードまたはそのコードがアプリケーションまたはプロジェクトに固有であるほど、再利用しやすくなり、変更または削除される可能性が低くなります。 これは通常、データの記録、サードパーティのAPI、ファイル記述子、またはプロセスの処理を記述するライブラリコードです。 削除する必要のない他の例は、リスト、ハッシュテーブル、その他のデータセットです。 インターフェースが頻繁にシンプルになるためではなく、時間の経過とともにスコープが拡大することはありません。



コードを削除するタスクを明確に促進しようとしないでください。 代わりに、この段階で、削除が困難な部分を、簡単に削除できる部分から可能な限り遠くに置くようにしてください。

ステップ3：定型コードをさらに記述する

ライブラリは、一定のコピーアンドペーストを避けるために書かれています。 それにもかかわらず、それらを書く過程でさらにコピーアンドペーストを追加することがしばしばわかりますが、私たちはそれを別の方法で呼びます：定型句。 ボイラープレートの作成はコピーアンドペーストに非常に似ていますが、異なる点は同じではなく毎回コードの異なる部分を変更することです。 コピーと貼り付けの場合と同様に、コードの一部を複製して依存関係を表さず、柔軟性を実現し、見返りにさらに冗長性を確保します。



ボイラープレートを必要とするライブラリは、多くの場合、ネットワークプロトコル、データ転送フォーマット、解析ツール、およびポリシー（プログラムが行うべきこと）とプロトコル（プログラムが行うことができること）をオーバーラップなしに組み合わせることが難しいすべてのコードベースのような開発です制限。 このようなコードを削除するのは困難です。原則として、他のコンピューターと通信するか、さまざまなファイルを処理する必要があります。 同時に、ビジネスロジックで汚染することは、私たちが最後に望むことです。 いいえ、コードの再利用に関する追加の演習については説明していません。 頻繁に変更されるコードブロックを、比較的静的なものから遠ざけるようにしています。 つまり、ボイラープレートを記述する必要がある場合でも、ライブラリコードの依存関係を最小限に抑えることに取り組んでいます。 最終的に、より多くのコード行を記述しますが、それらはすべて、簡単に削除できる部分に分類されます。

ステップ4：定型コードを記述しない

ボイラーは、ライブラリーが開発者の最も多様な好みに合うと想定される場合に最適に機能しますが、このアプローチは過度の冗長性をもたらすことがあります。 次に、柔軟性のあるライブラリを別のライブラリに配置します。別のライブラリには、ルール、スキーム、条件に関する独自のビューがあります。 使いやすいAPIを作成すると、ボイラープレートをライブラリに変えることができます。 そして、あなたが思うほど珍しいことではありません。 一例として、Pythonで最も人気のあるhttpクライアントの1つであるリクエストは、より冗長なurllib3ライブラリに基づいて動作し、シンプルなインターフェースの提供に成功します。 リクエストを使用すると、httpで作業するための多くの一般的なスキームを使用して、ユーザーの目からほとんどの詳細を隠すことができます。 同時に、urllib3はパイプライン処理を行い、接続を管理し、ユーザーに対して何も隠しません。



ここでのポイントは、あるライブラリを別のライブラリに入れることで詳細を隠すことではなく、責任を共有することです：リクエストは、世界中で人気のあるhttp旅行の旅行パッケージの選択肢を提供する旅行代理店と比較できますが、urllib3はこの旅に必要なものがすべて揃っていること。



いいえ、すぐに行ってディレクトリ/ protocol /および/ policy /を作成することはお勧めしません。 ただし、おそらくutil-directoryをビジネスロジックから解放し、同時に独自のライブラリタンデムの作成に引き続き取り組みたいため、これは必要になるでしょう。 ベースライブラリでの作業が完了するまで待たずに、並行して作業できます。



プロトコルの形式で作成された場合でも、サードパーティライブラリの「ラッパー」を作成することも有用です。 プロジェクト全体に共通のソリューションを使用する代わりに、コードに特に適したライブラリを作成できます。 作成するAPIは、使いやすく拡張性も高くないことがよくあります。 これらの2つの概念は、互いに相反します。



責任の差別化により、他のユーザーへの酸素をブロックすることなく、一部のユーザーを満足させることができます。 レベルに分割することは、最初は良いAPIを持っているときに行うのが最も簡単ですが、悪いAPIの上に良いAPIを書くことはあなたの好みではありません。 優れたAPIは、ユーザー（つまりプログラマー）がそれらをどのように見るかに基づいて設計されており、この意味で階層を作成することは、すべての人を同時に満足させることができないことを理解することを意味します。



コードをレベルに分割するという考え方は、後で削除できるコードを書くことではなく、使いにくいコードを使いやすくすることです（ビジネスロジックで汚染しないようにするため）。

ステップ5：大量のコードブロックを記述する

コピーまたは貼り付け、リファクタリング、レベルへの分割、またはデザインをいくら行っても、すべてコードが何らかの作業を行う必要があるという事実に帰着します。 場合によっては、すべてが意図したとおりにうまくいかない場合は、他のすべてを機能させるために、あきらめて低品質のコードを大量に書くのが最善です。



ビジネスロジックは、境界線のケースの無限のシリーズであり、迅速で汚いトリックです。 これは正常です。 それは私に合っています。 「ゲームコード」や「 ファウンダーコード」などの他のスタイルも同じです。かなりの時間を節約するためにコーナーをカットしようとします。



なぜ多くのコードを取得して記述することを提案するのですか？ 1つの大きな間違いを取り除くことは、互いに密接に絡み合っている18個の小さなものを取り除くことよりもはるかに簡単だからです。 一般に、プログラミングは研究と関係があります。 いくつかのミスをして結果を得るのは、最初に考えようとするよりも速い方法です。 これは、楽しみや創造的な努力の場合に特に当てはまります。 最初のゲームを書いている場合は、エンジンでこのプロセスを開始しないでください。 同様に、アプリケーション全体にWebフレームワークを記述しないでください。 私はあなたが精神的に健康な人が理解できない混乱をあなたがまだ得ると知っているので、これを言います。 したがって、最初に座ってこれを混乱させることをお勧めします。



モノリポジトリも同じトレードオフです。コードを分割する方法を事前に知ることはできません。 しかし、このような「1つの大きな間違い」を展開することは、20の密接に関連する間違いよりも簡単です。 コードのどの部分をすぐに破棄する必要があり、どの部分を削除するか簡単に交換する必要があるかがわかったら、さらに多くのコーナーをカットできます。 これは、1回限りのイベント専用のサイトやWebページ、または同様の作業を注文するときに発生します。既製のテンプレートがあり、必要なのは、コピーをスタンプするか、フレームワークの開発者が残した空白を埋めるだけです。



いいえ、彼女のすべての間違いを修正しようとして、同じナンセンスを10回書くことはお勧めしません。 私は何か他のものについて話している。 アランペルリスがかつて言ったように、「すべてを最初から最後まで作成する必要があります。」 新しい間違いを犯すことを恐れないでください。新しいリスクを負い、ゆっくりと、しかし確実に反復を繰り返してください。



プロのソフトウェア開発者になることは、後悔と間違いのカタログ全体をコンパイルすることを意味します。 成功は何も教えません。 良いコードがどのように見えるかを前もって知ることはできませんが、悪いコードに残っている傷跡は常に新鮮です。 いずれにせよ、プロジェクトは最終的に失敗するか、レガシーコードになります。 失敗は成功よりも頻繁に発生します。 がらくたの山を1つ輝かせようとするよりも、10種類の土の塊を成形して、その結果を確認する方が高速です。 コード全体を削除することは、部分的に行うよりも簡単です。

ステップ6：コードをパーツに分割する

汚れの大きな塊は簡単に彫刻できますが、維持が最も困難です。 一見しただけで簡単に変更する試みは、コードベースのほぼすべての部分に修正を導入することで終わります。



そのため、プラットフォームタスクとドメインタスクの両方の責任を分離するためにコード内に階層を作成しました。次に、これらすべてのロジックを共有する方法を見つける必要があります。

「最も複雑な設計上の決定または変更される可能性が最も高い決定のリストから始めます。 次に、そのようなソリューションを他のモジュールから隠すように各モジュールを設計します。 -デビッド・パルナッソス。

コードを同様の機能を持つパーツに分割する代わりに、お互いの違いに基づいてコードをパーツに分割します。 書き込み、保守、または削除で最大の困難を引き起こすものを特定します。 再利用できるかどうかに基づいてモジュールを作成することはありません。主なことは、将来それらを変更するのが便利であることです。



残念ながら、いくつかの問題は互いに密接に関連しており、他の問題と区別することはより困難な場合があります。 「各モジュールは1つの複雑な問題のみを解決しなければならない」という1つの責任の原則にもかかわらず、実際には「1つのモジュールのみが各複雑な問題に対処する」ことが重要です。 モジュールが一度に2つのことを行う場合、これは、1つの部分を変更するには他の部分を変更する必要があるために発生します。 1つのひどいが、インターフェースコンポーネントの点でシンプルな作業は、多くの場合、互いに慎重に調整する必要がある2つのコンポーネントよりも簡単です。

「この簡単な説明に該当する材料をより正確に決定しようとはしません[「弱い結合」]; おそらく、これを明確な定義にすることはできないでしょう。 しかし、 私はそれを見たときに知っています、そしてこの場合に考慮されるコードベースはそのようではありません。 -米国最高裁判所のスチュワート判事。

他の部分を書き換えずにその一部を削除できるシステムは疎結合と呼ばれますが、実際にどのように見えるかを説明することは、事前に作成する方法を知るよりもはるかに簡単です。 弱結合により、変数のハード設定や、その上でのコマンドラインフラグの使用も可能になります。 この手法の意味は、コード全体をやり直すことなく基本的な決定を変更できることです。



たとえば、Microsoft Windows製品では、外部および内部APIがこれらの目的に使用されます。 外部APIはデスクトッププログラムのライフサイクルに関連付けられており、内部APIはそれらが動作するカーネルに関連付けられています。 これらのAPIを非表示にすることで、このアクティビティの結果として多数のプログラムを壊すリスクなしに、システムに変更を加える柔軟性がマイクロソフトに与えられます。



HTTPには疎結合の例も含まれています。HTTPサーバーの前にキャッシュを追加し、CDNに画像を移動すると、それらへのリンクのみが変更されます。 どちらのメカニズムもブラウザを壊しません。 疎結合の別の例は、HTTPで使用されるエラーコードです。 Web上のサーバーの一般的な問題には、一意の識別子があります。 400エラーが発生した場合、エラーにつながった同じ操作を実行しても状況は変わらないことがわかります。 しかし、500エラーの場合、ページをリロードするとすべてが変更される可能性があります。 HTTPクライアントは多くのエラーを処理できるため、プログラマが自分でこれを行う必要がなくなります。



ソフトウェアを小さな部分に分解する際に、ソフトウェアがどのようにエラーを処理するかに留意してください。 そしてもちろん、これは言うよりも簡単です。

「非常に不本意ながら、LATEXを使用することにしました。」-ジョーイアームストロング。 ソフトウェアエラーがある場合に確実に機能する分散システムの作成。 2003年

Erlang / OTPは、「コントロールツリー」と呼ばれるエラー処理方法の点で非常にユニークです。 一般的に、Erlangシステムの各プロセスは、スーパーバイザーによって開始および監視されます。 プロセスで問題が発生すると、そのプロセスは停止し、その後スーパーバイザーによってすぐに再起動されます。 スーパーバイザ自体については、初期プロセスによって起動されます。これは、すでに障害が発生したときにも再起動します。



重要な考え方は、エラーを再起動するスキームはエラーを処理しようとするよりも速いということです。 このような障害の処理は、問題の解決を拒否することで信頼性が達成される場合、直感に反するように思えるかもしれませんが、実際には、一時的な一時的な障害の抑制にはシャットダウンと再起動の方法が非常に効果的です。



エラー処理と回復は、コードベースの外部レベルで実行するのが最適です。 別の方法では、これは2つの四肢の相互作用の原理と呼ばれます。 それは、エラー処理が、結合媒体の2つの遠端で、中央の他のどこよりも簡単であると言います。 これは、エラーに関する作業がその中間のどこかで発生した場合でも、とにかく境界レベルでチェックする必要があるという事実によるものです。 各最上位レベルがまだエラーを処理する必要がある場合、なぜプログラム内の他のどこかでエラーを処理するのですか？



エラー処理は、システムを内部で緊密に接続できる多くの方法の1つです。 密接な結束には他にも多くの例がありますが、それでも悪い結末を選ぶのは不正直です。 IMAPを除く。



IMAPでは、スノーフレークのようなほぼすべての操作に固有のパラメーターと反転アルゴリズムがあります。 エラー処理は非常に不快なプロセスになります。エラーは別の操作の途中で発生する可能性があります。



UUIDの代わりに、IMAPは各メッセージを識別するための一意のトークンを生成します。 後者は、別の操作の実行中に直接変更することもできます。 多くの操作は部分に分割できます。 1つのフォルダーから別のフォルダーに電子メールを確実に移動する方法を発明するのに25年かかりました。 そして、もちろん、非常に具体的なUTF-7およびbase64エンコーディングの使用に注意することを忘れることはできません。



比較のために、ファイルシステムとデータベースの両方がリモートストレージのはるかに優れた例です。 ファイルシステムは固定された一連の操作を提供しますが、それらを実行できるオブジェクトのセットは大きく、非常に多様です。 SQLインターフェースには、ファイルシステムよりも多くの機能があるように思われるかもしれません。 それにもかかわらず、彼は同じ作業スキームを使用しています。データセットを操作するための特定の数の操作と、これらの操作が実行される膨大な数の行があります。 また、あるデータベースを別のデータベースに常に置き換えることはできませんが、SQLで動作するソリューションを見つけることは、その場しのぎのクエリ言語の同様のソリューションよりもはるかに簡単です。



疎結合システムの他の例には、ミドルウェアまたはフィルターとパイプラインを使用するシステムが含まれます。 Finagle Twitterはサービスに通常のAPIを使用します。これにより、タイムアウト、再接続メカニズム、認証の基本的な処理を追加の労力なしで追加できます。 そして、もちろん、この点でUNIXパイプラインについて言及するしかありません。 それは多くのinりを引き起こします。



そのため、最初はコードをレベルに分割しましたが、これらのレベルのいくつかは一緒に同じインターフェイスを使用します。これは、さまざまなアプリケーションに適した動作と操作の共通セットです。 均一なインターフェースは、多くの場合、弱い結合の良い例です。



正しいコードベースを完全にモジュールに分割する必要はありません。 モジュール化されているだけで、コードを書くプロセスがより面白くなります。 レゴパーツは、一緒に遊ぶのが楽しいのと同じです。 正常なコードベースには、常にわずかに過剰な機能があります。また、動きのある部分の間の距離も正確であるため、手が動かないようになっています。



疎結合されたコードは必ずしも簡単に削除できるとは限りませんが、コードの置き換えや変更は常にずっと簡単です。

ステップ7：コードを書き続ける

以前に記述された行に関係なくコードを記述する機能により、新しいアイデアを試すプロセスが非常に容易になります。 いいえ、モノリスの代わりに常にマイクロサービスを作成する必要があると言っているわけではありませんが、システムではメイン作業に加えて1つまたは2つの実験を実行できる必要があります。



機能フラグは、以前の決定を変更する1つの方法です。 機能フラグは多くの人が新しい機能を試す方法と見なされていますが、新しいバージョンを再デプロイせずに変更を追加することもできます。



Google Chromeは、優れた機能を備えたすばらしい例です。 Chrome開発者は、定期的なリリースサイクルを維持することの最も難しい部分は、長時間実行される機能ブランチをマージする時間の大きな無駄であることに気づきました。



再コンパイルせずにいつでも新しいコードを有効または無効にする機能により、既存のメインコードを損なうことなく、大きな変更を小さなマージに分割できます。 さらに、同じコードベースに新しい機能が早期に登場したおかげで、チームは、長寿命の機能の開発がコードの他の部分に影響を与える状況を予測することができました。



機能フラグは簡単なコマンドラインオプションではありません。 これは、マージされたブランチまたはメインコードから機能リリースを分離する方法です。 新しいソフトウェアのリリースに数時間、数日、または数週間かかることがある状況では、プログラムの実行中に決定を変更する能力がますます重要になっています。 シニアレジリエンシーエンジニアに尋ねると、システムが深夜に目を覚ます場合、作業中の変更が必ず含まれるようになります。



このステップは、反復そのものではなく、フィードバックループの必要性に関するものです。 再利用可能なモジュールを書くことではなく、コンポーネントを分離して変更を加えることについて。 メインコードに変更を導入することは、新しい機能を作成するだけでなく、古い機能を削除することも覚えておくことが重要です。 拡張可能なコードを書くことは、3か月でプロジェクトがすべてうまくいくことを望んでいるようなものです。 削除できるコードを書くことは、逆の仮定に基づいた作業です。



テキストで前に説明した戦略-レベル、分離、共通インターフェース、構成に分割することは、優れたソフトウェアを書くのではなく、時間とともに変化するソフトウェアを作成するのに役立つように設計されています。

「したがって、管理上の問題は、パイロットシステムを作成して破棄するかどうかではありません。 あなたはとにかくそれを行うでしょう...したがって、それを最初から捨てることを計画してください。 とにかく、そのようになります。」 -フレッドブルックス。

もちろん、これは絶対にすべてを捨てる必要があるという意味ではありませんが、一部を削除する必要があります。 良いコードを書くことは、それを最初から正しく行うことを意味しません。 優れたコードは、指先で混乱することのない単なるレガシーコードです。 また、優れたコードは簡単に削除できます。