将来从一个人的项目转移到团队的项目。我现在应该准备什么，可以等待什么？

详细地说，我很想知道人们在一个人的项目中需要采取什么措施（团队源代码控制，文档，构建等），以及直到第二个人来时才需要做的事情进入项目。

任何有过这种情况经验的人，他们的见解将不胜感激。

我学到了什么。（我尝试了不同的顺序。我错了。这是事物相关的顺序。）

1. 将所有内容放入源代码控制中。使用的东西，每个人都可以访问，并开始现在。没有例外。没有延迟。没有理由。

2. 创建一个与您的个人“工作”或“开发”环境完全分开的质量检查/测试区域。至少一个单独的用户ID。理想情况下是在单独的VM上。
   完全分开。与您当前的工作环境不可能重叠。

3. 在您自己的工作环境中，停止超出单元测试的测试。代码和单元测试使您“像您自己一样”。您在单独的VM上执行的所有其他测试（集成，性能等）。永远不要自己测试。始终以单独的质量检查用户身份进行测试。理想情况下是在单独的VM上。

   必须对您的团队成员说“为我工作”是一件坏事。很坏。您需要弄清楚他们在做什么错。一天几次。

4. 计划写下一切。使用纯文本标记工具（RST或Markdown或其他工具），以便所有文档在版本控制存储库中均为纯文本。一个工具可以创建HTML页面（例如，用于RST的Docutils）或PDF页面，或看起来最好的页面。不要使用专有文档格式（即MS-Word）。它们在某些源代码控制系统中可能无法很好地发挥作用。

5. 您需要写下的第一件事是以下内容。

   • 如何创建一个工作的开发环境。如有疑问，请创建虚拟机并在该虚拟机上执行整个操作。确保步骤确实有效并且文档清晰。实际的行以实际的命令行键入的清晰度。

   • 如何运行单元测试套件。再次。确保说明有效并且不需要思考。“输入以下内容：”“确认：”这类内容。不是您的团队成员很愚蠢。除非您将所有内容写下来，否则您将不记得自己的假设。

   • 如何运行集成测试套件。

   不要浪费很多时间来描述架构或设计原则。您需要首先让某人启动并运行。您可以稍后再解释。

6. 接下来要记录的是用户故事。还有支持这些故事的测试用例。以及支持这些用户案例的测试用例所需的数据夹具。

   您将分享这个。它受源代码控制。

7. 最终，您可以记录其他4个视图。

   • 逻辑视图对文档很有帮助。图片在这里可以接受。这往往会迅速发展，因此不要花时间捕获旧信息。找出与您的团队成员合作的方式。

   • 流程视图通常很有帮助。具体取决于整个应用程序的重要性。

   • 开发视图（模块，库，框架等）通常是非正式描述的。一张照片可能会有所帮助，但是要使其完整到足以使人可以拿起文档并使其正反两面都很难。即使是历史悠久的非常公开的项目，其图书馆文档也被忽略了。（导致很多堆栈溢出问题。）

     除了可以接受非正式之外，这种趋势还会迅速改变。

   • 部署信息。服务器。IP地址。数据库凭证。所有这些东西都必须写下来。最终。

工具和方法

成功合作和提高生产力需要什么？

• 识别项目的部件/组件：区分不同的部件（数据库，数据访问层，网站，服务，API，测试项目，构建脚本等）和环境（开发，暂存，生产），并命名它们始终会影响您的口头和书面交流（文档，项目名称等）
• 使用源代码管理系统（以防万一）。考虑如何在项目和设置中使用分支。
• 自动化构建 -尽可能轻松地从源存储库设置环境。
• 对于大型项目，至少对于更复杂的项目，测试项目是必须的。
• 使用准备使用项目的暂存环境。此外，创建并维护用于自动登台设置的样本数据。
• 使用一个错误跟踪系统，该系统可以帮助确定优先级和计划开发，还可以存储过去的错误以及如何解决它们。
• 记录项目的每个部分，其中一些要比其他更多。我个人喜欢：概述-体系结构-依赖关系-配置-常见问题（从此处开始）。有时少即是多-为了不让您的文档过时，最好简明扼要，让文档成为您日常活动的一部分。

管理/团队合作

...或人际关系层面上的其他任何事物

