原本是为了完成软件工程课的作业任务，才打开了这么一本大部头的著作。虽然这一周只读了几章，但是却觉得第一次这样认真的将软件与代码区别开来，也是第一次以工程的角度考虑软件。虽然上了“软件工程”这样的课程，但一来上课不认真，二来课程内容经常纠结于局部问题，所以没有感觉。想来这门课的老师也知道这样的情况，所以第一堂课就说明要我们找些这方面的著作看。然而...还是没能引起我们的重视。
直到上周这个时候，说道要检查博客，才想起这回事。原本想随便找本薄些的书看看，但又想着，要看还是看些经典，于是找到了《代码大全》。读了五六章，现在看来，作者用coding来描述software programing很有道理，软件的编写过程，说到底还是编码的过程，所有的准备，文档，最后是为了正确的编码。这里的正确当然不是语法等的错误，而是从整个软件考虑而言的逻辑，功能，可维护性等正确。
读这样的广受赞誉的著作，第一感受是举例众多，也是作者一再提到的“类比“的很好使用。读了这些章节，下面这些语句让我感受颇深：
“在进行增量式开发时，我们先做出软件系统的一个尽可能简单、但能运行的版本。它不必接受真实的输出，也无需对数据进行真实的处理，更不用产生真实的输出，仅需要一个强壮的骨架，支撑将来要开发的整个系统。
对于你标记的每一部分功能，可能仅需要调用虚假的类。
骨架形成之后，把每个虚假的类替换成真正的类；不再假装接受输入，而是加入接受真实输入的代码；不再假装产生输出，而是把产生真实输出的代码加入。”
这样的观点放在半年前我应该是没有感觉，但由于这学期参与了实验室中一些项目的过程，开始知道这样的开发过程的意义，而且这样的过程，十分适合在对整个软件架构了解不够清晰时使用，由一个非常清楚整个软件的程序员负责整个框架版本。而后由几个程序员各自负责一部分功能的编码实现。有利于整个系统的连接，同时也加快的软件的开发速度。
“自己编写那些现成的代码通常是没有意义的。”
在c语言后，接触了c#语言，其中将很多经常用到的算法等封装成了函数，可以直接调用。一开始我有些怀疑这样的做法，觉得是否会出现看不到的问题，而后与同学讨论到python中众多的包，matlab中的工具箱。才发现很多工具其实都是现成的，而且是由十分有经验的程序员用十分精炼的底层语言编写，经过了很久的历史论证才成为现在的软件包。对于这些被广泛，长久使用的工具，我们在软件开发时，大可以直接使用，一来效率提高，二来现成的代码往往优于临时写的代码。
测试不可能检测出“制造了一个错误的产品”，“使用错误的方法制造”之类的缺陷。这样的缺陷必须在测试前解决-更确切是在构建活动前。
虽然我们十分强调软件完成后的测试环节，然而测试，如上所说，不能检测方向上的错误，这样的错误最为致命。需要在开始构建活动前，甚至是编码之前。
一些程序员确实知道如何进行前期准备工作，但他们并没有做，因为他们不能抵抗“尽快开始编码”的欲望。
这往往就是程序员与软件工程师的区别，我们必须抵抗“尽快编写代码”的欲望，做好充分的前期准备，才能构建一个真正正确的软件作品。
如果你的老板命令你立刻开始写代码，第二个不太靠谱的方法：在你的桌角放一份旧的程序清单，然后投入需求和架构的开发中，不用理会。
这样类似语气的句子经常可见，由此可见，作者也是个经验十足的程序员，并且站在程序员的角度，为我们这些新一代的程序员指点迷津。而从这样玩笑般的语气可见，“需求与架构”必不可少，即使你的老板不懂，我们仍需做好这些工作，不然最后困扰的还是我们。
程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，程序员消化设计。
这句话大概也是说到了很多程序员的心坎，也说明了一个正确的“需求与架构”对程序员而言的重要意义。
开发过程能帮助客户更好的理解自己的需求，这是需求的主要来源。
作者的这番话让我觉得恍然大悟，在此之前，我一直以为，我们要做的就是尽可能在开始开发前，确定需求。但似乎真的如作者所说，“这是不可能的”。想想如果我们是客户，哪里肯呢个在这个东西什么都没有的时候就能完全说出来想用它干嘛。我们需要积极的在开发过程演示，让客户更明确自己的需求，这才是需求的主要来源！！
面对需求变更： “我会整理一份修订过的进度表和成本估计表，这样你可以决定是现在实施还是再说”。
但往往，客户提出的需求有时是难以做到，或者对整个工程影响巨大，这时候作者的这个方法十分有效。整理好修订的进度表与成本表，这两个字眼最能让用户清醒的考虑提出的需求是否真的需要！！！
《代码大全》里，还有很多东西等待去发现，希望能从中体会软件构建的过程，理解软件成为“工程”的必要性。