东赢体育面向对象思想包括分析、设计、编码三个部分（OOA/OOD/OOP）。这些思想看起来繁文缛节，似乎非常啰嗦。然而，其核心思想却非常简单：从表达过程，转向表达对象。人类的思维中，对象、或物体，是一个个具备自己的信息特征的个体，而行为和过程，往往是依附于这些个体的。比如鸟会飞、账号会锁定、汽车会死火等等。所以如果我们的代码，是以表达对象东赢体育，把信息和行为统一起来，是最接近于我们的认识规律的。

　　互联网的客户个体多，服务内容丰富，功能变化快，是互联网项目中需求变更很多的主要原因。因此这也让敏捷开发，成为互联网项目开发中最重要的方法。——敏捷强调的是用原型来验证需求，在互联网服务里就是，尽快推出服务，通过数据来验证想法。如果我们能越频繁的修正原型，就能越快的接近真正的需求，也就是说，如果我们的互联网服务能越快的修正各种问题，同时越快的推出新的版本，就能让用户越牢固的“黏在”这个服务上。

　　对于一项服务来说，需求是持续变化的，你可以找到一些通用的模式东赢体育，但是必须保持变化。

　　开发效率是第一重要的，因为市场竞争中，应对需求变化快的单位将获得更多的客户。

　　由于服务必须保持长期的稳定可用，又要具备快速的更新部署能力，所以系统集成的效率和质量要求非常高。所幸的是系统运行的环境大多数都是在可控制的空间里（比如开发公司自己的机房内）东赢体育。

　　因此我们想到了流行的“重构”，然而，如果我们只是重构进程的关系，通信的层次，那些错综复杂的代码调用关系一样存在。各种回调、事件、耦合还是让代码无法理解。我们只是在试图把混乱塞到一些瓶子里面，并没有解决混乱本身。所以，我们需要的另外一个思想武器：代码结构。只有我们从另外一个角度，另外一个视图去观察代码，才能把握代码之间耦合的情况。正如建筑里的平面图和立面图，都是不可或缺的。

　　我见过无数的代码架构图，里面画满了进程和服务器的拓扑，各种线条上标注了通讯协议，编码格式，还有各种流程图和协作图，然而，这些架构设计，无一例外的对于需求变更毫无帮助。因为它们描述的是一种现状，甚至连现状都不是，只是一种猜测，一种关于现状的猜测。随着项目代码的不断变化，代码数量和关系都会膨胀，这种进程、通讯级别的结构，除了越来越复杂以外，根本对于指导项目如何应对各种“代码腐化”毫无用处。

　　敏捷开发讲究要快速的修改代码，我们往往会发现，代码修改的越频繁，BUG越多，这似乎是一个无法解决的矛盾。然而，在敏捷开发方法论中，有一个重要的措施，就是用来防止这种修改造成的BUG增加的。这就是——单元测试。 单元测试本质上，充当着自动的QA人员的角色，如果我们把所有的设计和需求，都先按单元测试的形式“固化”编写下来，那么我们在修改代码后，就能快速的、自动的、反复的去验证我们的代码有没有问题。如果这些测试足够全面和详细，那么我们是不会担心代码修改导致大量的BUG的，因为单元测试会自动帮我们支出问题所在。一旦我们知道了问题，修正起来反而变成是最简单的事情了。

　　与其我们拿着鞭子抽打程序员，还不如给程序员更好的开发工具，这样对于项目进度的推动，其实更有好处。

　　互联网公司是由人组成的，人是会流动的，有一些小型的公司，往往会因为一两个核心员工的离职，造成整个系统的代码无法看懂，无法修改，从而最后导致公司完蛋。这种糟糕的情况，不止一次的出现过。然而，如果我们能有一套完善的开发流程，或者是习惯，以及配合良好的开发环境，加上有一定质量的代码，是完全能做到把项目代码，在不同程序员之间顺利交接的。可惜我们很多公司管理者，并不重视程序员用什么工具开发软件，也不知道如何去提高代码的可读性，所以造成我们的项目特别害怕人员变动。如果我们把人员变动看成是一个必然会发生的事情，那么我们就会更重视整个代码的开发环境和开发过程，从一开始就把开发规范确定下来，规定使用什么环境，应用何种工具，并且坚持执行，同时在实践过程中不断的改进。只有这样有预备的去做，最后才会保留的住公司真正的资产。

