程序员修炼之道第四章读书笔记与感悟

   程序员修炼之道第四章读书笔记与感悟

与其他工程技术一样，软件工程是一项充满细节的工作，跟踪这些细节需要集中精力。并且能够持续地做出大大小小的改进。

最大的弱点就是害怕表现出来。

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

不要容忍破碎的窗户。当你看到糟糕的设计、糟糕的决策和混乱的代码时，及时修复。

记住大局。不要太专注于细节，而忘记检查你周围发生了什么。

不要对别人不负责任，做出你无法兑现的承诺。

用户宁愿明天就得到有问题的软件，也不愿等上一年才得到豪华版。让他们尽早使用，他们的反馈将引导你找到最佳解决方案。

随着新技术和环境的发展，您的技能和经验会过时，您对客户的价值也会降低。

 

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

 

系统中的每条知识都必须有一个单一的、明确的表达，而不是重复你自己。

 

把低级知识放在代码之外，把高级知识放在注释中。

 

让它易于重用。特别是知识和经验的重用更重要。

 

正交性意味着独立或去耦，其中一个事物的变化不会影响其他事物。当组件相互依赖时，就不存在局部校正，将整个组件拉到一起。

 

Contract: Contract指定了进入函数/方法/模块之前的条件，即进入模块必须满足的条件，通常是指满足模块操作的情况或变量值的范围等。条件后，即模块需要达到的结果，模块运行后能够达到的状态;不变量是对模块上

的约束的描述，在调用模块之前和之后总是为真。

 

合同可以是动态的，“合同代理”可以在不同模块之间协商一组合同，但我不了解这种技术。

 

这是一个好主意，它的优点是，当问题更小、更简单时，代码会在早期崩溃。但是在普通的c, cpp中，这个想法就不那么有效了。有些功能可以通过断言来实现。

 

但是，有了好的文档，您可以描述前置条件、后置条件和不变量，从而实现契约的思想，并在一定程度上获得契约的优点。

 

死机程序不会说谎:一个坏掉的程序会由于不正常的操作而造成很大的损害，所以当出现问题时，崩溃总比崩溃好。利用异常机制。

 

声明性编程:对“不可能的”场景进行断言，以保持系统的健壮性和安全性，防止由坏数据或恶意攻击引起的问题。

 

但是，在断言时要避免添加执行代码和其他有副作用的代码，避免“海森堡错误”:不适当的调试会改变被调试系统的行为。

 

异常:有必要检查每一个可能的错误，特别是在预期的情况下。

 

使用异常来处理真正的异常，而不是作为模块逻辑的一部分。检查这一点的方法是删除异常并查看模块是否正常工作。

 

少许诺，多兑现，给他们一个惊喜。略微超出用户预期。

 

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

 

把事情做好并不容易，它很复杂，需要扎实的知识和经验。自负和拍脑袋往往会导致混乱。靠运气把事情做对是不可重复的。