• 定义您对其他开发人员的期望。合理地说，没有人会像您一样带来相同的参与和热情-至少从一开始就不正确。传达您的期望和不期望的东西，定义您和另一个人的责任。并非每个人都是工程师，架构师，开发人员，dba和sysadmin，但是如果您要的是这种情况，请选择合适的人，否则您会失望的。
• 首先，精确定义任务，然后回顾和讨论结果。逐渐地，开始进行越来越少的微管理。这个想法是建立信任并增加责任。
• 计划您的项目，为您的项目和下一年的团队设定目标。写下来，以后再检查，这将为您提供透视图。这些目标可能会也可能不会传达给其他人（只要它们是您需要实现的目标，而不是其他目标），它可以只是您自己的清单。
• 花一天时间准备和计划新开发人员的第一个月（或两个/三个月）。与充分准备的人一起工作时，我发现这非常有激励作用。没有人会觉得自己的时间浪费了。
• 放开。是你的孩子，它也应该变成别人的。至少在项目的某些部分，允许另一个人比您更好地成为专家。这实际上意味着您成功了。
• 听着 -如果您雇用了她，她有话要说。准备学习。
• 准备分享您的知识和经验（因此，时间-耐心等待）。
• 错误会不断出现，这是如何处理错误以及每个人对它们的了解都至关重要的。
• 留出时间学习和实验

书籍参考

我将列出一些我实际上已经阅读并且通常认为值得一读的书籍，以获取更详细的描述或更多书籍，您可能想要检查一些有关SO的问题，例如这个或这个问题。

关于团队，组织和编程项目，这些书确实值得一读：

• 人民网
• 神话人月
• 软件估算，揭开妖术的神秘面纱

这些都不是有关如何实施方法X的实用指南（软件估算除外，这本书可帮助您选择适当的估算过程）。当然，更着重于编程本身的书籍（如Code Complete）也非常丰富。

我将根据经验谈谈，但请记住，每个人都是不同的。这些事情不是普遍的。

一件事就是让它个人化。这个项目与您一起生活了18个月，您自然希望每个更改都像您所做的那样。为同事犯错误，学习提供缓冲。为他们创建一个有用的房间。请记住，它可能不会立即发生。如果他们能感觉到他们在改进或创建方面成功的代码中的某些部分，那感觉很短，那么这也很棒。耐心和宽容在这里有良好的回报率。不要试图进行微观管理，如果要批评，说“你错了”，请确保自己有功绩，可以证明这一点，这不是一场“宗教”斗争。

另一个关键问题是找到适合您的人。理想情况下，找到比自己聪明的人会更好。它是主观的和相对的，但是如果您觉得一个人拥有一些您没有的知识和技能，那是最好的。这将是一个互惠互利的合作。

可以通过两种方法进行操作-同事会很累，您最终将重做他或她所做的事情，或者你们两个人的技能将成倍增加，而不仅仅是累加，并且您将非常喜欢一起工作。

关于“干净，快速，可重用的代码”主题-我建议在一次采访中，要求写一个小的微内核/服务经理和/或工作执行者。查看如何指定和配置可插拔组件。不一定要完成，这是很重要的想法。而且，您还将很快学习到知道如何做的人，他们会想要像样的钱；-)祝您好运！

我的观点：首先为不了解它的人记录您的内部项目的体系结构。尝试解释哪些假设是正确的，何时/何地偏离常规做法以及原因。

构建自动化：好主意，我可以为开发机器添加配置自动化。最容易的是构建更多的东西（这样可以更快/更快地部署测试）。

另一个想法（曾经对我有很大帮助）：让新开发人员在代码库的不同区域进行一些清理小规模的任务，以便他习惯于布局工具等。一个好主意是删除遮盖区域，这些区域以后可能会增加混乱（例如：如果您在某处的外壳脚本的两行中使用了emmm python，并且您的项目基于Java，请要求用Java重写这两行，以便开发人员＃3需要为了工作而少知道）

我将专注于使需要人工工作的所有事情自动化，因此可能会被经验不足的人弄糟。根据您上面的简短评论，其中包括以下内容：

• 安装版本控制并将手动备份替换为自动备份，
• 尽可能设置自动部署（至少要编写脚本来通过FTP部署，而不要手工完成）。

如果您不做这些，或者您将被束缚永远做这些任务，或者（某些）新员工迟早会不可避免地搞砸了。

正如@dimitris指出的，另一个重要任务是文档。@S。洛特为此增加了更多细节，因此他只给+1而不是重复:-)

以下是部分基于个人经验的想法：

