《构建之法》，相当有趣的一本书

五一假期间，翻完了从同事那里借来的 那听闻已久的 “神书”。这本书的第三版有400多页，不薄，当然是有些是选择性地快速浏览而过的。

这是本讲述计算机软件工程的书籍。软件工程，对一名有工作经验的程序员而言，实际商业应用软件开发是一件很复杂的一件事情，软件工程涉及的方面是很宽泛的，写不好就会让人觉得都是理论，很空洞，容易枯燥无味。

然而在我翻完了此书，之后，书中多处的情景内容示例，不禁让人对作者肃然起敬。作者确实是位大牛，经验十分丰富，知识面也很开阔，思维十分的灵活。当然了，也许是因为我对于软件开发方面的知识有些小白，才有这些感觉。

来来来，俺们一起通过书中的内容，感受一下此书的魅力。下面内容根据截取自原文，稍有改造。

• 软件效能分析方法（页面P31）

  1. 抽样（Sampling）
  2. 代码注入（Instrumentation）  
  
  抽样方式是Visual Studio会在程序运行时，时不时查看一下运行在哪一  
  个函数，并记录下来。程序结束后，会得到程序运行时间 分布的大致印象。  
  
  利用Visual Studio 内置的性能分析工具（Tools | Performance Tools  
  | Performance Wizard）来做抽样检测分析。 实际中可以利用此方法快  
  速找到瓶颈。
  
  代码注入，就很好理解了，就是软件开发过程中常用的性能统计分析方法, 在  
  已有程序中加入程序运行检测记录代码。
  

实际工作中我们可能很少会想到用第一种方式或者利用这样一种思路来做来做分析。

很多问题其实都可以采用这样一种策略，来进行分析：先采用一种能达到粗略目标（扩大目标范围）的方法去分析，而后对粗略的结果，再采用一种细致的分析方法，最终达到精确的目标。

• 如何衡量软件工程师的能力（页码P44）

书中原文示例，相当幽默风趣

  书中举了一个职业篮球运动员能力展示的例子，职业篮球运动员都有 许多  
  赛季的表现数据（得分。助攻，抢断，命中率等等），作为一名职业程序员
  
  有什么样的数据体现个人能力呢？
  非常幽默讽刺的一句回答  
   “唯一的数据是，上场时间还是挺长的，而且经常打加时赛———加班。”

  *  搬了多少块砖？
  *  搬了多远？
  *  多快搬完？
  *  搬的过程损坏了多少块砖？

虽然很幽默，但是不得不引人对自己的日常工作的思考。日常工作讲究效率，避免重复造轮子，大多时候会去利用网上或者已经写过的代码，做改造。有的人偷懒，什么都照搬，没有细究，结果引入了不必要的代码，甚至，引入了未知的错误，至使已有功能都被破坏了。

日常工作开发中应使用应尽量避免复制粘贴操作，养成好的习惯。

• 其它一些很不错的章节。

  • P48 软件工程师的思维误区
    分析麻痹：遇到问题时，过多的分析而导致个人在问题面前停滞不前，而不是主动去解决每一步分析中的疑虑
不分主次，想解决所有的依赖问题
过早的优化，过早扩大优化：功能还未完善，或者尚不稳定时，觉得某一代码不够完美，想去优化；或者在功能稳定完善后，优化代码时，不是逐步进行，一点点优化，而是一下子想把所有地方都给优化了，结果往往很糟糕。

• P52 专与精的关系
  一个人可以很快的成长为一名全栈工程师吗？
想想街头卖艺的单人乐队和交响乐曲作家，演奏家的差别也许就能明白了
交响乐作曲家，可以分别写各个乐器的乐谱，充分发挥不同乐器的特点，说明他对各个乐器都是非常的了解。然而在演奏这首交响乐的时候，不会是一个演奏家在满场奔走，一会儿拉小提琴，一会儿吹单簧管

书中还举例说明了很多其他的概念和问题，都非常的不错。

 软件 = 程序 + 软件工程
 软件的质量 = 程序的质量 + 软件工程的质量
 
 程序的质量，多反映在代码质量，功能组织框架设计质量；
 软件工程的质量则体现在代码库管理维护，自动化构建等方面。

还有用户的体验，UI设计等等，书中举了很多典型的例子，非常生动形象。

• 如何正确地给予反馈（页码 P85）

这一节，完完全全就是心理学知识嘛。内容过多，拍照截图更方便。
做任何事情，团队间良好的沟通都是非常重要的。全书我最最佩服的章节。