《构建之法》以相当轻松而易懂的文风表达了作者对于软件工程的理解。在快速浏览了全书之后，产生了这样几个疑问。
- 软件工程是否是更为正确、可靠的软件的正确方向？软件工程的目标是使得通过工程化的方法，可以在合理的时间内，以足够高的质量完成相应的目标。但最近函数式语言的重新流行也使人不得不思考这样一个问题：构建正确的软件能否存在其他的方式？目前的一些纯函数式语言甚至可以采用一些工具进行机器辅助证明。我们如果能用形式化的方法描述该软件的行为和特性，之后便可以让机器辅助证明软件是正确的。例如seL4这个微内核就是采用这种方式证明其正确性的。相较于单纯的测试而言，这样的方式得到的程序更为可靠。那么这是否是未来发展的一种主流方向呢？软件开发是否会逐渐由手工艺转向一种更为工业化的模式？我们不仅可以创建“足够好”的软件，更能创建完全正确的程序？
- 在个人软件开发流程中，代码复审的意义究竟有多大？代码本身就是我们自己写出来的，很多在我们设计时就存在的逻辑错误，通过复审并不见得可以发现。毕竟，我们一度认为那些逻辑是正确的。个人的复审仅仅能够处理手误或者是一时的疏忽，但对于一些根本性的设计问题，也许无从下手。那么如果我们直接进入单元测试等阶段，直接通过调试错误来定位代码中的逻辑问题，是否比复审更具有性价比呢？
- 针对最近频频爆发的信息安全问题，我们能否从软件工程的角度提出一些应对措施？比如在设计、复审等阶段是否存在一些方法可以大幅提高软件的安全性？
- 在《构建之法》中，我们关注的主要是一个一般的开发团队所面临的一些问题。那么对于像开源社区这种与传统的商业软件团队有明显区别的团队，在某些方面是否会有不同、乃至完全相反的情况发生？开源项目中的质量控制、bug修复、用户体验等等各方面是否会有截然不同的一些样貌或方法？
- 用户需求往往是在不断变化的。我们应当如何把握软件在哪些方面因留有扩展的余地？或者说，怎样的设计是合理的？怎样就会引发过度设计？如何把握好扩展性的度？
软件一词最早在论文“The Teaching of Concrete Mathematics”中被提出。软件工程一词则是在Margaret Hamilton为NASA开发阿波罗号飞船时提出的。
关于版本控制系统，事实上经历了数次变更。最早人们使用手工管理代码，这种方式低效且易错。之后有了diff和patch，方便了人们相互之间交流代码的修改。而后出现了一些早期的版本控制工具。之后版本控制工具进入了集中式版本控制的时代。CVS和SVN的相继出现使得集中式版本控制被广泛采用。集中式版本控制会在服务器上维护一个统一的版本库，每次所有的开发者都通过向这个集中的版本库检入检出代码来实现代码的同步。但像Linux等超大型的项目难以使用集中式版本控制，因为集中的版本控制可能因为一个人在解决冲突等导致其他人都必须等待。对于这种级别的项目来说，这是难以接受的。后来，Linux使用了git这种分布式版本控制系统管理整个Linux项目。与集中式版本控制不同的一点在于，分布式版本控制系统不会将代码全部储存在集中的服务器上，而是每个人的本地都会有一份完整的代码库的镜像。同时，git可以极快地开启新的分支，这一点相对于svn来说是一个非常巨大的优势。因此，git一跃成为了目前最为流行的版本控制系统。
除了版本控制系统以外，用于项目管理的工具还有缺陷追踪系统，如Bugzilla。用户可以在Bugzilla上提交错误报告，而开发者可以在其上跟踪、讨论错误信息。代码审查工具Gerrit也是一个被广泛使用的工具。例如Qt这个开源项目的开发就是在Gerrit上进行的。每次要向Qt的主线提交代码，首先会通过Gerrit进行自动化测试，当通过了所有测试后，会有其他社区成员复审。在通过了复审之后才能最终进入项目的主线之中。这样一种流程可以极大地提升代码的质量。