如何防止同事引入极端的复杂性和抽象性？

我的工作很困难，因为我的同事似乎在展览

1. 过早/不必要的优化工作
2. 具有可疑抽象的过早重复数据删除
   例如，我们使用了经过修改的VIPER体系结构。他实现了路由器组件的基类（使用泛型），作为实现第一个毒蛇堆栈的一部分，而实际上并不知道在其他路由器中将确切复制什么。现在我们不得不提供一种UseCase包含用例的类型，但是大多数路由器没有多个用例，只有一个。
3. 为潜在的未来功能发明通用解决方案
   例如，当我们在应用程序中只有两个这样的屏幕时，他写了一个用于填充静态单元格表​​格视图的管理器，他不知道设计将从无聊的垂直形式转变为更多的自定义形式UI，因此管理器无用。
4. 选择偶然的复杂性

当他还表现出英语差的语言障碍时，我该如何应对？

您的描述听起来像我在1990年代所做的编码。要在现代世界中恰当地表演并不容易。我建议重点关注以下因素：

• 配对。两套眼睛可以帮助您预防一个伟大而复杂的实现。
• 代码审查。现代商店会由多个人审查所有代码更改的100％
• 测试覆盖率。确保有简单的测试。过于复杂的测试可以反映过于复杂的代码
• 关于最小可行产品的大量讨论。将功能分解为最小的组件。可以用一张票来更改数据库，用另一张票来填充参考表，然后用第三张票来更新UI（最终用户实际上将看到的那一部分），但首先会感觉与直觉相反，因为阻力很大可能。
• 关于如何减少票数和更改的频繁讨论。
• 整个团队对故事点进行投票，以展开有关复杂性和方法的讨论。
• 教育。确保您有午餐和学习，培训课程等，以便人们可以接触良好的做法以及为什么做得好。

综上所述，我主要关注的两点是代码审查和较小的故事。

归根结底，我认为改变现有行为的最佳解决方案是让专人负责变更。在敏捷组织（可能是当今的大多数组织）中，需要像Scrum管理员这样的专职人员不断地提出正确的问题并指导开发方法。在我上一个组织中，我们有一打，每个团队一个，以帮助指导人们解决此类问题。这消除了一个团队成员开发人员试图说服其他人“他们的方法是正确的”的需要，而这常常会导致激烈的交流和鲜血。