過剰な通信は時々悪いソフトウェアの兆候ですか？
現在、私は製品を分隊に分割する会社で働いており、各分隊は異なる製品（またはソフトウェア）を担当しています。私が働いているチームは、他のすべてのソフトウェアが使用するソフトウェア（Payment Gateway）を処理します。変更を加えるたびに、他のチームと通信する必要があります。そのことを念頭に置いて、私は製品マネージャーに、これは悪いソフトウェアの兆候であると言いました。ソフトウェアは高度に結合されているためです。彼は私が完全に間違っていると言いました。コミュニケーションが成功の鍵です。
コミュニケーションが成功の鍵であることに同意しますが、何かを変更したいときに全員に警告する必要があるため、ソフトウェアが貧弱であるという事実は変わりません（APIの変更について話しているのではなく、内部です）
それについてどう思いますか？
問題の説明に基づくと、「内部コードを少し変更しただけでもAPIが危険にさらされる可能性があるため、それを使用しているソフトウェアが破損する可能性があります。」、APIが1つ以上の問題を抱えているようです ' リーク）抽象化 '。通常、これが発生する方法は、APIが基盤となるデータ構造への単なるパススルーである場合です。たとえば、一般的な問題は、ORMを使用して 貧血ドメインモデル を生成し、それを使用してWebサービスレイヤーを生成することです。これは迅速かつ簡単で、実際にコードを記述する必要はありませんが、データベースモデルへの変更は、APIへの変更として現れることを意味します。
あなたが述べているように：コミュニケーションはそれ自体悪いことではありませんが、不安定なAPIを補うためにコミュニケーションを使用する必要があるのは悪いことです。これは、問題の症状に対する解決策です。
上司がこれを理解していない場合、彼は技術的でないか、これが行われているレベルのソフトウェアアーキテクチャを理解していない可能性があります。私が言っていると思います：はい、これは悪いAPI設計を示している可能性があります。抽象化のポイントは、結合を小さな表面積に制限することです。これにより、他のすべてのチームが行っていることのすべての側面に関与する必要がないため、チームはより効率的に作業できます。 microservices の開発は、まさにこの問題によって推進されました。大規模なテクノロジー組織の場合、すべてのチームに継続的に取り組みを調整させるコストは持続不可能です。行間を読むと、このアプローチは、真に技術的な問題よりも組織/管理の問題によって推進されていることがわかります。
残念ながら、リードアーキテクトまたは開発者でない限り、この問題を解決できる可能性はほとんどありません。上司が問題を理解していれば、いくつかの改善に影響を与えることができるかもしれません。彼はそうしているかもしれませんが、タイムラインを満たすためにアーキテクチャのこの欠陥を回避するために、当分の間通信を続ける必要があることを受け入れます。
あなたのクライアント（そうです、あなたのサービスを使用しているのは同じ会社にいてもクライアントです）があなたのサービス内部に依存しているなら、何かがおかしいです。
これらの少なくとも1つが成り立ちます：
- インターフェイスが適切に文書化されていません。
- あなたのインターフェースは、カプセル化と抽象化でうまく機能しません。
- クライアントは試行錯誤を繰り返してプログラミングしています。
したがって、前進は遅く、危険に満ちています。
- 現在のインターフェースを適切に定義して文書化します。
- 必要に応じて、現在のインターフェースの一部を段階的に廃止し、より適切に設計されたものと交換します。
- どういうわけかあなたのクライアントをよりよく教育するためにプッシュしてください。
管理の論点は、お金（証拠を集めた後に推測するのではなく知ることによって節約される）、お金（効率と人間工学の向上のために節約される）、そしてあなたが推測したように、お金（同僚が何をしているのかを知っているために節約される）です。 ）。
うまくいけば、短時間でクライアントはそれから適度に安定したインターフェースにプログラムでき、すべての変更を緊密に調整する必要性を減らし、実際にそうする方法を知っています。
もちろん、法律や管理上の不備などにより、サービスのビジネスルールが変更される可能性があります。単純に抽象化できない場合は、少なくともバージョン管理を検討してください。
コミュニケーションオーバーコミュニケーションはいつですか？
強力なコミュニケーションは確かに何かが間違っているという症状である可能性があります。たとえば、コンポーネントがパーツに分割されているが、分割されるべきではなかった場合などです。しかし、共通点があるチームが非常に効果的に協力しているという証拠でもあります。
では、どのように違いを生むのでしょうか？ IMHOの場合、最も頻繁なケースはコミュニケーションの欠如であるため、量の問題ではありません。チームは、島に住んでいると考えてサイロで作業します。これは常に誤解、予期しない驚き（何？リリースの2週間前にAPIを変更したのか？）、そしてフラストレーションをもたらします。
内省の質問：コミュニケーションの質はどうですか？便利ですか？それは建設的ですか？それについてのあなたの否定的な気持ちは何ですか？この否定的な意見はあなたのチームメートによって共有されていますか？そして、他のチームのメンバーによって？なぜ「多すぎる」と思いますか？
事業領域の構造
いくつかの共通の機能またはドメイン部分がある場合（ゲートウェイのように）、あなたに応じた最善の解決策は何ですか？製品ごとに新しいゲートウェイを繰り返す/再開発/再発明するか、機能を分離しますか？
したがって、共有コンポーネントはまさに必要なアーキテクチャであり、チームが他のすべての成功の鍵となる可能性があります。しかし、他のチームがすべてそれに依存している場合、決定に利害関係者としてそれらを関与させるのは正常ではありませんか？結局のところ、アプリケーションチームに所属している場合は、要件を収集し、新しいユーザーストーリーをデモし、顧客の印象を収集するために、顧客と頻繁に会議を行うことになります。
内省の質問：コミュニケーションは役に立ちますか？つまり、要件と相互依存性についてですか？それとも、あなたのチームはあえて自分でいくつかの決定を下し、チームの決定に利害関係者を過度に関与させていませんか？
品質？
配信されるバグが多すぎる場合など、品質が悪いと、他のチームから余分な問い合わせが発生する可能性があります。これは、悪いソフトウェアの症状であるある種の通信です。
デザインも悪い。コンポーネントがSOLIDでない場合、たとえば、インターフェイスの分離と依存関係の逆転によって回避できる緊密な結合のために、あなたとあなたの顧客は不必要な議論をすることになります。
情報が不足していると、人為的に過剰なコミュニケーションが発生する可能性もあります。優れたリファレンスドキュメント（注意：過度にドキュメント化しないでください;-)）といくつかのリリースノートは、不必要な議論を避けるのに本当に役立ちます。
内省の質問：提供するものに誇りを持っていますか？また、別のチームに所属している場合は、ゲートウェイを利用して楽しんでいただけますか？
結論
私が持っている情報が少ないので、何が起こっているのかについて客観的な意見を述べるのは難しいです。
しかし、過剰なコミュニケーションは必ずしもソフトウェア設計の問題ではありません。コミュニケーションとコラボレーションの実践に問題がある可能性があります。幸いなことに、意識があれば、これらは非常によく改善することができます。