… 在项目结束时，我们将这种理念写在纸上。我们交付我们构建的系统、其背后的理念，以及构建该系统所使用的参考文献列表。这意味着我可以将目标级别工程师交给他们，让他们花一周时间阅读这些资料，他们回来后将具备足够的专业知识来负责这个系统。这也可以作为我自己的文档，以便在未来如果被重新招入项目时使用。在开始合同时，我可以回顾所有这些交付物，以便再次回到项目时能够迅速投入工作。
源讨论系统设计与架构复杂性的成本原帖 167 条评论 · 导入时统计我总是会想“我（或者任何人）在六个月后还能轻易回到这里吗？” 就我而言，我可能不得不这么做，所以肯定有一个自私的原因。 我最近经历了一系列令人沮丧的情况，我不得不重新发现旧代码/系统的工作方式，以便进行小的更改或找出小的更改其实很大。真的很让人泄气。这不是我的错，但会让人感到非常沮丧。感觉像是一副重担压在你身上……在那两次恐怖经历之后，我那天就彻底放弃了。甚至有一次，我现在还不确定整个事件的因果链是如何成立的。 然后昨天我有一个为期三天的项目开始，两个小时我就完成了。它非常灵活/强大，能优雅地处理错误，并且容易更改/测试。这一切都是因为一年前有人（我和另一个人）花时间简化了原始的混乱代码，原本的代码就是这样的。…
完整原文把你的经验，加入这段讨论。
这听起来是正确的方法。对我来说，很难想出一些不会听起来适用于任何系统的准则。你一开始可能是一个通用的CRUD应用，但随着它的发展，默认的/通常的Web框架结构往往会把你带入一团乱麻。你可以把其中的任何东西耦合在一起，而且由于时间紧迫，你往往会这么做。抽象看起来有点为时过早，当它们开始出现时，你又缺乏坚持下去的信念去彻底清理整个系统。 你有没有一些入门资源，可以帮助你为系统制定准则？也许有一些东西能展示某些准则如何引导你做出不同的实现选择，这些选择在另一种哲学下可能会不同。
完整原文听起来像是一份架构决策记录。这里有一个 ADR 模板的例子：https://github.com/joelparkerhenderson/architecture-decision... 。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。