10年前旧文：编程的美感

 

    最近整理10年前的一些文章，陈芝麻烂谷子再翻腾出来，mark一下，记录曾经思考的点滴。

一、从命名开始

你喜欢你的名字吗？没办法，名字是爹妈给的，不喜欢又能怎么样呢？但是每个人还是比较在意自己的名字的，以前是取个歪名好养活，但是现在生活好了，人们在起名上也讲究起来，也因此衍生出来这样专门取名的行当，可见命名还是有学问的。

那在软件开发中，我们也时刻关注我们的命名吗？你会说，是的，我们都有自己命名规范，各种语言也有自己通用的命名规范。比如java中，包名取组织的反域名，类名第一个字母一定要大些，方法第一个字母要小些，多单词第一个字母要大写。是的，我们应该有这样的规范，通过这些规范我们可以建立起沟通的桥梁。我们在项目开始前都会建立自己的项目规范，其中很重要的是命名规范，但是在项目的过程中，我们真的能一丝不苟的坚定不移的去执行吗？

从我的经历来看，随着项目进度的日益紧迫，随着软件监督的懈怠，我们便会疏于执行。将开始的代码和后期的代码比较，让我们很难理解这竟会出自一人之手。为什么我们不能坚持的为每个事物给一个好的命名呢？我认为我们没有把编程当成一种乐趣，而是一件工作，一件只讲究结果的劳动。清晰的命名是优秀代码的特点之一，恰当的命名事物的能力是代码艺术家们的一项重要技能，把代码当成自己的孩子，那么就不会让命名再如此的随意，你不想自己的孩子叫“狗子”什么的吧。

哪些是我们最常命名的对象？

变量、函数、类型、Java包、文件名等等。

怎样命名才算是恰当的呢？

长度适当。怎样才能算是长度适当呢？在名称有意义的情况下，尽量的简短。但是不能为了简短，使用tj（统计）这样的让人晦涩的字母。有的开发人员英语功底不行，却习惯使用金山词霸等词典工具翻译，往往有时找一些生僻的单词，让人很难一眼看懂。命名就是要简单，容易理解，有时候使用汉语拼音也比找一个只有词典才能认识的单词要好得多。

格调一致。有人喜欢动词-名词组合，有人喜欢名词-名词组合，对于有意义的命名，每种格调都是可以让人的阅读感到愉悦的。但是，每个人的格调应该是要保持一致的。比如你使用listUsers()来表示得到用户列表，那么你就一直使用这个。如果你即使用listUsers，又使用userList，这必然给别人的阅读带来困难，因为人们不敢从你的命名上即可推断该功能。

当然对于其他的事物还有特定的命名规则，我们需要在开发中一点点的思考总结。

你喜欢编程吗？你想成为高手吗？那你就从命名开始吧，因为她是我们的孩子，她是我们的宝贝。

二、你喜欢防守吗？

        观看足球比赛，那些在前面冲锋陷阵的前锋最吸引我们的眼球，我们喜欢他们行云流水的配合，喜欢他们单刀赴会一骑绝尘的背影，喜欢他们刀刀见血仰天长啸的豪情……，他们是足球场上的英雄，是胜负的主宰。

的确，美丽属于他们。但是我们又不得不面临着这样的事实，当我们举着进攻的大旗冲锋陷阵的时候，我们的后方是最危险的时候，对手的冷不防的偷袭便偷走我们胜利的果实。我喜欢的鲁能泰山，在中超各球队中进攻的能力可以说是数一数二的，但是仍然会输在一些弱小的球队身上，可见什么时候都不要忽视防守。也许图巴曾经说过，进攻是最好的防守，我们只要永远比对手多进一个球，我们就是胜利者。这当然是个真理，但是在软件开发中，它却不能成立，一个细微的错误便可以让整个系统瘫痪，软件开发的质量永远决定在系统的短板上，即使你有最锋利的尖刀。

这便引出一个概念：防御性编程。顾名思义，防御性编程是一种细致、谨慎的编程方法。防御性编程让我们尽早的发现一些小问题，而不是当出现灾难时在发现、弥补。我们常常看到“职业”的程序员不假思索的飞快写着代码，编写-运行-崩溃-修改-运行……，周而复始一次次的遭受着沉痛的打击，他们提高了开发的效率，却将时间大量的花费在非需求变更的修改上。我也经常听到有的程序员经常说的一个字：改。出了错误肯定要改，但是我们为什么不停下来好好想一想，为什么我们每天都要生活在更改之中，有没有可以改变的方法。方法当然有，在写每一行代码时都三思而后行，可能会出现什么样的错误？是否已经考虑了所有可能出现的逻辑分支？放慢速度，有条不紊的编程看上去虽然很平凡，开发效率不高，但是这的确是减少缺陷的好方法，它可以节省80%维护的时间，从完整的软件生命周期来看，其实这是高效的。

我们经常说：失去时才懂得珍惜。难道防御性编程也要当我们出现错误时才引起我们的注意吗？不，这是不对的。防御性编程应该牢牢的印在我们的骨子里，成为我们的天性。成熟的程序员应该从经验中吸取教训，在吃过一遍苦头之后，应该明白增加预防措施是明智的。在开始编码时就应用防御性策略，要比改进代码时应用容易的多。

再回到题目：你喜欢防守吗？讨论到这里，我们是否发现防守其实也是一种美，它是男子汉的铮铮铁骨，铜墙铁壁显示出它的刚强，它虽然没有利矛，但是所有的利矛都无法刺破它的身体，这样健壮的系统，难道不是我们想要的吗？

让我们开始学会防守吧。

 

三、要时装还是正装？

