前端框架 Bootstrap 是如何开发的

几个月前，有人问我：“你们是如何在Bootstrap中管理和开发功能的？”总的来说，这是一个管理比较松散的社区，但是我们的确制定了一些特别的指导方针。

目前，体验盒子(UB2016)也使用了Bootstrap框架。

将其视为一个产品

首先，我们将Bootstrap视为一个真正的产品。它有自己的功能、有自己的开发团队、有自己的release和用户。它有着自己的使命：让web设计和开发变得更简单。当我们添加或是移除功能的时候，我们会尝试用自己的，以及用户的经历和兴趣去匹配这个目标。

这种心态很多时候影响着我们使用Bootstrap的方式。我们非常在乎这个它，我们在影响人们的生活，我们是一个小团队，维护Bootstrap给我们带来了许多的快乐。在功能方面，我们探索自己有能力添加哪些功能，探索自己想要添加哪些功能，以及探索实现这些功能的最好方式 。

而且我们的工作方式非常实际，也就是说，除非我们能将其完成的很好，否则我们就不会去做这件事情。我们还会拒绝很多用户的新功能请求——我们专注于当前的工作，专注于当前功能的质量，这要比部署新的功能重要的多。

一般性功能请求

大多数情况下，我们都会在GitHub上监测趋势，确定添加哪些新功能。Bootstrap的issue tracker是我们用来管理新功能，以及对已有功能进行更新的主要方式。任何人都可以请求我们添加某种新的功能，或是对已有功能进行扩展或更新。我们会挑选我们觉得有意义的新功能请求，并且制定新的release的日期。其他的请求则会被关闭。

请注意，用户给我们提新功能请求，并不一定会被我们采纳。我们有的时候其实挺自私的。我们只会添加那些我们也觉得有用的功能。很多我们不喜欢，或是难度太高的新功能，我们不会去添加。

我们的这种做法，带来的一个结果就是，有许多开发者在完成那些我们没有做的功能，然后在社区内分享。对于需要这些功能的用户来说，这是一个极好的消息，我对此也感到非常高兴。

重大更新

在重大版本更新的开发过程中，我们不会对外分享太多的消息，直到我们需要外部帮助和测试的时候。这让我们能够专注于当前的工作，尽可能的降低决策数量——和其他产品一样。

我们会跟踪那些我们想要开发的功能，并且私下将它们添加在下一个版本中。我们在GitHub上有两个私密repo——twbs/team和twbs/derpstrap。我们的团队做了一个列表，上面都是我们想要在v4版本中添加、移除或是改变的功能。这个列表成为了我们的工作总指挥，在整个的v4开发工程中都发挥了重要的作用。

借着每一次重大更新的机会，我们都会重写一遍代码。在很早的时候，我们就采取了这样的做法，为的是保持自己的热情，不断开发新的东西。当你进行试验的时候，要让自己尽可能的获得乐趣，在老项目上实验新的创意。所以，我们会时不时的改变一下已有功能。这会让你不断的在这个项目中获得乐趣。

开发

Overall our development flow looks like this:定期的开发（小更新和补丁发布），有的时候是我们自己完成的，有的时候是由代码贡献者完成的。总体的开发流程是这样的：

• 在确定要打造哪些功能之后，我们会找到相关的代码，然后添加CSS、JS和文档。
• 打开一个Pull Request,并且将其cc给团队成员和最初的请求发布人。
• 添加相关的信息、屏幕截图和事件的当前状态，让人们知道目前的进展。
• 在功能开发完成并且通过了测试之后，我们会将其添加到主代码中
• 将新功能的说明添加到更新日志中
• 在新版本即将完成的时候，我们会在GitHub上创建一个release，然后将新版本共享给全世界

但是并不是每一个新功能都会受到欢迎。有的时候我们做出的改变也会受到不太好的效果。可能是代码写的不好，也可能是代码写的比较冗余，或是这个新功能并不是大多数人所需要的。有的时候我们会忽略许多人的新功能请求，但是我们并不会觉得不好意思——毕竟我们要优秀考虑整个项目。

简单与专注

简单来说，我们要保持简单与专注。由于对于我们大多数人来说，Bootstrap只是一个副业，轻量级、可执行的开发过程对我们来说是大有裨益的。我们喜欢为人们提供帮助，但是在这个过程中，我们也需要对许多人说no，最重要的是，在我们看来，Bootstrap不仅仅是一个开源项目。

原文：Managing features in Bootstrap
译文：SDK.cn
作者：Christian（编译）