软件工程迷思

“什么是软件工程？”，这是一家CMM5级，敏捷4年，号称全国最大的软件公司的一位开发人员的问题。而从我接触的众多项目来看，重业务轻工程在这个公司并非个别现象。大公司尚且如此，众多小公司就可想而知。没有软件工程的指导，他们是怎么交付一个又一个的软件版本的呢？

软件工程《维基百科》《百度百科》中是这么定义的：

软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。软件工程的目标是：在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并且满足用户需求的软件产品。

其实光看这个定义也没多大用处，我们对照看一下PMP中定义的铁三角“成本、进度、范围”和“软件过程定义”引申出的质量铁三角“人、过程、工具”。一个是从管理的视角，一个是从过程的视角来看待软件开发，似乎没有对错之分。但在不同的企业文化中，会产生截然不同的措施和活动来，向左走or向右走？

以市场导向的公司更注重进度、成本，通常采取更多的管控措施确保目标达成，较少关注人。而在工程师文化导向的企业中，更关注人的因素，过程和工具都是人的辅助。孰优孰劣其实并没有定论，前者更关注收获利益，后者的员工更容易感觉到成长和幸福。

 

我们打开软件开发过程来看该公司的工程活动，参考【维基百科】，ACM 与 IEEE Computer Society 联合修定的 SWEBOK^[13]（Software Engineering Body of Knowledge）提到，软件工程领域中的核心知识包括：

• 软件需求（Software requirements）：需求分析是一个逐层分析细化的结果。使用需求分解分配表跟踪，大致需要经过三层分解，将原始需求分解到模块级，并分配到对应的模块组开发。在理想化的情况下，模块之间接口都已经明确，大家可以各不干扰埋头苦干，干完集成就完事了。可惜的是，现实往往很骨感。
• 1、每个版本都是这样的增量需求、分解，导致无人对软件整体有把握；
• 2、需求分解包含了设计过程，导致分析师花了很大的精力考虑实现，对需求是否符合客户期望却关注较少；
• 3、分析师长期脱离代码，其设计的接口往往并不符合需要，返工量巨大；
• 4、部分项目没有产品经理或分析师对需求负责，导致自相矛盾的需求层出不穷。
• 近年来已经意识到这个问题，需求开始按特性进行分解，但和现有组织结构的矛盾依然突出。
• 要处理好需求的矛盾，必须关注的是：分析和设计的关系、全量和增量的关系，其中尤为关键的是必须有产品经理掌握产品整体的发展，权衡需求，保证实现的真正是需要的需求。
• 软件设计（Software design）：通常设计要经过HLD/LLD，也就是从概要设计到详细设计的细化过程，看起来很完美。但从上也能看出，SE往往在正确的事和把事情做正确之间犯糊涂，设计结果可想而知。而且需求都是补丁式的分解和开发，并未能审视新需求对架构的影响，采取更好的方案，这样的软件必然走向架构的腐化。其实有时候也不是设计师不知道有更好的方案，但要协调多个组的配合往往超出设计师的精力能及，出现妥协的方案就成为了更好的选择。详细设计就更搞笑，往往写完代码了，在QA的要求下补补文档，就出来了，QA检查后就束之高阁。当然不这么做，开发人员也会被要写到伪码级的word文档逼疯。
• 近年来在敏捷的影响下，文档的工作量已经少了很多。但又走向另一个极端，就是裸奔。软件往往不经设计直接开始编码。
• 要做好设计是很难的，目前看来并没有银弹。着力点还是在人上：1、正确的导向，不能为了满足流程或其他，而是要回归到产品本身生命周期和质量需求上；2、人员能力，设计和开发不能分离，否则设计不能落到代码中，始终是个屁。
• 软件建构（Software construction）：在BT来审计前，大部分人认为构建不就是把软件编出来能发布出去吗。领导不重视，也没有开发人员愿意干这个。但只有项目经理在软件开发完，各模块开始集成时才能感受到这种痛苦。不同的构建工具、构建环境、相同开源软件的不同版本，要把这些组件集成在一起能跑起来，那是个要脱一层皮的事情。知道BT要求源代码交付、一键式构建，这才发现情况已经到了多严重的地步。
• 构建的改进多是管理上的措施，如果能一开始重视，这是个顺理成章的事。感谢BT！
• 软件测试（Software test）：以前有人说，最好的测试改进措施就是裁撤测试部。这话虽然极端，但反映出测试人员是多么重要却无奈。由于测试部的存在，开发人员的测试技能退化为零。经常正常功能都有问题的版本也发给测试人员。而居然有测试部俺提单数考核测试人员的绩效，可以想象这是一出什么样的闹剧。我们不缺测试了流程，UT/IT/ST，不缺测试工具，也不缺方法，我们的测试缺什么呢？
• 软件维护与更新（Software maintenance）：公平来说，维护做得相对还可以。这个“可以”并不是指软件的质量维护得有多高，而是在规范的生命周期管理流程下，改动做到了可追溯。
• 软件构型管理（Software Configuration Management, SCM）：在公司叫配置管理，我们有着专门的配置管理部，但是
• 软件工程管理（Software Engineering Management）
• 软件开发流程（Software Development Process）
• 软件工程工具与方法（Computer-Aided Software Engineering, CASE）
• 软件品质（Software Quality）

 

 

“敏捷开发”（Agile Development）被认为是软件工程的一个重要的发展。它强调软件开发应当是能够对未来可能出现的变化和不确定性作出全面反应的。

敏捷开发被认为是一种“轻量级”的方法。在轻量级方法中最负盛名的应该是“极限编程”（Extreme Programming，简称为XP）。而与轻量级方法相对应的是“重量级方法”的存在。重量级方法强调以开发过程为中心，而不是以人为中心。重量级方法的例子比如CMM/PSP/TSP。

面向方面的程序设计（Aspect Oriented Programming，简称AOP）被认为是近年来软件工程的另外一个重要发展。这里的方面指的是完成一个功能的对象和函数的集合。在这一方面相关的内容有泛型编程（Generic Programming）和模板。