关闭

读别人写的代码 VS 自己写代码

488人阅读 评论(0) 收藏 举报

概述:专业程序员非常重要的一项技能是读别人写的代码,这项技能甚至比自己写代码更重要。

分析:

  这让我想到很多程序员讨厌去阅读代码,来接受它吧。人人都喜欢编写代码--写代码是很有乐趣的事。但阅读代码却是一种困难的工作。它不仅仅繁重,而且很无聊,让我们面对这个事实,任何不是自己写的代码都是差劲的(嘿嘿,虽然我们没有这样说过,但是其实我们都是这样想 的)。甚至当你写完代码后的仅仅几个小时之后,你的那些代码就开始变得越来越烂了,时间一长,你就会把它当作看起来的那种差劲作品。

  所以,你又何必要去花费时间来审视别人蹩脚的代码呢,这段时间你完全可以用来 自己去写一些非常优秀的代码,为什么不这样尝试一下,把自己写好的代码放上几个小时再回头看看,它是否依旧非常优秀呢?如果你不站在前辈们的肩膀上,你将没有可能成一个为技艺精湛的大师。其中一种途径就是亲自找到一个大师,让他把他所有的知识全部传授给你--当然这是有可能的,虽然可能性不高,你必须非常走运才能获到这种机会。然而你可以不用想着去碰运气, 我们很幸运的处在这样的一个职业里--大师们的经验和知识都在那里等着我们去吸收,这些都蕴涵在他们所写 的代码里。你所要做的事就是去阅读它,当然它可能会比找一个人坐在你旁边向你解释这些多占用一点时间,但是这是实现起来可能性较高,透视全局地思考下,若想成为优秀的木匠,你就必需观察大量的拥有优良结构的家具。

  ……

  【未完】更精彩的内容进作者的空间去看吧 >>> [译文]为何我喜爱读他人的代码,而你也应该去喜爱它

以下为两位笔者分享的一些经验,借来展示一下:

标题:说说我对阅读源代码的一些技巧方法,其实这并不难。
作者:afadgaeg
原文:http://afadgaeg.javaeye.com/blog/264490
正文:

  阅读源代码的利弊我不谈,我只说该如何读.

  首先是积累,当到了一定条件,你会迫不及待的想要去读,因为你想拥有程序的控制权 .

  我把一份陌生的源代码比做一个陌生的城市,你将在里面熟悉道路,你只要从一个大的标志开始进入(程序入口点)然后你面临很多分支,有的分支很明显的(依靠设计模式,oo,模块化,结构化,解耦,经验判断,当然还有文档,注释,别人的源码分析文章)与其它没有什么瓜葛,或者只有几个联系点,其实是一个模块化功能,就像你知道有一条路通向xx村,你先不管它,知道它通哪里就可以了,以后再专程访问xx村。

  一个设计优良的程序肯定是一个个通过乡村高速公路连接的村落,而不该是交杂在一起的钢筋水泥,至不济也该是用围墙围起来的一个个小区。

  当你知道并熟悉了城市的主干道之后,整个城市其实已经成竹在胸了

  你该学好模式,oo,模块化,结构化,解耦,接口,多态。。。。
广义来说就是oo

  写给初学的人,以让他们少走不成器的我走过的弯路。

  补充一条找源码分析文章的技巧>>> <b>在google中输入关键的源码片段</b>

  补充一点经验:

  当你读过一些模块之后,看到类似的模块就会下意识的去猜测该模块内部的代码结构,如果你读的够多,实践够丰富,模块就了然于胸了。

  比如看到一个方法名,根据方法的字面意思就能猜测出该方法的代码结构,看到类名,就可能会猜测出它该要有什么方法。 这时读代码的速度就快了。

  代码是一个有机体,当你具有把一份源代码解构成一个有机体的能力的时候,读代码其实并不痛苦。可是我还没有达到我想像的哪个层次。

 

标题:如何读代码?
作者:卢声远<michaellufhl@yahoo.com.cn>
原文:http://blog.csdn.net/michaellufhl/archive/2010/10/09/5930570.aspx
正文:

  有時候在察看开源項目的時候,如果你想參與其中,那項目的负責人基本上都是建议从bugfix開始了解程序,了解代码。所以第一个建议就是从bugfix和添加新功能入手 。事實上在公司參加一個新項目的开发或者维护也大多是從bugfix入手。這樣入手的好處在於可以集中精力去了解以小块代码的運作機制。显然這很符合人的思維規律-做简单的事情总比做复杂的事情來得容易和高效。当然這不是盲人摸象,要bugfix的話至少自己要知道整個軟件的功能和層次,这需要閲读文檔而不是代码。

  说到注释,这个时候就太有用了。不用说是别人写的代码,就是自己几个月前写的代码自己也需要仔细看一下才能搞懂。但是残酷的现实就是注释很少,更残酷的现实是越是低质量的代码,它的注释越是少。怎么办?只能猜 了。如果我们碰到一个很长的方法,但是我们需要跳过去看调它的代码,我们就需要猜测这个方法的功能了。然后再回过头来仔细看那个方法。我们可以运气好的话作者会取很合理的class名,method名和变量名。其实里面有个矛盾:很复杂,内聚很松散的method或者class,它们的名字就根本不可能取得合理。这个道理很简单,一个method里面做了很多事情,你就很难给它取一个合适的名字。像removeUserAndItsClientsAndUpdateTime(), 或者干脆来个缩写removeUCUpdateT()。 这样的名字基本没有可读性。

  还有就是读上层 和读下层 。读上层就是在代码的 高层阅读,碰到底层的API可以猜出它的作用。这样把一块高层的代码像读逻辑那样粗线条梳理清楚,其实就是一大块一大块地读代码。读下层就是把底层的代码if else一一读懂。这两者缺一不可。

  碰到很乱的代码几乎只能利用IDE debug, step by step 得一行一行执行。因为乱,所以没有仔细看整体结构的必要,而最有效的就是step by step了。当然有些时候程序逻辑必须依赖数据库或者外部数据,这样的话光看代码也不行。也只能step by step或者运行时log。

  在OO的时代design pattern也已经深入人心。在看高质量代码的时候会发现他们的代码有个特点就是相当抽象,或者说面向抽象。里面有很多interface, abstract class, 还有anonymous class, 很长的继承链。我认为既然作者写程序的时候面向抽象,那么我们读程序的时候也要面向抽象 。我们经常在读代码察看某个变量的时后用IDE的查看功能点进去,然后发现它是一个接口全无实现。很多时候我们的第一反应就是找到具体的实现类,我倒是认为可以关注这个接口先往下读代码,然后回过头来看实现。既然作者的意图就是让接口来工作,我们就可以先了解作者的意图来看代码。顺便说来,要读懂很抽象的代码,读者自己首先要有很好的OO概念和design pattern的知识。

  精彩文章推荐:今年程序员们解决问题的顺序

0
0

猜你在找
【直播】机器学习&数据挖掘7周实训--韦玮
【套餐】系统集成项目管理工程师顺利通关--徐朋
【直播】3小时掌握Docker最佳实战-徐西宁
【套餐】机器学习系列套餐(算法+实战)--唐宇迪
【直播】计算机视觉原理及实战--屈教授
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之矩阵--黄博士
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之凸优化--马博士
【套餐】Javascript 设计模式实战--曾亮
查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:349227次
    • 积分:3960
    • 等级:
    • 排名:第7869名
    • 原创:40篇
    • 转载:269篇
    • 译文:0篇
    • 评论:38条
    最新评论