软件开发，标准化流水线式开发的实施构想

这篇文章是我最近偶然看到的，我觉得写的很好，作者讲的问题很实际，也是我一直想要去做的，这么好的文章从11年到现在只有400+阅读，太浪费了，简单说下我的理解：

1、重视流程和规范
我比较认同的是IPD流程和PDCA戴明循环，一个华为用，一个丰田用
2、模块化设计
并非只有IC才有IP Core的概念，软件同样有，它的意义说出来都很熟悉，增加代码的重用性，避免造轮子，但是实际去做的时候发现却非易事，我很早就开始做自己的代码库，可是差强人意，总觉得还差一点，文中作者有很好的分析
3、重视架构设计
我自己很深的体会：架构没思路，一定是需求没弄清楚；模块没思路，一定是算法没弄明白；
4、重视文档
不仅仅是重视文档的阅读，更要重视文档的积累，开发人员与别人交流最好的方式就是文档，开发人员跟自己交流的最好方式也是文档，再次吹一波Xilinx
5、复盘
review很有用
6、以下为原文

///

软件开发，标准化流水线式开发的实施构想

近日看到一篇博文，讨论标准化流水线开发模式的话题，但是这篇博文仅仅提出这个问题，未见回应。

这其实是一个很大的问题，我从事软件开发这么多年，仍然未见到国内有任何一家公司真正做到，这个问题也是我一直到思考的。一直以来我也尝试推行这种模式，但是仍然未见起色，从中我不仅学习到一些经验，但是也深知其困难。通过这篇博文来跟到家分享下我的经验。

Ø 一个问题、什么是标准化和流水线开发模式，为什么要实施？

可能大家对标准化和流水线开发模式还不大清楚，我们先来细细阐述一下。标准化和流水线开发模式就是使得软件模块标准化，软件开发流程像生产车间流水线作业一样，所有的软件工程师只需要根据软件设计规格书去模块库选择适当的模块（即原材料），然后编写程序进行拼装、测试、发布即可。

无可厚非，这种开发模式，效率是极高的，而且对程序员水平要求也是极低，这样不仅仅可以提高软件系统的效率，而且也可以大大的降低人力成本，完全实现软件大批量式生产和开发，因此实施这种模式对一个公司来说确实很迫切。

Ø 又一个问题、国内软件公司为什么迟迟未能成功实施这种开发模式呢？

首先需要说明的一点，大家切不要以为国内的公司不想实施，其实做梦都在想，但是为什么没能成功实施呢？我认为有以下几点；

国内大部分公司的目标和需求都不明确。大家可以发现国内的公司有一个最大的特点就是产品种类多，其实这个也不算什么，最要命的就是，种类多还行业多。比如说有些公司既有煤矿安全监控的产品，又有电子消费方面的产品，甚至还有ERP方面的产品。其实细细观察，这些公司的产品却没有一个是已经具备一定规模的，可以想象，这些公司在这些相应的行业中的积累似乎足够浅，提炼这个行业的软件模块基本不可能，或者就是模块根本达不到通用的标准。因此大家常常会发现，公司的大部分工程师是在修改原由的模块来满足各类客户的需求，这样久而久之使得软件模块已经很难统一，维护异常困难，人疲马乏，还怎么实现标准化和流水化呢！其实总结一句就是，定制产品就是使得公司无法成功实施标准化和流水化开发模式的原因，可能这样说来说去又回到“鸡”和“蛋”的问题，大家细细琢磨吧！

国内公司的管理层和程序员还太年轻。在这么多的公司当中，大家其实可能发现，国内的公司都是青春期的公司，一些工作一两年的就是什么系统工程师，工作两三年的就当个项目经理甚至部门经理，可以想象，在中国这种环境下，这样的职位晋升从此断送这些人的技术前景和积累。从此这些人就开始不断的根市场打交道，学会市场却忽略了技术的学习和积累，如此长久下去，最终、公司的高层虽都具备市场的眼光，但却断送了工程技术的创造力，其慢慢就无法把握工程的基层开发流程，更不用去谈什么标准化和流水线作业了。这就是为什么有些公司发展数十载，再也发展和壮大不下去的原因——因为他们已经陷入了人才怪圈的循环，此后就会发现人才流动频繁，人才周期缩短等现象。