• 记录您的项目。设计规范，图表，手册和注释将帮助新员工快速入门。仅用口头解释一个复杂的系统会证明缓慢而令人沮丧。单人项目中经常忽略文档。确保您的例外。

• 首先，自己专注于API /核心级别的代码，同时为新员工提供一些“应用程序层”工作或bug修复，以使他们逐渐熟悉代码。通常，从更轻松，更有意义，因此有意义的任务开始。

• 沟通很重要。对新员工的问题，评论和想法做出回应。解释为什么您认为一个主意不好的原因。一双新鲜的眼睛可以令人惊奇地发现改善的空间。如果您的新员工是一个体面的员工，他可以同行审查您的代码并最终参与架构决策。互相讨论，互相讨论。这是在您的项目中拥有同事的最大好处之一。

• 一旦知道新团队成员要完成的任务，就可以清楚地定义职责。建立文档惯例和编码约定，以使事情顺利进行。

• 使用修订控制系统。保持逻辑的源文件布局并建立纪律。

至于面试-我不喜欢人工编码测试或技巧性问题，除非您希望尝试考生的压力承受能力。即使最聪明的问题解决者也可以锁定这种情况。您要寻找的特质包括：诚实，专业能力，技术知识/洞察力，热情和相互兼容。工作氛围可能意味着很多；建议您选择不喜欢的队友。将您的问题放在正确的位置，并进行一些非正式的讨论，以对候选人有所了解。祝好运！

技术

如果您邀请其他人作为开发人员，那么在他们开始之前，我建议您进行三项关键工作。

1. 源代码控制
2. 问题跟踪
3. 持续集成

如果这三件事正常运行，您将消除约75％的新团队成员出现的常见问题。这些技术的要点是仅将很多正在发生的事情带到您的脑海中，并将其带到您的团队成员可以与之交互的位置。

源代码控制可确保您都在做同一件事。问题跟踪不仅可以帮助您跟踪需要完成的工作，还可以使您更轻松地了解他们的工作和完成情况。持续的集成和测试将有助于确保您具有可重复的构建过程，并且新的改进不会破坏代码的其他部分。

实用程序员对此有一些不错的书。这是我推荐的一些。根据您使用的编程语言或要使用的版本控制，它们还有其他相似的标题：

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http：//www.pragprog。 com / titles / auto / pragmatic-project-automation

个人

通常，您将面临的困难不在技术方面，而在学习放手方面则更多。很难让其他人控制项目的各个方面-特别是如果您习惯于自己做所有事情并做出每个决定的话。如果您可以找到一个可以让新员工在开始时以合理的自由度工作的区域，从而为您建立信任的基础，那么您会为自己省下一些痛苦。如果您雇用一个好人，那么您可能会学到的主要事情是，如何信任另一个人做得好的工作，即使他们的所有个人决定与您所做的决定都不一样。

您希望给新员工以解决问题的自由，同时确保安全措施到位，以便您尽早发现问题。

我认为以下几点最重要：

1. 阅读代码的关键部分，并确保它们易于理解。使用注释或直观的功能和变量名称。
2. 让新人轻松提交代码。
3. 如果不是很简单，请创建一个README文件，该文件为新开发人员介绍了如何设置开发环境的所有必要步骤。或者，紧密协助建立此环境。
4. 在这个新项目上工作时，给新开发人员非常明确地定义任务。我认为这些任务应该涉及新的但简单的功能。在我看来，清理任务没有多大意义，因为新开发人员首先必须习惯您的编码风格及其习惯，即使它们很糟糕。清理甚至重构是需要知道代码的人完成的工作。
5. 弄清楚提交代码的过程。（例如，仅提交可编译的内容。）但不要太严格，一开始可能会令人沮丧。
6. 准备具有编码约定的文档。猜想其他编码约定是什么，真的很令人沮丧。
7. 如果应用程序很复杂，请准备一些文档以解释其架构。或使用流程图或类似方法向新手介绍该体系结构。您不想让新开发人员在项目的反向工程上浪费太多时间。
8. 如果应该由新开发人员自己进行部署，请准备一份有序的清单，以说明部署所需的所有必要步骤。

最后但并非最不重要的一点：获取版本控制系统。Subversion很好。但是请确保不要添加特定于用户的Eclipse文件（或其他文件），因此会不断更改。它们使您浪费时间。如果您有任何问题，请随时询问Stackoverflow。