你的分享就是我们的动力 ---﹥

我现在是这样编程的

时间:2013-06-17 14:43来源:www.chengxuyuans.com 点击:

注:文中图片均来自网络

 

我在做什么

曾经,我试过接到一些需求。一眼带过后,脑袋马上随着高昂的斗志沉溺在代码的世界中 ,马不停蹄地敲着键盘直到最后测试的完成。我从思绪中恢复过来,乍一看自己写的功能,和需求差了十万八千里,我TM都在干嘛?

除此之外,我还见过类似的很好笑的事情。有一个程序员,经理提了需求,然后他在那里折腾了一天。结果不但没做出来,而且和实际需求都是完全搭不上调。经过询问发现,他不知道经理说了什么,也不知道自己到底在做什么。

代码的世界可能是昏天暗地的,但是我们的思维不能这样随之混乱,否则一切都会前功尽弃。所以我现在编写程序的时候,经常会想一下:我要做什么,我在做什么。更好的方法是把详细需求落实到文档,并时刻核对文档。

 

 

大局为重

2-8法则告诉我们,一个项目核心的功能只有很少,其它大部分都是对核心功能辅助或增强的。但当任务分发下来,我手头总有一些自己很想开发的模块,不过它们不属于那20%。我以前经常会在这些感兴趣的模块上花费很多时间和精力。

结果项目快要到上线期限,主要的功能却没开发完成,其它一些不起眼的功能却做得很好,但为此项目不得不延期了。如果反过来,只要对整体功能预期不会有太大偏差,可以将就的先上线。重要一点是:即使功能还有遗漏,但项目可以上线了,老板自然不会太追究,自己工作也能图个安心。如果不知道那些功能模块是最重要的,先问问经理。

人总是喜欢做一些自己感兴趣或者有挑战的事。不过在这方面,为了项目和团队着想,应该尽量压制这种诱惑。

 

 

性能永远不是优先考虑的问题

我从来不会一开始就考虑性能问题。如果项目成本很低,甚至到项目结束时,如果没有感觉到明显的性能问题,也不会去管。要知道现在已经不是DOS的年代,CPU的计算能力很高,但成本很低了。重要一点是,如果只针对提升性能对代码做改动,很容易破坏代码的复用性和可维护性。而返过来,提高了代码的复用性和可维护性,则很容易提高性能。

下面有一个PHP的代码实例,功能是帮助用户重置密码(代码为了简单说明问题,请不要太在意一些无关的细节)

requestResetPassword是接收用户重置密码的请求并且做了相应的检查。为了更好的复用性,我将重置密码的操作单独分配到一个新的resetPassword的函数,更改完密码的后再调用sendEmail向用户发送一封通知邮件。

/**
 * 用户请求重置密码的接收器
 */
function requestResetPassword() {
    //检查用户是否存在
    if( !checkUserExists( $_GET['userid'] ) ) {
        exit('抱歉,用户不存在,请确认用户帐号。');
    }
    resetPassword( $_GET['userid'] );
    //最后向用户发送一封邮件
    sendEmail( $_GET['userid'], '重置密码成功', '新的密码是xxxx' );
    exit('新密码已经发送到你的邮箱。');
}


/**
 * 帮助用户重置密码
 */
function resetPassword( $userid ) {
    //检查用户是否存在
    if( !checkUserExists( $userid ) ) {
        return false;
    }

    //进行重置用户密码的操作
    //略...
    return true;
}


/**
 * 向用户发送一封邮件
 */
function sendEmail( $userid, $title, $content ) {
    //检查用户是否存在
    if( !checkUserExists( $userid ) ) {
        return false;
    }

    //发送邮件操作
    //略...
    return true;
}


/**
 * 检查某个用户是否存在
 */
function checkUserExists( $userid ) {
    $user = getUserInfo( $userid );
    return !empty( $user );
}


/**
 * 获取某个用户的数据
 */
function getUserInfo( $userid ) {
    //假设我有一个query的函数,它用来查询数据库并返回数据
    $user = query( "SELECT * FROM `user` WHERE `uid`=" . intval( $userid ) );
    return is_array( $user ) ? $user : array() ;
}

现在问题是,这三个函数都同时使用checkUserExists这个函数来检查用户不存在,数据库查询了三次,这样带来了一些额外的开销。

如果要去掉三者之间任意一个checkUserExists,看上去是可能的。但是如果之后有某些功能要调用resetPassword或者sendEmail,用户不存在时,系统可能会发生错误。

还有一个解决方法是,将resetPassword的逻辑写到requestResetPassword里,再过一点,把sendEmail的逻辑也写进去。这样函数调用减少,数据库查询也变成一次了,性能得到了提高。但是重置密码和发送邮件的功能将不能得到复用,并且违背了单一责任的原则,代码复杂度也提高了。


