したがって、プログラマーが新しいモジュールを作成したり、既存のシステムに機能を追加したりするタスクに直面していると想像してみましょう。 経験豊富なスペシャリストは何をしますか？ 彼は自分で中国茶を注ぎ、椅子に寄りかかり、鉛筆を取り、考え始めます。 彼はモジュールの構造を描き、エンティティー、インターフェース、およびそれらの間の相互作用を考え、特定のメソッドのレベルまで下げ、おそらくインターフェース上で単体テストを作成します。 そうしてはじめて、既存の構造をコードで埋め始めます（または、このタスクを多数のヒンドゥー教のコーダーに委任します）。
次に、この場合に典型的なジュニアが何をするかを見てみましょう。 問題があります-解決する必要があります。 彼らは大学でそのように教えられました。 それらの多くは、まだ「コードを書く、## dy！」という限界スローガンの影響下にあります。 そのため、彼はインスタントコーヒーを注いで、より強烈で大きなものをヘッドフォンに付けて、数時間ストリームに入ります。
すべては何もないでしょう。 私はコーヒー、ヘッドフォン、または流動状態に対して何もしません。 さらに、これは通常、最も効率的で、多くの場合、優れたコードを記述する唯一の方法です。 しかし、私たちは若くて経験の浅いプログラマーの典型的なケースを考えているので、結果を見てみましょう。
それはどのように見えますか
まず、機能が実装されます。 ほとんどの場合に機能し、非常に満足のいくものです。 私が最初にやりたいことは、若い専門家がタスクに非常に迅速に対応し、彼を称賛し、次のものを与えたことを喜んでいるということです。 しかし、コードを覗いてみてください。 すぐにフラグメントが実装された理由をすぐに理解できます。 そしてそれは怖いでしょう。
ここに私が通常「意識の流れのダンプ」と呼ぶコードがあります。 それを実現しようとせずに、何かを返して変更しようとせずに、単一のブロックで記述されているため、私はそのようなコードを呼び出します。 以下にその主な特徴をリストします。
まず、コードは通常1つの非常に長いメソッドで構成されます。 たとえば、データベースへの接続を順番に初期化し、目的のリクエストを作成し、データを受信、処理し、最終プレゼンテーション用にHTMLを作成します（webdevとします）。 著者は、彼が現時点で考えていることについて書いています。彼は完全に流れの中にいて、問題の解決に集中しています。 彼の意識は徐々に問題を解決し、これらのステップはすぐにコードに反映されます。
第二に、このコードは通常、不要になったコメントアウトされた行や部分で埋められます。これは捨てるのは残念であり、残される必要はありません。
第三に、通常、このコードでは基本的なユースケース、標準条件、および分岐のみが処理されます。 標準のユーザー動作からわずかに逸脱すると、コードは容赦なくクラッシュし、未処理の例外でクラッシュします。
なぜ悪いの
部分的には、このことについて少し高めに書いていますが、まだかなりの数の要因を指摘する必要があります。
そのようなコードからの最大の悪はそれを伴う絶対不可能です 。 実際、数日後には「通りから来た男」だけでなく、著者自身もこの作品の内部で何が起こっているのか、この支部が責任を負っているのを理解できなくなります。 明らかに、著者を含むプログラマは、しぶしぶだけでなく、非常に非効率的にそのようなコードをサポートすることに従事します。
ちなみに、これはプロジェクトの目標だけでなく、 納期を引き延ばし、 品質を低下させます 。これは間違いなくPMaを混乱させます。 このようなコードを使用すると、チームのモチベーションを2つの方向から深刻に損なうことになり、プログラマーの仕事の好きな側面を「私はクールで面白いことをしています」と「素晴らしい仕事をしています」から奪います。
「意識の流れ」の不快で不快な特性のもう1つは、一見「すべてが機能する」ため、問題がすぐには見えないことです。 非常に多くの場合、そのようなコードをテストするとき（もちろん、ブラックボックスの原理によって）、テスターは再現が非常に難しいバグに遭遇します。 通常、それらは、完全に驚くべき方法でコードの片方がもう片方に影響を与える場合、コールの質量の構造とそれに関連する暗黙の「ヒント」が完全に欠けているために発生します。
したがって、既存のプログラマーおよびプロジェクトマネージャーの「犠牲者」貯金箱にテストの専門家が追加されます。 結論として、この穴だらけの傘の下で完全なプロジェクトチームを編成するために、製品マネージャー（またはカスタム開発の場合は顧客）が製品に新しい機能を効果的に追加できず、アナリストは最小限の変更が可能かどうかわかりません。 、および「検索フィルターの動作をわずかに変更する」という簡単な文のために、プログラマーから非常に高い期限（またはわいせつな表現）を聞くかどうか。
結論は簡単です。「ダンプ」は戦わなければならない悪です。
この記事があまりにも理論的ではないように、私はこれを行う方法についていくつかのヒントを提供しようと思います。それを会社で実践しています。
対処方法
このコードに出くわしたときに最初に理解すべき最も重要なことは、 「これは正常です」です。
まだ「ダンプ」に苦労し始めていない（そして前任者がこれをしていなかった）場合は、おそらく、チーム内にこのアプローチを使用するプログラマーが数人いて、彼らはすべてを正しくやっていると心から信じています。
学生のベンチから直接あなたのチームに連れて行かれた新人も「ダンプ」を乱用する可能性があります。
そして、これは昨日の生徒の通常の行動であり、生徒は課題に直面し、それを達成しなければなりません。 彼は目標を見ている-望ましい機能を実装するが、悪いコードを作成するとき、彼はアプローチせず、それから離れるだけであることを理解していません。
したがって、ダンプを処理するために最初に行うことは、 定期的なコード検査を導入することです。
優れたアーキテクチャ、適切な分解、透過的なコード、およびその他の優れた形式のルールの「精神と文字」を理解している経験豊富な専門家がチームにいる場合、彼はそれを最初に検査する必要があります。
同時に、パフォーマーとしての彼、そしてリーダーとしてのあなたは、検査の目的は不注意なコーダーに抵抗を与えることではなく、美しい（飾り気のない！）コードとアーキテクチャを正しく書き 、「感染」させる方法を彼に教えることであることを理解する必要があります。
あなたのチームが初心者で構成されており、そのような専門家がいない場合、自分で彼を教育する必要があります。
コードの改善は、大きな（場合によっては巨大な）メソッドを小さくてきれいなメソッドに分割することから始めるのが最善です。 通常、各ピースがステップで何をするかをプログラマーに尋ね、これらのステップを別々のメソッドに入れるだけで十分です。 次に、それぞれの意味が単純で理解しやすくなるまで、同じ方法（再帰という言葉があります）で各メソッドを分離する必要があります。 この再帰的なアプローチについては、次のいずれかの記事で詳しく説明する予定です。
さらに、「20行を超えるメソッドを記述しない」というルールを簡単に設定し、検査でチェックできます。 プログラマーは、確立された「標準」に違反しないように、「ダンプ」を分割する方法を熟考する必要があります。 もちろん、このルールは、他のルールと同様、ドグマと見なすことはできません。 20行をはるかに超えて記述しなければならない方法を簡単に想像できます。 しかし、いずれにしても、プログラマーはそれについて考え、コードを記述するプロセスをより意味のあるものにします。
実際、それについて考えることは、すでに非常に大きく、しばしば高品質のコードへの道の決定的なステップです。
さらに、同じスキームに従って、プログラマーに1つのクラスをいくつかに分割し、後者をレイヤーやモジュールなどの形式で編成するように教えることができます。
しかし、それは別の話です。 そして今、プログラマーはあなたを驚かせて見ていますが、なぜ彼の素晴らしい方法は、仕事に2日かかり、「すべてを機能させる」のか、あなたは突然好きではありませんでした。
彼に説明してください！