8
開発時に同僚に対処するため、アドバイスが必要です[非公開]
ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 8年前に移行され ました。 現在のプロジェクトアーキテクチャを開発し、独自に開発を開始しました（次のようなものに到達します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"のため、ユニットテストは無効です。 ... （おそらくすべてではない）。 コミット履歴は、私の設計が過剰であると解釈され、人々がそれを個人用自転車と再実装されたホイールと組み合わせ始め、コードチャンクの統合に問題があったことを示しています。 さて、プロジェクトはまだやらなければならないことのほんの一部をしているだけで、深刻な統合の問題があります。メモリリークがあると思います。 この場合にできることはありますか？ 私はすべての努力が利益をもたらさなかったことに気づきましたが、締め切りはもうすぐであり、私たちは何かをしなければなりません。誰かが同様の状況にありましたか？ 基本的には、プロジェクトの良い（まあ、できる限りのことをすべてやった）ことは良いことになると思いましたが、間違っていることは理解しています。