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