全篇文字都是以Java语言为背景，如有与非Java语言项目雷同的地方，绝对是巧合。 既然标题都用到了"烂"这个词，那什么才是烂呢？ 在你的项目里，"烂"和"好"一样无法准确的衡量和定义，在大多数人的职业生涯里，你听到"烂"项目肯定比听到"好"项目的情况要多很多。 当你在一个维护型项目面前，一边嘴里跑出一万只草尼马，一边还在上面Coding，最后居然还如期交付了维护任务，你能说那是"烂"项目吗? 我自己也没有遇到过真正无法维护的项目，因为我就是那个让项目慢慢变烂的人。 也许，"烂"项目的罪证无法像《如何编写无法维护的代码》那样容易罗列，所以你根本就不认为那是烂。 不过本文说的"烂"，只是从程序员的角度去看项目，与项目本身的创意，项目在公司层面的战略意义没有关系。 工具在我刚出道时（06年左右），那时候的Java生态圈其实已经很强大了，但是我刚毕业工作过的几家公司，几乎在项目部署上都没有使用太多的自动化工具。 有的是直接用开发工具Eclipse打包war文件，其中一家公司，甚至是在本地编译Java文件，然后上传class文件到线上服务器，就算那时已经有ANT这样的先进工具，可惜我们还是类人猿，没有进化过来。 如今Maven成了Java构建的标准，Gradle成了Java构建的新秀。 如果你的项目中使用到了工具，但是它却很脆弱：过多依赖环境，依赖复杂的配置，有时候还会有BUG。 如果你的项目还不能做到一键命令构建，打包。 如果你的测试环境，和线上环境，不能在5分钟(5秒种更好)之内部署好一个程序。 那么你的项目，肯定会慢慢变烂。 框架是的，从你找工作开始，就肯定听说了这个词，如果你在学校的时候就是一个勤奋好学的同志，那么你早就听说过了，在Java的世界里，你不会几种框架，还好意思出去混吗，于是很多招聘里面都提到，精通Spring,Hibernate,Struts,Mybatis ... 我入职的一家公司，甚至还有公司框架Demo代码学习这个环节。 So，当你到公司第一次接触到项目的时候，我想上面提到的这几个框架，至少有一个出现在你的项目中，先来看看我遇到的项目中使用框架的情况：
框架一词原本来自建筑学，在软件行业里面，本人理解框架，就是解决特殊场景问题的 抽象 实现。本着娱乐的精神，这里就不引入太书面的文字，容易引起反感。 如果你的项目和我遇到的情况一样，满足了上面两点以上，我相信，只要这个项目还要继续，就会继续变烂，原因大概有以下几点：
如果你学过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下开发完成的，而且那个开发第三方工具包的人有可能还死了。 保持现状是一种惰性思维，它已经麻痹了开发人员对项目变化带来的风险评估。 如果将项目比做一辆汽车，它只是在不停地行驶，却没有定期保养。（重点是你不知道应该保养哪些部件） 不要让保持现状的思维腐蚀了项目，让项目慢慢变烂。
未完待续...... |
|
|