国内公司缺乏项目总结和软件重构的意识和投入。国内很多公司都是靠定制项目生存的，有些项目来的很紧急，需要迅速开发出来。大家都知道，这种快速的开发完全时间建立在成熟的技术至上，由于时间紧急，发布可运行的软件是最为紧迫的，大家工作的目的就是赶时间、赶工程、赶“发布”，然而如此往复，不仅人困马乏，而且我们时常发现，软件发布后，一旦获得用户认可，那么这个项目就算是完成了，然后项目组进行简单的项目总结之后就将项目组成员遣散到其他项目中去，也不对系统进行重新分析和模块进行重够构、甚至不做任何归档。这样、在这个项目的中获取的经验就完全属于项目组成员的个人经验，而非公司技术积累，一旦某个程序员离职，那么在项目中积累的一些经验（软件模块）就随之不复。IT行业，在国内来说，至少是一个高流动性的行业，因此对于国内IT企业来说，技术积累也是异常的困难。其实就我看来，一家人才流动性比较高的企业，其10年的行业技术积累还不如一些稍微稳定的公司6年的积累。

Ø 那么我们应该如何实施软件标准化和流水线开发模式？

在我的软件开发生涯当中，我时时刻刻在思考如何将实施软件标准化和流水线开发模式。我先后从事过应用开发、基础设备驱动开发、内核开发，每个开发过程我都试图寻找其中的开发模式，尽量作到标准化和流水线作业，以提高开发效率。这些年虽然未的到一个成熟的方案，但也获得一些经验，那我们来分享下吧；

第一、 开发过程尽量做到标准化，将文档作为开发过程的里程碑。

在一些急行军式的项目开发过程中，很多时候都会将文档忽略，或则就是只有少量的文档。软件开发过程也没有，需求分析、架构设计、详细设计等过程，只是项目一上来就开发编写代码。这样项目小还好说，如果项目比较大的话，那么到开发的后期就将无法控制了。记得前些年，我开发一套财务系统，当时是第一次作为项目负责人，时间比较紧，因此拿到项目需求之后，就立马组织人员进行简单分析、模块划分之后就开发编写代码，1.5月之后，我们顺利地将软件开发出来了，测试之后就部署到服务器上，之后我们就没有再过问这个系统。一天我的BOSS，突然给我电话，说财务系统导致亏损18万，当时我就惊呆（并不是因为金额，而是头脑中无一点头绪），之后就立刻组织人员对代码进行复查，当我再次那到这些代码的时候，似乎这些代码已经很陌生了，因为没有文档，程序里一些复杂的算法已经忘光了，无根无据，只能从头到未反复演算算法过程，那段痛苦的时间，每每提起都让人毛骨悚然。之后，在任何项目中开发中，我都尽量将开发过程标准化，以此避免这种类似的事情发生。

软件标准化和流水线开发模式的目的是要进行大规模大批量软件产品开发，在这种前提下，如果软件开发过程不够标准、文档不够齐备，那么公司就需要投入多倍的技术支持来弥补这些缺损、解决这种“无根无据”的问题。因此软件标准化和流水线开发模式先要将软件开发过程标准化、将（重要）文档作为开发的里程碑。

第二、 将软件模块更抽象、更细化，层次划分更合理。

在软件构架的时候，将软件进行层次划分，模块细化十分重要。以前看过一本书《设计模式》，一句话总结这本书的内容就是“层次划分、模块抽象和细化、高内聚低偶合”。就标准化和流水线开发模式而言，这更是重要的，也是实施的前提。

前些年在开发一些管理系统的时候，每次看到我的一位老师（重庆市著名的数据设计专家——王家伟）发给我数据逻辑模型的时候，总是会发现这个模型有些地方总会和上一次的模型的某些地方相同的，比方说用户管理模块。这样、我以前编写的模块代码就能完全复用，节省了这部分的开发时间。当时我就在想，如果每个模块都能抽象、细化成经典的模块，那么在下次开发的过程中我们就能直接引用，那该多节省时间啊，新的项目真正需要开发也就是业务层了。

第一次开发管理系统的时候，我一直对MVC模式无法驾驭，虽然口谈论足，但是未得其然。第一个项目之后，我又参加了另外一个稍微大一点的项目，跟着一个资深的工程师开发，当他给我项目设计书的时候，提出了四层级别的MVC模式，Model、DAL、BLL、Web四层开发模式。这引起我对ＭＶＣ模式的深思，随着项目经验增多，我慢慢才体会到，MVC模式是一个经典的模式，本身并没有什么，它的目的就是告诉你，在软件设计的时候要对软件进行分层，降低系统的模块和层次之间的偶合度，在后期面的开发过程中，最多时候我还设计了８层ＭＶＣ开发模式。

