如何构建一个持续发展的项目

最新推荐文章于 2020-05-20 14:45:12 发布

benben_1678

最新推荐文章于 2020-05-20 14:45:12 发布

阅读量415

点赞数

启示录

心中有原则
代码规范化
代码审查
代码重构
代码注释
代码逻辑抽象
工具类
项目闭环
持续改进
自动化

心中有原则

我认为这是搭建和维护项目的灵魂，失去了灵魂，项目虽然能运行，但是未来是没有方向的。来了需求就接，最后就是修修补补。其实我个人认为心中有原则就是有未来预见性，能根据现有需求预见到未来的需求发展。

比如我做过的一个项目是需要依赖数十个系统，那么之前的做法是让所有我依赖的系统在变更时调用我的同步接口把数据同步过来，此处存在这么几个问题：假设IP或域名变了，需要通知所有依赖方；假设我们出问题了，各个依赖方需要自己进行重试；假设数据出问题了，需要通知依赖方再同步一下数据；这种方式产生了严重的耦合。因此在设计新架构时我们要完全摒弃这种方法，改用异步通知+拉取依赖数据的方式，如通过MQ通知我们数据变更了，然后通过依赖方提供的接口拉取数据；这种方式的好处：和依赖方松耦合；假设数据有问题再调用下依赖方接口拉取下数据修复即可。因此这个项目的原则就是异步通知+拉取数据。而如果依赖方不提供这种接口我们就无法满足他们的需求。还有一种特例就是有些依赖方的数据可以一天全量同步一次，那么可以使用定时任务每天跑一次；即定时任务+拉取数据。也就是说最糟糕的情况就是使用定时任务+拉取数据机制。

比如我们接到一个需求说需要在你们页面上加一个数据来展示，此时要我们在展示页面时调用他们的接口拿到数据然后展示，此处存在的问题是：我们如果强依赖他们，那么他们的抖动将影响我们页面的体验，虽然可以降级，但是我们也不能容忍一点点抖动；因此我们提供的方案还是异步通知+拉取数据，将数据存储到我们自己这边；或者前端异步加载。

心中有原则，即必须有一个或几个中心原则指导我们的架构不偏离航线，否则项目将朝着腐朽的方向发展，越做越烂，最后没有几个人能维护这个项目。也不能因为图一时之省事，而为未来埋坑。

代码规范化

在写代码时也要有一些原则或规范化的东西来指导。比如我们的项目也分了什么DAO、Service、Controller；而每个人可能叫的名字/开发时思路不一样，那么我们必须统一起来，如：

1、没必要一上来就抽象什么DAO、Service的接口，我的原则就是就一个实现类，因为我项目90%以上情况不需要接口这个东西，为了接口而接口只能使类的数量暴增；

2、所有类名必须见名知意，不能表达含义的全部重构；

3、配置文件的规范化，其实就是分类，按照功能分类配置；

4、比如spring bean的名字可以带上后缀， **Service、**Dao、**RpcService、**HttpService、**DataSource，见到名字后缀就知道这个功能是什么实现的。

不同公司的规范化可能不一样，遵循自己公司的一套规范化让代码朝着好的方向发展。

代码审查

代码审查对于一些新人我个人觉得是有必要的，因为新人来了不了解我们的原则、不熟悉我们的代码规范；此时应该通过代码审查机制来纠正或着带领着他们朝着我们一个共同的方向发展。通过代码审查可以纠正一些错误的或者不好的实现，找出一种当前最优的方案；还可以让新人意识到一些他觉得无所谓的问题。

代码重构

发现不好的或者坏掉的代码必须重构，因为如果觉得这段代码有问题，只要这个项目活着，未来的某一天肯定会出问题。一个没事或以后改吧可能导致一个重大的线上事故。因此发现不好的代码应该找时间立即重构。重构的目标也是架构原则指导的，不符合原则的就应该重构掉。

代码注释

很多人可能不屑于写注释，觉得代码就是注释；那我觉得可能是他没见过变态的业务需求，在我们项目中总是存在一些非常变态或着说是魔法代码，这些代码只有当时写的人理解，如果没有注释，你是不了解他那么做的意图的，会觉得很不可思议，但是实际上那就是业务需求。还有一些是我们依赖别人的接口，而这个接口也是非常不可接受的，但是已经有非常多的部门依赖不可能改的，此时也只能默默接受。对于这些变态的需求或者不可理解的需求写注释吧。