Architecture 你如何让人们重视抽象性和灵活性而不是；“只是把它做好”吗；？

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

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

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

---

你是如何处理这些人的？

最好的办法可能是将他们提升到管理层，这样他们就不会造成太大的伤害。

说服他们走捷径是一种虚假的经济

解释初始编码工作不到初始开发工作的30%，并且不到整个项目工作（包括维护）的10%（以我的经验）

如果他们仍然不相信，而你有权这么做，那么告诉他们按照你的方式去做。如果你没有权力，那就别做别的。最终，你的主管，如果她有价值的话，会意识到这一点，你就会处于权威的地位。

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

我不太赞成结构和规则，只是为了结构和规则，但很高兴知道A）谁在驾驶船B）规则是什么，C）我们为什么选择这样做

在我的店里，我们不喜欢重写代码，因为我们搞砸了，硬编码了一堆东西，或者为这个问题创造了一些脆弱的“解决方案”。一旦人们意识到，当事情被一系列的需求变化搞得天翻地覆时，采用更灵活的方法会减少挫折感，那么遵循这种方法就不会变得更难了。我们为“长距离”编码，而不是为“今天需要”，通常情况下，因此设计是基于某个原因进行的，并且设计是基于同样的原因进行的

我花了一周的时间（连续7天）重写一个模块，因为我处于“快速完成”模式。七天的艰苦时间，每天10-12个小时的正确方式，在比赛后期，当我本可以观看超级碗的时候。真恶心。我在那里学到了一课。也许你的“朋友”们自己也需要经历这种大开眼界的经历

---

祝你好运

让他们处理一些遗留代码，修复其中的bug。我认识的大多数人就是这样学到了这些非常有价值的教训。。。困难之路。

问题是，除了最基本的概念和拖放式开发之外，大多数人对软件设计一无所知。对于每一个研究和教育自己所有最好的新概念和技术的开发人员，有十个回家不看电脑。你必须教他们。

展示给他们看！让他们在“但这会更容易”中做一个小模块，在你用正确的方式做的时候进行风格设计。然后要求他们对需求进行2到5次更改（必须是他们进行更改），并就实施更改进行计时竞赛。这可能需要一两天，但他们会得到的。如果你不这样做，你将对每一个新项目或任务进行相同的讨论。

你可以尝试对它们进行类比

国际象棋的规则很简单。你可以教孩子：“马像这样移动”，“城堡像这样移动”，等等

如果这就是你所知道的，你可以下一些国际象棋，可能会玩得很开心，但对这项游戏有更深入了解的人每次都会和你一起擦黑板。你会被打得很惨，甚至不再有趣，因为你不知道他们是怎么做的

同样的原则也适用于编程。了解该语言的语法和一些简单的数据结构就足以让您获得一个工作程序，但是对于一个必须在多个发布周期中生存的大型应用程序，您不会有太多的运气

国际象棋设置了开口、攻击策略等。我们有设计模式。

---

国家自然资源委员会等，pp；）

我真的不想在这个问题上持不同意见，但是

引用Van Halen（引用陈词滥调），“每件事都有时间和地点。”虽然我当然不提倡写得不好，但有时你确实需要完成它，并在健壮/持久和被黑客攻击/记录之间找到一个快乐的媒介。（有文件记录的部分在两个方面尤为重要：一是你清楚地表明，你所做的一切都是为了完成任务，并采取了某些捷径；二是关于解决问题的更正确方法的粗略想法

作为程序员，我们经常努力编写完美的代码（当然，我们中的一些人是这样做的），有时会忽略全局——有很多原因可以解释为什么（在某种程度上）快速而宽松地处理代码是可以的，同时最大限度地减少将来可能产生的影响

---

请不要以此为理由——80/20规则当然适用于这里。大多数时候，你绝对想沿着这些路线打破任何捷径；但有时…

大约五年前，我设计了一个庞大而复杂的系统。我花了五年时间将自己注入到每一个影响“我的”的项目中系统来防止野蛮人玷污我的建筑只要我申请