对软件开发核心目的的思考

今天读了一篇博文是关于谈论“软件开发的核心”，博客原文地址为：
http://kb.cnblogs.com/page/535278/

作者首先提出了一个问题：「我们一直这样做开发，时间做久了，便忘了当初的本意。」有关软件系统开发，我们谈些什么？

• 我们谈过程，编码规范、开发流程、同行评审、结对编程、持续集成，从瀑布到敏捷再到极限编程。
• 我们谈架构，企业级、J2EE、容器化、SOA（面向服务架构）、Microservices（微服务化）。
• 我们谈规模，大容量、高并发、大数据。
• 我们还谈可靠性、可用率、n个9、响应时间等等。。。

这一切的核心是什么？
然后作者通过一个简单的故事，来揭示这个问题的答案：

先讲个电力行业的一个故事，电力的项目我没做过，对电厂的原理虽有所了解，但看见那些大规模的电站还是感觉挺复杂的。 故事是这样开始的：

记得有个给我们上培训课的主讲老师是个须发皆白的老先生，进门后掏出一堆零件放在讲台上， 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水，点燃酒精灯，不一会儿水开了，从壶嘴里喷出了蒸汽，带动叶片旋转，然后小灯泡就亮了。

他说：这就是电厂。

他还说：如果烧的是煤炭，这就是燃煤电厂；如果烧的天然气，这就是燃气电厂；

如果获得热能的方式是核裂变，这就是核电厂；如果带动叶片的能量来自水从高处流向低处，这就是水电厂。

老先生说：你们或许会问 “那我们看到的电厂怎么这么复杂”，答案其实很简单， 电力项目需要复杂系统的目的，一是为了确保安全（Safety），二是为了提高效率（Efficiency）。

安全和效率的平衡，是所有工程技术的核心。

看完这个故事，我就感觉到所谓 “大道至简” 大概就是这样的。

开发软件系统的根本在于满足需求，不能满足需求的系统本身是没有意义的。 就像一个再安全、有效率的电厂不能发电又有什么意义呢。 所以软件系统开发也就是围绕根本的基础上确保安全与提高效率。

需求作为软件的根本差异很大，需求是多样，需求也是复杂的。 一个大型 ERP 系统，一个大型仓储系统，一个大型网站系统，到底谁更复杂，没有一个定量标准，甚至都不好定性分析。 所以前面我们谈软件系统开发那么多内容都是关于 “安全” 和 “效率” 这两个围绕根本的核心。

所有软件开发的方法论，像瀑布、敏捷到极限编程围绕的是开发活动的效率问题，而编码规范、流程制定、同行评审等等则是有关开发的安全问题。 那么 SOA 化或进一步微服务化其实同时考虑到了安全与效率，服务化拆分有利于大规模开发团队的并行开发，提升了开发效率， 但上线部署复杂了降低了运维效率，但运维效率可以通过自动化来得到弥补，而开发则不可能自动化。

同理，可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心，而性能优化，提升响应性则是围绕 “效率”。 有些关键的软件系统必须同时兼顾 “安全” 和 “效率”，例如用在飞机、汽车内用于控制起落、刹车、油门的软件系统， 不安全或无效率造成事故是会死人的，而另外一大部分软件系统因为不安全或无效率造成的事故则死的是钱。

没有人去争论建设电厂到底是不是一门艺术，但肯定有人在争论软件开发（程序设计）到底是不是一门艺术， 但终究大部分的软件系统开发还是更偏向于工程技术。

读完这篇博文，我也想说几句：

是呀，软件系统大致可以分为两类：一类是偏向研发性质的工作；一类是偏向软件工程，应用性质的工作。但无论是研发，还是工程技术应用，其实本质目的都是为了解决现实领域中的问题。即将现实世界中的问题域通过软件技术来进行求解。那么自然而然，我们在求解这些问题时，就需要注意两点：一是效率；而是安全。

所以大到一个软件组织，小到一个程序员，在使用软件思维去解决问题时，无论你是在做产品，还是在完成一个简单的软件程序，时刻都需要铭记我要解决什么问题？效率和安全如何？在接受或者可控的成本范围内吗？稳定吗？可靠吗？

一切的技术选型，架构设计，用户体验，数据处理都是围绕着上述问题展开的。

所以，作为一名软件工程师，我们不能陷入“技术误区”，无论做什么系统，无论设计什么样的软件应用都最求最新的技术、最时髦的框架、最流行的软件开发方法论，99.99999%的高可用性，……。我们不能被技术所绑架。应该是不是回过头来看看，系统在最初的现实域中要解决什么样的问题，随着现实中业务的不断发展或者变化，我们的系统是否能够满足这一变化？我们的系统效率和安全是否能够满足基本的需要？这一代/版本的软件系统生命周期会有多久？

如何不能达到这些，技术架构设计的再好，使用的技术再新，系统做的在华丽，也是不会被用户所接受的。甚至系统刚一上线就会产生一系列的问题。我们不应该牺牲效率（也可以理解为性能），牺牲安全而换取系统早日上线。没有用户愿意去使用一个效率低、安全性没有保障、操作极为不方便的软件系统。

我讲一个案例，某公司设计开发的一套ALM (Application Lifecycle Management) 系统，其目的是希望能够对应用软件的开发过程能够能够进行有效的管理与控制，属于一个软件项目过程管理工具。面向的用户群是软件企业的工程技术人员。但是这个系统最大的问题在于，在系统中初始化一个项目的信息，需要输入大概40多项内容，用户界面极其复杂。而这些初始化信息中，有至少一半以上缺少统一的标准（缺少统一的信息编码格式，至少可以做成选项让用户进行选择，而不是输入。）这样用户经常输错信息，而且后期导致数据不一致。而且系统在进行项目资源统计计算时，一个页面上，需要用户点击超过20次鼠标，才能够提交数据表单，进行后续的业务处理。

想想都可怕呀，多么复杂的业务和多么复杂的操作呀！（真的有那么复杂吗？）这需要用户处理多大的信息量呀！

这样的系统一上线，所有的用户都在抱怨，这个系统好是好，但是设计的太复杂了，操作上不但没有提高原来的效率，而且还更加耗费时间了。而且统计的信息不够准确。所以，历时一年多开发系统，最后几乎成了摆设。维护成本极其昂贵。

我们回过头来想想，问题出现在哪里？至少有一点就是软件的设计者，没有从用户的角度其思考，未来用户使用上的要求。

所以那些产品经理，软件架构师们，应该“大道至简”，想想软件产品的核心是什么？