不过,因为函数分离和复用性都很好,如果实际性能受到影响,可能考虑用缓存的方法减少数据库查询,我改动了它们共用的checkUserExists函数:

/**
 * 检查某个用户是否存在
 */
function checkUserExists( $userid ) {
    //增加一个缓存,用以记录检查用户的结果
    static $cache = array();

    //检查当前用户是否已经检查过一次
    if( isset( $cache[ $userid ] ) ) {
        return $cache[ $userid ];
    }

    $user = getUserInfo( $userid );
    //把结果记录到缓存中
    $cache[ $userid ] = !empty( $user );

    return $cache[ $userid ];
}

也可以用同样的方法改动getUserInfo函数。

这里可以看到,当代码的复用性提高时,想提高性能是很简单的,性能的瓶颈也很容易被发现和修改。

尽管这个例子对性能影响还不够大,还有一些影响更大的,比如说遍历,我可能为了复用而将遍历封装到一个函数中,并且多次使用它。这些开销对我的项目根本没有预想中那样有太大的影响,或者说是微乎其微的。所以我更愿意把时间花在如何提高代码的复用性和维护性方面,而不是纠结于浪费多这一点性能。实际性能如果真的达不到要求,也可以权衡增加硬件配置。

 

 

名字长一点好

函数名和变量名等除了给机器看,也要给人看的,有时一个简单直接的好名字实在是很难想,这时不妨用长一点的名字更好。可读性更好:

//好名字
class ErasedTypeEquivalence {
}

//坏名字
class ErdTypeEqe {
}

//好名字
function checkUserExists () {
}

//坏名字
function ckUserExt() {
}

//好名字
$result;

//坏名字
$ret;

我见过一些代码,由于简单写过多,整遍代码很多都是4个字母或以下的,可读性非常差,当然不排除是为了偷懒。

但如果想有更多的时间腾出来偷懒,不应该在这上面玩小聪明,否则这时我现在应该在思考前几天的代码是在写什么。

什么?短名字会让代码执行得更快? 那证明给我看,如果真的快,快了多少?

 

 

自说明代码很重要,但注释同样重要

代码本身可以说明问题的确是很棒的,但并不是说注释不重要,有时候我更喜欢先看注释,因为它总比我看代码更快的了解这程序是做什么的。

如果我把本文前面说性能的例子去掉注释,哪个能让你更快了解代码的意图?或者说,你更愿意看哪个?

function requestResetPassword() {
    if( !checkUserExists( $_GET['userid'] ) ) {
        exit('抱歉,用户不存在,请确认用户帐号。');
    }
    resetPassword( $_GET['userid'] );
    sendEmail( $_GET['userid'], '重置密码成功', '新的密码是xxxx' );
    exit('新密码已经发送到你的邮箱。');
}


function resetPassword( $userid ) {
    if( !checkUserExists( $userid ) ) {
        return false;
    }

    //进行重置用户密码的操作
    //略...
    return true;
}


function sendEmail( $userid, $title, $content ) {
    if( !checkUserExists( $userid ) ) {
        return false;
    }

    //发送邮件操作
    //略...
    return true;
}


function checkUserExists( $userid ) {
    static $cache = array();

    if( isset( $cache[ $userid ] ) ) {
        return $cache[ $userid ];
    }

    $user = getUserInfo( $userid );
    $cache[ $userid ] = !empty( $user );

    return $cache[ $userid ];
}


function getUserInfo( $userid ) {
    $user = query( "SELECT * FROM `user` WHERE `uid`=" . intval( $userid ) );
    return is_array( $user ) ? $user : array() ;
}

所以,即使代码本身很清晰,但是加上注释的话,可读性也能提高很多!

 

 

适当抽象

编程就是为了解决实际中的问题,在思考如何编码的时候,把问题抽象到一定的高度去思考,更容易把握问题所在。不过更多时候,我发现从代码抽象到现实的例子是有一定难度的,同时我也相信,编程高手也是抽象高手,他们很容易把问题反映到真实生活中去。

不过如果经常留意和思考生活中的细节,会提升自己的抽象能力。

举一个螺丝刀的例子,如果叫你造一个螺丝刀,你会做成什么样子?我这里有三把不同的螺丝刀:

 

显然第一种螺丝刀是最简单的,比较中规中矩。

第二种螺丝刀中间可以旋转刀柄,让刀柄和刀头成90度,这样的设计让拧螺丝更加轻松。

第三种螺丝刀则可以更换刀头,如果以后有其它类型的螺丝,则只要造一个适合这种螺丝的刀头就可以了。

 

那反映到编程中的问题,如果项目要增加一个工具类库。

第一种方法,可以直接把类库的所需功能写出来就可以了。

第二种方法,不但把类库写出来,而且针对项目的一些情况做特殊改进,使得在这个项目中更好用。

