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