墓碑上的软件工程：概论

本文系用户投稿，不代表机核网观点

⚠️ 未经作者授权禁止转载

 
很久以前，有一位程序员，发现了一颗名为软件工程的宝石。这块宝石闪闪发光，让他视为至宝。之后的很多年，这块宝石的光，照亮了他走过的很多夜路，直到有一天，他在市场上，拿出来想卖掉这块宝石，却发现根本没有人愿意出价，在市场里，这只是一块长得有点特别的石头，没有人觉得它有什么价值。多最后，这位程序员的墓碑上，就镶嵌着这块石头。
 
在谈软件工程之前，首先应该思考一下这一门类的知识，到底是做什么用的。经典的课程，都会用“软件危机”来说明要解决的问题。但是，在真实的世界上，在中国的互联网等 IT 公司里，所谓“软件危机”似乎是不存在的，或者是从来不会被提起的。这里只有被迫 996 的程序员，而不会有人说：我们面临了“软件危机”。——如果代码的生产出现问题，那就加班解决问题。
所以这门知识，对于一个公司来说，几乎是最没用的。甚至在大多数公司的面试中，能真正谈论到这些知识的人，都非常少。但是对于程序员自己来说，却是非常有用的，因为它有可能让你减少加班的时间（只是有可能，更大的可能是让你可以有一些摸鱼的时间），更重要的是，这么知识会让你感觉，自己不是一个无情的代码生成器，而是一个有思想的创造者。今天我之所以愿意谈论它，仅仅是因为喜欢这门知识，所以如果有人说我讨论这些是没用的，我也一定会衷心赞同。下面还是回到正题吧。
我认为，软件生成的主要矛盾，是无限膨胀的需求变更，和相对落后的软件生成率之间的矛盾。软件工程的核心目标，就是提高软件生产率。
软件工程这个门类的知识，都是遵循以下三个步骤，来提高软件生产率的：
明确一个软件开发中碰到的问题，提出解决这个问题的想法（方法论）
根据解决问题的想法，制作出一个工具。这个工具可以是一个软件，或者是一种文档表达方式（语言）
在软件开发过程中，制定使用上述工具的规矩（过程）
软件开发过程中碰到的开发效率问题，林林总总，非常复杂。对这些问题的思考和看法也会因人而异。但是大体来说，我总结下来可以分为三个层次的问题：
单个模块，功能较单一的代码碰到的问题，主要是代码编写效率的问题
功能较多，需要多个模块共同组建的软件系统的开发效率问题，主要是软件模块之间的关系出现的问题
整个软件开发过程中，在人员和计划进度上出现的问题，不在局限于软件代码本身
对于这每个层级的问题，我们都能找到一些不同的“知识”，有些我们可能比较熟悉，而有一些则不太熟悉。但是如果我们不能意识到，这些知识其实都有一个总的门类，可能会对他们直接的关系和重要性，缺乏必要的理解。为了写这篇文字，我也复习了大学里软件工程的一些课程，以及一些网上的视频和教程，这里面相当一部分充满了八股文的味道：说的内容显然是完整而正确的，但是真正能运用到开发过程中，恐怕是很难的。所以，我觉得从“工具”入手，一件件的说明它们的用途，可能才是打开《软件工程》的正确姿势。
第一个层次
代码版本管理
代码风格指导/高效代码指引
UML
编程范式：结构化编程/面向对象编程
软件测试
持续集成
缺陷跟踪
第二层次
重构
设计模式
DevOps
测试驱动开发
第三层次
领域驱动建模
架构模式
软件项目管理模式：瀑布、敏捷等
以上知识，在同一层次内的，基本可以视为是并行的，互相直接依赖的关系并不大。但是高等级层次，是一定依赖于低等级层次的，如果没有低等级层次的基础知识，可能是无法实践也无法理解的。——在实际工作中，我碰到过很多，直接拿出高层次软件工程知识概念，作为一个名目，来吹嘘或者糊弄项目的情况。事实上这些团队和项目，对于更低一个层次的知识压根就不具备。譬如有的人在项目排期不符合自己预期的时候，就会说：咱们这个项目能不能敏捷一点？我就知道意思就是让大家多加班。
虽然在这里，列举的知识只是短短的几个字，但每一个词，背后都最少有一本经典的书作为基础，并且可以单独成为一个知识门类。而且这些知识，往往并不如普通的编程语言或者功能类库一样，只要去学就能学会，而是需要在软件开发过程中有实践，才能真正的理解，并且用好对应的工具。
后续
面对如此庞大的一个知识体系，我应该不需要“代圣人立言”，而是写一些我自己的实践经验。特别是对于每一个细项中，具体解决的是哪种问题，有一个实践情况下的说明，这样可能会更有价值。对于软件工程类的知识来说，识别出问题，选择正确的工具，往往是更重要的。至于工具的用法，相信网上已经有太多很好的材料了。