我所理解的软件工程，应该是用一切方法来提高开发效率的一门知识。而开发效率的挑战者，是“需求”。为了搞明白“需求”是什么，业界想了很多办法，以前还有专门的一本书介绍“需求分析”。但是我这个问题是有两个入手方向的：

这本书是一个连接器，它把架构模式、设计模式、测试驱动开发、重构等软件工程知识都连接了起来，提出了一种很符合直觉，并且有实际操作案例的方法论。所以阅读这本书需要有一定的基础知识，我看到一半也发现了《分析模式》这本书从来没读过，跑去下载了一本看。

在我第一次学习“面向对象”概念的时候，我还没学会任何一种真正支持面向对象功能的 语言，那是 MUD 里的 lpc 语言，一种类似 C 语言的脚本。但是我能很明确的了解“类”和“对象”的概念，并且很清晰的看到，一个虚拟的游戏世界，可以怎样以抽象概念为模型，层层深入到最底层的网络、内存、文件、CPU 来实现。所以我天然的会认为，面向对象编程就是要用编程语言，去描述一个问题领域里的样子：如果游戏里有一个角色，那我就应该要有一个“角色”类，每个游戏里的 NPC，都是这个类的对象……然而，在后来的开发工作中，我写了大量的 CRUD 的基于 SQL 的“信息管理系统”，在数据库这个强大工具的影响下，很多问题并不需要去“模拟”真实世界的某个对象，或者说最多是用 SQL 的数据，去对应真实世界的各种表格、工单而已。这种割裂感曾经折磨过我。《领域建模设计》这本书解释了这种割裂，并且直面了数据库和面向对象编程的鸿沟，提供了一条跨越这两者的一种思想。

这本书另外一个重要的价值观，就是一个好的程序员，是需要学习和理解领域知识的。这在程序员群体里是有很大争议的话题，很多程序员认为所谓的领域知识是没用的，不算“技术”。譬如一个很熟悉会计规则的程序员，真的是一个好程序员吗？很多程序员都避免花时间在研究问题领域上，因为很可能下个项目就不做这个行业和甲方了。有时间应该学习那些更加“通用”的知识，譬如《厚黑学》都比会计知识要有用的多。这个问题也曾经折磨过我，我曾经对于程序员的所谓“技术”思考了很多。当一个程序员在某个行业熟悉了之后，显然他能更快更好的开发这个行业的软件，但如果这些不算技术，那又算什么呢？而另外有一些看起来很“技术”的知识，实际上是高度符合某个特定行业的需求的，在其他行业的软件里应用较少，那这种“技术”也称得上技术吗？而这本书很简单的给出了意见：领域知识就是技术。——当然，这并没有解决程序员最深刻的迷茫：怎样才能多赚一点钱。

我看过好几本关于项目管理的书，也试图读过一些 PMP 课程的资料。但是我觉得最认可的还是《人月神话》和《人件》。显然这两本书没有提供什么方法论，但是这两本书却有很重要的价值观：

我个人当时就有一个体会，程序员的开发效率要提高，最简单的方法就是：给每个程序员两个以上的高清显示器（当时普遍只有一个），给每个项目组一个单独的、带门的办公室房间（现在只有所谓封闭开发才会这样）。

对于软件开发，试图让过程“可控”是我这么多年来明确能感受到的甲方需求，但是这是一个悖论：如果一个软件你已经开发过，那么你能明确的评估出它的开发时间；但如果你已经开发过了，为什么不直接用这个成品呢？而对于你从来没开发过的软件，你可能需要很多时间去调研，去弄明白那些没做过的事情，甚至要尝试试验做一下，所以一开始就问你开发时间，其实你的回答也是没有太确实的根据的。——因此评估软件开发时间这个事情就被弄的很诡异，要么是程序员已经做过了，评估出一些略微好于甲方预期的时间，但实际上根本用不了那么多（因为程序员会拿以前的代码改吧改吧用）；要么是程序员的一个承诺，但实际上到时候能不能弄出来，基本只能看天了。我不是说评估软件的开发时间就是错误的，而是我认为不要把整个项目管理的重点放在“开发时间”这一条线上。而应该更加着眼于具体的开发过程问题的解决上：有没有合适的开发环境，开发人员是否适合做这个事情，需求的现状和未来是否经过充分讨论和预估，需要把哪些事情变成自动化等等。从这个角度来看，真正激励程序员更快更好的完成一个事情，并不应该靠打鸡血然后加班，而是应该鼓励程序员去改进自己的工作，让这个工作过程更专业。可惜到现在，有些大厂还在评估程序员的代码行数、BUG数量、工时、评估准确率等等指标，视之为衡量标准。

这个系列，我想就写到这里吧。虽然，关于极限编程、敏捷开发等等还有很多很多理论，但软件工程这门知识是一门实践的经验，而不是一种可以简单学会的知识。如果学校要设置软件工程的考试，我觉得也只能考一些工具的用法；对于各种概念和方法论，即便能写出很正确的答案，在真实项目开发中，也可能完全想不起来用。但这些知识又确实存在，是从开发过程中总结出来的。也许这有一点“艺术”的味道，但又不完全是，或者并不像其他理工科学，是那么的客观。不过不管怎样，能意识到软件工程是一项专门的知识，比起只把“代码写的快，BUG少”视为是个人素质来说，还是好很多的。