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