梦断代码读后感02

  梦断代码的第四章作者以乐高王国来命名不能不谓之为贴切，想想小时候玩的积木，我们热衷于把各色各状的小木快组合成形形色色自认为好玩的东西。而将之拉近到我们的编程中来，块化和组件化是软件程序员的梦想，谁都想把几个模块插到一起就能完美的运行并完成任务。这其实也是我们大部分人过去完成老师布置下来的作业的应对方法，美其名曰借鉴。确实在我们目前的小代码阶段是可行的。然而现实却相当残酷，可以运行的模块通常不能与自己想 写的程序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己另起炉灶，搭建自己的模块，但结果还是一样，做出来的东西让他人共享，这个现象周而复始，不断的在多个程序员身上上演。我们始终不能找到一个途径，来打破这个模式。程序员们一再发现，可复用软件之梦有一个悖论：几乎总能找到一段满足大部分需求的代码。但这些拿来的代码所不能实现的地方恰是项目与众不同的地方。就拿我们团队做的小软件来说吧，我们一开始是希望做一个扇形图统计的模块，于是花了不少时间去网上各种找代码，最后发现扇形图是很容易绘制出来了但和我们的程序没什么关系。于是到头来只好自己来重写，所幸最后成果不错，自己做出了动态获取数据绘制环形统计图。其实我们的编程就是一步一步的码自己的“积木”，不过这些积木大部分是我们自己做的。

  程序员每天的工作成果是代码，软件生产力最明显的量尺也是代码行。但是这量尺却不能令人满意，有时甚至具有欺骗性。在代码两盒程序完成度、质量以及用户价值之间，并无可靠的关联关系。因为有时候一些代码敲完后才发现自己做了一大部分无用功，或者码完这段长代码只是为了理解其中一部分的功能模块。程序员是顽固的独行侠，老调重弹不足以促其成事；他们需要哄逗和爱抚，要有耗子可以追杀，要有缺陷可以荡涤。看来程序员的管理也有着很高深的内涵。这里讲到了类似PM产品经理的职能。如何更好的管理团队，是我们每个人都因该深思的问题。在我们目前结成的小团队中，虽然每个团队都有各自的队长，但实际上这些队长并不能称为PM。因为各种因素，团队的队长往往碍于同学之间的私人情感，无法对任务分配和处罚机制做到尽其所极。

  第六章的主要内容是测试，我们当前阶段的测试通常被理解为书中所讲的“妈妈测试”，即由我们自己来猜测程序应该如何应对用户输入和机器状态的上千种可能组合。但我们并不善于站在用户的角度和立场考虑问题，想出合理之策。我们被调教的得按自己做出的系统一样的运作。就像老师上课所讲的例子。一个学生带着自己写的程序去找老师验收，然后告诉老师按照他所指的步骤去操作自己的程序。我们视之为理所当然的概念，其实是因为我们不了解用户的想法。

  OSAF的第一个“演示日”，看起来并不顺畅的演示，但是却是实现了以往没有过的模块，是工作人员们几个月的心血。而这整个改变正是许多细节都发生改变的结果。用户的错误理解却真实反映出关注细节、无视上下文的阅读方式是编程大牛们的专长。规格说明是程序员的圣经，编写一个好的规格说明很不易，但却很重要。

 总结一下，四五六七章主要讲了软件开发后期，对软件进行测试和发布所进行的工作，这对我们以后的软件开发有很大的帮助。