概述
花了几天时间看完了程序员修炼之道，有很多感悟，记录于此，供自己开发时参考，相信对其他人也有用。
值得一提的是，这本书写的非常好，很多大牛在走了很多弯路之后再读这本书都很感慨没有早些读。
弯曲，或折断
- 解耦与得墨忒耳法则
1.函数的得墨忒耳法则规定，某个对象的任何方法都应该只调用属于以下情形的方法：它自身；传入该方法的任何参数；它创建的任何对象；任何直接持有的组件对象。
2.委托服从得墨忒耳法则，从而减少了耦合。
- 元程序设计
1.元数据是关于数据的数据；要用元数据描述应用的配置选项。
2.有些配置是只在程序启动时扫描的，因此如果这些配置发生了改动，那么程序就需要重启来更新这些数据。
- 时间耦合
1.事务处理系统就是一个时间解耦的系统，也就是安排事物并发运行的系统。
2.我们可以用事件把某个对象的状态变化通知给可能感兴趣的其他对象。这样使用事件使得那些对象之间的耦合得以减至最少——事件发送者不需要对接收者有任何明确的了解。
3.为什么要使用树视图。因为树视图与解耦有很深的关系。
- 黑板
1.这是我唯一存在疑惑的地方，黑板系统在编程中到底是个什么样的系统。
当你编码时
- 靠巧合编程
1.只要你在制作代码，你就应该记住，有一天你必须对其进行测试，要让代码易于测试，这样你将增加它实际通过测试的可能性。
- 算法速率
1.某个O(n^2)算法可能比另一个O(n^2)算法要快1000倍，但你从表示法上却看不出来。
2.对于较小的n值，简单的O(n^2)循环的性能可能会比复杂的O(nlg(n))算法更好，特别是当O(nlg(n))算法有昂贵的内循环时。
3.如果你不确定代码需要多少时间，或是要使用多少内存，就试着运行它，变化输入记录的数目，或可能影响运行时间的无论什么东西。随后把结果绘制成图。
- 重构
- 易于测试的代码
1.我们喜欢把单元测试视为针对合约的测试。
2.测试时的热键虽然不会透露给最终用户，但这对于客户服务人员却非常方便。
- 邪恶的向导
1.我们虽然在使用向导，但是我们也要理解它制作出的所有代码。
在项目开始之前
- 需求之坑
1.在讨论用户界面时，需求，政策和实现之间的区别可能会变得非常模糊：“系统必须能让你选择期限”是对需求的陈述；“我们需要一个列表框，以选择期限”可能是，也可能不是。如果用户一定要有列表框，那么他是需求。相反，如果他们是在描述选择能力，但只是用列表框做例子，这个陈述就可能不是需求。
2.你的开发必须解决他们的商业问题，而不只是满足他们陈述的需求。
3.成功的工具会适应使用它们的双手。
- 解开不可能解开的谜题
1.当你认为你的问题是“不可能解决的”时候，问自己这些问题：有更容易的方法吗？你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？这件事情为什么是一个问题？是什么使它如此难以解决？它必须以这种方式完成吗？它真的必须完成吗？
- 等你准备好
1.作为开发者，你在整个职业生涯中都在做同样的事情。你一直在试验各种东西，看哪些可行，哪些不可行。
- 规范陷阱
- 圆圈与箭头
1.计算技术从来都不缺少意图使程序设计更像工程的方法。
2.形式开发方法只是工具箱里的又一种工具，不要成为方法学的奴隶。
3.注重实效的程序员批判地看待方法学，并从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯。
注重实效的项目
- 注重实效的团队
1.确保每个人都主动地监视环境的变化。可以指定一个“首席水情监测员”。
2.杰出的项目团队有着截然不同的个性，人们希望与他们一同开会，因为他们知道自己将看到准备良好，会让每个人都感到愉悦的演出。
3.有一个简单的营销诀窍，能帮助团队作为整体与外界交流：创立品牌。
4.按照对你的授权，你越接近用户，级别就越高。
5.项目至少需要2个“头”：一个主管技术，另一个主管行政。
6.找一找成功的团队，他们成功的原因是什么？
- 无处不在的自动化
1.你可以决定创建一个shell脚本来完成一些烦人的工作，但你仍然要记得在需要时运行这个脚本。
- 无情的测试
1.使用自动测试的团队成功的机会要大得多。
2.代码在它通过所有可用的测试之前，你不能声称它已经可供使用。
3.一旦你有了可执行的用户界面或原型，你需要回答一个最重要的问题：用户告诉了你他们需要什么？但那是他们需要的吗？
4.性能测试，压力测试或负载测试也可能会是项目的一个重要方面。
5.回归测试把当前测试的输出与先前的值进行对比。
6.你编写了一个测试，你还要故意引发bug，并确定测试会发出提示。
7.覆盖分析工具会在测试过程中监视你的代码，追踪哪些代码执行过?哪些没有？
- 全部是写
1.写注释或文档——把英语当做又一种编程语言。
2.比无意义的名称更糟糕的是误导人的名称。
3.在源文件里应该出现的最重要的信息之一是作者的姓名。
4.现在大多数完善的字处理器都有宏语言，尝试用下宏语言。
5.现在许多技术作者使用DocBook来定义他们的文档。DocBook是一种基于SGML的标记语言。
6.项目的成功是由它在多大程度上满足了用户的期望来衡量的。
- 极大地期望
1.管理期望：主动控制用户对他们能从系统中得到什么应该抱有的期望。
2.随着项目的进展，听取你的用户的意见，了解什么特性会使他们真的高兴。
- 傲慢与偏见
1.我们想要看到对所有权的自豪。“这是我编写的，我对自己的工作负责”。你的签名应该被视为质量的保证。
原文地址：https://www.cnblogs.com/yangzhou33/p/8407427.html