我阅读的是《代码大全》（《CODE COMPLETE》）第二版。我认为这本书是软件工程中比较优秀的一本书，它集中讲解了软件工程从设计到开发，从编码到优化等诸多方面的作者的心得。
当然，这本书不可能将软件工程中所有需要注意的细节写的一清二楚。很多时候作者讲述的是软件工程中需要秉承的精神，而不是一段具体的代码或者一个具体的开发实例。所以阅读本书要坚持进行开发练习，否则这本书所传达的精神和宗旨也只能停留在理论阶段。
对于像我这种菜鸟，想找出这本书的错误，我觉得还是有一定的难度的。不过关于本书，我有以下的几个疑问。
首先，作者用了很大的章节来叙述软件工程中风格和布局的重要性。这是非常正确并且必要的。毕竟随着开发项目的不断扩大，程序猿不可能一个人完成所有的工作，我们需要团队开发，那么代码的可读性就成了必须关注的因素。假如给某个程序猿一个框架，让他在这个成熟的框架的基础上稍作修改开发一个小程序，但是当程序猿拿到源代码时，发现编程风格诡异，布局奇葩，最关键的是连注释都没有，那么我相信程序员的第一反应是掀桌。作者甚至把风格和布局提升到了信仰的地步。但是后来作者又写到要把软件和“信仰”分开，就是强调不能在开发过程中固执的使用一种设计方法，笃信特定的布局和风格。那么这些是否和前面所写有所矛盾呢？
当然我理解作者写上述内容的含义是防止泥古不化。但是如何选择最优的设计方案呢？作者给出了折中主义和实验两种方法。两种方法都是解决上述问题的不错的方案，但是可行性呢？如果贸然采用新的设计模式，必然伴随高风险。（当然还有高回报）这种主义告诉我们可以使用新旧混合的方式，但是这样会不会导致这个程序的风格不伦不类？对于代码的可读性有没有影响？我不知道，也许随着学习的深入和开发实例的增多，我会找到自己的答案。那么实验法呢？先采用一个方法，实验效果，如果不好，则立刻采取应对措施：也许是放弃本模式，也许是修改。但是无论哪种，是不是都对软件工程的进度有所影响呢？当然，实验是必要的，即使使用已经成熟的方法。可是在这个讲究效率的IT行业，在实际生产过程中允不允许我们把客户交给我们的产品当成开发模式的实验案例？毕竟软件是有交付期限的，而且还要考虑到用户随时可能变化用户需求（用户脑子一热就加个需求或者改个需求可是常事）这个问题也让我感到困惑，我相信每个人的答案也会不尽相同。
还有关于防御式编程，讲到了同时使用断言和错误处理。关于断言，我个人了解的还不是太清楚，只知道他是DbC(契约式设计)的重要一环。那么同时使用断言和错误处理对程序的可读性是否有影响？（尤其是哪些不支持断言，需要自己写小函数模拟的语言）对于契约式设计，错误处理的地位如何？这些都是我比较困惑的地方。
关于结对编程，书中提到了很多关于这种编程方式的优点。比如，有人在旁边“监督”可以保证正在编程的程序猿的代码质量，是人们在压力之下保持更好的状态。还能缩短进度时间表，因为结对编程能够提高编程速度和质量，那么必然使项目后期修成缺陷所消耗的时间变得更少。由于结对编程可以加强程序猿只间的交流，对于初级程序猿可以培养集体归属感。结对编程是属于协同构建的一部分，协同构建的优点非常多，在这里不再详述。但是可以简单列举几项数据。IBM发现，一小时的代码检查可以节约软件后期100小时的测试和缺陷修正时间（而结对编程就是最好的饿代码检查方式之一）惠普发现，在软工中制定的检查计划每年为公司节约2150万美元（注意，这是1994年的数据）。对一下大型程序的研究发现，正式的1小时代码检查，可以减少约33小时的代码测试，并且检查的效能是测试的20倍以上。由此可见，协同构建的优势所在。但是书中也提到不是所有的项目都需要使用协同构建。那么我的困惑就是在何时使用协同构建，何时不使用，为什么在特定的情况下结对编程反而降低效率（是指从项目角度出发的问题，而不是从人际角度出发，两个有矛盾的程序猿显然不适合结对编程，这种因素不予考虑）。
以上就是我阅读《代码大全》的感想和困惑，相信随着时间的推移和个人水平的提高，我会逐渐解决自己的问题。
