所有程序员在一层定义上都是“疯子”，他们都是为了软件，代码会深陷其中但又一贯以乐天派示人的一帮怪人，有人会觉得昂浪费精力，浪费青春的事都会有人乐此不彼的去做，他们究竟是怎么了。
《梦断代码》讲述的是Chandler软件漫长而痛苦的开发过程，在该过程中，一系列的问题都要考验他们那些程序热衷者，那一刻真觉得是不是该同情他们一下，，在osaf开发组中，单单负责选择其他程序员用来创建软件的部件的“系统架构师”安德森一人就要面临：应该采用什么工具来创建程序的图形界面？应该采用什么软件技术来存储程序数据？应该采用哪种数据交换标准？等一个又一个难以抉择的局面，这让我觉得软件是那么的抽象。
软件=程序+软件工程（软件企业=软件+商业模式）
软件开发的不同阶段：玩具阶段→业余爱好阶段→探索阶段→成熟的产业阶段
软件所具有的特殊性：复杂性、不可见性、易变性、服从性、非连续性。
重要的单元测试：有效解决程序员对模块功能的误解、疏忽或不了解模块的变化之类的问题，使自己负责的模块功能定义尽量明确，模块的质量得到稳定的、量化的保证。
好的单元测试的标准：在最基本的功能/参数上验证程序的正确性；单元测试必须由最熟悉代码的人（程序的作者来写）；单元测试过后，机器的状态保持不变；单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）；单元测试应该产生可重复、一致的结果；独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性；单元测试应该覆盖所有代码路径；单元测试应该集成到自动测试的框架中；单元测试必须和产品代码一起保存和维护
单元测试的基础上能够建立关于这一模块的回归测试，目的是：验证新的代码的确改正了缺陷；同时验证新的代码有没有破坏模块的现有功能，有没有Regression
个人感受：一些大的项目是要分成许多小块来做的，这些小块也许由不同的人来完成，也许由一个人来完成，但是无论实在组装还是最后测试的时候总会涌现出来许多问题，所以在完成每一小块的时候要进行必要的单元测试，这样可以有效地减轻在最后组装测试时候的难度，提高一定的效率。以前也从来没有在意过这一点，都是弄一些小的作业，测试的时候改bug也不难，不过要是以后做大的项目的时候就要注意到这一点了，一定要分成小的单元并在完成的时候进行单元测试。