《程序员修炼之道：从小工到专家》读后感

1. 频繁的高强度的外部刺激和自主意识的反复提醒是成为高手的途径。但是外部环境条件有限，因此想要成为高手。必须有意识地去强化实践和反复提醒。

2. 每次参加会议，不应该觉得会议为什么没完没了的。应该考虑的是为什么要开会？是否可以通过其他方式来取代会议？是否可以让某件事变成自动化，以推进会议的进度。有时候开会并非远离编程，开会就是编程，让你更好的理清思路，改善编程。重点考虑自己的工作，注意实效。

3. 注重实效的程序员特点：

(1). 快速改变。喜欢尝试新鲜事物，并且快速掌握运用。

(2). 好奇。对新的知识感到好奇。

(3). 批判性思维。对一般陈述的事实具有一定的怀疑心态，考虑为什么事实是这样的。知其然也要知其所以然。

(4). 有现实感。理解问题的内在本质。考虑解决问题所需要的大概时间。

(5). 多才多艺。尽量熟悉广泛的技术和环境。让自己对问题的思考更加充分。

1. 注重实效的哲学

1. 注重实效程序员的特征：能够直接越过问题去思考，设法将问题放在更大的环境中思考，没有更大的环境，怎么能注重实效？又怎么能做出明智的判断和决策？

2. 大多数人很难接受变化，有时是出自好的理由，但绝大部分是因为固有的懒惰。

3. 在汇报问题时，应该提供各种解决问题的选择，而不是借口。而当你对某件事情无能为力准备和其他人交谈时，先听一下自己内心的声音，想一想别人会怎么问你？你尝试过哪些方式去解决这个问题？没有什么解决不了问题，只是解决方案的好坏程度不一样罢了

4. 不能忍受破窗户，一个人的烂代码习惯会影响所有人。

5. 学会经营自己的知识产权。新技术、语言、环境的出现，导致自己的知识变得过时,随着自身知识价值的降低，对客户和公司来说，自身的价值就降低了。要阻止这种事情发生，大致学习目标：

(1). 每年学习一种新语言。不同语言解决问题的方式不同，学习多种语言，扩展思维，避免墨守成规。

(2). 每季阅读一本技术书籍，也有阅读非技术书籍。

(3). 每周一篇中文论文和英文论文。

(4). 使用不同的环境开发。

6. 学习的过程将拓展自己的思维，使自己向着新的可能性和新的做事方式拓展。

2.注重实效的途径

1. 重复的危害和正交性：前者提醒自己，不要系统中重复自己的代码，后者提醒自己，不要把任何一项知识分散在多个系统组件当中。避免耦合性太高，不容易维护。最重要的好处是提高了生产效率与降低了风险。

2. 什么是正交性？

在计算机技术中，正交性表示某种不相互依赖性或者是解耦性。如果两个事物或者多个事物发生变化而不改变、不影响其他事物。说明这些事物是正交的。

3. 项目中存在一个现象：在讨论改动需求时，涉及到的人越多，团队的正交性越差。

但是公司目前存在一个现象：模块和模块之间出现了第一份模板，后面使用模板编码的人越来越多。出现的问题基本上也是一致的。这种现象存在好的地方是节省了大部分人的编码时间，存在的问题是当出现问题时每一个模块都有问题。如何解决呢？建议是当一个模板出现时，进行详细评审，之后出现错误的可能性会降低很多。并且与需求对应。

4. 编写的代码如何保持正交性：

(1). 让自己的代码保持解耦。

(2). 避免使用全局变量，原因是：当代码使用全局变量时，它把自己与共享该数据的接口绑定在一起了。对数据进行获取时，比较麻烦。特别是当你的代码要改变成多线程调用时，很容易出错。

(3). 避免写类似的函数接口。

5. 养成不断审视、批判自己代码的习惯，寻找任何一个可以优化、改进代码结构和正交性的机会。

3.基本工具

1. 要像工匠一样定期增添增加的工具，时刻保持着寻求更好的解决问题的方式的想法。如果当前的工具不能够解决问题，记得寻求更有利于你当前状况或者更强大的工具。

2. 不要太依赖于特定的集成开发工具（IDE），有些时候出现问题的地方不一定会存在你的开发工具。我们要超越IDE所施加的限制，要做到这一点的途径就是保持基本的工具的锋利和就绪。

3. 如果你没有高超的调试技巧，那么你就不可能成为一个优秀的程序员。

