按照阅读计划，本周我对梦断代码这本书进行了进一步的学习。在这一周，我大部分课余时间都投入了到了我们的团队项目第一次冲刺中，但是在繁忙的编程中，我还是抽出时间对《梦断代码》4、5、6、7章进行了学习，学到了很多知识，也有了很多感悟。
第四章的标题是乐高王国，讲述的大致内容是在技术工业的冰河时代，大量程序员失业或者半待业。相当多的程序员转而投身开源项目，在这个特殊时期，OSAF当然获益匪浅。米奇-卡普尔总认为，OSAF即依靠全职雇员，也依靠无私的志愿者。身为志愿者的他们投入到Chandler项目中，从软件抽象层的另一种维度，他们常常谈及的前台和后台的概念，前台是程序中和用户打交道的部分——显示窗体对话框和鼠标指示，告诉你正在发生什么，让你有办法输入信息并得到输出信息。后台是前台发生的事件和用户输入流向的地方，计算机对事件和输入进行处理，保存，取回。（在Chandler的原型系统中，Vista是前台，Shimmer则是后台。）前台应该精致，直观，功能强大，后台应该隐形，高效，如磐石般坚固。对于Chandler的前台，卡普尔清除自己想要什么，然而Chandler后台工作陷入了困境。对资料库的最主要需求是方便前端开发者，而前端开发者需要一种“对象持久化”的机制，把数据和代码一并保存为对象，这样有利于取出、操作和保存。实现“对象持久化”最简单的手段就是采用另一种数据库技术，即对象数据库，对象数据库把一段代码和与之相关的数据打包储存。Python程序员们搭建了ZODB。ZODB的出现带来了分歧，在他们的讨论下，出现了“乐高假设”——未来，程序将由可复用的部件组合而成。然而这条路并行不通。通过各个程序员的测试，最终终结了关于ZODB长达数月的争论。
第五章的标题是管束奇客和狗。在这一章中，提到了很多狗，并讲解了狗的特性，提到了狗管束不严就会戏弄主人。实际上说的是经理和程序员的关系。管理犬只和管理项目的相同点是必须做交易——想要有收获，必须牺牲一些东西。管理软件开发项目的方式往往更为原始——要从无到有创建秩序，要回答类似“从哪儿入手”和“怎么才知道何时完工”之类问题，还得协调难以控制的团队力量，使其朝向共同目标一致用力。从而有了项目经理。设计决策的原则导致寻找开发经理的工作进展缓慢。在后面的学习中了解到了一个词：geek，奇客，用来描述那些与计算机沟通易于与人类沟通的人。奇客后来演变，出现了一个词组geek out——奇拗，指的是沉浸到细节中直至变态境界——而且乐此不疲。奇客不都是编程人员，编程人员并非都是奇客。奇客的分类多种多样，社会表现性也各有不同。他们的共性是对特殊知识的狂热和糟糕的人际关系。但是，他们真的需要与他人倾谈。
第六章的标题是搞掂设计方案。在这章一开始，作者用自己的亲身经历来给我们讲解了很多东西，创建“终端用户应用软件”意味着将遭遇无数种人类行为与机器反馈的组合。因此需要制定各种各样的约定。通常由程序员负责猜测程序如何应对用户输入和机器状态的无数种组合。同时还要考虑各种极端情况和不太可能出现的情况。卡普尔认为，软件设计不仅仅似乎在程序员代理吗上覆盖一层诱人的图形。它是一种一种设想用户需求并在软件结构中满足这些需求的创造性基础工作。但是，我们并不能保证每个用户都完全按照我们提供的要求使用我们的软件，就如同作者前面所说，不小心让重要文件消失了，如果没有撤销键，那要怎么办。在软件世界里，集成的意思是把一段运行正常的代码链接到某个程序中另一段运行正常的代码上。对于刚开始做大型开源项目的人，从小项目做起，而且不要期望它变大，如果这么想，就会做过度的设计，把他想像得过于重要，更坏的情况是会被自己的想象的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去向大图景和好的设计。如果项目没有解决某些眼前的需求，多半就是过度设计。别期望在短时间内达到大的成就。
第七章主要讲述了关于做好细节视图。在这一章一开始，程序员们做出很大努力，根据自己得到的资料完成自己的任务，但是基本上没法用。就像吉他手吉尔.塔夫内尔的设计草图：一个多余的撇号就让十八英尺的巨石变成了十八英寸的石柱子。随着构建程序的真实用户界面进入人们的视野，程序员对信息的需求显而易见。计算机程序采用地窖、树状结构和类似的明确结构，是因为这些结构有助于保持组织数据，减少混淆。谨慎命名才能避免“名称空间对撞”和“冲突”的混淆情况。最著名也是最声名狼藉的变量命名方案是匈牙利语标记法。其名字来自于发明者查尔斯.西蒙尼的母语名，同时也来自该种语言神秘而不易发音的单词标记。这种命名法饱受多义性之害。对于简单的C、c++等程序，匈牙利命名法可能适合，但是对于Java等高级编程语言，匈牙利命名法带来的弊端就不小了。代码复查既可以是在计算机旁的非正式讨论，也可以是长达数周的代码检视。坚持，总会有回报，这句话，值得我们思考。
在以前，我知道编程不是一件轻松的事，我作为编程的初学者，总是对编程有一种恐惧心理，总觉得自己能力不够。
现在，我在阅读了这几章后，我对软件编程有了新的认识。软件编程是一个技术活，不是每个人都能精通，对于软件编程，我们不要局限于自身编程，我们要善于和他人沟通。
同时，在软件编程过程中，我们要从小做起，切合实际，不抱有不切合实际情况的幻想。别期望在短时间内达到大的成就。