系统设计、架构之类的随记

相较于土木工程、机械工程或制造工程等，计算机工程是一棵非常年轻的树。很多工程方面的理念会自然而然地移植到计算机工程上来。我们也很容易发现这些相似之处，比如：系统架构之于建筑架构，系统风格之于建筑风格，建筑设计图之于系统设计图，管程流水线之于生产流水线等等。

不可否认，在借鉴其他工程方面，计算机工程在短短几十年内作出了很大的努力，无奈于鱼龙混杂（学院派、实践派、商业派啥的），常常有种东施效颦、画虎不成反似犬之感。特别是当一个产品刚刚出现的时候，那股浓浓的商业气息，总让人不免嘘唏，比如：云计算、区块链、元宇宙等。好像他们的产品能够做一切的事情，好像他们的产品就代表了一切，没有这个东西，全世界都要完蛋一样，极尽夸张，那种神秘主义的玄学氛围，却也是很多人竞相追逐，一时间你的手机、电脑里到处充斥着这样的一些东西，简直无孔不入，可恶的推荐系统。

从某个时候起，系统设计或者架构开始高来高去的，一时间尽是不知所云的隐语。当我们去翻看那个统一建模语言图时，却有一种曾经熟悉的感觉。其实系统设计也像建筑设计一样，需要画设计图，施工图的，令人头疼的是围墙里很少有人去点破。因为它叫统一建模语言，不叫施工图，如果叫施工图的话，很多东西吹起来的泡沫就得破灭，程序设计不再叫设计，那叫码字，程序员不再叫程序员，那叫码农，但是吧，初学一门语言的时候，它却叫《****程序设计》，狠狠的割裂感。

集成电路图：                            用例图：                      协作图：                   部署图：

多年来，计算机披着一层商业科技的外衣，公众在日常生活中不断被灌输：系统不存在问题。其实我们又搞了些什么东西呢，借用某段子手老师的PPT:

 在饱受诟病的同时，这钱赚得也是小心翼翼、诚惶诚恐。

建一个茅草屋与建一个摩天大楼能一样吗？浏览网页与玩3A大作要求的电脑也不一样啊。。。。

很多时候，从面向业务的需求到面向技术的软件系统实现，特别是复杂系统的设计，需要跨越很大的鸿沟。需求分析即便已经很明确了，要把系统落到实处没有好一番折腾像话吗？怎么选设计方法，怎么选设计模式，怎么选架构，怎么选服务器，怎么选存储，怎么布设网络，还有怎么利用这些原材料把一个信息系统像模像样地给生产出来，可是一份劳心劳力的活。

一方面，我们在进行系统设计的时候，很多时候都会面临两难的境地：到底是将业务逻辑设计得更好（垂直方向），还是应该j将技术逻辑设计得更好（水平方向）；到底是应该将通用性功能设计得更好（框架），在未来个性设计中逐步拓展特性，还是应该从整体角度将系统和子系统之间的关系梳理明白（架构），在后续的开发中逐步拓展新加的系统或组件。其实，面对复杂系统时，还需要面对人员、资金、技术以及管理、销售各种问题。一个软件产品从设计、开发、应用到推广有着太多不确定性的因素困扰，你很难面面俱到。

另一方面，系统架构毕竟也是系统设计初期的产物，设计好了系统，还得编码、测试与交付，如果不能控制系统开发的复杂性、组织开发的技术成本、交付用户的产品质量和软件升级或再生的可能性，产品线过于宏伟或者复杂，与实际不相符合，也一定是失败的。某书说：

很普遍的一个做法，软件架构师在垂直线上花了太多精力（客户需要啥功能），却把大部分水平技术丢给了编码人员。正是这个普遍做法，在近几年的信息系统上出现了太多失败的系统（每隔一段时间就会听到某地信息系统崩了），架构师在注重功能的同时，也应该将性能（系统可靠性、服务稳定性，功能可扩展性等等）提上日程，需求之类的事情给项目经理或者系统分析员去做吧，好吧，你的项目经理正在喝酒（要拉项目），你的项目组没有系统分析员，当我没说。

一个信息系统从开发到交付，是一定会有时间限制的，不会也不可能让你一直拖延下去，当项目工期逐渐靠近临界点时，那种鸡飞狗跳的场面或许很多人都经历过。到底这个项目是否赚钱、项目工期要多长、技术上能不能实现、技术实现上复杂程度有多大、手上的开发人员能力档次是否达到等等，这些因素是需要认真考虑的，否则对大家都不好。

系统的功能（业务）、工期、质量和效益是需要同时需要考虑的，对于一些新入某个行业的信息开发企业而言，他们更加注重业务（这个行业有哪些数据，哪些功能可以表现业务，哪些技术可以实现该项功能）。很多时候由于过分的看重功能、工期和效益，却往往忽视了对于质量的考虑。也正是如此，对于一些已经深入某个行业的信息开发企业来说，系统的产品质量就显得尤为看重（性能，安全性、易用性、服务持续可用性、伸缩性、互操作性、可靠性、鲁棒性、可重用性、可移植性）。后者明显比前者更加成熟，但这种成熟是在多年深耕某个行业养成的习惯使然，也是甲方爸爸无数次的训斥和抱怨才得以不断改进。

系统开发技术权衡、产品成本效益分析是值得深入探讨的问题。项目并不存在于真空中，孤立地讨论系统设计或者架构是不是更经济、是不是更先进、是不是越简单、是不是越成熟、是不是越简单没有什么意义，在一定的场景或背景下，合适的才是最好的，这或许就是工程与研究的区别所在，高质量的系统如果在成本上产生了过多的开销，那还是先缓一缓吧，工程师与原材料、工具、技术、产品、成本的局部或全局最优解才是契合的。

合适与契合也难免陷入玄学的陷阱，其实对于一个多目标的问题求解而言，将目标逐个挑选出来进行规划或预测，无论你使用线性或非线性的函数，评估值相对还是可靠的。