《程序员修炼之道：从小工到专家》阅读笔记2

章节主题：注重实效的途径

第一章讲思想，这一章则是第一章的延伸，本章侧重讲述方法，从开发角度、以过来人的经验为我们带来了可以提高效率的几个途径，十分切合实效的主题，对我们未来的开发也很有帮助。

一、重复的危害

不要在同一系统中多次表达同一件事物。如果某段知识或逻辑出现在多个地方，一旦需要修改，就必须记得同步所有位置。

核心要点：

• 重复有四种来源：无意重复、开发者间重复、强加重复、无耐性重复
• 在使用面向对象语言的过程中，应尽可能地使用访问器函数读写对象的属性
• 欲速则不达，现在节省的几秒钟，将来可能耗费更多的时间
• 访问是互惠的，不要害怕别人钻研我们的代码，同时要记得阅读他人的源码和文档

个人思考： 之前在编程时，在网上参考过别人的代码，很多时候，为了省事，我都直接粘贴了部分代码，没有仔细钻研过原理和过程，就导致部分测试点不通过，后来学会了自己先研究再复用，过程中补充原代码没有涉及到的可能测试点。写题时，也发现有些代码会在多处重复使用，我就在想：能不能编一个自己的代码库，对常用的代码进行收集，这样就不用每次都编一遍，等后面有时间了找找网上教程实现一下这个想法。

二、正交性

正交性在计算技术中用于表示某种不相依赖性或是解耦性，简单来说，就是如果两个或多个事物中的一个发生变化，不会影响其他事物。

核心要点：

• 如果组件是相互隔离的，那么改变其中之一就不用担心其余组件
• 要消除无关事物之间的影响，编写正交的系统
• 正交系统的好处：降低开发和测试时间，促进复用，隔离有问题的代码等
• 尽可能减少团队组织的重叠，向正交团队靠拢，但依旧鼓励团队进行相互交流
• 系统应该由一组相互协作的模块组成，每个模块都实现不依赖于其他模块的功能
• 不要依赖无法控制的事物属性，例如：若把电话号码当作顾客标识符，但电话公司重新分配了区号，该怎么办
• 维持正交性的方法：让代码保持解耦，避免使用全局数据，避免编写相似的函数

个人思考： 感觉这一节对将来做项目很有帮助，比如避免把所有逻辑堆在一个类里，否则改一个功能牵一发动全身。应该尝试把数据库操作、业务逻辑、界面展示分开写，虽然代码量变多了，但改bug的时候就清晰轻松了，因为知道问题一定出在某个特定的层里。

三、可撤销性

简单单一的解决方案固然让人觉得舒服，但这正是危险的来源，所以永远不要假设某个决定是不可更改的。今天选择的数据库、框架、技术方案，明天可能都需要替换。

核心要点：

• 不存在最终决策，要为可能出现的意外事件做准备
• 把第三方依赖抽象成服务接口，即使无法彻底隔离，也要使用各种机制让它可撤销
• 保持模块边界清晰，方便整体替换

个人思考： 这一点在对以后做课程项目时也很有帮助。这启示我们不要一开始就选定了某个框架或数据库，然后所有代码都跟它绑死，应该一开始就把数据访问层抽象成接口，这样换数据库只需要改一个实现类，而不是重写整个项目，可以大大节省空间。

四、曳光弹

当面对一个复杂的新系统、不确定如何实现时，不要试图一次性规划完美，而是用"曳光弹"方式——先搭建一个基本结构，然后以此为骨架逐步添加功能。

核心要点：

• 曳光弹 vs 原型：原型用过就扔，目的是验证可行性；曳光弹虽然简约，但构成最终系统骨架的一部分，是渐进式开发
• 曳光代码的好处：尽早让用户看到可用的东西、团队中每个人都变得更有生产力、调试和测试会变得更快等
• 曳光代码并不总是一下就能满足客户需求，我们要做的是找出已有的能改变的东西，使之不断接近目标

个人思考：感觉这节也是对未来做项目有帮助，但我目前接触还不够，无法应用这些技巧，因此也就没有什么很深的体会，可以在以后的实践中逐步加深一下理解。