zoukankan      html  css  js  c++  java
  • 如何能出令自己满意的代码

    640?wx_fmt=jpeg

    1. 数据结构和核心算法

      关于数据结构的重要性,大神Linus Torvalds讲过这样的话,我觉得非常赞同:”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” (低水平程序员总在考虑代码,高水平程序员总在考虑数据结构及其之间的关系)

      数据结构考虑清楚了,核心的算法自然就出来了,这就是关于每个类的每个方法如何实现的问题。比如需要实现一个中位数查询方法,如果你前面确定了数据保存的格式是一个列表,那么你可以考虑采用插入排序法;如果数据格式是自平衡二叉排序树(AVL),则只需直接返回根节点就可以了。

      数据结构决定算法,所以你在考虑数据结构的时候,一定要尽可能地使数据的结构和它的自然属性相匹配,不然后面的实现就会是一场噩梦。比如,你把一个多层级的结构定义成二维数组,看上去也靠谱,相当于在一个表格里维护一个组织结构图,可是当你做到部门增减的时候,本层级的数组元素移动自不必说,下面各个层级的元素移动就很容易乱套,而且性能很差,可能你写了2000行代码还有很多边界条件会出错。相反,如果用一个孩子兄弟链表来表示这个树型结构,操作起来就非常容易,可能100行都足够了。

    2. 功能实现

      思路确定后,实现过程也需要大量的构思活动。碰到你比较熟悉有经验的领域,你自然可以轻车熟路,但难免会有一些你不太熟悉的技术需要尝试。有的同学比较排斥这种领域,比如我好不容易才掌握了Struts 2,领导又让我去学习Grails框架,我就会觉得很不爽,大概看了看就挑出它的一堆问题,然后能躲多远就躲多远。可是我要说,这样的心态会阻碍自己不断提高技术水平。作为一个程序员,最大的挑战也是最大的乐趣所在,就是不断学习新的技术,没有这样的心态,很快就会落后。

      好,那么遇到不熟悉的技术怎么办?我的体会是,先不要急着实现项目中的代码,自己另外维护一个测试项目,在里边边查文档边学习,边做一个小功能,把所有需要在项目中实现的功能先在测试项目里跑通,然后再写项目里的代码。这样做的好处是把单个技术问题和其他潜在的bug隔离开来,便于快速学习新技术。否则,你直接在项目里写代码出错以后,要判断问题的源头都要多费好几倍的精力。

    3. 测试

      测试很重要,设计测试用例就像开发时设计数据结构一样,也是很关键的。在设计测试用例的时候,要把当时自己设计数据结构的思路全部忘掉,或者找别人来设计测试用例,不然会不由自主地测试那些你已经考虑到了的地方。这样测试是跑通了,用户一用起来可能各种边界条件会到处出问题。

      有人会推崇TDD的方法,先设计好测试用例,然后在开发过程中确保所有测试通过。我个人不喜欢这种方法,虽然承认从开发质量管理和长期维护的角度来说TDD是很有必要的,但我个人尝试的结果是,设计完测试用例后,想到开发的目标不是实现功能,而是为了跑通测试,就感到毫无乐趣可言。这一点我自己也觉得很矛盾。

      写到这里我又想到大神Linus说过的另一句话:”Regression testing” What’s that If it compiles, it is good; if it boots up, it is perfect. (“回归测试”?这是什么东西?如果代码能编译就是好的,如果它启动了,那就是完美的。)
      当然了,大神水平摆在那里,他有资本目空一切,咱确实没资格仿效。但是我还是觉得TDD也有TDD的问题,测试是很重要,但把它摆到驱动开发的高度,就有点本末倒置了。这个是我自己的一点看法,本人对TDD了解得不深入,如果有谬误之处,请多多指教。

    4. 代码可读性

      要想自己满意,代码的可读性一定要好。要做到一年后甚至几年后你拿到自己写的代码,还能很容易看明白当时的思路和实现。这就涉及到命名和注释的问题。

      命名就像超市里的商品标签一样,要让看得人一目了然就知道这是个什么东西,比如你在员工类里定义了两个属性是到岗日期和离职日期,定义成date1和date2就没有多少可读性,定义成dateOnBoard和dateQuit就比较清晰一些。

      注释也是很重要的,它可以用来说明一段代码的作用,算法的设计思想,或者是方法调用的参数格式要求等。有人觉得命名就是注释,代码本身就为自己代言了。我觉得这种说法用来强调命名规范的重要性是很好的,但是因此说不需要注释则有失偏颇。试想,如果Dijkstra首次发明最短路径算法的时候,他给出的代码里没有一行注释,即使所有的变量命名都定义得准确而严谨,又有几个人能看懂他的算法呢?所以,在重要或者复杂的地方,都需要详细地写一些注释,便于看代码的人清晰地了解你的思路。

      最后总结一下:要想写出自己满意的代码,首先不要急于动手,要先仔细想清楚思路性的东西,尤其是数据结构,然后在实现过程中大胆尝试小心验证,设计好测试用例,确保代码的可读性,就可以在代码中表现出自己的最高水平。但毕竟各人水平是有差异的,自己满意并不等于其他人欣赏。我对此的看法是,不求尽如人意,但求无愧我心,足矣。最后再


  • 相关阅读:
    SentiAnalysis
    大数据索引技术 B+ tree vs LSM tree
    Regression, 回归问题
    Data Mining with R
    Why Vector Clock are Easy or Hard?
    How to know what an HRESULT code means?
    如何判断数据库表的某个列上有重复值的记录存在?
    关于SharePoint 2010里Servers in farm页面里status意义的澄清
    SharePoint Security系列 之二 CrossSite Request Forgery
    从MOSS2007升级到SharePoint2010后Report Server content types升级失败
  • 原文地址:https://www.cnblogs.com/hgmyz/p/12351050.html
Copyright © 2011-2022 走看看