開発時の同僚の対応、アドバイスが必要
私は現在のプロジェクトアーキテクチャを開発し、自分で開発を始めました（revision 40）のようなものに到達しました。
私たちはシンプルな地下鉄ルーティングフレームワークを開発しており、私の設計は非常にうまく行われているようです-いくつかのメインモデル、対応するビュー、メインロジック、およびデータ構造は、「本来あるべき姿」で完全にモデル化されていますレンダリングとは別に、アルゴリズムモデルもメインモデルとは別に実装され、マイナーな数の交差点がありました。
私は、その設計をスケーラブルで、カスタマイズ可能で、実装が簡単で、主に「ブラックボックスの相互作用」に基づいて相互作用しているといいます。
今、何が行われたか：
- 対応するインターフェースのいくつかの実装を開始し、いくつかの便利なライブラリーを移植し、いくつかのアプリケーション部分の実装スタブを書きました。
- コーディングスタイルとそのコーディングスタイルの使用例（自分で作成したコード）の例を説明したドキュメントがありました。
C++コード（スマートポインタでラップされたもの）などを含む、多かれ少なかれ最新のno-delete開発手法の使用を強制しました。- 具体的なインターフェース実装の目的とそれらの使用方法を文書化しました。
- ユニットテスト（多くの「実際の」コードがなかったため、統合テスト）とすべてのコア抽象化のためのモックのセット。
私は12日間不在でした。
現在の状況（プロジェクトはチームの他の4人のメンバーによって開発されました）：
- プロジェクト全体で3つの異なるコーディングスタイル（おそらく、そのうちの2つは同じスタイルを使用することに同意しました：）、同じことが私たちの抽象概念の命名にも適用されます（eg
CommonPathData.h、SubwaySchemeStructures.h）、これは基本的にいくつかのデータ構造を宣言するヘッダーです。 - 最近実装されたパーツのドキュメントの絶対的な欠如。
- 私が最近
single-purpose-abstractionと呼ぶことができるものは、少なくとも2つの異なるタイプのイベントを処理し、他の部分と密接に結合しています。 - 使用されているインターフェースの半分には、メンバー変数
(sic!)が含まれています。 - ほぼすべての場所での生のポインタの使用。
- 「
(Rev.57) They are unnecessary for this project」のため、ユニットテストが無効になりました。 - ...（それはおそらくすべてではありません）。
コミット履歴は、私のデザインが過剰だと解釈され、人々がそれを個人の自転車や再実装されたホイールと組み合わせ始め、問題があったことを示していますintegratingコードチャンク。
さて、プロジェクトはまだやらなければならないことのほんの少ししか行っていません、私たちは深刻な統合の問題を抱えています、私はいくつかのメモリリークを想定しています。
この場合、何かできることはありますか？
私のすべての努力には何の利益もなかったと思いますが、締め切りはもうすぐで、私たちは何かをしなければなりません。 誰か同じような状況でしたか？
基本的には、プロジェクトのための良い（まあ、できる限りのことをした）スタートはおそらく何か素晴らしいものにつながると思っていましたが、私は間違っていることを理解しています。
混乱から抜け出すために容赦なくリファクタリングしてください！
使用可能なスタイルの大部分を占めるコーディングスタイルを使用して、このプロジェクトで使用します。
最悪なのは、リビジョン40にロールバックする必要があり、プログラマーが12日間のトレーニングセッションを行ったことで、主題についての理解が深まったことです。
プログラマーがクリーンなコーディングについて学ぶことがたくさんある場合、12日が最も少ない遅延です。
あなたの質問を言い換える-「私は数週間離れて行って、私がいなくなったときの私のチームの行動に同意しません。ここにいないときにどうすれば彼らがやりたいことを彼らにさせることができますか？」
これは技術的な問題ではなく、管理上の問題だと私は言います。私の見解（私が間違っている場合は私を許してください）は、何らかの理由であなたの解決策に同意できないか理解できない、ミニオンの軍隊に技術的解決策を指示するというものです。
12日間でデザインに大きなダメージを与えた場合は、理由があるはずです。デザインは壊れやすいですか？やりすぎですか？それともチームはそれをしなくてもそれをしましたか？あなたの締め切りと配達はどのようなものですか？タイト？彼らはただ会うつもりでしたか？
私がこれを目にした1つのケースは、技術的なリードがゲームのはるかに先を行っていたため、平均的な開発者（私）が追いつけなかったことです。彼はそれを維持することができた唯一の人だったので、テクニカルリードは商業的に実行可能なコードの設計に失敗しました。大学院の開発者がそれを維持できない場合、それは商業の世界には複雑すぎます。他のすべてのケースでは、それは管理側の人々管理スキルの明らかな欠如でした。
チームのダイナミクスが壊れています。 （他の人が示唆するように）混乱のリファクタリングに時間を費やして、次に休暇を取るときにすべてをもう一度行う必要があります。チームメンバーをスキルアップする必要があるかもしれませんが、どんなに醜いと思っていても、チームダイナミクスを修正する必要があります。
ペア
あなたが説明しているのは、技術的には正しいことの多くですsolo。はい、あなたは文書化しようとし、標準を課そうとしました-しかし、あなたは（どうやら）コミュニケーションに失敗しました。
ええと、あなたのチームは、あなたに非常にはっきりと連絡を取りました。彼らは言った、「ねえ、イッピー-あなたはコミュニケーションしていません！」私が知っている最も強力なコミュニケーション形式はペアリングです。ペア。彼らがそれを手に入れるまで、または彼らがあなたに違うことをするように説得するまで。
Brooksが過去30年ほど私たちに言っていたように、概念の整合性はどのプロジェクトでも最も重要な部分です。自明ではない完全なサブシステムの場合、その設計を担当し、その実装を指示する権限を持つ責任者は1人だけである必要があります。プロジェクトのこの部分で問題が発生しました。それが何であれ、唯一の解決策はそれが起こる前に存在していたリポジトリのコードにロールバックすることです。 12日の損失は、壊れた設計を維持するための費用と比較して何もありません。また、無能であることが判明したため、このグループに関係する人々をプロジェクトの今後の作業から除外する方法についても考えます。
手始めに、良いコードレビューツールを入手し、それを使用して悪いコードにマークを付け、それがなぜ悪いのか、および（概念的に）どのようにすべきかを文書化することです。さて、私が理解したことについては、多くの悪いことが行われているため、確認するのは大変な作業になります。コードに問題があるのはあなただけだとすると、自分ですべてを確認することは不可能かもしれません。しかし、最悪の違反をマークして、対応するコードを書いた人に割り当てられた問題追跡システムのエントリに変えることができます。
高品質のコードを書くための最も良い動機は、もしそうでなければ、将来あなたを悩ませることになるということを知ることです。あなたの同僚はそれを気にしていないようですので、最良の薬は彼らが彼ら自身に間違った部分をリファクタリングして学ばせることです。
時間をかけて、問題のあるコードの他の部分に再度アクセスして、元の（悪い）作者に再度割り当てることができます。しばらくすると、彼らは初めて良い仕事をすることの利点を理解するでしょう。
私は、元のバージョンへのロールバックをオプションと見なしていないと想定しています。つまり、同僚が書いた悪いコードにもかかわらず、いくつかの機能が追加されており、現在のバージョンの正味の価値は元のバージョンよりも高くなっています。私はまた、そうでない場合でも、ロールバックを実行してコードを書き換えさせる政治的資本がないことを想定しています（そのような資本を持っている人は地球上で非常に少ないため）。これらやその他の多くは、自分が経験していない状況を判断する複雑さですが、私の2セントが助けてくれることを願っています。
私が言及したことはありませんが、最近私が働いているところに出てきたのは、「開発者のサイロ」と「買い込み」の問題です。
現在のプロジェクトの初めに、基本的に自分でコアライブラリを設計することになりました。 （あなたがrev。40までやってきたように）。その後、私がそれを行ったとき、私はチームの残りの人にプレゼンテーションをして、みんなにそれを使い始めることができると伝えました。その後の数か月に起こったことは、人々がすでにこのライブラリにあるものと同じものを他の場所に実装し続けたことでした。 CTO（積極的にコーディングしている）は、ライブラリーのアーキテクチャー/設計/パブリックインターフェースに関するチームの他のメンバーからの賛同はなかったと指摘しています。
さて、私たちはそのライブラリを大幅に書き直し、現在の設計に合わせて全体的な設計を間違いなく改善しましたが、開発者はこのライブラリを唯一のプロジェクトとして取り上げ、数週間作業しました。その後、それを提示しました。 「ボイラ！ここにある！きれいじゃない？」
今私は新しいバージョンを使用しなければならず、同じ問題があります-彼のやり方が嫌いです。また、作業中に他の人との共同作業に失敗したため、必要なものを省略しました。繰り返しになりますが、他の場所にも同じことを実装し始めて、自分がやるべきことのために働く方法を模索しています。
短い話-コードの品質を向上させ、一貫性を持たせる場合は、チーム全体をまとめて標準やスタイルなどを確立することをお勧めします。さらに、誰かがあなたの基盤またはコア部分を構築するときはいつでもアプリケーションの場合、責任者がクラス全体の設計などでチーム全体を主導し、結局のところ、チーム全体がアプリケーションアーキテクチャ全体に投資する必要があることをお勧めします。さらに、他のチームメンバーのコードがどのように機能するかを知っている場合は、自分に合った方法でコードを再度実装する可能性が低くなります。
あなたはこのチームの上級開発者（または上級開発者の1人）ですか？もしそうなら、あなたはベストプラクティスに関するいくつかのトレーニングセミナーを開催する必要があるようです。実行した作業の多くを元に戻し、チームとのミーティングを開催し、既存の設計を維持する方法で必要な機能を実装する正しい方法を説明する必要があります。
厳しい期限に直面していることを考えると、コードをそのまま出荷し、リリース後にリファクタリング（リライト？）する必要がある場合があります。
また、いくつかの一般的なコードプラクティスを定義して適用する必要があるようにも思えます。仕事でコードレビュープロセスを実施していますか？もしそうでなければ、今のように聞こえるのはそれを実装する時です。ちなみに、コードレビューは、新しい開発者のベストプラクティスを教えるのに最適な方法です。
編集：
最近同じような状況に遭遇しました。私の会社の経営陣は、契約の開発者を使用してアプリケーションの多くを作成すると主張しました。彼らが作成したコードは（親切に言うと）ひどいものでしたが、使用せざるを得ませんでした。今日、請負業者が私たちのために書いたコードの80％を書き換えました。バグが多く、新機能で拡張することは不可能でした。あと数か月で、私のチームはすべてを書き直し、契約の開発に投資したお金を無駄にしてしまいます。
悪いコードは本当にお金がかかります。コーディング標準の実装と施行にはおそらく彼らの助けが必要になるので、それはあなたがあなたのマネージャーと話したいかもしれないことです。
あなたは努力しましたが、実際は誰も担当していませんです。 「でも、私は自分のコーディングスタイルを好む」、とんでもない。私は私の個人的なプロジェクトに終日取り組み、それでも給料を受け取りたいです。
うまくいけば、あなたはそれをある力に提示し、2週間続いたWild West Showとは対照的に、何ができたかを彼らに示すことができます。何かをドアから出さなければならないようですが、コントロールの欠如と一貫性の問題について引き続きフォローアップします。
計画に沿ったいくつかに焦点を合わせ、この混乱を修正し、将来のプロジェクトでチームに参加させるために、できる限りのことを行います。一緒に取得できない場合は、残りを拒否する必要があります。