開発時に同僚に対処するため、アドバイスが必要です[非公開]

現在のプロジェクトアーキテクチャを開発し、独自に開発を開始しました（次のようなものに到達しますrevision 40）。

シンプルな地下鉄ルーティングフレームワークを開発しており、私の設計は非常によくできているようです- いくつかのメインモデル、対応するビュー、メインロジック、データ構造が「あるべき」ようにモデル化され、レンダリングから完全に分離され、アルゴリズム部分も実装されましたメインモデルとは別に、少数の交差点がありました。

私は、その設計をスケーラブルで、カスタマイズ可能で、実装が容易で、主に「ブラックボックスの相互作用」に基づいて相互作用し、非常に素晴らしいと呼びます。

さて、何が行われたか：

• 対応するインターフェースの実装を開始し、便利なライブラリを移植し、アプリケーションの一部の実装スタブを作成しました。
• コーディングスタイルとそのコーディングスタイルの使用例（自分の記述コード）を説明したドキュメントがありました。
• コード（スマートポインターでラップ）などC++を含む、多かれ少なかれ最新の開発手法の使用を強制しましたno-delete。
• 具体的なインターフェイス実装の目的と、その使用方法を文書化しました。
• 単体テスト（ほとんどの場合、「実際の」コードがあまり多くないため統合テスト）と、すべてのコア抽象化のための一連のモック。

私は12日間休みました。

現在何がありますか（プロジェクトはチームの他の4人のメンバーによって開発されました）：

• すべてのプロジェクトの上に3種類のコーディングスタイル（私は推測する、それらの2つが同じスタイルを使用することに同意した:)、同じことが私たちの抽象化の命名にも適用される（例えばCommonPathData.h、SubwaySchemeStructures.h）基本的にはいくつかのデータ構造を宣言し、ヘッダーです。
• 最近実装された部品のドキュメントの絶対的な不足。
• 私が最近呼び出すことができるものsingle-purpose-abstractionは、少なくとも2つの異なるタイプのイベントを処理し、他の部分と密接に結合しています。
• 使用されるインターフェイスの半分には、メンバー変数が含まれるようになりました(sic!)。
• ほぼすべての場所での生のポインターの使用。
• " (Rev.57) They are unnecessary for this project"のため、ユニットテストは無効です。
• ... （おそらくすべてではない）。

コミット履歴は、私の設計が過剰であると解釈され、人々がそれを個人用自転車と再実装されたホイールと組み合わせ始め、コードチャンクの統合に問題があったことを示しています。

さて、プロジェクトはまだやらなければならないことのほんの一部をしているだけで、深刻な統合の問題があります。メモリリークがあると思います。

この場合にできることはありますか？

私はすべての努力が利益をもたらさなかったことに気づきましたが、締め切りはもうすぐであり、私たちは何かをしなければなりません。誰かが同様の状況にありましたか？

基本的には、プロジェクトの良い（まあ、できる限りのことをすべてやった）ことは良いことになると思いましたが、間違っていることは理解しています。

混乱から抜け出すために容赦なくリファクタリング！

使用可能なスタイルの大部分を占めるコーディングスタイルを採用し、このプロジェクトに使用します。

最悪なのは、リビジョン40にロールバックする必要があり、プログラマーが12日間のトレーニングセッションを行ったため、主題をよりよく理解できるようになったことです。

プログラマーがクリーンコーディングについて学ぶためにそれだけ多くを持っている場合、12日間はあなたが持つであろう遅延の最小です。

あなたの質問を言い換えます-「私は数週間離れて行って、私のチームが行っていなかったことに同意しません。どうしてここにいないときに彼らがやりたいことをやらせるのですか？」

これは技術的な問題ではなく、管理の問題だということです。私の見解（私が間違っている場合はご容赦ください）は、何らかの理由であなたの解決策を理解できない、または理解できないミニオンの軍隊に技術的な解決策を指示することです。

設計に多大な損害を与えるのに12日間で十分な場合は、理由が必要です。デザインは壊れやすいですか？過剰に設計されていますか？それとも、チームは意外にそれを行ったのですか？締め切りと配達はどのようなものですか？タイト？彼らはただ会おうとしていたのですか？

私がこれを見たケースの1つは、技術的なリードがゲームよりもはるかに先だったため、平均的な開発者（私）が追いつかなかったことです。技術的なリーダーは、商業的に実行可能なコードを設計することができませんでした。彼がそれを維持できる唯一の人だったからです。卒業生の開発者がそれを維持できない場合、商業世界にとっては複雑すぎます。他のすべての場合、それは管理側の人々の管理スキルの単なる不足でした。

チームのダイナミクスが壊れています。（他の人が提案したように）混乱をリファクタリングするのに時間を費やし、次に休暇を取るときにもう一度やり直す必要があります。チームメンバーをスキルアップする必要があるかもしれませんが、チームダイナミクスを最初に修正する必要があると思います。

ペア。

あなたが説明しているのは、技術的に、ソロで多くのことを正しく行うことです。はい、あなたは文書化しようとし、標準を課そうとしましたが、あなたは（明らかに）コミュニケーションに失敗しました。

まあ、あなたのチームはあなたに連絡したばかりで、かなり印象的です。彼らは言った、「ねえ、イッピー-あなたは通信していない！」私が知っている最も強力なコミュニケーション形式はペアリングです。ペア。彼らがそれを得るまで、または彼らがあなたにそれを違うように説得するまで。

