你如何让人们重视抽象性和灵活性，而不是“只是完成它”？

Question

当其他人希望跳过官方接口而直接访问底层实现细节时，我有时会遇到困难。

他们争辩说，这样做可以让他们更快地解决问题。我认为这样做会导致我们的体系结构变得更加紧密耦合，并且很难随着新需求的出现而改变。

我指出了当前设计中的所有工作，以及设计哲学和灵活性的价值，试图维护和更改脆弱代码的成本，封装和数据隐藏以及分层体系结构的价值，并保持健壮，以便规范中的小更改导致代码中的小更改。他们会说：“但这会更容易。”

你是怎么处理这些人的？

Answer 1

让他们相信走捷径是一种虚假的节约。

解释说，初始编码工作量不到初始开发工作量的30%，也不到整个项目工作量(包括维护)的10% (根据我的经验)。

如果他们仍然不信服，而你有权这样做，那么告诉他们按你的方式去做。如果你没有权限，那就什么都不要做。最终，你的主管，如果她有任何价值，会认识到这一点，然后你将处于权威的位置。

Answer 2

让他们处理一些遗留代码，修复其中的bug。这就是我认识的大多数人是如何学到这些非常有价值的课程的……艰难的方式。

Answer 3

“更容易”是什么时候？现在，当一切都不是处于不断变化的状态时？或者三个月后，当客户的需求发生变化，他们得到了一个不再是解决方案的“解决方案”时？

为了结构和规则，我不太喜欢结构和规则，但知道A)谁在驾驶小船B)规则是什么以及C)为什么我们选择这样做是很好的。

在我的工作室里，我们不喜欢重写代码，因为我们搞砸了一大堆东西，或者创建了一些脆弱的“解决方案”来解决问题。一旦人们意识到当事情因一堆需求变化而颠倒时，遵循更灵活的方法将会减少挫折，那么遵循更灵活的方法并不会更困难。我们编写代码是为了“长途旅行”，而不是为了“今天就需要”，所以设计是的原因是，而设计是遵循也是出于同样的原因。

我花了一周的时间(连续7天)重写了一个模块，因为我处于“快速完成”模式。七天令人精疲力竭的时间，每天10-12个小时的正确方式，在比赛后期，当我本可以观看超级碗的时候。真是臭死人了。我在那里学到了一课。也许你的“朋友”自己也需要体验这种让人大开眼界的东西。

祝你好运！