開発者間でソフトウェア設計を効率的に通信する方法は？
最近、職場での深刻な問題は開発者間のコミュニケーションの欠如であることを理解するようになりました。私たちは完全にオープンな組織なので、奇妙です。誰もが誰にでも行くことができ、必要なものは何でも尋ねることができ、コミュニケーションはほとんど規制されていません。それでもそれだけでは起こりません...
私が最も強く感じている種類の不足は、私（システムのアーキテクト、多かれ少なかれ）と残りの開発者（通常、フレームワークではなく、必要な機能の一部で作業している）の間です。コンポーネントや命名規則などを作成するときはいつでも...これを知る必要のあるすべての人にそれを知らせる方法はありません。せいぜい私にそれを頼んだ仲間に直接話すだけですが、それだけです。
その結果、車輪が再発明され、コードにはほとんど規則がありません（ほとんどがコピー貼り付けから進化したものです）、たまにカーゴカルトコーディングなどがありました。大きいので、そのような機会はめったにありません。 :(
これを解決する方法は本当にわかりません。作成されたすべてのもの（おそらく少なくとも1週間かかる-それほど多くの時間を費やすのは難しい）を社内wikiに文書化することはできますが、そのような場所を定期的に読んでニュースを読む人はいますか？そして、必要なものがすでにどこかに実装されている場合、どのようにして見つけますか？
この落とし穴を回避するために他の人は何をしていますか？どの方法が効率的であると示されていますか？
私は2つのものを使用します-私の声とホワイトボードです。
つまり、開発者が会議を嫌うのと同じくらい、あなたはdoチームとして働く必要があります。スタンドアップは、コードで行っている新しいことについて話し合う（そして、すでに何かが存在するかどうかを尋ねる）絶好の機会です。大きなことについては、スプリント計画会議はチーム全体が設計に情報を提供する良い機会であり、誰もが何が起こっているかを知っています。また、スプリントデモミーティングは、スプリントの開始以降にデザインがどのように変更されたかについて簡単に説明する良い機会です。私の経験では、ホワイトボードは、開発者の間でその設計を伝えるための最良のツールです。コードを読むのに熟練している人は少なすぎ、誰も（すぐに時代遅れになった）ドキュメントを読みません。
また、特に大きく複雑な微妙なことについては、その情報を広めるために専用の会議を開く必要があるでしょう。
コードレビューは、重複した作業やコードの誤用/誤修正に対する最後の防御策となります。しかし、それらは後ですべての作業が完了したことをキャッチします。良いチームワークを持つことで、無駄な仕事が完全に行われるのを防ぎます。
アジャイル/スクラムを使用しないのですか？まず、お悔やみ申し上げます。第二に、前提はまだ成り立っています。チームとして話す必要があります-毎日ささいなこと。そして、あなたはチームとして働くために定期的に大きなものを調整する必要があります。
簡単な答えはありません。
壁に貼った大きな写真が役立ちます。 4Cダイアグラムのようなもの（コンテキスト、コンテナ、コンポーネント、クラス） http://static.codingthearchitecture.com/c4.pdf （クラスはおそらく詳細すぎる）
これらは、コード内の人々を方向付け、存在するものを理解するのに役立ちます。
コードレビューは良い習慣を広めるのに役立ちますが、それらをうまく行うことは芸術です。レビュアーは頼りにされるべきではなく、（ほとんどの場合）リポジトリへのゲートキーパーは1人ではないはずです（他にバスがヒットしない問題があるため）。
それ以外に、スタンドアップとカードボードはチーム内で知識を共有するための方法であり、自分自身を向上させたいと望んでいる善意のあるチームは、全体の取り組みのかなりの鍵です！
作成されたすべてのものを試して文書化できます…
どこかから始めなければならない。
…そのような場所でニュースを定期的に読む人はいますか？
次に、電子メールを使用して変更を通知します。 SNRを低く保ちます。
変更（管理を含む）の背後に人々を連れて行き、採用された変更を彼らに知らせる必要があります。一部の変更については、それらの入力が必要な場合があります。それ以外の場合は、メール/アップデートでそれらをフロートさせてください。より複雑なトピックについては、説明に数分かかり、Q + Aがフロートされてから間もなくです。
そして、必要なものがすでにどこかに実装されている場合、どのようにして見つけますか？
コードレビューは良いスタートです。それでも人々がコードを再利用しない場合は、より早い段階（つまり、コードが記述される前）に入る必要があります。
その結果、車輪が再発明され、コードにはほとんど規則がありません…
それは難しい部分です。誰も主導権を握りたくない。私の典型的なアプローチは、自分で変更を実行し、フロートし、必要に応じて議論し、Pushしてから強制する（ツール許可）ことです。
したがって、コーディング規約の場合：
- todoリストの次の重要な変更の予行演習を行う
- それが成功したら、エンジニアに変更をフロートします
- 質問/懸念がある場合は、メールまたは会議の変更についてのケースを詳しく説明してください
- 押す
- 実施（ツール許可）
とにかく、それが私が通常行う方法です。時には、より大きなタスクが分割されます。
最も単純な答えはコードレビューです（そしてcodeレビューとは、実際には「コード自体を含むコード変更に関連するすべてのもの）です。これは明らかにドキュメントが必要であることを意味します。
私は、人々がいたるところにハッキングしている場所を知っています。私の仲間が最新のコードを取得するバグを修正するために彼が来たたびに最後に働いた場所は、変更されていました。あるチームはこの方向に変更を加え、別のチームは別の方向に変更を加えます。時々チームが一人で方向を変え、あなたは製品に何も行われなかった純粋な混乱に終わったが、絶え間なく激しいコードの変更があった。
これは、開発者以外のタイプの変更制御のフォームが必要な場所です。変更が制御された方法で行われるシステムを実装する場合、つまり誰もが何かを変更できるということを意味するのは、それを行うには何らかの理由と、それを進めるのが良いことであるという何らかの承認が必要なことだけです。
したがって、変更チケットに応答しない限り、変更が適用されないように指定できます。 （もちろん、変更が必要な問題を記述したチケットを誰でも作成できます）しかし、これらのチケットは、製品の方向性を担当する人（ビジネスアナリストや技術設計の権限、さらにはチームの集まり）によって人またはチームに割り当てられます。重要なのは、変更が個別ではない方法で行われることです。
それが処理されると、誰かが行って変更を加え、あなたはそれらをレビューしてもらいます。これは、他の誰かがコードだけでなく、チケットの変更やドキュメントも見ることを意味します。したがって、DBアクセスシステムを変更する場合は、問題ありませんが、それが何であるか、なぜ変更されたのか、現在どのように機能するのかを説明する必要があります。そのような文書がないと、変更はレビューに失敗します。その後、茶色のバッグやコード道場などの内部「トレーニング」を実装して、チームの他のメンバーに情報を提供できます。
一部の人々はこれに抵抗しますが、「製品で作業する」のではなく、「コードをカットする」というコードを絶えず解約する傾向があります。これは重要な違いです。開発者は誰でもコードが重要であるという概念に夢中になる可能性があるためです-それは重要ではありません。あなたが構築している製品は重要であり、それは単なるコード以上のものです。
ドキュメントは広範囲である必要はなく、あなたがやったことやそれがどのように機能するかを他の人に伝えるのに十分です。 Wikiにすることも、チケットに関するメモにすることもできます。チケットが古くなると、表示やドキュメントが消えてしまいますが、関連する最新のドキュメントのみが保持されるため、これは問題ありません。あるいは、コンポーネント、アーキテクチャー、および使用法のwikiを用意して、各コード変更の一部として最新に保つことができます。または（私の好み）ビルドサーバーによってhtmlに組み込まれ、Webサーバー上に提示されるマークアップ形式のテキストドキュメントとして、コードと一緒にすべての技術ドキュメントを保存することにより、誰でも簡単に更新される最新のドキュメントを見ることができますコードを更新しました。
最後の手段は、システムを文書化する責任があるアーキテクチャチームを取得することですが、文書が最初に更新されない限り、変更が行われないようにする権限も持っています-多くの緩いチームはこのより制限的なアプローチを好まないかもしれませんが、彼らが私の提案を使用してそれを機能させることができない場合、これは次に実装する必要があるシステムです。
この一般的な問題には、（少なくとも）2つの問題が隠されています。 1つ目は、適切なコミュニケーションが行われていることを確認するプロセスです。2つ目は、開発者が実際にプロセスに従うようにすることです。方法）など.
後者の方が実際には前者よりも簡単に実現できることが多いと思います：デプロイメント（最終統合）テストの開発をコーディング担当者から分離し、すべてのテストに合格するまでコードをマスターブランチに受け入れません。次に、開発者がコミュニケーションプロセスを聞いたりフォローしたりする程度に関係なく、開発者が行った変更は、既存のテストに違反しても、デプロイされたコードに影響を与えません。テストがすべての要件（機能的および非機能的）の真の表現である場合-new機能がテスト確認なしに追加されないことのテストを含む-そうしないと開発者のコードがどこにも行かないため、このプロセスは通信を強制します。次に、最小限の仕事は、新しい要件をテストライターに伝え、それらが最初に実装されるようにすることです。
前者、つまり実際のコミュニケーションプロセスは、時間の経過とともに発展する可能性があります。最初に、上記で説明した完全な統合テストの品質ゲートを使用するとbeforeマスターへのコミットが許可されると、人々はyou機能や要件などについて尋ねるか、誰のコードもデプロイされず、開発者はデプロイメントによって動機付けられます。次に、コミュニケーションの適切なメカニズムを使用して作業を開始できます。スクラムミーティング、Trelloなどのコラボレーションツール、メーリングリスト、コードレビュー、毎日の要件のユーザーストーリーディスカッションミーティングなど、チームの構造に適したもの。
独立した展開品質ゲートを最初に配置し、残りは最終的に続きます。
OO=設計と実装を行うチームの場合、コミュニケーションの一部は、問題空間の共有された理解と、それらの問題を解決するために使用される典型的なツールであるべきです。
デザインパターンの概念は、問題のあるスペースについて話すときの省略形として使用できる共有語彙を作成するために、非常に具体的に作成されました。
面倒な会議の時間を延ばす方法としてデザインパターンを使用するつもりはありません。引数。むしろ、特定の実装について詳細に説明する代わりに、設計パターンを使用して、全体像と各要素がどのように適合するかを説明できます。