别怕Linux编程 名书名人

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

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

文章作者为 rocrocket。

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

===

[正文开始]

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

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

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

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

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

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

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

26 用代码沟通

“精确地解释代码做了什么,每行代码都要加注释。不用管为什么要这样编码,只要告诉我们做了什么就好了。”

源代码可以读懂,不是因为其中的注释,而应该是由于它本身优雅而清晰。

要尽量避免使用神秘的变量名。(i常用于循环索引变量,str常用于表示字符串。如果用str表示循环索引变量,可真不是好主意)

在代码可以明确传递意图的地方,不要使用注释。

解释代码做了什么的注释用处不那么大。相反,注释要说明为什么会这样写代码。

27 动态评估取舍

“性能、生产力、优雅、成本以及上市时间,在软件开发过程中都是至关重要的因素。每一项都必须达到最理想的状态。”

与其花费时间去提升千分之一的性能表现,也许减少开发投入,降低成本,并尽快让应用程序上市销售更有价值。

如果现在投入额外的资源和精力,是为了将来可能得到的好处,要确认投入一定要得到回报。(大部分情况下,是不会有回报的)

28 增量式编程

“真正的程序员写起代码来,一干就是几个小时,根本不停,甚至连头都不抬。不要停下来去编译你的代码,只要一直往下写就好了!”

如果不对自己编写的代码进行测试,保证没有问题,就不要连续几个小时,甚至连续几分钟进行编程。相反,应该采用增量式的编程方式。

采用增量式编程和测试,会倾向于创建更小的方法和更具内聚性的类。你应该经常评估代码质量,并不时的进行许多小调整,而不是一次修改许多东西。

在写了几行代码之后,你会迫切地希望进行一次构建/测试。在没有得到反馈时,你不要走的太远。

29 保持简单

“通过编写史上最复杂的程序,你将会得到美誉和认可,更不用提保住你的工作了。”

Andy曾经认识一个家伙,他对设计模式非常着迷,想把它们全都用起来。有一次,要写一个大概几百行的代码程序。在被别人发现之前,他已经成功将17种设计模式,都运用到那可怜的程序中了。—这不应该是编写敏捷代码的方式。

问题在于,许多开发人员倾向于将投入的努力与程序复杂性混同起来。如果你看到别人给出的解决方案,并评价说“非常简单且易于理解”,很有可能你会让设计者不高兴。许多开发人员以自己程序的复杂性为荣,如果能听到“Wow,这很难,一定是花了很多时间和精力才做出来的吧。” 这时,他们就会面带自豪的微笑了。其实应当恰恰相反,开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。

简单不是简陋。

30 编写内聚的代码

“你要编写一些新的代码,看看IDE中现在打开的是哪个类,就直接加进去吧。如果所有的代码都在一个类或组件里面,要找起来是很方便的。”

内聚性用来评估一个组建(包、模块或配件)中成员的功能相关性。内聚程度高,表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话,表明各个成员提供的功能是互不相干的。

类也要遵循内聚性。如果一个类的方法和属性共同完成了一个功能,这个类就是内聚的。

不过,不要把一些东西分成很多微小的部分,而使其失去了实用价值。当你需要一只袜子的时候,一盒棉线不能带给你任何帮助。

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

over~

发表您的评论

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