硬核

软件工程爬坑之路(一)——软件的诅咒

. 6 min read . Written by seki
软件工程爬坑之路(一)——软件的诅咒

前段时间作为设计师参与了一些面向后台的项目。为了理解用户——也就是开发者们的工作,我开始了解软件工程的相关概念,学习过程中有了一些零散的笔记和想法,记录而成为这篇文章。文章重点在于理解(爬坑)的过程,使用了一些设计师的思维去解释概念,不保证严谨性。

首先,什么是软件工程?

一言以蔽之,软件工程的本质是控制复杂度。将一个庞大的程序切分成一个个小块,保证每个小块可以由一名开发者开发和维护。

作为设计师,不难想象,这正如我们在工作流程中会产生PRD、线框图、icon和.rp等各类产物。只是对于开发者而言,他们的工作更要比这庞大而复杂数倍,在保证基本开发效率、运行稳定性的同时,程序员们产生了新的诉求——如何让维护效率上升?

事实上,解决问题的方向简单而明确——古人动用数年时间才能建好一间木屋,而现代人可在几小时内搭好数个临时篷房,这并不仅仅是因为建筑学和材料学的发展,更重要的是,现代社会有工业流水线来生产钢筋和帆布,就算某一天,我们需要去翻修一座摩天大楼,也可以使用现成的建筑材料,而不必就地挖土制作砖头。

如果你对前端有一定了解,会发现上文的内容也是“前端工程化”的思路,前端工程化也正是软件工程的实践之一,这种思想围绕着模块化、组件化、规范化和自动化进行讨论。

那么,是什么原因让我们重新研究起这门诞生于上世纪七、八十年代的学科?

来自软件的诅咒

实际上,并非软件工程“过时”,而是互联网时代的开发过于“简单”,当项目变得庞大且臃肿时,过去小步快跑的方式就行不通了。

脱胎于软件工程的互联网行业,曾用着“快速迭代”的方法论披荆斩棘、开拓疆土,却又理所当然的受制于“稳健性”这一软件工程中的刚性要求,两个相互矛盾的诉求犹如孪生恶魔,从互联网诞生之初便成为整个行业的泥沼,它们带来的是无穷无尽的BUG、抱怨声与加班。

一个爆款产品的1.0版本背后或许只有是寥寥数名开发者参与,获客和运营从一开始就是互联网的黄金法则,而开发的工作却无法受到重视。当产品突破成长期,用户数量指数级增长之后,我们需要一名架构师使用软件工程的知识去解决庞大代码中的上述问题。

那么,想必有一个黄金准则,只要我们慢工出细活按部就班做下去,就能像现代摩天大楼一样打造出稳固的软件了吧?

可惜的是,这一黄金准则在软件领域中并不存在。“没有银弹”——这一概念来源于软件工程管理领域著作《人月神话》,它将项目中的不稳健性和缺陷比作月圆之夜的怪物。神话故事中,往往有一件圣物可以降伏这些鬼怪,譬如大蒜、十字架或是银制的子弹,而对于软件中的怪物,我们至今没有将其一击必杀的方法。作者在书中写道:“未来十年内,无论是在技术还是管理上,都没有任何突破性的进步的可能,可以保证软件的生产率、可靠性和简洁性大幅度地提高。”

在成书四十多年后的现在,我们依然在吸取同样的教训。

http://www.blackzs.com/wp-content/uploads/2018/11/778h945utom6s.jpg
焦油坑

不仅如此,当人们在协作一个大型的软件时,这些问题会变得更容易出现,并影响整个项目的进度。《人月神话》中将这种情景比作焦油坑——不论是多么庞大的动物,都会淹没其中,而其中的任何一员则难以看清问题的本质,人们无法互相救助,就像庞大项目中,人手越多,沟通成本反而越大。

简单来说,软件开发中有四大根本问题——复杂度、一致性、可变性和不可见,这四大困难是没有银弹的,而架构师则是通过瀑布模型、面向对象、敏捷开发、微服务等理论和方法去减轻这些困难的程度。

设计师思维与工程师思维

同一产品中,设计师之间同样存在协作关系,比如设计资产的管理、风格统一、设计文档,那么这种协作与软件工程有什么区别呢?

实际上,这是一个量变引起质变的过程。

在创业故事里,似乎一到两名产品+设计+前端开发就可以完成产品0到1阶段的工作,但这些只是作为冰山一角的前端业务。无论是工具类产品还是金融产品,对于其使用者而言,与之连接的始终只是一块小小的用户界面,但在金融产品的冰山之下,成百上千名后台开发者正在努力处理海量数据,这样庞大的协作关系显然不是几个文档可以解决的。

此外,用户对页面的感受是模糊而主观的,设计师之间不需要太精确的约束也能够保证产品的一致性。但对于“工程”而言,一个数据类型、标点间的错误,将会导致结果失之千里,因此工程师之间的协作更为严谨。