4. 投入一定精力去熟悉自动化脚本，会提高自身很大的工作效率。

5. 要接受一个事实就是调试就是在解决问题，bug无论是谁的过错，现在在你的手里就是你的问题。在技术竞技场上，应该专注于修正问题而不是发出指责。

6. 在调试bug之前，尽量先让自己的代码没有警告。把时间浪费在编译器能够为你找到的问题上没有意义。之后可以使用DDD调试器让自己的数据可视化。

7. 不要去假设，要去证明。

4. 注重实效的偏执

1. 你不可能写出完美的软件。追求极致，但也要适可而止。注重实效的程序员针对自己的错误进行防御性的编码。

2. DBC。按照合约设计代码，按照合约约束用户使用。会在一定程度上减少异常的出现。

3. 我们很容易掉进“它不可能发生”的心理状态，主要原因是我们对一些代码的异常处理考虑得不是很全面。如何弥补这方面的缺陷？主动去思考用户在使用过程中各种可能性的发生，检查任何可能的错误，使用断言设法检测你疏漏的地方。

5.弯曲，或折断

1. 保持灵活的代码的一种方式是以少有的代码量实现功能。

2. 得墨忒尔法则：某个对象的任何方法都应该只调用属于以下情形的方法。其优点是代码易用性更好，健壮性更高。缺点是需要封装大量接口，远行速度慢、空间开销大。

3. 任何技术都有优缺点，你必须评估其正面和背面因素。解决方式总是会有的，好的解决方式是需要思考的。

4. 通过反转得墨忒尔法则，耦合若干部分可以获得性能上的提升。如果耦合的内容是可以接受的话。

5. 什么是元程序设计？使用文本来描述应用配置信息，包括用户偏好、安装目录等。使代码变成可配置化，更容易适应改变。

6. 什么是元数据，就是对任何应用进行描述的数据，一般是文本形式。常见的属性有

(1). 运行时被访问，而不是在编译时被访问和使用。

(2). 一般采用文本文件存储，例如：Windows 下的 .ini 配置文件。

(3). 一般采用自定义文本类型或者系统标准类型，就是自定义文件后缀名。

(4). 存储的信息的格式常采用键值对，例如：user_name : tom。

7. 元数据设计的优点：

(1). 使你设计解耦，从而带来更灵活，适应性更好的程序。

(2). 推迟对细节的处理，创建更健壮、更抽象的设计。

(3). 无需编译使用，可以定制自己的配置信息。利用这种方式，有时候可以避开代码里的一些bug。

(4). 可以用实际领域的语言来描述元数据信息，从而间接确定了应用的运行行为。

(5). 在同一个项目下，使用不同的元数据，实现不同的项目。

8. 元数据设计的适用场景：

(1). 若元数据改变时，应用在运行时可以动态加载元数据。这种情况适用于长期运行的服务器程序。

(2). 若元数据改变时，应用需要重启并重新加载元数据。这种情况适用于小型的启动速度快的 GUI 程序。

9. 提示：把抽象放在代码里，细节放在元数据里。

10. 在最初设计架构、或者编码时思考的方式是线性的，结果会带来时间上的耦合。我们要容许并发，并考虑解除任何时间或者次序上的耦合。

11. 编写线性代码，有时候容易做出一些不合理的设定，把我们的代码引向不整洁的道路。但是并发编程迫使你更仔细的思考，因为代码是写给别人用的，事情有可能在同一时刻发生。现在问自己，当初设计的时候为什么选择全局、静态变量。

12. 有一些系统库接口本身就不支持多线程的，当我们在设计一个功能接口的时候要了解我们要使用的官方系统接口的特性是否符合我们的设计需求。

13. 提示：总是为并发进行设计。如果我们在设计时就考虑并发，到时候就更容易地满足可伸缩或性能需求。

6.当你编码时

1. 大多数人认为项目进入编码阶段只是机械地将设计转换成代码的过程。我们认为这种态度是代码丑陋、低效、bug繁多的一个重要原因。我见过设计方案写得很完美，但是代码却很烂的情况。一段优秀的代码不仅仅只是设计方案就能描述得出来的。

2. 注重实效的程序员会批判思考所有人的代码，包括我们自己的。（保持成一种习惯）

3. 当自己在编写代码的时候，要记住终有一天你会对它进行测试。所以要编写易于测试的代码，这样将会增加你代码实践通过测试的可能性。

