《代码大全》读书讨论结果

我们宿舍在闲暇时间进行了一次读书讨论，探讨《代码大全》这本书，总结出了以下几点：

管理复杂度

软件开发是一项很复杂的工程，面对大型的项目，没有人能清楚地知道整个项目的细枝末节，一个小小的bug可能就要耗费你数小时甚至一整天的时间，而代码如果是别人写的，这个过程可能就会更加的漫长和痛苦。即便不是别人写的，你也很有可能不认识自己一个月前写过的代码。人的大脑是有限的，你不可能同时将五六个密切相关的类同时装进你的大脑并思考改动其中的一个会对其他几个都产生怎样的影响，如果这些类之间的关系是一团乱麻，那么改动其中任何一个都将是非常困难的。套用我同事很形象的说法，你的大脑“内存溢出”了！

所以，管理复杂度便是软件开发过程中非常重要的一个环节，这也是《代码大全》这本书中讨论得最多的一个主题。

管理复杂度是一项很艰巨的任务，大到框架的设计，子系统的划分，小到函数的内聚性，参数的个数，变量的命名，都牵涉其中。一个复杂度小的系统能让你专注于系统的某一点工作，而不用操心你的修改会对系统的其他部分产生怎样的影响。

《代码大全》这本书便从子系统的分割，类的设计和接口的定义，函数的编写，变量的作用域和命名，代码的逻辑，循环控制语句的使用等等，一层一层的讨论下来，总共花了十五章的篇幅！

提高质量

除了管理复杂度，这本书还讨论了一个主题，便是如何提高软件开发的质量。这里的质量包括几个方面，需求的质量（详细的说明），开发过程的质量（对需求变更的控制，增量集成），代码的质量（代码审察，结队编程），测试的质量（单元测试，覆盖率）等等。
作者还提到，过早的对代码进行优化对项目的进度其实是有损害的，然而偏执的程序员总是对优化上瘾，并为此感到自豪，一个好的解决办法是，profiling! 很多优化有时候是程序员想当然的，如果不能对优化前后进行客观的测量对比，那么就不要优化！

代码是写给人看的

这也是这本书中很重要的一个主题，写给机器看的代码很容易，谁都会写，你写得再难看，机器也能运行。但是写给人看的代码就难了，你写代码时要考虑到这个代码是要给你的同事来修改的，或者你自己一个月后也可能会重新维护一下。
之前讨论的管理复杂度是这个主题的一方面，除此之外，良好的注释，详细的代码规范也很重要，它降低了沟通的成本。
关于规范的制定可能会引起争执，缩进该用空格还是制表符，大括号写在末尾还是另起一行，每个人都有自己的喜好，毕竟萝卜白菜各有所爱嘛，然而这些争执其实是没有必要的，制定规范不是选美，目的是要能让你专注于代码的逻辑，减轻阅读和理解代码的负担。