こんにちは、Habr！
きれいなコードについて話すことは終わりではありませんが、Dave Nicolettaの次の記事は非常に比phor的で、できれば翻訳に値するものです。 著者が元の記事で事前に読者に警告しているように、それは少し「啓発的」にしましょう。
良い読書をしてください。
自宅では、長年にわたって、悪い習慣が定着しています。 任意のツールを使用して、その場所に置くのを忘れていました。 次に誰かがそれを必要としたとき、彼らは問題を解決するよりもツールを探すのにより多くの時間を費やさなければなりませんでした。 最も悲しいことは、このツールを最後に取ってどこにでも投げた人でさえ、まったく同じ検索に運命づけられたことです。 私たちが持っているツールを探すよりも新しい機器を購入する方が速いことがよくわかりました。 -どこかに横たわっています。
そこで、4つのフィリップス中型プラスドライバー、3つのフラットスロット、余分なトングとレンチのセット、アダプターのセットを入手しました。 ペン、テープのかせ、電池、その他の商品が至る所に散らばっている印象的なコレクションは言うまでもありません。
決定したら：それで十分です！ すべてのものに場所を割り当てて、在庫を整理します。 慈善団体に寄付された手渡された道具。 私たちは、自己規律を培うためにあらゆる努力を払い、常に彼らと協力してからツールをその場所にのみ置きました。 単位時間あたりの作業の質と量が大幅に増加しました。 ストレス、無駄なお金、甘やかされた気分はずっと少なくなりました。
企業のガレージで注文する
企業のガレージで働く自動車整備士がツールをどこにでも落とすとしたらどうでしょうか？ 彼らは実際に働くよりもツールを探すのに多くの時間を費やすでしょう。 詳細は間違った場所に置かれ、紛失、錆び、台無しにされ、単に盗まれます。 供給コストは大幅に増加します。
タスクを完了するにはもっと時間がかかりますが、作業の質は低下します。 メカニックが錆び、磨耗、破損したツールを使用しなければならない場合、パーツを適切に取り付けて固定することは困難です。 さらに、ワークショップに混乱を配置する習慣は、必然的に仕事の質に影響を与えます。
顧客は無限のエンドジョブ転送にうんざりします。 すぐに彼らはより信頼できるワークショップに行くでしょう。 どういうわけかあなたなしで。 おそらく、ソフトウェアの開発とサポートとの類似性はすでに明らかです。
ソフトウェア開発に秩序を置く
具体例を見てみましょう：増分リファクタリング。
この表現は多くの人にとって困惑しています。 どのような単語がそれらを混同するのかわかりません：「増分」または「リファクタリング」。
増分（段階的）リファクタリングは、大規模とは根本的に異なります。 多くの人にとって、リファクタリングは必ず「大規模」であり、誰かが「認可」しなければならないので、おそらく作業を引きずり出さなければならないようです。 実際、作業中にリファクタリングを怠ると、すべてが大幅に遅れます。
私を含むほとんどの技術コーチは、この場合の違いをほとんど説明しません。 この違いが定義上複雑なためではなく、言葉で表現するのが本当に難しいからです。 ただし、利用可能な在庫を慎重に検討し、供給を監視する習慣は、この場合の良い例えだと思います。
段階的なリファクタリング
段階的なリファクタリングを行うことは、作業の高さでもワークベンチの順序を維持するようなものです。 ドライバーを使用して-それを所定の位置に置きます。 新しいタスクを行う前に、このためのワークショップを再構築することはありません。 むしろポイントは、終了する能力です...開始したものを終了する方法です。 両端を剥ぎます。
段階的なリファクタリングには余分な時間がかかりませんし、上から誰かの許可を必要としません。 そのため、急いでいる必要がある場合は、コードをクリーンアップしないように許可を求める必要があります。 コードを常にきれいに保つ能力は、実際にはプログラマーの基本的な専門的スキルと見なされるべきです。 今日では、「クリーンコード」にプロパガンダが必要であり、一部のプログラマーもそのような純粋さをもたらすことに反対しているのは残念です。 段階的なリファクタリングには、大規模なアーキテクチャのリファクタリングとはまったく関係がありません。これには、慎重な計画、時間、お金、および人員の割り当てが必要です。
スカウトルール
プログラミングには、いわゆる「スカウトルール」があります。コードは、少なくとも受け取ったときと同じくらいきれいに保ちます。 同じことが自宅での作業ツールの保管にも当てはまります。 ペンチを探しているのに、マイナスドライバーが誤って十字架に差し込まれ、十字ドライバーがマイナスになったことに気づいた場合、その過程でそれらを所定の位置に置きます。 これを行うために公的な承認は必要ありません。
これが段階的リファクタリングの仕組みです。 コードの一部である前に、利用可能な構成のリストに新しい条件を追加する必要があります。 リストは、大きなif / elseブロックとして実装されています。 条件を追加しながら、スイッチまたは選択演算子として再設計する必要があると判断しました。 議論することができます：これはif / elseブロックよりも本当に優れていますか？ はい、あなたは正しいです：あまりない。 しかし、少し良くなりました。 誰かが次にこのコードを読んだとき、あなたは彼の開始位置を改善したので、彼はそれをさらに改善することができます。 これまでにこのようなことをしたことがあるなら、すべての条件を注意深く読んだだけで、重複する構文、次に最適でない式の順序が見つかることがあることに気づいたでしょう。 たぶん、あなたは決して満たすことのできない条件に出くわしました。あるいは、制御シーケンス全体がif / elseブロックを通過し、いくつかのケースがまったく処理されない論理的な「穴」にさえ遭遇しました。 テクニカルサポートサービスから対応するチケットを受け取った深夜ではなく、今すぐ発見したことを喜ぶだけです。 そのような瞬間、目がくっついたとき、混乱したコードを理解したいという欲求はまったくありません。
アプリケーションにいくつかの新しい機能を追加して、作成した関数/メソッドがコードベースに既にある別の（別の）メソッドに非常に似ていることに気付くかもしれません。 ほんの数秒を費やしただけで、シックなIDEのサービスで提供される追加のツールがなくても、このような重複を取り除きます。 自己規律に慣れており、このケースをカバーするマイクロテスト（ユニットテスト）がすでに記述されていることを保証しているため、ためらうことなくリファクタリングできます。 手動リファクタリングはひどいものではありません。 最後に、少なくとも1つの理由を考え出してください。
「長期」は通常、見かけほど長くはありません
多くの場合、リファクタリングは「長期的な」メリットをもたらすとさまざまな人々から聞いています。 理論的には、ここでは現実の世界ですが、常に厳密な条件で作業を引き継ぐ必要があります。 ただし、小さな段階的なリファクタリングによってコードの純度を維持することについて話す場合、「長期」は他の誰かがコードベースに触れる瞬間まで正確に持続します。 次回まで正確に。
悪いニュースは、逆のことが当てはまることです。 作業中にコードをクリーンアップしないと、すぐにコードが劣化します。 私たちには、問題が始まるまで免罪で結婚を積み重ねることができる10年間の「エアバッグ」がありません。 次の変更が必要になると、私たちから許容できないほど長い時間がかかり、コード回帰のリスクが高まり、適切に注意を払わない状況が悪化するだけです。
顧客の欲求を満たすためだけにハッキングしている（そして、彼はできるだけ早く完成品を望んでいる）場合、コードを州に持ち込んだため、迅速な変更が行われないことを確認した後、これらの要求にどのように対応し続けるのでしょうか？混乱、それを維持することは不可能ですか？
速いもの、遅いもの
どんなに早くアレンジしても、顧客は常にあなたがもっと一生懸命働くことを望みます。 リリースまでの時間を短縮する最も効果的な方法は、すべてを正しく行うことです。 うまくやる 常に例外なく、常に端をきれいにします。 「加速する」ためにコーナーを切ります。実際には、一時的な「長期」ではなく、ここで、そして今だけ減速します。
顧客があなたがより速く働くことを要求するとき、これは彼があなたが不注意に働くことを許可することを意味しません。 当然のことながら、彼は、各要求の後に、彼が高品質に興味があることを思い出させてはならないことは明らかです。 高品質は私たちの仕事の構成要素の一つとして暗示されています。
エンジニアとして、段階的なリファクタリングを専門的な活動の基本要素として検討するかどうかを選択します。 外科医が手術前に手を洗う時間があるかどうかを会計士に尋ねないのと同様に、適切に働くことができるかどうかは尋ねません。 操作に費やされる時間は、操作の成功に必要な時間とまったく同じです。 患者は虫垂を慎重に除去する必要があり、退院後、人は通常の生活に戻ることができます-傷の感染や腹部のタンポンはありません。 人が必要以上に10分早く手術室から連れ去られた場合にのみ悪化し、その後合併症が始まります。
多くの場合、この場合、彼らは「すべてが科学に従って行われた」場合、それは「長すぎる」ことが判明します。 いいえ、実際には、「長すぎる」とは、適切なプロフェッショナリズムなしで作業が急いで行われた場合に結果を修正するのにかかる時間です。 感染からの回復は、患者とその家族にとって本当のショックです。これは必然的に彼の仕事に影響を与えます。 忘れられたタンポンを腹部から切り取らなければならない2番目の手術は、はるかに深刻な介入であり、初めて急いで手術を受けた場合にのみ必要となります。
プログラミングの際に、誰かが急いで書いたという事実のためにコードの5つのリグレッションに行かなければならない場合、「時間の節約」について話す必要はありません。 それどころか、変更はより長く行われます。 作業は、正しく行われるまで「完了」しません。 チームが「ドラフト準備」後のエラーの修正に数時間と数日を費やさなければならなかった場合、これは他の有用な作業に費やすことができる時間を失います。 これは利益の損失です。
このようなエラーは波のような結果をもたらし、時間とお金の長期的な損失につながり、時には顧客の損失にもつながります。 追加のストレスがエンジニア自身の肩にかかっています。 士気が低く、離職率が高い。 ここから、ますます厳しくなり、道徳と仕事への関与がさらに減少します。
比phorとしての技術的負債
段階的なリファクタリングのトピックに目を向けるたびに、誰かが間違いなく技術的な負債を思い出させます。 彼らはこう言います：「私たちはコーナーをカットするだけでいいほどの締め切りがあります。」 この場合、チームはビジネスのニーズに応じて、技術的な負債を意識的に蓄積します。
そう言う人はこの比metaを理解せず、おそらく比metaもまったく理解しません。
比phorは、特徴付けられているものの完全で包括的な説明を意図したものではありません。
比phorは、一般的に、このことのある側面の印象を概説するのに役立ちます。
人々は物をその比phorで置き換え、その後、あたかもそれがあったかのように比phorで動作する傾向がある
説明されているものは、まったく同じものです。 いいえ、これは同じものではありません。 ポイント。
また、人々はメタファーを元のコンテキストを超えて広く解釈するのが一般的です。 したがって、比phorの意味はあいまいになり、有用性は次第に低下します。
ワードカニンガムは、金融業界における顧客とのやり取りを説明する技術的負債の比metaを提案しました。 彼は、この特定のコンテキストに適した比phorを探し、機会を徐々に実現することでフィードバックループを作成し、プログラムを絶えず最適化する方法を強調しました。 彼は「急速な発展の錯覚を作り出すためにコーナーを切る」ことを意味しませんでした。
技術的負債のメタファーの元の概念は、コードが必然的にきれいに保たれることを暗示していました。 コードに残された問題を理解している人々は、その解決に向けて段階的に移動し、コードは常にそのような漸進的な改善ができるように十分に正確です。 いくつかの技術的な理由が、コードがガタガタで、絶え間ない修正が必要な理由を正当化するかもしれないという事実の問題ではありません。
仕事を迅速に引き渡すためにコーナーを切ることは、技術的負債の蓄積ではありません。 これはよくあるハックです。
誰が責任を負いますか？
高速配信を実現するには、作業の問題を最大限に取り除く必要があります。 これらの問題の1つはジャンクコードです。 自制心を働かせることを学ぶことで、この障害を段階的に取り除くことができます。 この場合、「ウォーターフォール」モデルまたは「攻撃」に応じて、どのように作業するかは重要ではありません。 キーボードに触れるたびに作業方法を選択します。
まとめます。 エンドのクリーンアップを含めて正しく作業すれば、クライアント、スポンサー、マネージャー、将来、そしてもちろん私たち自身のコードをサポートする人だけに利益をもたらすでしょう。