读构建之法笔记
构建之法感悟 更新中
[TOC]
对于一个项目的构建在这本书被分为了大概以下几个步骤
- 需求分析
- 设计文档
- 编码
- 单元测试
- 代码复审
在我看来其实总的来说可以用以下几个计算机行业的名词来概括
抽象化 ，互信息，递归 ， 模块化 ，规范
这本书在讲到程序员的成长会在几个方面都需要持续升级，包括 代码的编写 , 团队沟通能力 , 工程构建 , 编程思想 。
并且在微软的高级工程师和初级工程师的地方可以罗列为一张表
| 等级 | 要求 |
|---|---|
| SDE（初级软件工程师） | 入门会一些技能，尚未熟练 |
| SDE II （中级软件工程师） | 独立编写 ，如未清楚知道如何查 |
| Senior SDE | 小组领导，影响3-12工程师 |
| Principal SDE 首席 | 团队领导，影响着10人上的大团队 |
这是一个由小到大的过程，就像国学中“修身，齐家，治国”的迭代过程 。
从最初级的能够修改一点别人的bug，可以连项目的语言本身都不用学会，只需仿造即可；
到能够编写要求的小模块，需要知道语言本身的语法；
到编写更为庞大和重要的模块，需要的是对语言特性的熟悉；再上的发展需要的确实对项目的整体把握。
而在这个分水岭的地方，有几个很重要的东西：
就是如何去决定一个项目的结构，和如何去构建一个庞大的项目
这是抽象的最终的结果，而如何去完成这一过程，大概会从
设定目标（需求分析）
设定结构
试运行
丰满它
以上的说法和书中很相似，但我个人看来，就是抽 和象，抽离本质，赋予其象，也就是前两步，也是最重要的两步。对于一个项目存在必要性就是完成需求，但是往往需求和最后的结果会有所偏差，最重要也是最最开始的一步就是抽离出需求的本质，这在具体下，便是需要理解要求。了解需求背后的意义。
而象这是项目的结构，如何去构建。
- 往往了解行业普遍做法是很重要的，可以作为重要的参考，不要“一来就想搞个大新闻"，借鉴的必要性不言而喻，可以让项目的起点和最后的结果在一个可以评估和可以接受的范围，而创新的到底在什么地方，应该在需要它的时候才应该需要。
- 模仿和模拟用户使用的过程能够让我们把结构的沟和壑大致理顺
- 往往大多数软件相似的很多，但真正优秀，而让人长久的赞扬的很少，这之间的差别在哪？在我看来也是象的程度问题，乔布斯的“人机交互"是一个很好的例子，程序员沉于自己的领域，但是计算机行业所服务的确是所有行业和所有普通人。这是一个互信息的深度过程，你对你所服务的对象又能了解多少呢？你对整个项目的结果也就是完成的软件的本质了解到何种程度呢？
这是一个迭代的过程，这整个过程和一门语言的编程过程很像，Lisp，其语言特性决定了它的抽象高度，如果要我对上面的我的感悟写成某样及其简介的东西的话，我一定会写
(defmacro 象
(抽 需求))
(eq 项目 象)文中在第三章提到的另外一个概念就是领导
- 当过新人的导师么？知道如何让他们准从你的教诲？
- 做过一个项目的灵魂人物么？让团队的成员听从，愿意遵循你的安排？
这个东西要求的往往不在局限于计算机领域了，而是社会学的内容，而这让很多的程序员，特别是理科生 为难，但对于这点我和 格拉汉姆 在《黑客与画家》中所述的是赞同的，一个人是否真的精通某项能力，就在于能否给普通人沟通并让他明白。往往程序员之所以很难和别人沟通是因为往往我们陷入自己的世界。和别人沟通的时候总是用自己领域的
行话，让一般的人根本无法理解，这发生在很多领域中。我们学会的知识总会最后抽象为各种简洁而难以理解的概念和名词。
会有很有趣的以下的对话
你试试把下面这句话告诉普通人：
“如果分派给孩子们的任务不再需要了，父母会把它们杀掉。”这让普通人无法理解，但对计算机行业的人却习以为常，这中间所唯一出的错就是对于概念的理解的偏差，“sub thread ”和“children” 在通常意义上的偏差决定了沟通鸿沟有多深，如果你习惯于将行业术语作为日常概念，那么沟通永远无法正常进行。
回到主题，沟通的关键是什么？
我认为是理解沟通信息的理解偏差，两方聊到同一个概念，必然对其理解有落差，比如说thread ，普通人知道它有线的含义，但一个程序员即会知道它有线的含义，也会知道它代表线程。这在沟通的时候我们需要确定的东西.
“概念在沟通时会有落差”正确的沟通方式是如同瀑布一样向下流，应该在都能理解的领域交流。而不是逆流.
当然排除某种行业的刻意炫耀，在一个程序员与普通人，程序员与程序员之间沟通的时候，应该在有交集的领域沟通。。否则一个团队的效率很难提高