分类 思考控 下的文章

代码是怎么腐化的

新三年,旧三年,修修补补又三年。
                                                             — 中国俗语。

上面的这句俗语用来形容很多遗留软件系统(legacy software system)的现状是再合适不过了。

今天下午做了一下午的代码评审,对象是一个运行了7年的遗留系统。会上除了几处明显的代码逻辑错误我发言指了出来外,涉及业务流程以及代码设计的问题,我 大多保持沉默。因为我清楚,即便我明确指出问题,可能也得不到修正。也许参与评审代码的其他同事也都知晓这些问题,只是觉得现在还不能去改…。

为何不能去改?回想当年第一版代码出炉时,它是那么的“出淤泥而不染”,而如今它身材臃肿,满身赘肉,千疮百孔,让人无处下手,看起来都不舒服。虽然它依旧能坚持工作,但终会有一天,它会轰然倒地,酿成大错。为何代码会腐化到如此地步?是怎么腐化的?这里谈几点体会。

* 第一版的设计和实现水准

我们知道:设计再完美的系统也终会有腐化的一天,时间才是最可怕的武器,它是一把无情的刻刀,不仅能使人老去,逻辑抽象世界的程序也不能幸免。但是你的程 序设计和实现的越完美,这个衰老和腐化的周期就会越长。一个糟糕的初始设计和实现,只会让系统更早的发霉、腐败直至被替换。我们的这个legecy系统在 最初的代码设计上就给后人留下了许多“糟糕的参照物”,在后人无以伦比的“复制粘贴”的技能下,这些糟糕的设计和实现就像癌细胞一样扩散到系统机体的每个 角落,让你无法重新建立其免疫系统。

* 没有测试做保障,不敢改

系统从诞生的那天起就使用“人肉测试”的方式,而且是粗粒度的系统功能测试。没有白盒的、可重复使用的、自动执行的单元测试集做保障,以致没有人敢对其轻举妄动,一旦出了问题,后果自负。另外人肉测试,精力和成本双重消耗,测试人员“耗”不起啊。

* 缺少崇尚“美”的文化

记得组织第一版企业文化中“美”这个成分还有立足之地的,但后期改版后,我们就再也看不到“美”了。码农们也是一样,在缺少了“俱美”之风的吹拂下,大家 都变得有些“丑陋”了,大家都开始摒弃“美”,认为代码只要能工作即可,美不美不打紧,于是工作就变成了修修补补,系统变得日益臃肿,臭气熏天。

* 进度之忧高悬

很多人会说:“如果给我充足的时间,我会让系统获得新生。但我没有时间,客户那边催的急,只能下次再重构、完善和优化了吧”。从这里不知大家是否看出了:“改善是没有的,下次却是永恒的”这一“道理”。在进度堪忧的情况下,我们多数时候选择了屈服,而不是自己的原则。

* 成本,老板们不得不面对的

“能用即可,新三年,旧三年,修修补补又三年”。如果你和老板谈重构、谈优化,那么这句话就是老板最好的拖词儿。成本永远是悬在老板头上的一把宝剑,老板们不能视而不见。因此,如果你要和老板谈重写遗留系统,那得需要多么强大的魄力和坚定的意志啊。

* 拷贝粘贴,最好的伙伴 or 最大的敌人

相信发明复制、粘贴以及剪切板的那位仁兄无论如何也没有想到,自己送给世界的礼物,竟然被码农们操练的如此熟练,应用在各种场合,尤其是Coding中。代码中充斥着大量重复代码信息,都是拷贝、复制和粘贴的结果,于是乎代码腐败的最大敌人就此出现了。

牢记:“千里大堤,溃于蝼蚁”。下一步该怎么办?去闻闻,你的代码腐化了没有!

那些代码中的“中国式”命名

