如何开发不可维护的软件?


发布者 ourjs  发布时间 1382970497000
关键字 心得体会 

本文由 乾龙 翻译自 Greg Jorgensen

我从别人遗留的的技术性债务中获得报酬。在我的日常工作中,我见到了很多难以维护的代码,并且我一次次地看到了很多相似的并可以避免的问题。

我专门从事调试、修改、维护、扩展遗留软件系统这类工作,我的典型客户一般都有一个或多或少可以运行的网站或者软件,但是其开发者都因为各种原因不 再维护了,因为商业需求改变导致软件无法跟上需求;或者我的客户有一些“几乎快要完成”的软件,但是因为预算用光或者计划有变与开发者分道扬镳。通常这种 软件会缺少一系列的功能并有一坨bug。

我那些客户通常被其他程序员告知,需要废弃已有的所有代码从头开始。大部分程序员不喜欢维护代码,尤其不喜欢维护别人开发的代码。当程序员写代码 时,当他们谈论到可维护性时,程序员经常会问一些错误的问题——想了解这种情况是如何发生的,请参看Matt Duvall的文章《可维护性的神话 | The myth of maintainability》。

以下是一些你可以在你自己的软件工程中做的“好”事,因为这些事可以帮我找到活干。

 

不要用版本控制软件

我经常很惊讶的发现,在过去的几年里编写的大型软件工程竟然不在源代码版本控制中。如果你不使用版本控制,下一个承接你项目的程序员就没法确定哪些 文件属于你当前的系统,哪些是淘汰的以及哪些是备份文件,他也无法从提交信息或者修改日志中获得任何关于代码的历史信息。我在我的文章《面向卑鄙的编程介 绍 | Introduction to Abject-Oriented Programming》中,介绍了“如何不使用版本控制”。

 

大量定制你自己的开发环境

千万不要让承接你项目的程序员轻易的开始工作。开发软件时,一定要用特殊版本的编程语言、工具,确保它们与一起交付的操作系统有冲突。像疯子似的定 制你的Eclipse、VisualStudio或者vim环境,然后编写只能在你定制的环境下才能工作的宏或者脚本。不要制作硬盘镜像或者脚本以复制你 的开发环境,并且不要费劲巴拉写任何说明文档——这太直观啦。

 

创建一个精心制作的构建和部署环境

把网站部署到一个测试或者产品服务器上的方法,应该看起来像这样:

svn up
git pull
hg pull

程序员可以与简洁性和优雅作斗争,然后反过头构建精心制作的巴洛克式的构建和部署环境。这是一项不受控制的事,程序员可以在不面对客户的情况下,或 者项目经理不审查或者不理解的情况下完成,所以很容易失控。当你把八种不同的工具用不同的脚本语言链接起来时,记得不要写文档。

 

不要设置测试/分段平台

修改产品系统是很令人兴奋地事。不要费劲巴拉的搭建测试/分段平台,相反要保留秘密登录入口和后门URL,以测试新的特性。把测试数据和真正的数据混合起来放到数据库中,

既然你不使用版本控制软件,保存软件旧版本的副本,以防万一。不要把日志信息插入到代码中。在测试过程中,不要禁止传出电子邮件,信用卡授权信息等等。

 

从头编写所有模块

不要费劲巴拉使用像Django、Rails或者CakePHP一样很容易理解的框架,你可以自己写一个更好的模板引擎,ORM,排序或者哈希算 法。每当我看到代码中诸如”比已有字典算法要快“或者”替换了PHP库函数,因为那些函数参数顺序太烂了“的注释时,我都忍不住的想弄死自己。

 

增加对特殊版本的库和资源的依赖

尽可能的加入第三方代码,在你需要时链接尽可能多的共享库。我曾经见过依赖于很大的外部库文件只为了使用其中一个函数的代码。修改第三方库文件源代 码,这样就可以保证在有新版本出现时,那些第三方库就不会自动更新,但不要把你修改的版本置于版本控制中,我会用diff命令比对你的版本和最原始版本, 并发现其中不同的。

 

……但是不要保护或者编写依赖性说明文档

因为更新和升级错误给我打紧急电话的,是所有工作电话中最多的。一个看似无害的WordPress升级,Linux包更新,或者新的jQuery发 布将会引发一系列的错误。不要让你的代码自动检查特定版本或者你修改的外部资源副本或者第三方库文件,甚至不要添加注释以提醒你自己。

 

使用一坨不同的编程语言,跟上潮流

每天HackerNews和Reddit都会对一些新又酷的编程语言唧唧歪歪,在你为客户编写软件时就可以试用那些语言。任何牛逼的程序员都应该瞬 间学会一门编程语言,所以如果继续承接你代码的程序员是个菜鸟那不是你的问题。不同语言的边界、不兼容的API和数据格式、不同服务器配置需要等,都是很 有意思的挑战,把这些贴到SackOverflow秀一下也是怪牛逼的。我确实看到过PHP网页中嵌入Ruby代码,因为每个人都知道PHP烂透了而 Ruby好太多。半生不熟的项目,中止的Rails和Node.js项目,尤其是NoSQL解决方案(这个伸缩性更强)都是我的菜。

 

编程建议:

你的代码是否是完美面向对象并闪闪发光的,这没什么鸟用。当程序员不得不维护一个遗留系统时,他们几乎总是看到意大利面条式的代码。我很擅长使用 diff、grep和ctags等工具追踪代码、重构、调试,我终究会搞明白你的代码。如果不使用版本控制软件、代码有太多依赖和定制、没有测试/分层平 台,那些最漂亮优雅的代码依然非常难搞。这就像在满是囤积物的房子里,找一个装饰漂亮、干净的房间一样,就算找到了,有啥鸟意思?