读书笔记——读《代码大全》有感
最近拜读了《代码大全》，一开始听说这本书名字的时候如雷贯耳，觉得应该是关于代码方面的煌煌巨著，包罗了尽可能多的精妙代码。一见之后才知不是如此，这大块头倒是名副其实，但是它主要涉及的不是具体代码，而是代码的方方面面。读了这本书，我在这几方面有了一定的感悟。
在《代码大全》里，有这样一句话“将主要精力集中于构建活动，可以大大提高程序员的生产率。”在以前的电子设计实践中，对于这一点，我就饱尝辛酸。在上学期的电设中，我们前期设计的不足导致了我们在硬件架构还是软件开发，甚至在最基本的算法、数据传输方面都错误不断。在最后的日子里与DDL鏖战，确实是一件心理体验极差的事情。书中还有类似的话语：“健康的生态中，……，这是一条健康的食物链”。如果前期的设计工作不做好，那么隐藏的矛盾不会就此消失，而是会愈来愈富集到下游的工作之中，让人寸步难行。不仅是对于整个项目来说，在我平时编写程序中，一开始的分工布局也是十分重要的。一个不合理的布局经常能让人抓耳挠腮。而在我们这种小规模的团队内，不合理的构建就像是一记“七伤拳”，一拳既出，众人皆伤。
第二点是需求，这是邓老师在指导我们的时候强调的一个词，或者说“痛点”，后者显然是大而急的需求了。读《代码大全》，让我对这一点有了更深的理解。在我们这个阶段，需求分析一般以书面形式完成，也就是所谓的项目需求分析。里面包含了很多问题：用户要什么？我们能做什么？是否需要我们做这方面的事情？诸如此类，不一而足。这些都是需求分析中我们所需要关注的，“知己知彼，百战不殆。”一份详尽的需求分析，是我们软件（项目）开发的基石，它使得策划基本稳定，能够有一个较为准确的核心。如果考虑到软件的更新方面，那么每个版本所做出的各自的需求分析不单单是各版本的立足之本，同时也展现了用户在该方面的需求变迁，这对把握需求走向，预判未来领域是十分有益的。
最后我想来谈一谈我对于程序中耦合的看法。以前编程因为只写一些小程序，所以对耦合并没有比较清晰的认识。上学期在编写风力摆的代码的时候，耦合成为一个非常头疼的问题，经常是按住葫芦浮起瓢，令人无奈。后来我们主要采用了传参、大规模使用全局变量和宏定义的办法，最后结果尚可，不过代码结构比较混乱。《代码大全》中对于耦合并未提出“最好的”解决方法，而是将几种解决方法进行了比较，供我们自己去根据需要选择。举个例子，对于一个点的坐标Point(x,y)，可以采用对象的办法；可以采用结构体；可以传参；甚至简单粗暴地怼值进去也行。当如果需要频繁应用的时候，封装起来可能比较好；当如果它只是程序的一个匆匆过客时，临时代入就成为了一个不错的选择。许多程序员追求“低耦合”，但耦合不猛于虎，适当的耦合也能给我们带来方便，减轻一些生产负担。
有话很多，没话更多。不知不觉就在读罢《代码大全》之后洋洋洒洒了一堆，如此虎头蛇尾不失为一个好方法啊。（括弧笑）敬请各位斧正，若为涂抹，不留一字亦可。