别怕Linux编程 名书名人

《高效程序员的45个习惯》-之八

原创文章属于《Linux大棚》博 客,博客地址为http://roclinux.cn

文章作者为 rocrocket。

为了防止某些网站的恶性转载,特在每篇文章前加入此信息,还望读者体谅。

===

[正文开始]

请您在阅读本文之前,先了解

《高效程序员的45个习惯》-之一

《高效程序员的45个习惯》-之二

《高效程序员的45个习惯》-之三

《高效程序员的45个习惯》-之四

《高效程序员的45个习惯》-之五

《高效程序员的45个习惯》-之六

《高效程序员的45个习惯》-之七

每一期都会涉及5个话题,用9期来列出这45个习惯,每次不贪多,贪精,大家如果有空,一定要细细品味这5个习惯。

注意:每一个好的习惯,开头都会相应有一个唱反调的句子哦。

31 告知,不要询问

“不要相信其他的对象。从别人那里去拿你需要的信息,然后自己处理,自己决策。不要放弃控制别人的机会”。

告知=命令,询问=查询
命令和查询相分离模式,就是要将功能和方法分为命令和查询两类,并在源码中记录下来,以做到将命令代码都放在一起,并将所有查询代码都放在一起。
绝对不能允许一个看起来无辜的“查询”去修改对象的状态。

32 根据契约进行替换

“深层次的集成是很棒的。如果你需要其他类的函数,直接继承它们就好了!”

保持系统灵活性的关键方式,是当新代码取代原有代码之后,其他已有的代码不会意识到任何差别。
如果你不确定一个接口做出了什么样的承诺,或者有什么样的需求,那就很难提供一个对其有意义的实现了。

33 记录问题解决日志

“在开发过程中是不是经常遇到似曾相识的问题?这没关系,以前解决过的问题,现在还是可以解决掉的。”

面对问题是开发人员的一种生活方式。当问题发生时,我们会希望记起第一次是如何解决的,而且希望下次能够更快地把它搞定。但是,有时我们又记不清上次是如何修复的了。
不要在同一处跌倒两次。
要想得到更好的效果,不妨维护一个保存曾遇到的问题以及对应解决方案的日志,我们称之为每日日志(daylog)。
可以选择符合需求的任何格式,下面的内容可能用得上:

  • 问题发生日期
  • 问题简述
  • 解决方案详细描述
  • 引用文章或网址,以提供更多细节或相关信息

任何代码片段、设置或对话框的截屏,只要它们是解决方案的一部分,或者可以帮助更深入地理解相关细节。
务必要将上述信息变为计算机可搜索的格式。

34 警告就是错误

“编译器的警告信息只不过是给过分小心和过于书呆子气的人看的。它们只是警告而已。”

有些警告是过于挑剔的编译器的良性副产品,但有些则不是。例如,一个关于未被使用的变量的警告,可能不会产生什么恶劣影响,但却有可能是暗示某些变量被错误使用了。
签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。

35 对问题各个击破

“要调试一个明显的错误,只要去查看整个系统的代码,而且是要全部过一遍。毕竟你不知道问题可能发生在什么地方,这样做是找到它的唯一方式。”

单元测试带来的积极效应是它会强迫形成代码的分层。要保证代码可测试,就必须把它从周边代码中解脱出来。
认识复杂问题的第一步,是将它们分离出来。
很多应用的代码在编写时没有注意到这一点,使得分离变得特别困难。应用的各个构件部分之间会彼此纠结:想把这个部分单独拿出来,其他的会紧随而至。在这些状况下,最好花一些时间把关注的代码提取出来,而且创建一个可让其工作的测试环境。

敬请期待:《高效程序员的45个习惯》-之九

over~

发表您的评论

请您放心,您的信息会被严格保密。必填项已标识 *