第三种方法,根据类库的特性,把公共部分的逻辑做成接口,特殊的部分分离出来单独实现,如果以后要增加相同类型的类库,则实现特殊部分的逻辑,然后接入接口即可。

 

但是在抽象的时候,要避免不合理的抽象,有时也可能造成过渡设计,现在只需要一种螺丝刀,但你却把更多类型的螺丝刀都做出来了(而且还是瑞士军刀的样子。。):

 

 

一致性

团队开发中,可能每个人的编程风格都不一样,拿花括号来说,有些人喜欢和代码在同一行,而有些喜欢独自一行

//例一
function func() {
}

//例二
function func()
{
}

命名风格也都不一样,比如说声明变量接收一个函数返回的数据,有些喜欢用result,有些喜欢用data。

它们可能都很好,不过在团队开发中,尽量统一用同一种风格能够很好的减少交叉开发的成本。

 

将错就错

面对项目一些无关紧要的分歧或错误,应该要接受和理解。承接上面的问题,如果团队中已经有人大量用了data的变量命名,但你认为result的更符合当前状况的描述。这种情况,我优先选择data命名,因为如果再使用result的话,会破坏项目的一致性,对开发没有任何好处。

这只是很少的一方面,如果项目规范没有很好的落实,实际工作中会有大量的一致性问题,必须靠团队每个人的决心和责任心去把它做好。通常,加入一个正在开发中的项目,编写功能前,我都会首先看项目之前的类似的代码,并尽量模仿他们的写法。不过,如果有明显的错误,应该及时指出和修正。

只要坚持把一致性做好,很多方法会成为团队甚至业界的标准,即使它们不是最好的,但是有什么关系呢?

 


质量至上

现在还有人认为把时间花在提高代码质量上会降低开发进度。如果你有开发一个长期项目,最后花在修BUG的时间占整个项目的比例是多少?一个质量把握不好的项目,修BUG的时间可能占项目50%甚至更多。如果有兴趣,或者可以看一看这篇文章《不要再问效率还是质量的伪命题》的观点,如果还不够说服力,《人月神话》《代码大全》这两本关于项目管理的书,里面有详细说明这个问题。



适当休息

编程的时候如果没有思路或者感到混乱,到外边休息10分钟,或者看一下风景,让脑袋清醒一下是很好的。这招很管用,亲测。

 

 

至少把代码完整运行一次

有时函数的逻辑过于简单,以至于会认为这个不可能发生错误,但事实上最容易发生错误的通常就是这些代码,常见的单词拼写错误,参数错误,还有一些意料之外的问题。所以无论什么情况,我都会把代码完整运行一遍。

当然更好的做法是用一些系统的测试方法,比如说单元测试。

 

 

编程不是艺术 

从一开始,编程语言的出现和发展,都是为了解决现实生活中的问题,包括它自身产生的问题。

面向对象、设计模式的出现,是用来解决编程语言自身带来的可读性和维护性等问题,而不是为了让编程语言上升到艺术的层面。尽管编程中有‘优雅’一词,但我更认为它只是用来形容代码更容易让人读懂和维护。

我拒绝一切看起来很‘优雅’,却不能为编程工作带来一点好处的代码。如果你喜欢玩弄语言,应该去当作家。 

 

 

甘于平凡

程序员真的很高傲,在我接触过的人中,包括我自己也是。我以前经常对一些简单的代码感到不屑,而总想在项目中写一些犀利的代码,让人看起来很NB,但结果总是和想象差太远,代码总是写的很差,逻辑也不够清晰。归根到底,是我带着这样的思想去写代码,而忽略了编程的根本:解决问题。现在我改掉了这个坏毛病,以解决问题为目的去编程,以简单为主。出乎意料的是别人有时会对我说,这里的代码写得很棒。

踏实的做事,会有意想不到的收获。

 

 

承认错误

不要怀疑,当别人用自己的程序或者代码无法运行时,首先考虑是否是自己的逻辑哪里有问题。一来别人会觉得我谦虚,二来实际大多数情况的确是自己的问题。

 

 

有原则,有决心

做任何事情都坚持原则,并有决心是最好的。有很多道理我们都明白,但经常做不到,没有任何人能帮到自己,未来也是自己争取的。

所以,如果知道什么是好,就尽量去做,什么是不好,就尽量避免。

即使是在公司面对经理和领导,也要坚持自己的做法,一些不合理的需求应该指出或拒绝。我还年轻,大不了换一家公司,而不愿意做一个受欺压的码农。

 

 

我在做什么

文章写完了,现在来回想一下,我是在分享自己现在编程的一些习惯,总算没偏离开始的主题。本文的思想都是来自实际工作和一些书籍,想了解更多的话,推荐阅读《整洁代码之道》《代码大全》《重构》这几本书。

如果你有一些认为好的编程方法,不妨拿出来和大家分享一下。

 

转载注明地址:http://www.chengxuyuans.com/program_life/64827.html