如何学习实现一半功能的正确方法？[关闭]

我领导一个开发团队，我想尽可能多地发布我们的产品（连续交付）。

在许多情况下，我们必须实施比发布之间的时间花费更长的时间才能实现的功能。我仍然希望人们每天提交他们的代码（持续集成）。

很多时候，实现新功能需要更改现有功能，并且即使新功能尚未完成，现有功能当然仍然需要工作。

如果开发人员使用正确的方法，则他们可以仔细调整现有功能，而上述所有都不是问题。

但是，正确的方法实际上是什么？我自己的编程知识告诉我如何处理每个案例，但是我需要了解更多信息，还需要一些阅读材料，我可以阅读并推荐团队成员阅读。或任何其他学习正确方法的方法都可以。

这就是问题所在。如何确保团队成员学习实现一半功能的正确方法？

我搜寻了自称对此有策略的人，但还没有找到，只是人们对此主题写了一些随机的想法。也许我没有使用正确的搜索词，或者也许没有人对此做出任何权威性的指导。

我已经对这里的其他答案有不同的看法。我同意您的看法，您希望尽快集成开发人员的更改，并继续测试组合的代码。

但是，我不同意今天早晨开发代码的权利，只是因为我们今天下午要发布。那是让失望的顾客满意的秘诀。

解决方案是在版本控制树中有分支，并且您有一个单独的过程将经过验证的增量从develop分支提升到release分支。

这样一来，您可以两全其美。您有开发人员进行持续集成，并带来了很多好处，您有规律地向客户交付稳定的代码，并且您有一个新的过程来测试开发人员分支中已完成的功能，如果这些功能通过测试，则使其成为已发布产品的一部分。 。

我熟悉有两种工具可以很好地支持此类过程。如果您的开发结构很简单，那么带有git-flow的git会实现一个良好的分支结构，该结构在中小型团队（大约20个开发人员）中可以很好地工作。

对于较大的开发团队，或者需要更复杂的分支策略来支持产品的多个“分支”的地方，accurrev是最好的。不参与变更管理的开发人员会抱怨说，它比子版本更难……但是它确实支持复杂的开发环境。

这里有两个问题：一个是实现一半功能。另一个是在持续开发过程中保持运输产品正常工作。

实现一半功能

强大的总体设计将对此有所帮助。这样一来，您就可以清楚地定义其边界来实现该功能-例如，到相邻代码位的API，对数据结构的期望以及对如何以及何时调用所实现的代码的理解。

测试可以包括该功能其他部分的模拟代码版本；这有助于您顺利实施下半年的过渡。

保持运输产品正常工作

这里有一些选择：

1. 关闭出厂产品的功能。仅仅因为代码包含在产品中并不意味着必须执行该代码或将其呈现给用户。不利的一面是，您不会为用户提供增量价值，也不会获得反馈。
2. 向用户显示功能的边缘。显示您所拥有的，并提供一些指示。
3. 让用户在新功能和旧功能之间切换。有时这需要维护两个可供最终用户使用的代码路径。

最后，如果您在使用这些解决方案时遇到问题，请考虑是否已沿着正确的边界分割功能。如果您以不同的方式切成薄片，会更容易分开吗？

如何确保团队成员学习实现一半功能的正确方法？

通过教他们。（du）

学习将涉及迭代：尝试某些事物，了解其工作原理，然后修改其方法以获得更好的结果。对于这种事情，我主张设计/代码审查。您将了解半功能的设计/实现方式，并有机会提供反馈。“那样做就行不通，因为它们会破坏我们的CI； XYZ呢？”，“这里做得很好，真的很干净。”

团队进行审核将帮助每个人学习您已经直观地了解的内容。

在这里对您最大的帮助是将关注点很好地隔离开，以使一个代码区域尽可能不干扰另一个代码区域。

在这里可以使用依赖注入和对接口进行编程确实有帮助，因此您可以在站点上拥有ISupportingFeature的当前实现，然后在需要创建依赖于不同实现的INewFeature时，只需使用新的实施，并维护生产中的现有实施，直到经过充分测试并可以投入使用。假设您的DI在某种配置系统上工作，这将使您可以在系统中并行使用相同的代码，并始终使用稳定的代码。

实际上，Martin Fowler将这种配置方法描述为功能切换。

当然，这个问题如果要部署只出现所有代码的所有的时间。这正是为功能分支设计的场景类型，尽管我承认福勒先生对它们不满意，但我不知道它们的坏处，特别是如果它们是按计划和经过深思熟虑创建和使用的，通过方式。