关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
4年前关闭。
Improve this question
想象一下，您在一家小型精益软件公司工作。您知道公司 future 的竞争力在于拥有可利用的良好可重用代码库。管理公司的再利用政策以确保您今天交付，同时为 future 提供支柱将非常重要。
在我看来，在业务中编写可重用代码有两个原因； 1) 在公司内部共享，以提高 future 的速度和效率 2) 在网络上发布和其他人将有助于改进代码(某种意义上的众包)。
当然，开发人员应该始终将常识应用于重用。但是为了从管理的角度处理这个问题，我需要一些整体的代码重用指南，以确保我们现在和将来都具有竞争力。这些指南应该鼓励开发人员问“我的代码是否适合重用？”。 这些指南应该说什么？
我最初的想法:在最低级别编写可重用的代码是不值得的(例如，我有一些在字符串末尾添加“'s”的内联代码)，这些代码太多了甚至筛选，发现有人已经做到了。在最顶层即应用程序编写可重用的代码也不值得，因为您的客户报告应用程序最终会被通用化为 SQL 客户端——对大多数用户来说毫无用处。
可重用代码的主要障碍:除非你知道它存在，否则你不能重用它；信任——已经完成，但你相信吗？使代码通用/可重用(并记录它)所花费的初始时间。
最佳答案
您可以花很长时间尝试使某些东西可重用，而无需任何人重用它。所以我通常遵循这样的格言，即我只在要重复使用的东西时才使其可重复使用(有一些异常(exception)情况会很突出)。
通常只有当你开始重用某些东西时，你的客户才会说“我希望它也这样做，除了……”或类似的。只有到那时，您才能了解可重用代码的哪一部分是可重用的，以及需要参数化的内容(例如，通过 strategy 模式或类似方式)
因此我不倾向于认为代码是可重用的，除非它真的被重用了:-)
关于agile - 什么代码是重用的候选代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1124668/