　　曾几何时，我们认为，使用什么语言开发，用结构化编程，还是面向对象编程……这些一般人难以深入理解的事情，都是程序员这伙顽固的家伙的怪癖，基本属于私人喜好的范畴。外人既不应该深入干预，也没办法去影响，因为如果你不识好歹去在这些事情上冒犯程序员东赢体育，他们随时可能一言不合就辞职。既然我们只需要可以运行的代码，我们为什么冒风险去激怒程序员呢？然而，在互联网服务开发过程中，代码本身并不是某一个固定的、静态的东西，它需要不断的与时俱进，需要跟随这业务的发展而变化，同时也会从某一个程序员手里，流向整个开发团队。在这种情况下，软件开发习惯、代码的风格、程序的设计思路，就变成一个非常重要的事情了。

　　针对上面说的几个问题，很多都可以通过应用更好的开发工具来解决。比如一些新的需求类型，我们可以求助于互联网上丰富的开源软件和开源库；面对需求变更，我们可以使用设计模式、单元测试等工具；开发中的事务问题，更是可以有大量业界先进工具可用：SVN,Git,Jira,Project,IDE,Chef,Docker……

　　软件到底是“服务”还是“产品”，这个话题一直都非常具有争议。作为程序开发者，实际上是非常希望软件能够是一个产品，因为软件的后续维护和修改，往往是“导致”项目失败的最常见原因。然而事与愿违的是，在互联网企业中，打多数的软件项目，表现出来的是典型的“服务”特征：

　　没有明确的需求合同。这导致了没有办法为软件设计固定的开发方案，也难以确定长期目标。

　　不管是敏捷开发的快速迭代，还是重构系统，我们都将频繁的编译代码、部署、测试，也就是所谓的集成。如果我们的系统集成效率太低，那么快速的迭代可能变成慢速的迭代，重构系统的频率也会大大降低。有一些项目，每一次集成，都要最少经历两三个小时，如果不顺利的话，搞一个通宵都未必能完成。“发版本”是很多程序员和运维管理人员的常见加班原因。对于这个问题，很多小型公司开始的时候，并没有给与足够的重视，认为这些事情不过是程序员或者运维的本分工作之一，也是最日常的工作。真正得到出问题了，才发现重要性。

　　是否CMM这种软件开发模式，就根本不适合互联网行业呢？这是一直以来我都在思考的问题。反而是跟随着互联网企业的一步步长大，我无意识的体验了很多现在流行概念的早期实践：敏捷、重构、持续集成、DevOps，这些实践一开始都非常的幼稚粗糙，但是却真正的伴随着互联网业务的逐步成长。所以，在讨论互联网服务的开发模式时，我认为必须要先搞清楚互联网服务开发的核心问题是什么。

　　确实现在还存在大量的讨论，说“面向对象不是万能的”。说得对，但是，世界上有什么东西是万能的呢？我只能说，在需求变更非常快的情况下，面向对象思想，是现在我们能选择的最好工具了。在“数据结构算法=程序”的时代，软件主要是以计算任务为主，电脑是为了代替人脑进行超乎想像的运算任务而存在。而在互联网时代，软件主要的任务已经变成了处理这个真实世界的信息了。信息的存储、交换的任务，已经远远超过了“计算”的任务数量。虽然我们知道，所谓的信息处理，最底层还是依赖大量的“计算”，然而，我们的程序员们，早已不再需要编写大量“计算”的代码，我们面临的挑战，是如何用代码准确而快速的表达这个世界。

　　一家互联网公司，我们在评估其开发资产的时候，并不应看他“拥有”多少行代码，因为这些代码是无法直接卖钱的。而互联网公司的开发速度，以及这个速度背后的能力才是最重要的。

　　敏捷开发是我们现在最常见的一个“开发模式”，然而很多时候，我们看到“敏捷”两个字，似乎就是让程序员多加点班，或者忽略一些过程加快把代码弄出来，而真正理解“敏捷”含义的并不多。实际上，敏捷并不会加快单位代码的开发速度！敏捷最主要的目标，是应对需求不明确和需求变更，而这两者正式互联网服务中最常见的情况。

　　没有预付款和客户验收。互联网服务用户来了就用，爽了就给钱，不爽了就走，连沟通的机会都不会有。

　　甚至连明显的销售环节都没有。很多互联网公司只有市场推广部门，而没有所谓“销售”部门，因为推广就几乎等于销售，在推广的同事，就必须把销售的事情一起做了。

　　因此，在互联网行业中，软件开发更多的是以一种服务的形式存在。这种特征，在对需求的分析管理；开发技术的选择；集成与测试；运营和客服四个方面，都导致了不同于“产品”型软件的巨大差异:

　　程序员的能力水平。有一些项目其中的技术，是程序员完全没接触过的类型，这里包含了学习、调试的时间。

　　开发过程中的各种修改变更。由于对可行性、需求确认等方面的因数，开发往往会走“回头路”。有些项目做到一般会发现技术上不可行，需要修改需求；而另外一些项目是在项目做到一半甚至快完成的时候，需求方发现需要修改产品设计，因为在产品可体验之前，完全无法想象到最后会是现在的样子。

　　各种和开发无关的过程中的事务。这里包括开会东赢体育、写报告、沟通、等待开发电脑编译、处理开发服务器故障、各种开发环境和测试环境的问题处理等等……这些事情往往都看起来不是非常“有技术含量”，但是实际上会严重影响开发进度。因为开发工作需要一个稳定、专心的工作环境，频频的被各种事务打断，会让程序员反复的花费时间去“进入”工作状态——面对成千上万行程序代码，要找到之前写到哪个部分，其实不是那么简单。

　　所以我们应该高度重视“代码架构”，也就是描述代码之间的关系的架构，而不是进程之间的关系的架构。在关注代码互相调用、耦合的关系上，我们能把混乱复杂的代码关系理清，整理出一个便于理解，便于修改的代码外观。这些工作看起来完全是针对开发人员的，但是实际上，这些工作是能提高整个开发效率的。它能让代码从难以修改，变得容易修改，从而得以支持快速的业务需求变化，这是对业务、对产品最重要的支持能力。

　　在互联网开发领域，由于网络无处不在，涉及到的领域异常广泛，如果我们没有一个能把代码世界和现实世界联系的纽带，我们的项目将非常难以理解。——难以理解的项目，就难以变化，从而就失去了互联网最显著的特征。所以我认为，面向对象的思想，是每一个互联网开发人员都应该理解的，并且应该是面对大部分业务时，首先考虑选择的。

　　假如一个项目的代码丢失了，但全面的单元测试都还在，那么要重建这个项目并不困难，因为所有的需求，都被蕴含在这些测试代码中，程序员们几乎不需要去重新啃文档，谈需求，他们只要把代码弄成能通过单元测试就好了。这种需求的“代表物”不但是程序员开发的概念和目标，而且还可以自动的帮程序员去验证他们的实现。所以，如果你要使用敏捷开发，要尝试频繁修改原型，就一定要使用TDD(测试驱动开发)，特别是高度重视单元测试的作用。

　　当我1999年进入互联网行业工作的时候，华为刚刚通过了著名的CMM认证。当时作为一个小程序员，非常向往业界经典的软件开发模式。因为看上去，如果企业实行了CMM，我们程序员就不用再天天为了老板一个拍脑袋的主意而加班开发了，各种各样的奇葩需求和无理变更，也会烟消云散。但是，在接下来的十几年，几乎没有那个互联网公司再去通过CMM认证。

　　服务是公司和客户的一种持续沟通和交互的过程，并非一个单向的发售行为，所以互联网服务需要更多细致的运营和维护的工具，否则难以做到迅速而细致的满足海量的互联网用户的需求。

　　在各种项目管理的课程里面，陈述了大量针对人去工作的方法。各种会议、报告、表格、评估、测量多不胜数，然而软件项目进度的控制，依然是一个难度堪比登月的事情。——对于很多项目经理来说，程序员们基本是一个黑盒子，他们自己都不知道一个事情需要多长时间干完，就更别提别人怎么去预估和控制。这里最大的问题，我觉得是：我们往往总是想着怎样“控制”住软件项目的进度，而忽视了如何减少不利于项目进度的因数。实际上影响软件开发进度的主要因数，一般有一下几个：

　　在互联网服务中，由于没有直接的“客户”下单要求，所以很多需求，都是由公司内部的人“代表”的，最典型的就是我们的“老板”们了。正式因为没有明确的“下订单”的过程，所以很多传统的需求分析变得没法做了，因为不管是老板还是产品经理，都是面对着成千上万的客户去猜测他们的需求，如果他们自己能代表客户还好，如果猜错了，项目的代码肯定要修改。很多互联网公司都非常重视“数据”，原因就是这些“数据”往往代表了用户对产品的看法，而这些看法成了互联网产品设计的唯一客观标准。然而这些数据本身，会包含了大量复杂性，由于统计方式、产品形态、季节时间等等，都会产生偏差。我们的项目需求，往往就是在这些偏差中确定。这就难免产生需求的变更了。