10月中旬,有人在Quora网站上发起一个调查:“程序员职业生涯中最难的事是什么?”,调查结果让人实感意外。世界范围内的程序员同胞们普遍认为: “命名是让大家感觉最困难的事情”。对于主流的欧美程序员尚且如此,对于英文非母语的中国程序员来说,苦逼程度可想而知了:(。

虽说中国程序员大多也都学了10年以上的英语了,但能“地道”的表达和书写甚至是选词的程序员们比例却不高。而在编写程序的过程中,给变量、常量以及函数命名即意味着我们要选择恰当地道的词汇或缩写。

事实证明,任何事情经过中国人民的加工,就会呈现出意想不到的效果,于是我们有了Chinglish,有了“中国式”的命名。就此,我特地花了些时间翻阅了下面几个项目组的源码,总结出了一些“中国式”命名的门道,这里也说道说道^_^。

一、万能的动词

通过阅读代码中的一些命名,我发现了代码中经常出现的一些动词堪称“万能”,这些动词包括:handle、do、process、check、collect等。无论对象是什么,你只要像如下这么命名,中国程序员基本都能看懂或猜个八九不离十:

    process_xx  处理xx
    do_yy       做yy
    handle_zz   处理zz
    check_xx    检查/校验xx
    collect_xx 收集xx

二、标志/类型代言人

在项目源码文件中,你会变量声明或结果体声明中看到太多的xx_flag或xx_type。xx_flag被大家“公认为”各种标志的代言人了;xx_type也好不到哪去。

    route_flag
    protocol_flag
    msg_flag
    session_flag

    msg_type
    check_type
    command_type
    session_type

三、字面意直译式

比如我们要声明两个变量,一个的意思是“是否打开消息过滤”,另外一个“是否关闭消息过滤”。对于中国人来说,打开/关闭最直接对应的就是open/close,于是就有了这样的变量命名:

    is_message_filter_open
    is_message_filter_close

其实一般认为更地道的方式应该是:

    is_message_filter_on
    is_message_filter_off

再举个例子,我们的系统要处理一种中文名为“长短信”的对象,于是直译过来就是:long_sms。但其真正的英文术语应该是Concatenated SMS

四、中文拼音式

在国内做行业解决方案,不可避免会遇到各种领域词汇,比如我们处理的一种业务称为农信通。估计是开发人员没能找到其对应的英文翻译,于是乎用上了我们的看家本领 – 拼音。

    nxt_url  农信通地址

这样的例子是否似曾相识呢!

五、单词“选秀”

采用这种方式的程序员应该是更具“责任心”的,至少他/她知道去查查英文词典^_^。

于是乎有了dispense_message、cache_overstock等变量命名。显然他是在字典的单词选秀中随意找到一个“顺眼”的、意思还算相近的单词就挑了出来。显然dispatch 、overflow要比dispense、overstock更地道和准确。

六、尾声

以上的“实例”确是从我们项目的代码中“挖掘”出来的,希望只是个案。面对这样的命名bad smell,我们是否有解决方法呢?没有捷径,语言的感觉是要一点点的去找的,个人觉得一个最行之有效的方法就是去看那些英语地道的程序员编写的代码,留 意他们是如何命名的。比如看一些著名欧美程序员的开源项目代码。另外对于行业特定领域,尽量用经过认可的英文翻译结果来命名。

不可否认,英语是编程领域的主流语言,包括中文在内的以其他语言为编码语言的编程语言十分罕见。对于欧美程序员来说,这是天然的优势;而对于其他非欧美国家的程序员,尤其是中国程序员来说,在走向“地道”的路上还要付出很多才行。

关于程序员的构思能力的一些体会

有一段时间,我完全沉迷于在脑海中想象机械绘图和设计新机型所带来的极致享受,这是我一生中有过的最完美的精神愉悦。创造的灵感像泉水般源 源不断 地涌出,我遇到的唯一困难就是必须设法牢牢抓住它们。对我来说,构思中的设备零件都绝对是真实的,所有细节都触手可及,甚至最细微的标识和磨损状态也是如 此。想象发动机在持续不断地运转,仿佛一道迷人的风景呈现在面前,令我欣喜若狂。
                                                                                                       尼古拉. 特斯拉

看完上面这段特斯拉回忆录中的自述后,我们不禁惊叹于特斯拉超乎寻常的大脑构思能力。读完特斯拉的回忆录《被世界遗忘的天才:特斯拉回忆录》后, 我完完全全相信特斯拉是一个不折不扣的“外星人”,就是像克拉克.肯特那样被送到地球的“超人”。不同于超人的是他给地球带来的不是钢铁般的身躯和无比的 正义,而是超级智慧。他的所思所想所做所为完全超越了那个时代,甚至是当今的时代。作为程序员,我们不敢奢望能拥有特斯拉那样的超级构思力,但拥有一个良 好的构思力对于程序员来说还是蛮重要的。

【什么是构思力】

就我自己的认知和经验来说,构思力是一种“在大脑中构造事物的能力”,构造出的事物不是静态的,它在你的构思下不断演化,像是一部电影。日常生活工作中, 绝大部分人都是被动构造,当收到外界的输入时,包括影像、声音、感悟等时,在大脑中应激性的出现一些事物和场景。这种构思的持续时间很短,从长度上来说, 都是微电影,并且很难抓住并转换为现实,价值不大。真正的有价值的构思应该是主动、有意识、有目的地在大脑中构造。因此构思力常用于在创造、创作以及发明 的过程中,各个行业莫不如此。

【构思 vs. 设计】

构思与设计都需要经过脑力完成,甚为相似,难于区分,但个人觉得还是有些许差别。就就像特斯拉回忆录里描述的那种情形,我们称之为构思。构思强调事物从无到有, 都在脑中完成,是一种全脑演算。有时就是一个闪念,瞬间迸发出来,很迅速,并可被快速捕捉到,构思者往往会变得热情高涨,并在短时间内完成主体设计和实 现。构思往往一次成型,多用于整体或全局设计,是真正设计阶段开始的前置条件。构思过程会将事物的全貌在大脑中构造出来;将关键的技术难点在脑中完成突 破,形成思路;会将事物与外围接口在脑中进行对接;会对创造出来的事物在脑中进行初步的验证,证明其正确性。

设计则会将前期构思的事物分解并细化,落于纸面,或画出各种图形,多是渐进和迭代的;有时用作局部优化。

因此可以看出,构思是更高层次的设计

【程序员与构思】

程序员的日常工作与创造关系紧密,而“创新”则离不开构思。哪些工作属于构思范畴呢?目前看来比例不多,在目前这个网络四通八达发达,搜索引擎智能强大的 时代,你要的解决方案基本都能在Internet上找到,只是将现成的方案挪到你的solution中,我觉得算不上构思,顶多是设计,设计如何将现有的 东西组合起来。

构思的结果是崭新的方案或是基于已有方案的优化改进,是有脑力参与的事物演化。但构思不是必须凭空创造,多是站在巨人的肩膀上,是个借鉴再创新的过程。构思有时候可能有“重新发明轮子的味道“,但重造轮子不一定不好。

构思可大可小,Linus Torvalds设计并实现GitMatz发明Ruby等属于大构思,你将某个算法的性能提升20%可算作小构思。

在软件开发领域,构思不是技术领域专有的,业务流程或过程的创新都与构思不无关系。

Non-trivial的开源项目多是构思的结果。我个人在开源lcut, cbehave, buildc时也是深有体会的。当大脑中构思演化出目标图景时,人会变得极为亢奋,软件的主体架子在短短几个小时或一两天内就完成了。很多著名的开源项目也是如此。

【影响构思力的几个因素】

构思力高低要看大脑的活力。个人理解影响构思力高低的几个因素:

    * 脑部成像构造能力
      
        就像特斯拉那样,每个人脑部都有一定的事物成像能力,比如提到神舟发射,你脑中会呈现某种画面;再比如提到Google数据中心,你脑中又会出现何种场 景。当然这些例子还都是简单的事物还原能力。当提到让你改进神舟飞船或降低Google数据中心能耗时,你的脑中的画面会有怎样的变化呢?能否变化或能否 沿着对应的问题演化能反映出构思能力的高低。当然这是需要有领域知识、眼光和技能的。改进的神舟飞船与降低了能耗的Google数据中心是不存在的,需要 你使用纯粹的空想构造能力对其进行演进的。训练你的脑部构造能力,要求你日常勤于用脑,勤于思考,经常将各种信号输入(语言、声音、感觉)进行转换,在脑 中尝试成像,减少视觉信号的输入。记得小时候印象最深的一件事就是一边听着单田芳老师的评书,一边在大脑中构造对应的场面、人物形象和情节,我想这对我大 脑的构思成像能力是大有裨益的。

    * 知识与眼光的广博
       
        凭空的构思创造毕竟是少数,而多是站在巨人的肩膀上。这要求你对所属领域甚是是相关领域有一定的了解和认知,这样在构思时,才能如特斯拉那样思如泉涌,思想的碰撞火花四溅。这就像拍摄电影,需要在日常积累各种素材和技法,兼容并序。

    * 对问题域的透彻理解

        构思多是行业领域相关的,构思的结果都是隶属于某个领域或行业的。构思出的方案是为了解决一个明确的问题或满足特定需求,因此是否对问题有透彻的理解将直接影响构思过程和结果,以及你构思力的发挥。

以上关于构思力的论述感觉还不够系统成熟,仅是一些主观心得体会罢了,供参考并欢迎交流。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多