今天打算把一家已经黄了的公司的软件开发流程拿出来说一说，别觉得不靠谱，失败是因为商业决策的失误，与技术关系不大。
几年前曾风靡一时的社会化新闻网站Digg，由于一次失败的改版而人气大跌，最后被收购。其工程总监Will在自己的博客回顾了公司当时的开发架构和流程。
团队架构刚开始，Digg的组织架构很传统，产品、运维和工程团队各自独立。产品团队只有4名成员，运维团队8人，QA有6个人，研发大约20人。研发团队本身分为4个水平团队：前端、API、平台和基础设施。
后来由于人员流失，组织结构变得更为简单。运维团队只有3个人，工程团队7个人，广告工程团队4个人。
开发实践他们使用Git管理源代码，Grrit做代码评审。所有的代码都要得到同事的评审，并通过所有的单元测试。
有代码补丁提交到Grrit等待评审时，Jnkins会自动运行单元测试，并将测试结果更新到Grrit中，也就是说评审代码的人不会浪费时间去看失败的补丁代码，这样的代码也无法进入Git代码库中。
一旦Grrit中补丁代码通过测试和评审，它们就会被合并入Git的mastr分支，Puppt会将其自动部署到alpha环境中，在其中成功通过集成测试后，这些新的补丁代码会合并到Git的生产环境（production）分支。
向生产环境的部署是手工构建Jnkins方式完成的，接下来会使用Puppt一起部署更新代码。
开始时，他们使用了持续部署的方式向生产环境部署，但是出现一系列问题后，他们决定还是先采用人工方式。
Will说：
如果我们当时坚持使用持续部署，最终会改善我们的测试，使错误代码很难通过，但在当时，我们觉得投入那么多时间做这个并不值得。
Will认为这个评审、测试和部署系统是Digg当时最重要、最成功的开发流程系统，足以让40个人的团队开发出高质量和一致性的代码，也不会让14个人的团队被流程拖慢效率。
慢慢涌现的新实践刚开始，他们的单元测试覆盖率非常高，随着团队人员缩减，他们写的单元测试就非常少了。虽然没有人明说，但是他们相信：单元测试并不能减少他们遇到的绝大部分问题，比如在高负载下生产环境多个组件出现问题，最终导致系统故障；还有前端展现的问题等等。
他们使用Thrift定义前端和平台团队之间的接口，因此团队之间的沟通和协调非常直接。而且很少变更已有Thrift接口的行为，如果需要新功能，会开发新的接口并更新客户端，然后再移除旧的接口。虽然这个流程貌似奇怪，但是由于他们的前端和后端代码各自独立部署（部署所有的前端或后端服务器只要几分钟），这种做法很安全。
新的前端变更只会推送给一部分用户，如果有问题就会禁用。虽然他们一开始想用这种方法来完成新功能的A/B测试，但是其最大的价值在于管理版本发布，并从一小部分可信用户那里获得反馈。
在发布可能会影响性能或负载的后端功能时，他们都使用不宕机的方式。
康威定律下的“架构”康威定律，由计算机科学家MlvinConway在年提出，内容是：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的通信结构保持一致。
在Will看来，对比下他们的v4版本架构和他们设计这个版本时的组织架构，这基本上就是康威定律的直接表现。
当时的构成是：一个API团队和一台API服务器、一个前端团队和一台前端服务器、一个平台团队和一台后端服务器、一个广告团队和一台广告服务器、由基础设施团队管理的一大堆数据存储，以及一个分析团队使用的Hadoop集群。前端团队使用无状态的PHP、HTML和JavaScript开发，状态和存储由后端服务器管理，消息队列用来处理长时间运行和非事务处理。
他们同时使用Tonardo、Apach+mod_wsgi+Pylons、gvnt服务器作为后端服务，虽然让Will有点不爽，但是在实际工作中，整个团队并没有多大困扰，主要原因是使用了Jnkins和Puppt来部署系统。
在总结中，Will认为：
我们的流程和结构还是比较合理的，而且也很有效。如果今天重新来过，我们当然会有不一样的方式，或者要是我们的团队没有那么快减员，或者要是我们没有同时应对那么多技术债务——包括遗留系统、API和代码契约等等。
在互联网蓬勃发展的今天，创业公司层出不穷，它们在人员和资源上有不少限制，于是往往选择简单粗放的产品设计和开发方式，这种妥协被很多人认为是“对”的，但这会给公司的后期发展留下很多“基因”问题。因此有必要在公司创建时就建立较成熟的软件开发流程，以保持良好的效率和生产力。Digg的开发实践在某些方面值得借鉴和参考。
来源：技术风向标
关于21CTO21CTO是中国互联网第一技术社交与学习平台。为CTO、技术总监，技术专家，架构师、技术经理，高级研发工程师、PM等提供学习成长，教育培训，工作机会、人脉影响力等高价值的在线教育和社交网站。
