这周开始读《代码大全(第二版)》，没什么特别的原因，只是希望能开阔一下眼界，增加一下见识，丰富一下自己内在的知识。面对当前纷乱的技术分支，沉下心来读一读经典的著作，或许可以从中可以找到一些答案。打算每一周看一部分，看了一下目录，本书一共分为七部分。每周看完一部分就写一篇笔记，粗略记录一下自己的理解。

其实，本书的经典早已不言而喻，所以其中所讲的内容都很经典。在这里只是记录下自己的理解吧。也许现在看起来理解的很幼稚，不过我觉的，应该会随着时间的不断累加，自己会有更多的感悟吧。所以，凡事都有一个开头，对吧。 ^ _ ^

从前言说起

其实，我看书有一个癖好，每本书基本上我都会从前言开始阅读，总是担心会漏掉什么重要内容似的。这本书也不例外，很幸运，有一段话我体会很深

(page.xxii)…因为学习并掌握不止一门语言通常是专业程序员职业生涯中的分水岭。一旦一名程序员意识到编程原则是超越特定语言语法的东西时，通往能够实质地改善编程质量并提高工作效率地知识大门也就向他敞开了。

回顾了一下自己地学习经历，觉得感受还是蛮深刻的。最早开始的时候我只会 C# 一种语言，那两年思想上基本被束缚在了 Windows 平台上，眼睛里只有 C#，而且编程习惯基本上也被束缚在 Visual Studio 工具上，认为编程就应该用 Visual Studio，编程和 VS(Visual Studio)工具绑定到了一起，离开了 VS 工具基本就不会写程序了。我觉得这并不好笑，而且相信很多 Windows 平台的同学还是有这种想法的吧。

很幸运，三年前有幸接触 C++，算是迈出了只会一门语言这个圈子。不管是从心理上还是技术上都算是往前迈出了一步。自从去年开始使用 Mac，之后不断接触 Linux 相关，之后逐渐逃离 Windows 世界，随后接触了一些新的语言比如面向前端的 Dart语言，当前侧重于服务器端的Golang语言，古老的Lisp语言，年轻的Ruby语言，当然还有 iOS 开发常用的Objective C等等。回想了一下，现在基本突破了面对新语言的恐惧感。了解这些语言的过程中除了学习具体的语法以外，也让我逐渐意识到，写程序，其实只要一个好的文本编辑器(例如Vim或 Textmate) 和相应的编译器就可以了。不需要安装一个臃肿而且庞大的图形界面工具。其实想想，编程语言和人类语言统称为语言，只不过一个是面向人的，一个是面向计算机的而已(注：这里面向计算机指的是让计算机执行的角度说的，而不是从让人阅读的角度说的。当然了，写程序当然是让人能够更好的阅读。但前提是计算机得能运行，你说是不？)。多接触一些语言还有一个很好的感受是，当大牛们对一门语言评头论足的时候，你多少也可以产生一点点理性的切身能够体会到的想法(共鸣或反对) ^ _ ^，而不是盲目且木纳的对着大牛们不断的点头(例如某大牛说 VS 工具是反人类的，至少你可以理解他的吐槽点在哪里)。

第一章－欢迎进入软件构建的世界

作者一开始列了一个构建软件的步骤清单，随后否定了这个按部就班的固定的步骤，并称其为红头文件。并解释说

(page.4) 在不太正规和正规之间找一个平衡点是不容易的……

我想凡是参与过公司项目的同学多少都可以理解其中的意思 y( ^ _ ^ )y。随后强调了软件构建的重要性。

第二章－用隐喻来更充分地理解软件开发

看此处之前我是隐隐约约有一种感觉的，但是我不知道应该如何表达。作者用这样一段话比喻软件隐喻像是什么

(page.11) 与其说一个软件隐喻像是一张路线图，还不如说它是一盏探照灯。它不会告诉你到哪里去寻找答案，而仅仅是告诉你如何去寻找答案。隐喻的作用更像是启示(heuristic,启发、试探法)，而不是算法(algorithm)。

恰好昨天晚上看到一篇关于程序员招聘的文章，我很赞同文章里的招聘观点。而且我也觉得，通常情况下，决定一款软件是否成功的主要因素并不是某个牛掰的算法。书中的隐喻，我自己的理解是在构建软件过程中对软件的一种需求上的感悟，是非理性的，恰好和算法这种理性思维形成互补，就像阴阳八卦图中的黑白两部分共同构成一个圆一样。不过，我隐约觉得，构建软件过程中隐喻的重要性要高于个别具体算法。

之后作者针对于软件过程中的隐喻给出了几种不同类型的软件隐喻。我觉得软件的隐喻很耐人寻味，因为它同样突破了固有的计算机领域，同样可以扩展到世间万物，上升到方法论的高度。

第三章－三思而后行：前期准备

本章主要讲述了构建软件的前期准备工作。针对不同的软件类型，采取不同的准备策略，例如遇到什么样的客户需要制定哪些策略。并用实际的科学数据表明如果前期准备不够充分会由于软件的进度的不同所遭受的损失比例。总之一句话，前期准备是重中之重，并举例说明了软件开发的不同阶段对前期准备会产生哪些影响。我觉得，这些可以起到指导作用，需要很强的实际操作经验才能驾驭或者说熟练的运用，并不是另一个红头文件。之后描述了架构包括哪些具体的内容，需要考虑哪些方面。觉得很多还是需要不断的实践才能深刻的理解其中的意味，单看这些罗列的文字没什么太大的意义。

第四章－关键的“构建”决策

这一章主要是构建过程中，编程语言的选择问题。并介绍了几种常见的语言都有哪些特点。书中有一句话让我不太认同

(page.66~page.67) …，我还看到了 Web 的崛起和 Windows 的衰落。我只能假设当你读到这本书的时候，又会有某些新的技术蒸蒸日上，而我今天(2004 年)所知道的 Web 编程将会慢慢消失。这些技术周期(或者说是技术浪潮)意味着不同的编程实践，编程实践取决于你在技术浪潮所处的位置。

很显然，目前来看(2013 年) Web 编程不会消失，而且还会有成为主流的可能。说说我的想法，对于未来移动端会被 Web 取代的这种说法我也不敢完全认同。我认为未来会是移动终端的 UI 加上 Web 的后端会成为主流(或者说是云端？)，因为我认为 Web 的 URL 对于普通大众来说是使用 Web 的一个门槛，远远没有移动端的 UI 更友好。当然了，我也像作者一样给自己留条后路，我只能假设当你读到此篇博客的时候，又会有某些新的技术蒸蒸日上，而我今天(2013 年)所知道的 Web 的 URL 会慢慢退化。

至于书中的语言介绍，我就不总结了，以免招致“杀身之祸”。但作者的一个观点，我觉得非常有启发。引用书中的解释

(page.68) gries 对“在一种语言上编程(programming in a language)”和“深入一种语言去编程(programming into a language)”做了区分。“在一种语言上编程”的程序员将他们的思想限制于“语言直接支持的那些构件”。如果语言工具是初级的，那么程序员的思想也是初级的。“深入一种语言去编程”的程序员首先决定他要表达的思想是什么，然后决定如何使用特定语言提供的工具来表达这些思想

其实，我的理解是，要让语言为你的思想服务，而不要让你的思想服务于语言。