互联网开发模式一：核心问题
互联网开发的核心问题
当我1999年进入互联网行业工作的时候，华为刚刚通过了著名的CMM认证。当时作为一个小程序员，非常向往业界经典的软件开发模式。因为看上去，如果企业实行了CMM，我们程序员就不用再天天为了老板一个拍脑袋的主意而加班开发了，各种各样的奇葩需求和无理变更，也会烟消云散。但是，在接下来的十几年，几乎没有那个互联网公司再去通过CMM认证。是否CMM这种软件开发模式，就根本不适合互联网行业呢？这是一直以来我都在思考的问题。反而是跟随着互联网企业的一步步长大，我无意识的体验了很多现在流行概念的早期实践：敏捷、重构、持续集成、DevOps，这些实践一开始都非常的幼稚粗糙，但是却真正的伴随着互联网业务的逐步成长。所以，在讨论互联网服务的开发模式时，我认为必须要先搞清楚互联网服务开发的核心问题是什么。
本质：服务，而不是产品
软件到底是“服务”还是“产品”，这个话题一直都非常具有争议。作为程序开发者，实际上是非常希望软件能够是一个产品，因为软件的后续维护和修改，往往是“导致”项目失败的最常见原因。然而事与愿违的是，在互联网企业中，打多数的软件项目，表现出来的是典型的“服务”特征：
- 没有明确的需求合同。这导致了没有办法为软件设计固定的开发方案，也难以确定长期目标。
- 没有预付款和客户验收。互联网服务用户来了就用，爽了就给钱，不爽了就走，连沟通的机会都不会有。
- 甚至连明显的销售环节都没有。很多互联网公司只有市场推广部门，而没有所谓“销售”部门，因为推广就几乎等于销售，在推广的同事，就必须把销售的事情一起做了。
因此，在互联网行业中，软件开发更多的是以一种服务的形式存在。这种特征，在对需求的分析管理；开发技术的选择；集成与测试；运营和客服四个方面，都导致了不同于“产品”型软件的巨大差异:
- 对于一项服务来说，需求是持续变化的，你可以找到一些通用的模式，但是必须保持变化。
- 开发效率是第一重要的，因为市场竞争中，应对需求变化快的单位将获得更多的客户。
由于服务必须保持长期的稳定可用，又要具备快速的更新部署能力，所以系统集成的效率和质量要求非常高。所幸的是系统运行的环境大多数都是在可控制的空间里（比如开发公司自己的机房内）。
服务是公司和客户的一种持续沟通和交互的过程，并非一个单向的发售行为，所以互联网服务需要更多细致的运营和维护的工具，否则难以做到迅速而细致的满足海量的互联网用户的需求。
小米的MIUI开发节奏
管理：手段.vs.工具
在各种项目管理的课程里面，陈述了大量针对人去工作的方法。各种会议、报告、表格、评估、测量多不胜数，然而软件项目进度的控制，依然是一个难度堪比登月的事情。—————对于很多项目经理来说，程序员们基本是一个黑盒子，他们自己都不知道一个事情需要多长时间干完，就更别提别人怎么去预估和控制。这里最大的问题，我觉得是：我们往往总是想着怎样“控制”住软件项目的进度，而忽视了如何减少不利于项目进度的因数。实际上影响软件开发进度的主要因数，一般有一下几个：
- 程序员的能力水平。有一些项目其中的技术，是程序员完全没接触过的类型，这里包含了学习、调试的时间。
- 开发过程中的各种修改变更。由于对可行性、需求确认等方面的因数，开发往往会走“回头路”。有些项目做到一般会发现技术上不可行，需要修改需求；而另外一些项目是在项目做到一半甚至快完成的时候，需求方发现需要修改产品设计，因为在产品可体验之前，完全无法想象到最后会是现在的样子。
- 各种和开发无关的过程中的事务。这里包括开会、写报告、沟通、等待开发电脑编译、处理开发服务器故障、各种开发环境和测试环境的问题处理等等……这些事情往往都看起来不是非常“有技术含量”，但是实际上会严重影响开发进度。因为开发工作需要一个稳定、专心的工作环境，频频的被各种事务打断，会让程序员反复的花费时间去“进入”工作状态————面对成千上万行程序代码，要找到之前写到哪个部分，其实不是那么简单。
针对上面说的几个问题，很多都可以通过应用更好的开发工具来解决。比如一些新的需求类型，我们可以求助于互联网上丰富的开源软件和开源库；面对需求变更，我们可以使用设计模式、单元测试等工具；开发中的事务问题，更是可以有大量业界先进工具可用：SVN,Git,Jira,Project,IDE,Chef,Docker……
与其我们拿着鞭子抽打程序员，还不如给程序员更好的开发工具，这样对于项目进度的推动，其实更有好处。
资产：代码.vs.流程
互联网公司是由人组成的，人是会流动的，有一些小型的公司，往往会因为一两个核心员工的离职，造成整个系统的代码无法看懂，无法修改，从而最后导致公司完蛋。这种糟糕的情况，不止一次的出现过。然而，如果我们能有一套完善的开发流程，或者是习惯，以及配合良好的开发环境，加上有一定质量的代码，是完全能做到把项目代码，在不同程序员之间顺利交接的。可惜我们很多公司管理者，并不重视程序员用什么工具开发软件，也不知道如何去提高代码的可读性，所以造成我们的项目特别害怕人员变动。如果我们把人员变动看成是一个必然会发生的事情，那么我们就会更重视整个代码的开发环境和开发过程，从一开始就把开发规范确定下来，规定使用什么环境，应用何种工具，并且坚持执行，同时在实践过程中不断的改进。只有这样有预备的去做，最后才会保留的住公司真正的资产。
一家互联网公司，我们在评估其开发资产的时候，并不应看他“拥有”多少行代码，因为这些代码是无法直接卖钱的。而互联网公司的开发速度，以及这个速度背后的能力才是最重要的。
感谢大家的阅读，如觉得此文对你有那么一丁点的作用，麻烦动动手指转发或分享至朋友圈。如有不同意见，欢迎后台留言探讨。