一个资深Java架构师告诉你咱们是如何将一个项目作烂的

首先我想声明一个项目作烂不是你一我的挖坑就行的，这是一个很大的工程 须要团队协做

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

在你的项目里，”烂”和”好”同样没法准确的衡量和定义，在大多数人的职业生涯里，你听到”烂”项目确定比听到”好”项目的状况要多不少。

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

我本身也没有遇到过真正”烂”到没法维护的项目，由于我就是那个让项目慢慢变烂的人。

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

意识到项目的”烂”与闻到代码的坏味道同样是优秀开发人员的基本素养。

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

工具

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

有的是直接用开发工具Eclipse打包war文件，其中一家公司，甚至是在本地编译Java文件，而后上传class文件到线上服务器，就算那时已经有ANT这样的先进工具，惋惜咱们仍是类人猿，没有进化过来, 要知道 使用制做工具是人类起源的重要标志.

现在咱们在一个最好的时代, Maven成了Java构建的标准，Gradle成了Java构建的新秀, 请把打造高可用自动化工具链与开发高可用系统提高到一样一个高度。

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

若是你的项目还不能作到一键命令构建，打包。

若是你的测试环境和线上环境程序部署时间不在可控范围。

……

那么你的项目，确定会慢慢变烂, 由于效率过低。若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java进阶群：591240817，群里有大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们

框架

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

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

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

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

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

4. 一个原本只须要几十K代码搞定的项目，最后把框架依赖一块儿打包，至少几十M

5. 没看出来为何这个项目须要用到这个框架

6. ……

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

若是你的项目和我遇到的状况同样，知足了上面两点以上，我相信，只要这个项目还要继续，就会继续变烂，缘由大概有如下几点：

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

• 最后老板仍是赞成了，没事儿你就重构吧，可是，你敢把一个正在好好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

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

代码

框架和模型是让你站得更高的角度来看项目,最后仍是得回到代码上,好的项目(应该说团队)必定可以找到一套规范(当前流行叫”军规”), 每一个团队制定的规范可能有些不一样,但仍是能找到不少共性.

• 代码规范(Checkstyle, 方法名,类名规范,注释规范,代码格式规范……)

• 工程规范(构建流程,版本发布……)

• 设计规范(设计复杂度控制,模块依赖……)

• 数据库表设计规范, SQL规范

• ……

通过我多年的经验,制定规范这事儿,其实重点在如何让项目成员理解和认同,最后才是执行,不少项目成员对规范的抵触源自浮浅地认为规范只能让他们将时间消耗在非功能性需求上.

规范是一种认同感, 但要想让项目成员创建更好的认同感, 有时候你必须利用人格魅力(若是你有的话),或者惨痛的经验(老司机确定有的).

抬头看看你的项目, 能不能找到一条硬性要求的规范, 若是找不到, 能够直接跳出该文.

若是你有所觉悟,而后只是到网上处处借鉴各类军规堆砌在项目里, 那么依然没什么卵用.

规范并不能让你的代码变得多优秀. 规范只是防止代码里处处弥漫着单身屌丝程序员(猿)的我的感情色彩,规避一些显而易见的错误.

有了规范, 你有没有代码审查?

你在网络上处处都能搜索到” XX团队如何看重代码审查,XX团队为了代码质量开发了一个代码审查工具”, 但是你很难找到XX团队是如何作代码审查的,因此搞清楚如何让代码审查起到做用 比代码审查自己更重要.

总之,在代码审查以外,你还须要权衡,要不要把代码审查搞成政治任务,要不要搞成批斗大会, 若是你在代码审查的气氛里面闻到了坏味道, 那就应该停下来.

一个作好了代码规范和代码审查的项目,想变烂都没那么容易.

测试

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

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

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

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

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

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

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

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

需求

全部的业务需求你都应该去知足

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

然而对于一个发展中的项目，有可能正是需求在让它慢慢变烂.

由于我见过太多的需求来至项目控制人员(简称领导),而不是来至于真正用户,这些项目控制人员还会振振有词地说:”我也是用户中的一员”,大部分开发人员基本上又都处于食物链的最低端, 因此遇到上面这种状况,基本是无解的(排除那些真正执行工程师文化的公司).

大部分项目的需求，都会对应到一个系统功能，系统功能都会有生命周期，可是项目中的代码却每每随需求一块儿增加，对于过期的功能代码，没人敢随便删除，而后就变得臃肿。

另一种状况就是需求超越了领域模型，例如：ATM取款机，让你植入视频播放功能（现实生活中却真有的）,你有时候没法分辨出这类需求，而后却漂亮地实现了它。

恭喜你，你的项目正在面临慢慢变烂的风险。

负面情绪

负面情绪让项目慢慢变烂，听起来有点牵强，其实负面情绪与项目中的”烂”有点像鸡与蛋的关系，但这也只是其中一方面，放眼望去，项目中的负面情绪来自于方方面面。

部分开发人员若是遇到《如何编写没法维护的代码》 中提到的问题会让他们大怒，而后抱怨没有统一的代码格式化工具，没有规范的目录结构，甚至日志输出格式也是五花八门……

若是你在项目中常常听到这种骂街的声音，那么你所在的项目还不至于那么快变烂。

不满现实，并动手去改变它，这也是优秀程序员的基本素养，但你必须停下来思索一下，你周围的人是不满的多，仍是动手去改变的人多。

我本身就很是愿意和不满现实而且情绪化的开发人员一块儿工做，很是害怕那些只是抱怨，说到动手去改变的时候又保持沉默的人。

情绪会传染，有些情绪在团队中会产生负面的效果，有些却能成为动力，这取决于团队的自我认知能力。

如何识别项目中遇到的负面情绪呢？

• 小A最近常常一边写代码，一边上逛招聘网站

• 小B常常给你说，某某公司的工资更高，全员MAC环境开发，23寸显示器…

• 小C给你讲，小A和小B的代码写得真烂

• 小D抱怨技术上得不到提升

• ……

放心，若是你在项目中是个领导角色，上面这些抱怨列表你基本上是不会听到的，若是你只是一个普通的开发人员，那么就去购买一本《程序员自我修养》，将负面情绪转化为正能量。

保持现状

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

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

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

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

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

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

请注意,咱们不是在讨论升级的问题,咱们是在讨论 变化 的问题.

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

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

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

最后记住:

在一个团队协做的时代，你不是一我的在挖坑。

也能够关注咱们的微信公众号