程序员修炼之道第四章读书笔记与感悟
程和其他工程技术一样，是一项充满细节的工作，追踪这些细节需要专注。且要能持续地作出大大小小的改进。
在所有弱点中，最大的弱点就是害怕暴露弱点。
跳到更高的层次思考你的技能和工作。
不要容忍破窗户。当你看到糟糕的设计、错误的决策和混乱的代码时，修正它们。
记住大图景。不要太过于专注细节，以至于忘记了查看你周围都在发生什么。
不要承诺你做不到的事情，这是对别人的不负责任。
用户宁可明天用上有瑕疵的软件，也不想等一年再用上豪华版。让他们尽早使用，他们的反馈会把你引向最好的解决方案。
随着新技术、新环境的发展，你的技术和经验会变得过时，从而对你的客户来说，你的价值也在降低。
你说什么和你怎么说同样重要。
不要重复你自己，系统中每一项知识都必须有单一的、无歧义的表达。
把低级的知识防止代码里，高级的知识放在注释里。
让复用变得容易。尤其是知识和经验的复用更重要。
正交性指不依赖性或解耦性，一个事物的变化不会影响到其他事物。当各组件相互依赖，就不存在局部修正这样的事情，牵一发而动全身。
合约：合约约定了进入一个函数/方法/模块的前条件，即进入模块必须满足的条件，常常指满足模块运行的情景或变量取值范围等等；后条件，即模块需要达成的结果，模块运行之后所能达到的状态；不变量，是对于模块的约束，在调用模块前后始终为真的一些描述。
合约可以是动态的，由“合约代理”在不同模块之间协商出一套合约，但我不知道相应技术。
这是一个很好的想法，其优点在于让代码早崩溃，此时问题更小更单纯。但是在常用的c、cpp中这个想法并没有那么可行。可以通过断言实现一部分功能。
不过通过良好的文档，可以对前条件、后条件、不变量进行描述，从而达到合约的想法，一定程度上获得其优点。
死程序不说谎：一个出现问题的程序可能会因为异常操作造成很大的破坏，所以运行出现问题时，崩溃好于破坏。要利用异常机制。
断言式编程：对于“不可能发生”的情况进行断言，以保证系统的健壮与安全，以免因错误数据或恶意攻击出问题。
然而断言时要避免加入执行代码及其他有副作用的代码，避免“海森堡bug”：不当调试改变了被调试系统的行为。
异常：检查每一个可能的错误，尤其是意料之中的错误是有必要的。
要将异常用于真正异常情况的处理而非模块逻辑的一部分。检查这一点的方式是去掉异常，观察模块能否正常运作。
承诺少些，交付多些，给他们以惊喜。温和地超出用户的期望。
团队要花时间学习系统的、正规的知识，没有这些知识，就只能靠直觉来寻找解决方案。
把事情作对是很不容易，且很复杂，需要扎实的知识和丰富的经验。自负和拍脑袋往往会带来混乱。碰巧把事情做对是不可重复的。
标签：感悟,断言,读书笔记,代码,知识,程序员,模块,合约 From： https://www.cnblogs.com/2351920019xin/p/16845688.html