我最近意识到到目前为止我完成的大部分工作都必须重写。我可以回收一些零件，但一切都必须重做。由于这不是第一次发生这种情况，我已经非常非常恼火。将来应采取什么措施来防止此类事情发生？写出什么模块导入哪些模块应该做的事情（我必须使用一些非常丑陋的黑客来阻止循环导入），但我确定还有很多其他的漏洞我不知道。
答案 0 :(得分：1)
由于这不是第一次发生这种情况，我已经非常了， 非常恼火。
您似乎对代码的结构感到不满意并且感觉它确实如此 不符合你的标准。我们都去过那里。
将来应该采取什么措施来防止这类事情发生？
这很简单：你需要更多的经验。你如何获得更多经验？您 保持编程，这无疑意味着你不断犯错误。那么你 从这些错误中吸取教训。
我建议不要重写。请记住Joel Spolsky：
的智慧重要的是要记住，当你从头开始时，有 绝对没有理由相信你会做得更好 比你第一次做的那样。
我建议改变你的心态“这段代码糟透了，我要改写 它！“，”这个代码过于复杂，使用了一些讨厌的黑客，我想我会 重构它。“通过迭代重构，你将慢慢改进代码 直到你认为它是“可接受的”并同时获得宝贵的价值 体验，以便您从头开始创建的 next 项目会更好 结构
在决定特定代码更改时，规划会发挥作用 考虑它将如何影响代码库的其余部分 依赖性，复杂性，可维护性，可重用性等。
有很多关于重构的文章，所以我不会在这里重复，但是 在你开始之前，你应该进行正确的测试（即单位 或集成测试）这样您就可以在更改代码时充满信心。
答案 1 :(得分：0)
我的建议是看看软件开发公司如何处理需求收集和实施过渡。我会指出你研究开发模型的方向，比如瀑布和迭代方法。他们听起来有些陈词滥调，但实际上它们正是他们的目标：从需求到实施的过渡。
从我的（有限的，不可否认的）经验来看，瀑布式开发在实施之前将具有很多更长的规划阶段，但会产生非常强大的设计。更多迭代方法（如大多数独立开发人员大致采用的方法）可以更快地实现，但是他们对模块化的巨大关注才能有效，并且仍然依赖于设想大局的能力。
我建议尝试将最终结果映射到一个非常高的级别，并逐步将其映射到较低和较低级别，慢慢接近实现。对于大型项目，我计划花费同样多的时间（如果不是更多）计划而不是实际编码。
您的最终目标是尽早发现问题，以尽量减少重新安排修复工作所需的工作。您的设计中总会遇到问题。然而，你发现它们的关键点将决定它们解决的难度。
我无法真正提出许多建议，即“确保检查依赖关系”，因为当您逐渐降低计划中的抽象级别时，会出现这种情况。最终，你将会在这里看到要导入的库等等，然后就会出现这些问题。
答案 2 :(得分：0)
@Jkomusin提出非常有效的观点。一些较老的生命周期中的一个教训是强调在不同阶段修复物品的成本。作为一个粗略的指南，在分析中花费1英镑的问题，将花费10英镑来修复设计;编码100英镑; 1000英镑的实施;和部署后的10000英镑。花在计划上的时间永远不会浪费，你的目标应该是花费最少的时间来计划编码 - 或者更多的是计划而不是其他阶段。正如其中一个众所周知的引语所指出的那样“如果你没有计划（充分 - 我的补充），你就是计划失败”。