后来我慢慢发现，一个好的经典的模块应用，一个恰当的系统层次模型往往会使得的整个项目开发周期大大缩短、稳定性大大增高。因此、我认为、标准化和流水线开发模式，如果离开了标准（经典）的模块和合理的层次结构，那么也就是“口谈论足，未得其然”罢了！

第三、 将项目总结和模块标准化、软件重构、模块抽取纳入到开发周期中。

就像上面的叙述一样，很多公司为了赶项目，往往忽略了后期的项目总结、软件（模块）重构等方面的工作。

有些项目开发经验的程序员就会发现，客户的需求总是变化的，以前项目中的一些相似模块总是需要有些改动才能适用新项目的需求。

确实如此，我也总是遇到，但是后面我改变方法了，每次项目结束之后，我都会对项目总的一些经典的模块进行分析、重构、最终抽取出来建立自己的模块库，下次用的时候，就可以直接采用，或则稍做少量的修改就能符合新的需求。这种方法我已经获得一定的见效，并且屡试不爽！

前不久，我经历过一个项目，需要开发一个波形图绘制的模块，大家都知道这个模块并不复杂，很多人只需花费一个上午就可以完成。也不差、很快我就开发完成了，并成功应用到系统当中去了。但是，着并不算什么，为了让这个模块更加健壮和适应后期的需求，我仔细分析了，后面我发现，这种波形图模块，少不了坐标选项、少不了波形回查（重现）、少不了波形图走势记录等功能，因此我以经典的模型图类派生了三个子类，形成波形图较为经典的模块。这个模块在后期也得到了很好的应用和验证，节省了很多不必要的时间。

标准化和流水线开发模式总是要将软件需求预先预料，以适应更加广阔的需求，那么项目总结和模块标准化、软件重构、模块抽取就是软件开发中的“未雨绸缪”，因此建议将其纳入到开发周期。

第四、 建立公司的模块库，制定软件开发流水作业模型，并建立培训单位。

最后一个话题，有了上面的开发过程标准化、模块抽象、模块重构和抽取，如果我们都这样做到了。那么就公司而言，就必须做好技术积累的相应措施了！

有了模块，公司就必须建立模块库，并进行分类管理，如GUI库、控制协议库、业务逻辑库等。如果公司10年如一日的坚持模块库的建立，如果以平均1000个程序员的规模计算，那么整个库将涵括1万个经典子模块库，这些模块就是软件的构件，也是软件标准化和流水线作业的原才料和基础，就相当制造业工厂生产线的螺丝。

模块库一旦形成，就必须建立软件开发流水线作业模型，其实也就是新的适合公司的软件开发流程。如下过程如何；

{《需求分析》—《模型设计》—《架构设计》—《模块复用设计》—《详细设计》—《编码》—《测试》—《发布》—《项目总结、新模块重构和抽取》—《模块库归档》}

如果模块库和流水线模型建成，那么建立培训机制就更显重要，对于新员工来说，让他们了解项目开发过程当中能够使用的资源比什么都重要，这样可以避免做无用功。

至此一个简单的标准化和流水作业实施方案已经趋于完成，最后介绍一下测试。

Ø 测试也需要标准化，建立标准化、自动化、压力测试部门。

很多公司都不太注重测试，很多公司即使有了测试，也有些行同虚设，不得其要点。在标准化和流水线开发模型当中，测试显得更加重要，其实大家都可以发现，在真个项目周期中测试所占用的时间都是真个周期的40%，无可厚非，如果不能精简这部分的时间消耗，那么标准化和流水线实施的意义也就大大折扣。

就想我以前的一篇文章中介绍的一样，其实试分析一下，现在公司的大多数项目都是基于行业应用的，行业应用的产品通常都有自己的参数指标，例如工控产品需要过竟EMC检测等。

另外公司也可以形成自己的普通软件的测试标准，比如说，接口测试必须自动化测试1000次以上不失败等。对于很多软件而言，通过压力测试也是必须的，例如高性能服务器必须通过5000连接同时传输7天的压力测试等。

就此种种、建议大部分有势力的公司在实施标准化和流水线作业模型的过程中，建立标准化、自动化、压力测试部门，这些部门主要用于制定标准测试方案、流程和编写自动化测试软件。

以上就是我的一些想法，似有不足，请大家评论。最后要说一句，印度的大部分外包软件公司都成功实施了这种标准化和流水化的开发模式，其开发规模和效率确实远高于我国。

///