我在Scrum，TDD，领域驱动设计和Bob叔叔的配方之后一年就开始工作了......但我有一些疑问是我们应用各种原则，主要是在阅读“Java Application Architecture”（从现在的JAA）时来自马丁的系列。 如果我错了请纠正我！ （希望我是） 问题始于TDD和Scrum，他们说我们应该在系统出现后改进系统，避免前期设计。这使我的工作让所有可扩展性点都保持开放，（ab）始终使用所有类型的可扩展性模式。这确实是一个“黑暗的一面”：增加了整个系统的复杂性。我事先并不知道我的代码的某些部分是否需要进一步发展。
但是，正如所指的那样（并且经常在JAA上），您应该仅在需要时添加复杂性。这个恕我直言的结论是，应该进行适当的前期分析......与其他食谱相冲突......
因此循环.... aaargh我讨厌循环依赖!!!“
在“确认”功能后，我们是否应重构某些内容以降低复杂性？我们应该使用最简单的方式，只有在需要时才能扩展它吗？例如当你不需要它们时，不要构建超级解耦的东西吗？
（欢迎任何改进问题风格和内容的建议，我是stackoverflow的新手）
答案 0 :(得分：8)
在“确认”功能后，我们是否应重构某些内容以降低复杂性？我们应该使用最简单的方式，只有在需要时才能扩展它吗？例如当你不需要它们时，不要构建超级解耦的东西吗？
是即可。虽然这是相当主观的，但我不喜欢能够灵活地改变每一件事情的系统，而你却不会利用所有这些灵活性。你的陈述是矛盾的：测试驱动开发教会我“做最可能有用的事情”。
如果需要更多功能，您可以添加测试，然后重构和扩展代码以确保它完成您希望它执行的操作。因为您已经进行了测试，所以您可以放心，您不会破坏当前现有的代码。
简而言之：不要因为可以而建立灵活性。你应该建立灵活性，因为情况决定了你。我坚信，“按需”重构会使项目的构建时间比内置（未使用）灵活性更短。通过测试，“按需”重构不会花费太长时间。
更短：保持简单，愚蠢。 ;）
答案 1 :(得分：4)
我相信在简单的事情和对系统的一些深刻的架构理解之间存在平衡。
我试图将短期计划与长期计划分开。在短期规划中，我认为只需要几步，如果此功能在下一次迭代中可能进行扩展/修改/更新，那么我将尝试为此做好准备。但如果我没有预见到任何延期，我将遵循KISS原则。
在长期规划中，我认为至少提前半年。什么是互动，可能的路线图是什么？这给了我基本的想法，我将把事情变得更加先进。
恕我直言，应该在规划和完成短期目标之间做出明智的决定。
答案 2 :(得分：2)
我怀疑有经验的设计师会继续坚持直觉。有“明显的”架构决策，分层，关注点分离设计决策有点“辍学”。诀窍是避免分析 - 瘫痪和过度工程。
随着粒度的增加，随着我们越来越接近代码，“你不会需要它”的口头禅变得更加重要 - 它很容易陷入美妙的灵活性。但您可以通过一些简单的方法启用future flex。例如，根据（在Java中）接口表示组件之间的关系。您可能不会选择完全成熟的抽象Factory Pattrern，但如果将消费者编码为接口，则很容易引入一个。同样地，不会在代码周围散布字符串文字，而是在一个地方收集字符串文字，这可能会大大简化未来的国际化或动态配置，即使现在您不需要将字符串外部化。
我看到的真正优秀的设计师似乎几乎像是国际象棋或围棋的游戏，他们预测未来的动作，但当然不会在他们需要之前发挥作用。 （Go术语aji-keshi可能值得考虑。）
哈，这很有趣：我查了一下aji-keshi的参考来解释这个术语只是为了发现作者已经将这个术语用于系统设计，正好解决了这个问题！答案 3 :(得分：1)
毫无疑问，您应该首先添加最简单的代码 - 但您添加的代码应遵循SOLID原则。
不要仅仅通过推测未来可能出现的变化来引入复杂性（例如设计模式，框架等）。
您正在解决的问题的Essential complexity无法更改。这需要前期思考，头脑风暴，但Accidental complexity复杂性会随着猜测而增加。
定期同行代码审核有帮助。如果您的同伴可以阅读并理解代码而不会引起人们的注意 - 那么我认为应该没问题。
答案 4 :(得分：1)
这使我的工作让所有可扩展性点都保持开放，（ab）始终使用所有类型的可扩展性模式。这确实是一个“黑暗的一面”：增加了整个系统的复杂性。我事先并不知道我的代码的某些部分是否需要进一步发展。
我们是否应该使用最简单的方式并且只在需要时才展开它？
我认为通过调整“简单性”和“复杂性”的定义，至少可以解决一部分难题。
JAA“食谱”，SOLID原则等都是在设计中管理耦合和凝聚力的捷径。如果您将设计的“简单”定义为达到最大内聚和最小耦合的程度，那么您可以说这些原则和模式旨在保持您的设计简单。
因此，根据该定义，您所谓的“可扩展性点”实际上是保持设计简单的结果，因此不会增加复杂性。此外，它们是否会在将来用于扩展目的而忽略了这一点，因为简单设计的目的是促进未来的改变。
短语“做最简单的事情可能有效”，更多地指的是构建内容的选择，而不是代码的设计。例如，如果需要显示HTML页面，请构建HTML页面，而不是Web应用程序。
因此，如果您按照维护设计的方式遵循上面简单的定义，并且只构建 minimum 来解决任何给定的问题，那么代码库将更小，您的设计不那么复杂，您的应用程序将邀请未来添加功能所需的更改。
最后一点注意事项：请注意测试对您的设计所说的内容。耦合和内聚问题经常表现为笨重的测试装置。当你看到它时，它表明你已经跳过了一些必要的重构步骤。