Brooksが過去30年ほどの間私たちに語っていたように、概念の完全性はプロジェクトの最も重要な部分です。自明ではない完全なサブシステムの場合、その設計に責任を持ち、その実装を指示する権限を持つ、正確に1人の人がいる必要があります。プロジェクトのこの部分で何か問題が発生しました。それが何であれ、唯一の解決策は、それが起こる前に存在していたリポジトリのコードにロールバックすることです。壊れた設計を維持するための費用と比較して、12日間の損失はありません。彼らは無能であることが証明されたので、私はプロジェクトのさらなる作業からこの再編成に関係する人々を取り除く方法も考えます。

手始めに私がしたいことの1つは、良いコードレビューツールを入手し、それを使用して悪いコードをマークし、それが悪い理由と（概念的に）どうすればよいかを文書化することです。さて、私が理解したことについては、多くの悪いことが行われているので、レビューするのは多くの仕事になるでしょう。あなたがコードに何か問題があると思っているのはあなただけだと仮定すると、すべてを自分で確認することは現実的ではないかもしれません。しかし、最悪の違反をマークし、問題追跡システムのエントリに変換して、対応するコードを書いた人に割り当てることができます。

品質の高いコードを書くための最も良い動機は、もしそうしないと、将来あなたに悩まされることを知ることです。あなたの同僚はそれを気にしていないようですので、最良の薬は間違った部分を自分でリファクタリングして学ぶことです。

時間があれば、問題のあるコードの他の部分を再検討し、元の（悪い）作成者に再度割り当てることができます。しばらくすると、彼らは初めて良い仕事をすることの利点に気付くでしょう。

元のバージョンへのロールバックをオプションと見なさないと仮定しています-つまり、同僚が書いた悪いコードにもかかわらず、彼らはいくつかの機能を追加し、現在のバージョンの正味価値は元のものよりも高くなっています。また、そうではない場合でも、そのロールバックを実行してコードを書き換える政治的な資本は持っていないと仮定しています（このような資本を持っている人は非常に少ないため）。これらは、私自身が経験していない状況を判断することの複雑さですが、2セントが助けてくれることを願っています。

私が言及したことはありませんが、最近私が取り組んでいるのは、「開発者サイロ」と「購入」の問題です。

私の現在のプロジェクトの最初に、基本的に自分でコアライブラリを設計することになりました。（あなたがrev。40までやってきたように）。その後、作業が完了したら、チームの他のメンバーにプレゼンテーションを行い、全員に使用を開始できることを伝えました。その後の数ヶ月に起こったことは、人々がこのライブラリに他の場所ですでにあるものを実装し続けたことでした。CTO（積極的にコーディングしている）は、ライブラリのアーキテクチャ/設計/パブリックインターフェイスについて、チームの他のメンバーから賛同を得たことは一度もないと指摘しています。

さて、私たちはそのライブラリを大幅に書き直しました。これにより、現在の作業に合わせて全体的な設計が間違いなく改善されましたが、開発者は再びライブラリを唯一のプロジェクトとして取り、数週間作業しました提示しただけです。「Voila！ここにある！かわいいじゃない？」

今、私は新しいバージョンを使用しなければならず、同じ問題がそこにあります-彼のやり方が嫌いです。そして、彼は作業中に他の人とのコラボレーションに失敗したため、必要なものを省きました。繰り返しになりますが、私は他の場所に同じものを実装し始め、私がする必要があることのために働く方法を始めています。

簡単に言えば、コードの品質を向上させ、一貫性を保ちたい場合は、チーム全体をまとめて標準やスタイルなどを確立することをお勧めします。アプリケーションの場合、担当者がクラス全体の設計などでチーム全体を率いて、最終的にはチーム全体がアプリケーションアーキテクチャ全体を購入する必要があることをお勧めします。さらに、他のチームメンバーのコードがどのように機能するかを知っている場合、彼らが機能する方法で再び実装する可能性は低くなります。

あなたはこのチームの上級開発者（または上級開発者の1人）ですか？その場合、ベストプラクティスに関するトレーニングセミナーを開催する必要があるようです。おそらく、行われた作業の多くを元に戻し、チームと会議を開き、既存の設計を維持する方法で必要な機能を実装する正しい方法を説明する必要があります。

厳しい締め切りに直面していることを考えると、コードをそのまま出荷し、リリース後にリファクタリング（書き換え？）する必要があります。

また、いくつかの一般的なコードプラクティスを定義して適用する必要があるように思えます。仕事でコードレビュープロセスを実施していますか？そうでない場合は、今が実装する時だと思われます。ところで、コードレビューは、新しい開発者のベストプラクティスを教えるのに最適な方法です。

編集：

私は最近、同様の状況に遭遇しました。私の会社の経営陣は、契約開発者を使用してアプリケーションの大部分を作成すると主張しました。彼らが作成したコードはひどいものでした（親切に言えば）が、使用することを余儀なくされました。今日の時点で、請負業者が私たちのために書いたコードの80％を書き直しました。それはバグでいっぱいであり、新機能で拡張することは不可能でした。あと2、3か月で、私のチームはすべてを書き直し、契約開発に投資したお金を無駄にします。

悪いコードは本当にお金がかかりますが、コーディング標準の実装と実施にはおそらく彼らの助けが必要になるので、これはマネージャーに相談したいことです。

あなたは努力しましたが、事実は誰も担当していません。「でも、自分のコーディングスタイルが好きです」私は私の個人的なプロジェクトに一日中取り組み、それでも給料をもらいたいです。

願わくば、これを権力者に提示し、2週間続いたワイルドウェストショーに対抗して何ができたのかを見せてください。何かを外に出さなければならないように思えますが、コントロールの欠如と一貫性の問題のフォローアップを続けます。

あなたの計画に沿った少数の人々に焦点を合わせ、この混乱を解決し、将来のプロジェクトであなたのチームにそれらを手伝ってもらうためにあなたができる限りのことをしてください。彼らが一緒にそれを得ることができない場合は、残りを拒否する必要があります。