我相信人人都喜欢看时装表演吧，模特们那妙曼的身材，漂亮的脸蛋，加以时髦的时装，真是美丽动人。的确，时装让我们魅力四射，让我们看起来与众不同，为我们赚来了不少的回头率。我们不断的变换我们的服饰，以至于朋友们都认不出自己，这也是一种美丽的尴尬。

张扬个性是一种美丽，但整齐划一也不失一种美感。还记得九九年国庆阅兵式吗？多么威武，多么壮观。各方队统一的服装，整齐的步伐，响亮的口号，展示了军人的英武壮美，我们深深的被这些场面打动着。走到哪里我们只要看到军装，我们就知道这是人民解放军，看到绿色我们知道这是骁勇善战的陆军，看到蓝色我们知道只是展翅在蓝天的雄鹰，看到白色我们隐约听到海军归来汽笛的声音。在我眼里，穿正装的女孩也是分外的漂亮，严肃而不拘谨，整齐而不失个性。

时装和正装都是美的体现，你喜欢哪个呢？

在软件开发中，我们需要张扬个性，发挥个人主观能动性，但是我们更需要协调、规范。我们思考一下，谁能成为我们写的程序的读者呢？第一，我们自己。我们是自己的读者，我们需要经常拿出我们自己的程序进行修改重构，如果代码让我们都难一是从，我们是什么心情？第二，编译器。这是最好伺候的家伙，也是让人头大的家伙。只要你的程序，在逻辑和语法上符合他的口味，它是多么和蔼可亲的家伙。但是，如果你即使少些了一个逗号，在它哪里也通不过，管你是漂亮的代码还是乱作一团糟。第三，其他人。对，我们不能忽视这些读者，在现代的软件开发中团队协作是必不可少的，相互阅读代码也是必须的，想想怎样让这些人能读的懂你的代码这也是非常重要的。看一个例子吧。

int fn(String arg){return ts.getById(arg).getAccessNum()+1;}

我们先不理会这个方法的含义，如果满屏的都是这样的代码，你是什么感觉呢，是不是要崩溃掉。的确，没有缩进，没有分行，杂乱无章。这就是我要阐述的第一个观点，请将你的衣服穿整齐，最好能找到一个合适的格式编排，并坚持使用它。我们现在就来改造它。

public int fn(String arg) {

       return ts.getById(arg).getAccessNum() + 1;

}

       是不是比以前好看多了，K&R式缩进，方法名和方法体分离，代码变得就很清新。

但是我们仍然感到不知所云，我们是不是再想，如果有注释那该多好啊，的确，缺少注释的代码就像一本看不懂字符集，可能只有编译器才能明白，这对于阅读和维护你代码的人来说，无疑是一个梦魇。让我们再来改造它吧。

/**

     * 得到当前文章的阅览量

     * @param arg 文章ID

     * @return

     */

    public int fn(String arg) {

       return ts.getById(arg).getAccessNum() + 1;//得到文章原有访问数将其加一

}

的确，看着注释我们终于明白了这个代码的意思，我们长舒一口气。我们发现注释可能对于编译器毫无用处，它会被忽略，但是对于每个阅读你代码的人来说，你可以让他少花多少大量的时间来阅读你晦涩的代码。作为负责的程序员，我们有义务添加必要的注释。注释是对程序的一种额外的说明，我们不要过度使用注释来描述程序。同时，团队开发一定要有一个注释规范，让所有人的注释都能整齐划一，一目了然。幸好，现在的IDE大部分都有注释模板的功能，让我们可以制定相同的注释模板。同时，像java语言，JavaDoc也有一些强制的规范和标准供我们参考执行。另外值得注意的时候，要及时维护你的注释。我们经常会为一些未实现的方法标注/**该方法稍后实现*/，然而我们再维护了代码以后，却没有及时的更新注释，这必然给其他维护代码的人造成误解和不必要的工作。就上面几行代码却充满了这么多的注释，阅读注释其实也成为一种负担，因为我们是关注的程序本身，而不是注释，怎么做呢？前辈们给我们提出了这样一个概念—文学性编程。这的确比较困难，我们不是作家，那么简单一点就是自文档化的编程方法。

我们经常为写文档而发愁，我们是程序员，我们热爱编程，我们不希望每天都要处理那没完没了的文档，还有阅读文档并不能最大程度的提高我们编程的效率，如果你也有这些困扰时，那就开始自文档化编程吧。还是改造上面那段代码。

private final int MAXVISITS=85;//最大访问限制数

    public int addVisitNum(String topicId){

       Topic topic = topicService.getTopicById(topicId);

       if(topic.getVisits()>=MAXVISITS){

           return MAXVISITS;

       }else{

           return (topic.getVisits()==null?0:topic.getVisits())+1;

       }

}

这样的程序，难道还要写过多的注释来说明吗？代码就是注释，这样的代码阅读起来难道不是一种享受吗？既然意识到这一点，那我们就从现在开始书写自文档化的代码吧。

上面说的这些，其实就是我们大家一直在强调的规范问题，现在的软件开发已经不是一个人的游戏，它是一个团队协作配合的结果，每个程序员用程序进行着相互的交流，致力于书写规范的一致性的代码其实是我们迫切需要的。如果您的团队已经有了相应的代码规范，那就坚持使用它，不要轻易更改。如果您的团队还没有相应的规范，参考现行的一些通用规范，再结合自身的实际，花点时间制定自己的规范，对您的团队绝对是有好处的。

要时装还是要正装？我们心里其实已经渐渐明白了，那就为您的团队制定一身合体的正装吧。

 

2009年2月23日

转载于:https://my.oschina.net/yongtree/blog/3101023