そして、プロジェクトの責任者であるあなたは、同時に、フラストレーション、プログラマの仕事に対する不満、そして、健全なフレームワークを超えて予算にほとんど手に負えない失敗したプロジェクトに必然的に続く不快な結果を期待するという複雑な感情を抱いていました。
ほとんどの失敗したプロジェクトには1つのパターンがあります。 それらは完全に構造を欠いています。 そのようなシステムのアーキテクチャを「プラスチシン」と呼びます。
ちょっとした抽象化
適切に設計されたシステムは、アーキテクチャによって定義された明確なエッジと有能なコードによって実装された直線を持つワイヤーキューブによって表されます。 それらを変更する必要がある場合は、適切な場所でワイヤーフレームのねじれを解き、新しい部品を追加してから、すべてを再度組み立てます。 このようなシステムは硬く、理解しやすく、構造はほとんどすぐに見えます。
しかし、残念ながら、他にもあります。 私は彼らが多数派であることを恐れています。 これらのシステムは、形のないプラスチシンボールのように見えます。 最初に、基本機能の小さなボールが作成されます。 おそらく、その奥のどこかに隠されたワイヤーフレームの有能で思慮深いアーキテクチャーがあるでしょう。 しかし、その後、すべてが変わります。 「機能していれば」という原則に従って、新しい機能、新しい修正および修正はそれぞれ急いで行われます。 そのような修正を行うたびに、私たちはプラスチシンの塊を取り、既存のシステムの側面に固執します。
このような修正は数十、数百、または数千にも及ぶことがあります。 プラスチシンの断片はランダムに成形され、サイズと形状が異なり、多くの種類があります。 外観では、すべてが機能し続け、新しい機能が追加され、エラーが修正されますが、システムの内部から急速に複雑になり、別々のマルチカラーのピースで構成される形のない塊に変わります。
そして今、ある時点で、システムのいくつかのコンポーネントに影響を与えるタスクが表示されます。 通常の動きで、私たちは別のしこりを彫ります...しかし、突然、まったく異なる機能が機能しなくなったことがわかります。 別のピースを貼り付けて修正すると、さらに2つのエラーが発生します。 そして、これは連鎖反応です。
最良の場合は、グローバルで複雑で非常に高価なリファクタリングが続きます。これにより、システムを予定どおりに予算内で提供するというすべての希望が失われます。 最悪の場合、システムは「現状のまま」で提供され、膨大な数のエラーが発生し、拡張や変更が絶対に不可能です。 まれな例外を除いて、そのような製品は市場で失敗し、リーダーにmy罪が課せられ（私の意見では、当然のことです）、その後彼は亡命に送られます。
いくつかの理由
なぜこれが起こっているのですか？ 多くのオプションがありますが、そのうちの3つは私にとって最も重要なようです。
1.プロジェクトが実施されている不適切な時間枠。
誰もが急いで、緊張しています。 顧客はフライパンで回転し、上級管理職が契約を破ると脅します。 十分な睡眠をとらず、休みなく3週間働いた後、プロジェクトマネージャーはプログラマーを急いで駆り立てて、仕事を早くするように叫びました。 先月オフィスに住んでいてカフェインに取り組んでいるプログラマーは、この不幸をすぐに終わらせるために可能な限りのことをしています。 考える時間はありません。 設計する時間はありません。 機能を発行する必要があります。 ひとつずつ。
通常、そのようなプロジェクトは独自のバグで窒息します。 受け入れテストの段階で、顧客は135個のエラーのリストを作成します。そのうちの98個が重要です。 そして、奇妙なことに、彼らは確かに重要です。 無責任な「プラスチシン」構造を考慮して、それぞれを修正するのに1〜2日かかります。
そのようなプロジェクトに対する彼の会社の態度を考慮して、結果を読者に任せます。
2.フローティング仕様
プロジェクトの初期仕様が十分に詳細でなく、機能が曖昧に記述されており、機能の一部がまったく指定されていない場合、そのようなプロジェクトは「塑像用建築」のリスクにさらされることが保証されます。
最初は、すべてが「期待どおり」に設計および実装されています。 システムは、通常の構造、適切なアーキテクチャ、およびクリーンなコードを備えている場合があります。 しかし、ある時点で（通常、顧客に説明するときは配達に近い）、一部の機能が顧客の望むものとまったく一致しないことが判明しています。 そして、問題は、メインプロジェクトの完了後に顧客にRFCフェーズへの実装を延期することを要求することが可能なほど詳細に記述されていなかったということです。
その結果、実際には、考慮された前のケースで-時間と予算がない場合にコードに大幅な変更を加える必要があります（プロジェクトが終了し、最終的な支払いが通常最大になる）。 さらに、プラスチシンコムが成長し始め、エラーが現れ、さらに多くのエラーが発生し、エラーが雪崩します。その結果、グローバルで長期にわたるリファクタリング、または不安定な製品になります。
3.偶然開始されたプロジェクト
これはおそらく最も恐ろしいオプションです。 誰もプログラマーを見ていません。アクションは調整されていません。コード検査は実行されていません。 プロジェクトマネージャーは、職場でのプログラマーの空き状況をチェックし、場合によっては流“に「創造性」の結果を見ることに制限されています。 これは通常、顧客に製品をデモンストレーションする必要があるときに発生します。
すべてのプログラマーは自由を満喫し、「永遠を創造します」。 半分は自転車を発明します。 他の半分はそれに四角い車輪をボルトで固定します。 彼らはコードを書きます。 クラスごと、メソッドごと。 ただし、ブランチに数十の条件を追加することにより、古いクラスまたは古いメソッドにコードが追加される場合があります。 簡単です。 とても速い。 考えないでください。 上司は満足しており、プロジェクトは急速に動いています。 明らかに、一定の限界まで。 その後、すべて同じプラスチシンボール。 すべて同じ結果になります。
どうする
その結果、「プラスチシン」コードを防ぐ方法が問題になります。 無視できない多くの重要なことがあります：
プロジェクトには、システムアーキテクチャを担当する明示的に専任の開発者がいる必要があります（さらに、プロジェクトの開始時だけでなく、開発全体を通じて）。
定期的なコード検査が必要です。リーダーの参加が非常に望ましいです。 技術専門家でなくても、彼は自分の病棟がどれだけ多くの間違いを犯すかを知っているでしょう。
すべての仕様変更を修正し、それに応じてコードを再構築する必要があります。
可能であれば、「パッチ」を除外する必要があります。 はい、バグの「症状」を破壊することは簡単ですが、それは病気の症状を治療することに似ています。 このエラーが次に発生したときにどの器官が影響を受けるかは明確ではありません。
しかし、実際には、私は1つだけアドバイスを与えることができます。 私の意見では-最も重要なこと： 考える！ コードを書く前に考えること、それを書く過程で考えること、そしてコードが書かれた後でさえ考えること。 プログラマーなら、アーキテクチャを考慮せずにコードを書き始めないでください。 あなたがマネージャーである場合、これをプログラマーに禁止してください。 また、塑像用粘土アーキテクチャはプロジェクトに表示されなくなります。