《程序员修炼之道》读书笔记

 

编程和其他工程技术一样，是一项充满细节的工作，追踪这些细节需要专注。且要能持续地作出大大小小的改进。

在所有弱点中，最大的弱点就是害怕暴露弱点。

跳到更高的层次思考你的技能和工作。

不要容忍破窗户。当你看到糟糕的设计、错误的决策和混乱的代码时，修正它们。

记住大图景。不要太过于专注细节，以至于忘记了查看你周围都在发生什么。

不要承诺你做不到的事情，这是对别人的不负责任。

用户宁可明天用上有瑕疵的软件，也不想等一年再用上豪华版。让他们尽早使用，他们的反馈会把你引向最好的解决方案。

随着新技术、新环境的发展，你的技术和经验会变得过时，从而对你的客户来说，你的价值也在降低。

你说什么和你怎么说同样重要。

不要重复你自己，系统中每一项知识都必须有单一的、无歧义的表达。

把低级的知识防止代码里，高级的知识放在注释里。

让复用变得容易。尤其是知识和经验的复用更重要。

正交性指不依赖性或解耦性，一个事物的变化不会影响到其他事物。当各组件相互依赖，就不存在局部修正这样的事情，牵一发而动全身。

如果某个想法是你唯一的想法，再没有比这更危险的事情了。

由于我们并非能在一开始就作出最好的决定，所以要保证这些决定的可撤销性。要设计灵活的架构，允许变化的发生。

消除无关事物之间的影响。

不存在最终决策。

用曳光弹找到目标。

靠近问题领域编程。

估算前可去咨询已经做过这件事情的人。

估算涉及到认识问题的语境、理解问题、建立模型来描述问题、找到参数和取值，然后进行计算，不断修正模型和你的估算能力。

工具是工匠双手的延伸。工具放大你的才干。

用纯文本表达知识。

shell比GUI更容易自动化。

源代码控制系统有诸多好处：首先是一个巨大的Undo系统，且可以追踪变动，建立分支等。

精通一种编辑器。

学习一种文本操纵语言。

当发现别人的bug时，要修正问题，而不是发出指责。

发现自己的bug时，不要恐慌。

使你的数据可视化。

log调试记录要采取一致的格式，从而可使用Perl等文本操纵语言来分析它们。

不要假定，要证明。

你不可能写出完美的软件，要适可而止。

契约式设计，结合单元测试。为测试而设计。

如果它不可能发生，用断言来保证它不会发生。

把异常留给意外事件。

配平资源的分配，要有始有终。

动态的配置胜过于静态写死。

分析工作流，改善并发性。

使视图和模型分离。

不要靠巧合编程。

跟踪测试你的估算。

为测试而设计。

抽象比细节活的更长久，在设计上要延迟实现。

英语就是一种编程语言。

把文档建在里面。

温和地超出用户的期望。

 

个人感想

 

有用的道理不一定非得用晦涩抽象的语言来表达，平实易懂的说明更具实用性，配以恰当的实例，更容易让读者领会。
另一方面，无知往往掩藏在看似高深的表象背后，有些人整日搬弄时髦且学术性的词语，其实有可能他连最基本的知识都没有弄懂。

如果不能深入到实现细节，怎样的道理都是没用的。

前期多尝试，无论什么样的计划都要试一试，如果要失败，就早点失败。

保持灵活性，不要拴在一件事物上，这样不仅丧失了主动性，也带来了高风险和僵化。

如果有错误，就让它容易浮现处理，往往设计上和人性上的原因，人们往往会让错误在表面上不可见。

测试，测试，还是测试。科学的、客观无情的测试，才能带来好的产品。测试是技术，更是文化。

事前花2小时说清楚，比事后花1个小时互相指责强。

与人平时打交道要尽努力估计到对方的面子，让对方感觉良好。但与事情打交道的时候，就不要抹不开面子，不要不好意思，否则事情没用做好，大家都丢面子。

如果想要拖延，总会找到一堆非常具有说服性的理由。

承诺少些，交付多些，给他们以惊喜。温和地超出用户的期望。

团队要花时间学习系统的、正规的知识，没有这些知识，就只能靠直觉来寻找解决方案。

把事情作对是很不容易，且很复杂，需要扎实的知识和丰富的经验。自负和拍脑袋往往会带来混乱。碰巧把事情做对是不可重复的。