4. 怎么样深思熟虑地编码：

(1). 总是意识到你在做什么。（目标意识）

(2). 不要盲目编程。试图使用你不理解的应用或者不熟悉的技术。有可能会被误导。并且你使用的技术不一定符合当前的情景。

(3). 按照计划行事，依赖可靠的事物去编程，不要依赖巧合或者假定。

(4). 为你的假定建立文档，有助于澄清思路并且容易传达别人。

(5). 不仅测试你的代码，还有测试你的假定.

(6). 为自己的工作划分优先级。把时间和精力花费在重要的事情上（一般也是最难的部分）

(7). 不要做历史的奴隶。不要让已有的代码来支配将来的代码。如果不再适用，所有的代码都会被替换。

5. 注重实效的程序员都会估计自己算法使用的资源——时间、处理器、内存等。时刻考虑当你的数据量增加时，你的运算时间是多少？是否可以优化？

6. 懂得测试自己的估算，如果要获取自己准确的计时比较棘手，可以使用代码剖析器来获得你算法中不同步骤的执行次数。

7. 最好的算法并非总是最适用的。考虑自己当前的数据量的变化和使用环境。

8. 在重构代码时的注意事项：

(1). 不要试图在重构的过程中增加功能。

(2). 在重构之前，确保你拥有良好的测试环境。良好的反应问题的渠道。

(3). 采用短小、深思熟虑的步骤，并且在每一个小步骤完成之后进行测试。如此能够避免长时间的调试。

9. 一个完整的测试系统所具备的功能：

(1). 用于指定设计和清理的标准路径。

(2). 用于选择个别或者所有可用测试的方法。

(3). 分析输出是否预期结果的手段。

(4). 标准化的故障报告形式。

10. 提示：测试你的代码，否则你的用户就得测试。

11. 提示：不要使用你不理解的向导代码。

7.在项目开始之前

1. 完美，不是在没有什么需要增加，而是在没有什么需要的时候去掉。

2. 不要收集需求，而是要挖掘它们。找出用户为什么有这个需求的这个原因，而不只是满足它们的需求。与用户一起工作，以用户的角度去思考。

3. 需求文档不能太过于详细。需求不是架构，不是设计。需求就是简单的需要。

4. 注重实效的程序员，要倾向于把需求收集、设计以及实现视为同一个过程。不要信任这样的开发环境：收集需求、编写规范、然后编码。这种每一个环节都是孤立开发的。相反的，要实现敏捷性开发。

8.注重实效的团队

1. 即使是目标最明确的团队对项目中的重大改动也有可能会遗忘。要确保每一个人都主动的监视环境、代码的变化。可以指定一个监测员来持续检查项目的变动。保证项目的变化进度。

2. 什么是杰出的团队？人们希望和他们一起开会、因为他们知道自己将看到的是准备充足、精彩的演出。他们制作的文档新鲜、描述明确、一致。团队使用一个声音说话。甚至拥有幽默感。（希望在这样的团队里，但是要保证自己足够的优秀）

3. 无处不在的自动化。让计算器去做重复、平常的事情。因为他们比我们做得更好。我们有更重要、更难的事情要处理。每天思考一下，现在手里有哪些事情可以自动化解决。

4. 注重实效的程序员，一定较为完善的测试自己的代码，以免以后由别人找到自己的bug的羞耻感。我自己也一样。一定要一直保持这种羞耻感，不害怕别人测试我的代码。但是要竭尽全力保证自己代码的正确性。

5. 提示：早测试、常测试、自动测试。bug发现越早，进行弥补的成本越小。

6. 项目测试的主要三个方面：测试什么？怎么测试？以及何时测试？（任何产品一旦开始存在，就需要进行测试）

7. 测试什么的主要类型有：

(1). 单元测试。

(2). 集成测试。

(3). 验证和校验。

(4). 资源耗尽、 错误及恢复。

(5). 性能测试。

(6). 可用性测试。

8. 怎么测试内容包括：

(1). 回归测试。

(2). 测试数据。

(3). 演练GUI系统。

(4). 对测试进行测试。

(5). 彻底测试。

9. 注重实效的程序员不会逃避责任。相反的，他们乐于接受挑战，乐于使我们的专业知识广为人知。

10. 不要怀着猜忌心理阻止要查看你的代码的人；出于同样的原因，你应该带有尊重对待他人的代码。