写什么样子的代码？

 

        最近领导不知道抽哪门子风，突然要求我们注重代码质量，每天都进行代码评审. 让我们感觉突然一下子代码质量完全主宰了我们的声明似地,搞的一惊一乍的.

       当然近期也在领导“辛勤的辅导下”了解了很多谢代码应该注意的规范.

 

1：写的代码不能有明显的错误

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

 

2：写容易查错的代码

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

 

3：写扩展性好的代码

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

 

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

 

4：写高性能的代码

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

评论

24 楼 justice_jl 2012-05-24  

……相当理解你了。。
遇到那种傻B组长和客户谈需求最无语。。
根本不按照产品本身的功能和框架本身的局限性来。
总是想一出是一出，TMD 动不动客户没要求加功能，这B，自己给你提新功能点，然后吧，需求咋告诉你的呢？没有邮件，没有文档。就是口述…… 然后4个需求告诉你一个，我开始研究，开始想，开始写。TMD半个小时，之后来告诉我第二个需求，我TMD脑子里刚有点想法，全被打乱了，你还得听，不然人家不愿意~。然后讲完了回去了，15分钟后过来和你说第三个，第四个可能是没到10分钟，我就急眼了，我说咱一个一个来不行么！
遇到这种SB头和领导真无语，我很理解你。。
至于说的性能：草，就是JB坑爹的，框架，代码底层的东西都TMD的是各种循环套循环迭代的，让我们上面改JB毛，咋改能提高性能？有些东西能改，有些东西就算改了，也 提高不了多少性能，为啥？那些架构师和产品研发的最清楚~
一个SSH 面对奇葩的SQL和大数据量 高并发的性能测试，想想就可乐。
最搞的是 TMD加班没加班费 人家加班到9点，我刚开始都加班到10点以后，为了做贡献，也为了多学点东西，新人么。现在想想自己真的好SB。。人家头不领情。。所以现在离开那个项目组了，也不加班了。感觉世界真好，合计跳槽了。
跟这种团队，说实话，只能埋没了你。。
其实我们那个项目组都挺好的，只不过俩奇葩都让我遇上了，主要是我的那个组长奇葩。一个35+的大老爷们，一个实施，做了这么久了就是个普通的实施，总幻想着我们的系统应该有什么~还行，他不玩魔兽世界，不然真要我给系统添个那东西，我感觉我还真做不来。
有时候客户和顾问都说没必要做。这SB经常跟客户争，非要做，我花了好久做好了，把影响的很多地方都改了。结果 最后评审，人家客户没说呢，这B说不要了~你删了把，我操了，好在有SVN，不然咋JB改回去。。
还有，人家觉得你不行，是啊，我刚进项目组时刚毕业，不是人家理想中的牛人。
人家对牛人的定义是：哦，一般技术好的，都不用连数据库，盲写，自己想里面是啥东西。
给接替我的和我一起来的同事干崩溃了~
没接触的模块 业务都不清楚，是不是得跟跟代码，看看怎么回事？
还有测试时，让你拼SQL，做假数据。然后呢，库不一样，一些外键的值不一样（人家别的组的都是自己手动点功能建，这B很懒，让我来），你拼好了SQL，给他，他不会用，甚至不知道哪是啥，我说这是SQL语句，然后我回去了，他过了5分钟，问我，这个咋用。我当时就无语了，我说，你CTRL+C,CTRL+V 然后按F5…… 等等~

23 楼 pincoo 2012-05-24  

[color=brown][/color]

引用

[code="

• java

[img][/img]"]

22 楼 yuhuarengo 2012-05-24  

      

21 楼 showing_me88 2012-05-24  

     

20 楼 aniyo 2012-05-24  

我们现在公司更扯淡，每周要求提多少代码，没得代码自己就写单元测试，或者从其他地方找个工具类，放上去，还不能构建失败，不然你就悲剧了。

19 楼 viMory 2012-05-24  

写什么样子的代码，是最呀最摇摆

18 楼 mixer_a 2012-05-23  

17 楼 idealwangqing 2012-05-23  

我写代码时，也很注意这些方面，但自己做的远远不够。继续努力！
同时在51cto.com上看到一篇标题不现，内容相同的文章。http://developer.51cto.com/art/201205/337519.htm

16 楼 古尔德 2012-05-23  

呵呵，这是编程规范么？

15 楼 lyunabc 2012-05-23  

说的不错呀

14 楼 mysaber 2012-05-23  

对于第三点深有感触。。。。

13 楼 shaka 2012-05-23  

说到人心坎里去了，深有感触诶，尤其是第二点debug日志，发现公司里没多少人有这意识

12 楼 qiyang199132 2012-05-23  

我们公司两个字，烂，乱。

11 楼 xiaolei0228 2012-05-23  

对现在的代码不做评价...

10 楼 com_xpp 2012-05-22  

我们公司没质量，连设计都没有，何来代码质量

9 楼 zcy860511 2012-05-22  

我们公司没质量，连设计都没有，何来代码质量

8 楼 llh110220 2012-05-22  

一开始，偶还很注意代码的，现在，给项目折腾的，偶都不管饿了

7 楼 miao19880124 2012-05-22  

哈哈  刚开始还进行 代码审查 现在都不查了  对代码审查 表示无压力

6 楼 Mybeautiful 2012-05-22  

呵呵，说的话很好啊。
时而就会看到“明显有错误的代码”...

5 楼 TheMatrix 2012-05-22  

偶只关心有没把代码给我排整齐咯，命名是否规范，不然鬼看得懂。