陈太汉:软件随想之编写出色的代码

来源:陈太汉

1:写不易出错的代码

第一次听说“写明显没有什么错误的代码”时,我觉得这个说法很新鲜,让我记忆深刻。其他的很多观点听得我耳朵生茧,基本都是左耳进右耳出。明显没有什么错误的代码肯定是思路清晰、很容易理解的。而要做到这点很难,牛人才能写出牛叉的代码,要做到这一点要有足够的阅历和实战,只能当做目标啦,哪天也和云风一样:今天完成了XX功能,代码明显没有什么错误。现在还不知道明显没有什么错误的代码是怎么样的,但我知道很多代码让我半天不知所云。如从类名和方法名看不出其职能;变量命名让人蛋疼;不对参数做任何验证;参数到处都是都是基本类型;方法参数十几个;一个方法几屏;不能适应半点变化的方法;要么没有注释,要么一堆废话;排版稀烂。这些都是不好理解,半天找不到问题的代码,也是容易出错的代码。

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

 

 

2:写容易查错的代码

一直想写很干净的代码,代码除了功能没有多余的代码,但是代码必须有日志,如果代码没有日志,要是出错了,查错肯定很麻烦,有时候真的是无从下手,一个功能涉及到一堆的模块,要想很快的定位错误,就必须记好日志。越清楚越好,程序执行到哪一步,当前的状态最好都要记下来,日志不在多,清楚记录有效的日志非常重要,过多无效的日志不方便查看,而且对于快速定位错误的位置没有任何帮助。如果日志都记录在文本文件中,最好能写一个分析日志的工具。可能是我写的和维护的代码太容易出错了,个人觉得记好日志真他妈重要。一看到日志就能知道出了什么问题那不是一般的爽,当然听说又出问题了让人郁闷。我以前所在的一家公司记录日志的方式是在很多类中都定义一个int类型的成员变量,每隔几行让它自增1,将这个值记录起来,当出错了就能大致估计是哪几行出错了。这种方法虽然有点蹩脚,代码中到处是这个变量,但的确能帮助我们快速定位错误的位置,日志的作用就是保存案发现场,只有记录犯罪分子作案的过程才能更好的抓住它。

 

3:写扩展性好的代码

“今天说要这样,明天说要那样,在上线的前一天说:还是觉得开始的做法是最好的”。而我们程序员总是为这种人2B的想法买单。写扩展性好的代码真的就是不仅要满足需求还要超越需求。我们到处可以听到这样的口号,当然很多情况下是这样的人自己都不知道需求是什么。最让人无语的是菜鸟提需求,我来实现。杀了我吧。但现实是杀了我之前我先要满足他的需求。当这种需求像滔滔江水绵延不绝的袭来时,我想到了四个字:生不如死。既然死不了,生活还得继续。代码还是要做到超越需求(你说这世界对程序员要求怎么就这么高呢),要做到这点难啊,我们是帮别人实现梦想的开拓者。前途是光明的,道路是坎坷的,现实是残酷的,代码必须是扩展性好的。当然这里所说都是人为因素。

还有就是项目的需求本来就是变化的,或者说你现在完成的是一期,还有二期,三期……,你在做的时候就必须考虑这些情况,不要把代码写死。我以前总是想:这个可能以后不会变化,可以写死,少一个参数,少一个变量性能会更好写。其实性能的提升相当于一个千万富翁突然多了几毛钱。但是要是以后需求变了,你就得改写代码,还得担心是否会出问题。有时候我就有点怕重构,就怕一个好的功能,被重构坏了,当然也和时间紧,测试不专业有关。写扩展性好的代码别在乎所谓的那点性能,那真的就是九牛一毛不值一提。一个项目维护时间久了,发现那些本来看是不变的很多都变了,而代码也被改了很多次,每一次修改就要做一堆本来没有必要的事情(修改代码,写测试说明,送测,协调上线,而这些沟通时间也不少,真叫一个低效浪费时间),如果能考虑到可能发生的变化,写好代码,效率会高很多,这一点就能体现高手和菜鸟的区别。

 

4:写高性能的代码

这是我一直渴望的(我当然也会说是我还没有做到的)。我觉得要写出高效的代码首先要非常明白你要实现的功能,将功能分析得很透彻,你找到了解决方案,回想你的实现,如果你的思路非常清晰,你就大致知道每一步是否够好,大致知道你的代码是否高效,或者更进一步说,你确定这就是最优解;如果功能实现了,但是你对自己实现的功能不是很了解,记忆模糊,那肯定不是最优解,你肯定会对自己不是很清楚的代码不放心(我经常是这样),就别谈性能,是否正确都待定。很多高效的代码都很简洁,容易理解,而有些代码总让人看起来很郁闷,如一堆看起来类似的代码实现一个很简单的功能。用数组和一个循环经常能将这样的代码简化,让你轻松实现简洁容易理解的代码,或许它不是最高效的。82法则告诉我们,我们应该对影响系统性能的20%的代码进行优化,而不应对其他的80%的代码耿耿于怀。20%影响性能的代码应注重性能进行优化,而其他80%则更多应该考虑理解性,扩展性等。

 

高手的代码特点有很多,很多优点是并存的。上面只是我个人认为最重要的四点。

 

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部