《程序员修炼之道》第二章已经读完，感触颇深，接下来由我来做个总结。
既然已经选择了软件工程这个专业，以后的工作难免要参与到团队中进行项目开发，任何工作都讲究实效，软件上的实效不仅仅是指代码的运行效率，即时间复杂度，空间复杂度这样的，还要具备相应的思想。在谈到实效之前，我们不妨先回忆一下自己的学习经历，在接到一个新的任务时，发现其中的某个要求我们曾经做过，这个情况你会不会去翻以前写过的代码呢？确实，将之前的代码搬运过来，稍加改动便可以应付任务，但是，这算是一种“重复”。要培养自己的能力，首先要做到的就是DRY原则（Don't Repeat Yourself），这也是注重实效的程序员的工具箱里最重要的工具之一。有的时候，我们也会在无意中出现“重复”的问题，这往往发生在编写代码的时候，这个时候就需要我们在完成任务之后去回顾，审视自己的代码，及时做出修正，很多时候我们会因为“这个任务已经完成，我没有必要再去看了”这种想法而对自己的作品视而不见，但是回过头来优化自己的代码，确实是提升能力的一个好手段。
注重实效，首先要理解“正交性”，我们在编写代码的时候，经常会写那种关联性的东西，比如C++中的类嵌套，Java的接口等等，这种关联性若是放在工程上，就值得讨论了。当客户要求你更改某个功能时，会不会因为这次修改把与它关联的功能破坏掉呢？而如果两个功能之间存在正交性，即二者互不影响，可想而知，工程量将大大减少。目前我对正交性只有理论上的认知，按找书中的介绍，最简单的正交性用法似乎就是“避免使用全局变量”，“避免编写相似函数”等等。全局变量说实话我还真的用过，当时是为了方便调用变量，但反过来想，两个函数已经因为这个变量“连接”在一起，失去了正交性。如果在写代码时因为某处出现了疏忽而在我不知情的情况下改动了变量，那么我面临的就是两个函数同时出错的尴尬境地。
除了正交性之外，我们还需考虑可撤销性，当然这是术语称呼，说白话就是别把话说的太满，做事不要太绝。开发团队有一个确定的目标确实方便下手，但是切忌不要下达太过绝对的决策，否则一旦发生了什么变故，那将会非常头疼。
接下来就是我比较关注的一点，曳光代码。也就是在为客户设计的时候，不妨根据客户的要求以及自己的预测先弄出些什么，这样能让客户看到进度，及时提出改动建议，也能让开发者明确方向。这种曳光代码正是一个好的开发者所必须掌握的方法，也是我从现在开始有意培养的意识之一。
最后，学会估算。估算的准确与否看上去并不能对结果造成什么影响，而这种估算有利于给团队树立一个明确的目标，方便开始计划，对注重实效的团队而言，估算也是一不可或缺的一项。