目前，我有一组或多或少有组织的项目，我正在工作或正在从事。有些经过重构、记录和单元测试，有些则没有。
当我想重用以前编写的代码时，我会花几分钟搜索我编写此代码的项目，然后将此代码复制粘贴到新代码中，如果需要，进行重构、记录和单元测试。
它很丑陋，因为它需要做额外的工作，记住编写的内容和位置，并且（可能是最丑陋的）跨项目复制代码。在没有通用代码库的情况下与其他开发人员合作也是一个问题。
现在，我想创建一个代码库，但我对此一无所知，也从未在任何公司见过认真的代码库。
那么从哪里开始呢？是否有书籍或在线文档解释如何创建此类代码库或描述现有或虚构的代码库、它如何工作、如何维护等？
Currently, I have a more or less organized set of projects I work or worked on. Some are refactored, documented and unit-tested, others are not.
When I want to reuse a code I've written before, I spend a few minutes searching for the project where I've written this code, than copy-paste this code to a new one, refactoring, documenting and unit-testing if need.
It's ugly, because it requires to do extra work, to remember what was written and where, and (probably the ugliest one) to duplicate code across projects. Working with other developers without having a common codebase is a problem too.
Now, I want to create a codebase, but I don't know anything about it and have never seen a serious one in any company.
So where to start? Are there books or online documentation either explaining how to create such codebase or describing an existing or imaginary codebase, how does it work, how is it maintained, etc.?
发布评论
评论（3）
我认为您指的是可重用的库。它有点依赖于语言，因为带有链接器和编译器的语言会删除不用于使可交付成果更小的代码，而即时编译或解释语言则不会，因此加载整个库可能会浪费资源。
简而言之，就是查看您的代码，了解通常执行的任务和使用的参数。添加一点更改空间并创建一个界面来隐藏所有功能。正确定义接口是最重要的部分。尽量避免函数调用的集合，而是在接口后面创建相关函数，然后为每个操作任务创建一个接口 - 您试图将工作拆分为多个操作。
接口解决方案将解耦（重构工作的）实现和使用接口的工作。这将有助于将公共代码与项目代码分开，从而允许它们以不同的速度进行开发。
尝试将有关特定工作或任务的所有相关信息分组到界面后面，以便界面不会相互依赖。
有关接口的一些有用的链接。有些链接讨论面向对象语言，但原理和思想可以应用于任何其他类型的语言。
http://en.wikipedia.org/wiki/Interface_%28computer_science%29# Software_interfaces_in_object_orient_linguals
http://en.wikipedia.org/wiki/Interface_ %28computer_science%29#Programming_against_software_interfaces
I think you are referring to re-usable libraries. It's a little bit language dependant because languages with linkers and compilers will strip out code which is not used to make the deliverable smaller whereas just-in-time compiled or interpreted languages don't so resources can be wasted by having the whole library loaded.
The long and the short of it is to look at your code, realise the tasks that are commonly performed and the parameters that are used. Add a little room for change and create an interface in which to hide all that functionality behind. Defining the interface correctly is the most important part. Try to avoid a collection of function calls, but rather create related functions behind an interface, then an interface per operational task - you are trying to split the work into operations.
The interfacing solution will de-couple the implementation (of the refactored work) and the work that uses the interface. This will help with separating the common code with the project code allowing them to be developed at different rates.
Try to group all the related information regarding a particular job or task behind an interface so the interfaces don't rely on each other.
Some useful links about interfaces. Some of the links talk about object oriented languages but the principles and ideas can be applied to any other type of language.
http://en.wikipedia.org/wiki/Interface_%28computer_science%29#Software_interfaces_in_object_oriented_languages
http://en.wikipedia.org/wiki/Interface_%28computer_science%29#Programming_against_software_interfaces
使用版本控制服务，例如 Google 代码 或 GitHub。这样您的代码就会在线备份，并且您可以根据需要恢复到旧版本。
Use a version control service such as Google Code or GitHub. This way your code is backed up online, and you can revert to older versions if you need to.
首先，认识到这是一项重大工作，需要其他开发人员和管理层的参与。在重新组织代码库时，您可能需要停止新功能的开发，这几乎从来不是管理的选择。即使向他们提及这件事也可能很糟糕。 “我们可以把这件事推迟到重组之后”，然后是“在这件事完成之前我们不能进行重组”，大任务和重组都互相等待。这是管理功能的僵局，而且很难修复。
接下来，您需要与您的团队坐下来确定您的产品是什么、它们是如何构建的、重叠的地方以及产品如何从这种重用中受益。您需要仔细检查产品的构建结构，并重构它以包含您的公共库（您将要构建的）。
展望未来，您需要隔离依赖项。不要让公共资源依赖于项目。如果项目 (projB) 将来很可能最终依赖另一个项目 (projA)，则不要让一个项目 (projA) 依赖于另一个项目 (projB)。循环依赖让人哭笑不得。
First, recognize that this is a significant effort that will require the involvement of the other devs and management. You will probably need to stop work on new features while you reorganize your codebase, which is almost never an option for management. Even mentioning it to them can be bad. "We can put this off until after the re-org" is then followed by "we can't do the re-org until this piece is done", and both the big task and the re-org wait on eachother. It's the management-feature-deadlock, and it's hard to fix.
Moving along, you need to sit down with your team and identify what your products are, how they're constructed, where the overlap is, and how the products can benefit from this re-use. You need to closely examine the build structure of your products, and refactor that to include your commons-library (that you're about to build.)
Moving forward, you need to isolate dependencies. Don't let commons rely on a project. Don't let a project rely (projA) on another project (projB) if there's a good chance that project (projB) will end up relying on it (projA) in the future. Circular dependencies make for weeping and gnashing of teeth.