软件&工程

和很多行业一样,软件行业(不完全包括互联网行业)也经历了从混乱到规范再到突破的发展历程。对于不了解软件或者没有太关注软件发展历史的朋友来说,寻找一个合适的相似行业进行类比,对于了解软件行业发展会更容易些。

这里我们会用土木工程行业进行类比,而且也强烈推荐它。——因为他们就像异卵双生的亲兄弟,一个在改造实体世界,一个把实体世界抽象为二进制世界。

英雄的时代

刚开始,计算机还是少数社会精英的工具(当然计算机的诞生是为军事服务)。从军事到实验室再到民间,少数先锋搭建了二进制世界的雏形。——有计算机体系结构、有编程语言、有操作系统、有网络等等。

大众参与

后来随着信息化发展,政府部门(government——toG的G)、大型企业(business——toB的B)为了提高管理效率,需要定制大量专用软件。如此大量的需求,催生了软件行业的崛起,软件工程师(有时自嘲为码农)就像当年做土木工程的工程师和建筑工人一样(其实再根据工种细分还有好多称谓)逐渐成为一个庞大的劳动力群体。

随着软件行业的发展,一些集体智慧逐步被积淀下来。——杂乱无章的代码不利于维护和阅读,有的企业规定了一些约束和规范,优秀规范也成为了行业共识。

这些共识(前人的知识结晶)里面,我认为值得一提的是设计模式和UML。

设计模式,一种超越了具体编程语言的针对特定问题的特定解决方案。就像土木工程里的一些通用方法。软件工程的确这么做了,也使用了土木工程里的一些理念和名称。——工厂模式、组合模式、适配器模式、装饰模式等等,“人如其名”,程序就是盖房子一样搭建起来了。

UML使用特定的符号来表述二进制世界里的元素和元素间关系。可以使用UML绘制一组“建筑图纸”,只要懂得这些符号的工人,按照图纸施工,就可以完成庞大的软件工程。当然UML绘制的不是一张图纸,而是一组图纸,有高层次抽象的用例图,也有表示一个过程的流程图或者时序图,还有表现“门窗”细节的类图和对象图。

管理失败

如果软件工程只要管理好代码就能成功,那就太容易了。但往往事与愿违,就像那烂尾楼、豆腐渣工程,以及一拖再拖的交房时间,软件工程也总是面临失败的尴尬境地。——钱不够、死亡行军、拖延症、无休止地增加需求或者激进地引入新技术——总之,人类有的缺点,软件工程里都会出现。毕竟需求是人提的,工程是人实施的。

在工程管理方面,传统行业(特别是建筑行业)已经积淀了不少经验,甚至发展出一门叫做项目管理的学科。这是一门关注约束和过程,力求把独特项目做成功的学问。它甚至定义了什么是项目成功——在特定的成本和时间约束内把约定的需求(不多也不少)转化为软件,成功交付给甲方。

软件行业再次施展“拿来主义”方法论,把项目管理引入本行业。——业内比较认可的PMP,提出了五大过程组和十大知识领域。——从立项到交付,软件就像流水线上的物品,工作人员各司其职,有项目经理(PM)、有架构师、有开发工程师、有测试,还有运维。

项目是独特的、一次性的。但相似企业或者政府部门的需求总是相似的。做大的软件企业便花费一些精力根据已有经验和研究,提出了超越客户需求的行业解决方案。——比如SAP。

引领者

后来,互联网作为软件行业的一次变异,产生了划时代的意义。它是一个庞大的知识和沟通平台,每个用户即是消费者又是生产者。

互联网在终端消费者(customer——toC的C)身上取得突破性成功。但相比与政府部门和企业,消费者的需求更五花八门、更善变,商业竞争越来越大,项目管理也越来越难。

2001年,17位软件行业领军人物共同发表了《敏捷宣言》。他们确定了4个核心价值观和12条原则,开启了敏捷软件开发和敏捷项目管理的新纪元。以下为敏捷宣言的引用,供大家了解。

Agile Manifesto 敏捷宣言

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:
我们正在通过亲自开发和帮助他人开发,发现开发软件的更好方法。通过这项工作,我们开始更重视:
Individuals and interactions over processes and tools
  个体和交互 高于 流程和工具
Working software over comprehensive documentation
  可工作软件 高于 面面俱到的文档
Customer collaboration over contract negotiation
  客户合作 高于 合同谈判
Responding to change over following a plan
  响应变化 高于 遵循计划
That is, while there is value in the items on the right, we value the items on the left more.
也即是说,右栏中的项目固然有价值,但我们更重视左栏中的项目。

© 2020, 李德涛博客. 版权所有.

发表评论

电子邮件地址不会被公开。

11 − 1 =

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据