同僚がコードの保守性を重視しない場合の対処
同じソフトウェア開発部門で数年働いています。その間、開発者の平均滞在期間は6〜9か月です。一握りの人が2年以上前から出回っていますが、20人程度の開発者の大多数が比較的高い頻度で行き来しています。
その結果、私たちのプロジェクトの大部分はメンテナンスの悪夢になりました。請負業者がやって来て、いくつかのパッチリリースをコーディングして、去ります。
私たちの部署には開発ガイドライン（私たちはTDDを行っています）がありますが、強制されていません。
最近、私は私たちの部門がより保守しやすいコードを作成するように強く要求しています。私は必須のコードレビューと必須のTDDを求めてきました。経営陣は私に完全に同意します...理論的には。
実際には、TDDは常にウィンドウの外に出ます。私たちの領域では、今すぐ提供する必要があるという正当化は常にあります。
私は、私たち自身のために穴を掘っているだけであり、ソフトウェア開発への現在のアプローチは、私たちの部門に多大なコストをかけていることを同僚とどんどん続けています...しかし、それは耳が聞こえないようです。
コードの保守性の価値を同僚に見てもらうにはどうすればよいですか？長期的なビジョンのない短期的な勝利は持続可能ではないことをどのように説明できますか？
あなたが説得する必要があるのはあなたの同僚ではありません。
経営陣があなたに本当に同意した場合、彼らはコードレビューとTDDを実施することになります。それがそうであるように、彼らはあなたがそれらを煩わせるのをやめるように彼らの頭をうなずいているだけです。
ここには2つのオプションがあります。
従業員の離職率が高いことや、クライアントが直面しているバグレポートの多くが彼らに費用をかけていることについて、上級管理職に売り込みます。強制的なコードレビュー、TDDなどを含む実行可能なソリューションを売り込みに含めます。タイムフレームをラップして、配信することを約束します。彼らはあなたにそれを修正することを担当するマネージャーにするかもしれません。
去れ。それが崩壊することがわかっているなら、なぜ固執するのですか？
これは、ある開発者が長期間独占的にプロジェクトに取り組んでいるときによく起こります。彼らは、落とし穴がどこにあり、どのようにそれらを回避するかを知っているので、彼らは一般にそれらが存在することを気にしません。共通のコーディング標準とベストプラクティスを採用するように開発者を説得する一番の方法は、時々他の開発者のコードに取り組んでもらうことです。自己文書化コード、適切な例外処理、デッドコードのクリーンアップなどの価値がすぐにわかります。これを1〜2回行うと、開発者仲間がこれらのプラクティスを喜んで採用します。
マネージャーにとって、それは通常別の話です。優れたマネージャーは、開発者からの苦情に対応し、会社のコーディング慣行を改善する方法を積極的に探します。悪いマネージャーは、製品が時間通りに外に出る限り、気にしません。これらのタイプのマネージャーの場合、あなたはshowを持っているでしょう。コードベースが混乱しているため、新しい開発者のトレーニングに必要な時間の2〜3倍、または数分で修正できるバグを見つけるのに数日かかることを説明します。可能であれば、保守が不十分なコードに関連するコストの実際の具体例を示します。