同僚が極端な複雑さと抽象化を持ち込むのを防ぐ方法は？

私の同僚が展示しているように見えるので、私は非常に困難な時間を過ごしています

1. 早すぎる/不要な最適化の取り組み
2. 疑わしい抽象化を伴う早期重複排除
   たとえば、変更されたVIPERアーキテクチャを使用します。彼は、他のルーターで何が複製されるかを実際に知らずに、最初のviperスタックを実装する一環として、ルーターコンポーネントの基本クラスを（ジェネリックを使用して）導入しました。現在UseCase、ユースケースを保持するタイプを提供する必要がありますが、ほとんどのルーターには複数のユースケースはなく、1つだけです。
3. 将来の投機的な機能の
   ための汎用ソリューションの考案たとえば、アプリ内にこのような画面が2つしかない場合、静的なセルテーブルビューを作成するためのマネージャーを作成しました。 UIなので、マネージャーは役に立たない。
4. 偶発的な複雑さの選択

ひどい英語で言葉の壁があることを示しているとき、どうやってこれと戦うのですか？

あなたの説明は、1990年代にコーディングしたように聞こえます。現代の世界に適切に対応することは容易ではありません。次の要素に注目することをお勧めします。

• ペアリング。2組の目は、1人の人間に対して優れた、しかし複雑な実装を防ぐのに役立ちます。
• コードレビュー。現代のショップは、複数の人によるすべてのコード変更の100％をレビューします
• テストカバレッジ。簡単なテストがあることを確認してください。過度に複雑なテストは、過度に複雑なコードを反映する可能性があります
• 最小限の実行可能な製品に関する多くの議論。機能を可能な限り最小のコンポーネントに分解します。データベースを変更するチケットと、参照テーブルにデータを入力するチケット、そしてUI（実際にエンドユーザーに表示される部分）を更新するチケットを用意してもかまいませんが、抵抗と同様に直感に反する感じがしますありそう。
• 小さいチケットと変更をどのように持つかについての頻繁な議論。
• チーム全体によるストーリーポイント投票により、複雑さとアプローチに関する議論が開かれます。
• 教育。ランチと学習、トレーニングセッションなどがあることを確認してください。そうすることで、人々は優れた実践とその良い理由に触れることができます。

上記のすべてから、私の主な2つのポイントは、コードレビューと小さなストーリーです。

結局のところ、既存の動作を変更するための最善の解決策は、変更をリードする専任の人を置くことだと思います。アジャイル組織（今日の大多数の可能性が高い）では、スクラムマスターなどの献身的な人が常に適切な質問をし、開発アプローチを指導する必要があります。私の最後の組織では、各チームに1つずつ、この種の問題を人々に案内するのを支援するために、それらを12個持っていました。これにより、あるチームメンバーの開発者が他の人に、「彼らのやり方は正しい」と納得させようとする必要がなくなります。