前文
あなたがあなたの会社の分野の1つを率いるように頼まれたと想像してみましょう。 もちろん、あなたはチームのすべての人々を知っており、廊下を繰り返し横断し、企業のパーティーでビールを飲みました。 過去のリーダーは良い人でしたが、彼の計画は変わり、彼は辞めました。
そのため、この投稿を受け入れるとき、チームに精通します。経験のある潜在的に強力な開発者がいるようで、有望な後輩がいくつかいるようです。 しかし、何かがすぐに目を引きます。 そして、仕事で忙しいこれらの賢い人々を長く見れば見るほど、これはチームではなく「開発グループ」であることに気づきます。 そして、彼らが書くこと...あなたはプログラマがそのようなコードを書くことができるとは思わなかった。 6,000行のコードのクラス、タイプライターで書かれたテキストの10ページを占めるメソッド、Lernean hydraの頭のように分岐するケースで、塑像用粘土のアーキテクチャを調べます。 そして、あなたは非自発的な質問を持っています：そのようなチームで何かをすることはまったく可能ですか？
そして、私の答えはイエスです。 そしてそれは必要です！
気づき
それではどこから始めますか？ 意識的に悪い書き込みをする人はいないことを理解することから始めなければなりません。 おそらく、前のリーダーは、現在の財務指標と計画に完全に焦点を合わせて、病棟のコードの品質をまったく監視しなかったか、同じ現在の財務指標に対してコードの品質を意識的に犠牲にしました。
「現在」という言葉を特に強調しました。 いずれにしても、悪いコードは最終的に製品のさらなる開発を妨げ、そのサポートを顧客やプログラマーにとって地獄だけでなく、会社にとって非常に不採算なビジネスにもします。 この場合、あなたの会社は、開発に投資する代わりに、ミスを修正し、製品の内部のugさの重みで死にかけている人の生活を維持するために多額の投資を強いられます。 または、適切なアプローチで長期にわたって存続し、ビジネスに利益をもたらし、開発者に喜びをもたらすことができる製品の新しいバージョンの作成にリソースを費やします。
一般的に、確立されたプログラマーが突然正しく書くためには、奇跡または長い骨の折れる作業が必要です。 あなたの楽観にもかかわらず、私は第二の道を選ぶことをお勧めします。 このパスは、3つの異なるステップで構成されています。これについては、以下で展開します。
おとぎ話のイヴァン・ツァレヴィッチは、復活して、最初に死んだ水で水をやり、それから生きていました。 おそらく最後に彼はいくつかの賢者ヴァシリサと結婚した。 ソフトウェア開発では、ほぼ同じです。
最初のステップ。 嫌い
これはおそらく、私がここで引用するすべての中で最も物議を醸す論文です。 彼らはしばしば私に同意しませんでした（それは性格に変わり、コーナーで不快なスニッフルになりました）が、その有効性は実際にテストされています。
そのため、プログラマーは最初から憎悪を植え付ける必要があります。 500行とクラスが家の大きさの1つのメソッドで構成される場合、悪いコードや汚いコード、馬鹿げたミスを嫌います。
どうやってやるの？ オープンコード検査の実施を開始します。 週に1回チーム全体を集め、誰かがコード内の汚れやアンチパターンを探すようにします。 悪いコードを良いコードと区別するスキルがある場合は、自分で参加してください。そうでない場合は、この点に関して信頼できる人に尋ねてください。
いくつかのそのようなレビューの後、プログラマーはほとんどの場合、マジックボタンとは何か、「レンダリングメソッド」リファクタリングを呼び出す場所をすでに理解しているでしょう。 繰り返しますが、誰も悪いコードを書くことを好まないと仮定します。 ただ多くは彼が悪いことを理解していません。
繰り返しますが、個人的にはなりません（誰がこれを書いたのですか？Vasya？Vasya、あなたは恥ずかしくないのですか？あなたは賞金なしのままになります！）。 しかし、悪いコードをspareしまないでください。 「 潜在意識のこのダンプがどのような目的のためにコードに注がれたのか」を尋ねるのは完全に普通のことだと思います。 コードがゴミだからです。 あなたがそう言うまでプログラマはこれを理解しないからです。 大変ですが効果的です。
ステップ2 情熱
プログラマーのパターン、優れたアーキテクチャーの例、美しいコードを示してください。 これで感染させます。 「工場」や「装飾者」のようなスマートな言葉を投げさせて、彼らの専門的な能力を実感させ、そのコードには役に立たない戦略と挑発的なテンプレート手法がたくさんあります。 このステップは簡単ですが、最初とほぼ同時に行う必要があります。 ソフトウェアアーキテクチャの理論的基礎に関する知識の事実を設計し、考え、楽しみましょう。 これは有益であり、ところで、非常にやる気を起こさせます。
しかし、実現する必要がある主なことは、非常に魅力的であり、プロのチームと仕事をする感覚を作り出すにもかかわらず、 このステップで停止することはできないということです。
ステップ3 正気
プログラマーがファウルコードから発生する臭いをキャッチし、異なる色のウィンドウインターフェイスを作成するためのファクトリーを構築できるようになったので、次は主なこと、つまりリアリズムについて考えます。 デザインパターンは適切な場所と適切な時間にのみ適用され、メソッドは3行以上で構成でき、一般にテキストの文字列定数が有効な場合があることを説明します。 まず、シンプルで透明性のある安定した作業システムを作成する必要があることを説明し、その後で「完璧なアーキテクチャソリューション、93％が設計パターンでカバーされる」ことを説明します。
これが最も難しいことです。 最も難しいのは、「コードへの無意識のダンプ」がなぜ難しいのかを説明することですが、ボタンラベルに一定の行を作成するためのファクトリーの実装もそれほど複雑ではありません（ローカライズは提供されていません）。 しかし、あなたはそれを取り除く必要があります。 このステップを踏まないということは、プログラマーが以前よりも少し上手に書いているのに、彼はよく書いてアーキテクチャを理解しているという永遠の自信に任せることを意味します。 そして、これはどのチームにとっても災害です。
したがって、なぜ「工場は良い」、そして今は「工場は悪い」のかを説明するためにあらゆる努力をする必要があります。 しかし、彼らは完全に報われると確信しています。
結論のいくつかの言葉
まあ、実際には、それだけです。 私自身の経験から言えば、「憎悪」と「情熱」は約6か月で教え込まれ、「正気」のステップを完了するには2年以上かかることがあります。 そして、「現在の財務実績」がしばらく沈む可能性が高いことを覚悟してください。 しかし、代わりに受け取ったチームは、長期的なサポートと拡張に適した軽量できれいなコードを作成する方法を知っているので、投資する価値があると考えています。