这不是一个直接的编程问题，但是编程社区的一些帮助将不胜感激。
我患有过度全身化疾病。我不能停止花费宝贵的时间来使我的代码最通用和抽象。我也可以称之为工具包/库疾病。我倾向于将每个编程任务转变为一般问题并尝试“编写工具包”，这将适用于许多类似的问题。
我知道这是一件好事，如果有足够的时间，但有时我应该写一个快速的原型，似乎无法编写适用于特殊情况的快速和脏代码。我经常对一个让代码更通用，用户可配置的想法感到兴奋，并且低估了以这种方式实际实现它所需的时间。
有没有其他人有这种经历？如何强迫自己在“快速入侵”和“好解决方案”之间找到适当的平衡点？
答案 0 :(得分：4)
Test-driven development（又名TDD）可以成为对过度推动普遍性的一种有用的平衡 - 它引用了一种做法，引用我刚刚指出的维基百科条目，
编写代码很重要 仅用于通过测试;没有 进一步（因此未经测试） 功能应该预测和 在任何阶段'允许'。
一旦你严格地练习了一段时间（最好，如果可行的话，在配对编程中，合作伙伴加强了彼此遵循这些习惯的动机！ - ），你可以超越这个。
这是通常的学习循环：shu，“保留”，在你掌握它之前练习一种技术;哈，“分离”，你在那里平衡技术;最后ri，“超越”，你超越了这种明确的学习，掌握并内化了一切 - 它的编程效果也一样，就像它最初设想的No剧院一样（大多数人都在熟悉shu-ha-ri概念的West可能在武术的背景下遇到过它，但是，从历史上看，这已经是原作的巨大延伸; - ）。
答案 1 :(得分：4)
我也倾向于这样做。但是当我开始使用重用我的“通用”代码时，我通常发现它并不是我在新情况下所需要的。
这些天我试着等到我已经实施了几次之后再考虑如何推广它。这样我就可以更好地了解我应该涵盖的实际用例。
这个问题也让我想起了查尔斯摩尔在this blog post中的引用。每次重新实现某些内容时，您都会了解更多信息，并改进实施。在将实现粘贴到库中之前，您可能需要重新发明几次。
答案 2 :(得分：3)
写快速和脏，并测试它是否有效，重构直到你不为代码感到羞耻。
答案 3 :(得分：3)
确定截止日期。如果您没有截止日期，请创建自己的截止日期。
程序员不是在真空中工作，他们在大多数时间都是为了满足业务需求。
我通常先获得快速交付解决方案，如果我有时间，我会开始清理它（确保不要破坏功能。截止日期的最后一个好的版本是发货版本。
相信我，后端的第一双靴子或其他糟糕的性能评估将教会你这个的重要性： - ）
答案 4 :(得分：2)
工作代码优于设计良好但非工作代码。即使是最粗暴的实施也比不起作用或甚至没有完成的东西要好得多。
从原型/快速和脏的实现中，更容易进行重构和结构改进，因为有一个工作引用来测试。
正如其他人所写的那样，TDD非常有用，因为如果没有经过适当的测试，它很难在任何重构项目中取得成功。
但最后，将程序运行的问题域中的泛化与整个计算域内的泛化分开是非常重要的。
项目最终经常会重新发明数据结构，算法，网络协议等解决方案，而不是使用现有的实现/库。
我见过很多程序员实现自己的哈希图，http实现等的例子，而不是使用现有的哈希图。有时候库和应用程序之间可能缺乏兼容性，但是facade模式可以用来封装外部库的使用。
答案 5 :(得分：0)
我认为这是许多程序员面临的问题。这就是为什么我们需要了解业务的项目经理。不幸的是，我们的工作环境不仅仅是学术性的。因此，我们所做的工作只有在及时满足业务要求时才有用。
你必须在代码“正确”和实际交付工作软件之间找到适当的平衡。
答案 6 :(得分：0)
我总能找到的最佳答案是代码需要持续多长时间？您不必编写整个框架，只需确保其可维护。