在你读到这篇牢骚的时候，无数个项目正在慢慢变烂。

全篇文字都是以Java语言为背景，如有与非Java语言项目雷同的地方，绝对是巧合。

既然标题都用到了"烂"这个词，那什么才是烂呢？

在你的项目里，"烂"和"好"一样无法准确的衡量和定义，在大多数人的职业生涯里，你听到"烂"项目肯定比听到"好"项目的情况要多很多。

当你在一个维护型项目面前，一边嘴里跑出一万只草尼马，一边还在上面Coding，最后居然还如期交付了维护任务，你能说那是"烂"项目吗?

我自己也没有遇到过真正无法维护的项目，因为我就是那个让项目慢慢变烂的人。

也许，"烂"项目的罪证无法像《如何编写无法维护的代码》那样容易罗列，所以你根本就不认为那是烂。

不过本文说的"烂"，只是从程序员的角度去看项目，与项目本身的创意，项目在公司层面的战略意义没有关系。

工具

在我刚出道时（06年左右），那时候的Java生态圈其实已经很强大了，但是我刚毕业工作过的几家公司，几乎在项目部署上都没有使用太多的自动化工具。

有的是直接用开发工具Eclipse打包war文件，其中一家公司，甚至是在本地编译Java文件，然后上传class文件到线上服务器，就算那时已经有ANT这样的先进工具，可惜我们还是类人猿，没有进化过来。

如今Maven成了Java构建的标准，Gradle成了Java构建的新秀。

如果你的项目中使用到了工具，但是它却很脆弱：过多依赖环境，依赖复杂的配置，有时候还会有BUG。

如果你的项目还不能做到一键命令构建，打包。

如果你的测试环境，和线上环境，不能在5分钟(5秒种更好)之内部署好一个程序。

那么你的项目，肯定会慢慢变烂。

框架

是的，从你找工作开始，就肯定听说了这个词，如果你在学校的时候就是一个勤奋好学的同志，那么你早就听说过了，在Java的世界里，你不会几种框架，还好意思出去混吗，于是很多招聘里面都提到，精通Spring,Hibernate,Struts,Mybatis ... 我入职的一家公司，甚至还有公司框架Demo代码学习这个环节。

So，当你到公司第一次接触到项目的时候，我想上面提到的这几个框架，至少有一个出现在你的项目中，先来看看我遇到的项目中使用框架的情况：

使用了框架，但是版本已经是上个世纪的了，却依然在线上跑着

依赖同一个第三方开源工具包，却有多个版本

有的地方用了框架的注解配置方式，有的地方却用的XML配置文件

一个本来只需要几十K代码搞定的项目，最后把框架依赖一起打包，至少几十M

没看出来为什么这个项目需要用到这个框架

......

框架一词原本来自建筑学，在软件行业里面，本人理解框架，就是解决特殊场景问题的 抽象实现。本着娱乐的精神，这里就不引入太书面的文字，容易引起反感。

如果你的项目和我遇到的情况一样，满足了上面两点以上，我相信，只要这个项目还要继续，就会继续变烂，原因大概有以下几点：

你是一个有理想的男青年，你想把机械键盘砸在那个已经不知离职多久的前前前同事的脸上，然后大声喊出来“老子要重构”，然而老板说:可以，你先把这一堆需求实现了再说。

最后老板还是同意了，没事儿你就重构吧，但是，你敢把一个正在好好running的线上项目框架换成最新版本吗？（你的项目用到还不只一个框架，有些框架之间在版本上还有依赖的，你不可能只升级其中一个）

想到这里，再抬头看看周围Coding的同事，有的是已经工作了数年的老腊肉，还有一波刚入职的小鲜肉，他们是否和你一样有理想，有追求呢

• ......

如果你学过PMP，那么上面这些问题可以概括为风险和成本。

这样，框架就成了项目的枷锁，即使不会让项目慢慢变烂，也不会让项目慢慢变好。

领域模型

对啊，没问题，我们项目里面的使用Spring，爽得不要不要的，Spring不是提倡面向接口编程吗，我们有完善的Service接口层。

是的，就像上面提到的，我曾经学习过公司的框架Demo代码，里面把Module都分好了，Domain, Dao，Manager（用于管理DAO层的事务），Service，Web。 真实的情况却是，Service里面，一个Service接口对应了一个Dao（大部分情况是这样的），你有几个数据表，大概就有多少个Service接口，如果有个新业务来了，添加了一张表，就再搞一个Service接口。

是不是感觉你的Service，Dao基本都是在为数据库CRUD服务。

在充满疑惑的岁月里，我找到了真相，原来我把名词理解错了，“DDD”的含义有两种，一个是Data-Driven Design，一个是Domain-Driven Design

一个没有领域模型抽象的项目，迟早要慢慢变烂。

测试

我在大学里面学编程的时候，似乎老师都没教过什么是测试，当时写TC的时候，老师只是说上机执行，现在回想起来，好像当时的教材也没有专门讲测试。（也许我就没有好好学过）

从项目代码来看，最基本的就是单元测试。

你的项目虽然有单元测试，但是他们要么过时（没有和被测试代码一起演化），要么根本就没有达到覆盖率要求。

当你想给一个功能补写单元测试的时候，发现编写单元测试的难度比重新实现这个功能的难度还要大，结果你就真那样做了。

测试的目的就是为了发现尽可能多的缺陷， 尽量 保证质量。

然而很多项目根本就没有清晰定义出 质量 的边界，甚至只完成了功能测试。

罗列你项目中的测试项，将他们分类列举，如果测试项用一张纸都能写完， 那么这个项目本身就是烂的，根本不需要慢慢变烂。

再强调一下，如果没有充分测试（怎样才是充分测试？）的项目，其实已经烂了。

需求

所有的业务需求你都应该去。

业务是项目的基本驱动力，可以说没有需求就没有项目存在。

然而对于一个发展中的项目，需求正在让它慢慢变烂，有时责任却并不在需求本身。

大部分项目的需求，大致上都会对应到一个系统功能，系统功能都会有生命周期，但是项目中的代码却往往随需求一起增长，对于过时的功能代码，没人敢随便删除，然后就变得臃肿。

另外一种情况就是需求超越了领域模型，例如：ATM取款机，让你植入视频播放功能（现实生活中却真有的）,你还高兴地接受了这个需求。

你有时无法分辨出像我给出的这个明显例子，然后却漂亮地实现了它。

恭喜你，你的项目正在慢慢变烂。

保持现状

有一个老程序员自豪地告诉我，他写的一个程序已经在线上跑了快10年了，从来没动过。

我只是笑了笑，说了一句：牛逼

如果我写一个打印Hello world的程序，部署在一台太阳能Linux机器上，然后把它放到外太空,谁知道能运行多久呢。

我做的部分项目里面，用到的第三方工具距离最新版发布时间有的至少快5年了。

同事告诉我，用着这么稳定，干嘛要升级。

你要知道，JDK现在多久发布一次？每次都有哪些BUG修复？有哪些性能提升？你用的这个第三方包，可是在5年前那个版本的JDK下开发完成的，而且那个开发第三方工具包的人有可能还死了。

保持现状是一种惰性思维，它已经麻痹了开发人员对项目变化带来的风险评估。

如果将项目比做一辆汽车，它只是在不停地行驶，却没有定期保养。（重点是你不知道应该保养哪些部件）

不要让保持现状的思维腐蚀了项目，让项目慢慢变烂。

在一个迷念团队协作的时代，你不是一个人在挖坑。

原文:

http://www.360doc.com/content/16/0811/07/9437165_582380406.shtml