我在Scrum,TDD,领域驱动设计和Bob叔叔的食谱之后一年就开始工作了......但我有一些疑问是我们应用各种原则,主要是在阅读"Java应用程序架构"(从现在的JAA)总是来自Martin的系列.如果我错了请纠正我!(希望我是)问题从TDD和Scrum开始,说明我们应该在系统出现后改进系统,避免前期设计.这使我的工作让所有可扩展性点都保持开放,(ab)始终使用所有类型的可扩展性模式.这确实是一个"黑暗的一面":增加了整个系统的复杂性.我事先并不知道我的代码的某些部分是否需要进一步发展.
但是,正如在任何地方正确陈述的(并且经常在JAA上),您应该仅在需要时添加复杂性.这个恕我直言的结论是,应该进行适当的前期分析......与其他食谱相冲突......
因此循环.... aaargh我讨厌循环依赖!!!
功能被"确认"后,我们是否应该重构以降低复杂性？我们应该使用最简单的方式,只有在需要时才能扩展它吗？例如,当你不需要它们时,不要构建超级解耦的东西吗？
(欢迎任何改进问题风格和内容的建议,我是stackoverflow的新手)
功能被"确认"后,我们是否应该重构以降低复杂性？我们应该使用最简单的方式,只有在需要时才能扩展它吗？例如,当你不需要它们时,不要构建超级解耦的东西吗？
是的.虽然这是相当主观的,但我不喜欢能够灵活地改变每一件事情的系统,而你却不会利用所有这些灵活性.你的陈述是矛盾的:测试驱动开发教会我"做最可能有用的事情".
如果需要更多功能,您可以添加测试,然后重构和扩展代码以确保它完成您希望它执行的操作.因为您已经进行了测试,所以您可以放心,您不会破坏当前现有的代码.
简而言之:不要因为可以而建立灵活性.你应该建立灵活性,因为情况决定了你.我坚信,重构"按需"让你的项目比具有内置(未使用)的灵活性,更短的构建时间.有了你的测试,"按需"重构应该用不了多长时间.
更短暂的:保持简单,愚蠢.;)