|
说起项目，每个程序员都应该搭建过自己的项目，而我也搭建过数十个企业级或互联网级项目;在做企业级项目时也抽象了一套通过的开发脚手架ES方便开发，也做过一些通用的代码生成工具来生成通用项目架子或一些CRUD的代码。做这些平台或项目的时候或多或少给我一些启示和原则，而这些启示和原则一直指导着我内心方向，时刻指导我不偏离航线。项目经理圈子
启示录blog.mypm.net
心中有原则项目管理者联盟
代码规范化项目管理者联盟文章
代码审查blog.mypm.net
代码重构项目管理者联盟
代码注释项目经理圈子
代码逻辑抽象项目管理者联盟
工具类www.mypm.net
项目闭环www.mypm.net
持续改进项目管理者联盟
自动化项目管理者联盟
心中有原则项目经理博客
我认为这是搭建和维护项目的灵魂，失去了灵魂，项目虽然能运行，但是未来是没有方向的。来了需求就接，最后就是修修补补。其实我个人认为心中有原则就是有未来预见性，能根据现有需求预见到未来的需求发展。talent.mypm.net
比如我做过的一个项目是需要依赖数十个系统，那么之前的做法是让所有我依赖的系统在变更时调用我的同步接口把数据同步过来，此处存在这么几个问题：假设IP或域名变了，需要通知所有依赖方;假设我们出问题了，各个依赖方需要自己进行重试;假设数据出问题了，需要通知依赖方再同步一下数据;这种方式产生了严重的耦合。因此在设计新架构时我们要完全摒弃这种方法，改用异步通知+拉取依赖数据的方式，如通过MQ通知我们数据变更了，然后通过依赖方提供的接口拉取数据;这种方式的好处：和依赖方松耦合;假设数据有问题再调用下依赖方接口拉取下数据修复即可。因此这个项目的原则就是异步通知+拉取数据。而如果依赖方不提供这种接口我们就无法满足他们的需求。还有一种特例就是有些依赖方的数据可以一天全量同步一次，那么可以使用定时任务每天跑一次;即定时任务+拉取数据。也就是说最糟糕的情况就是使用定时任务+拉取数据机制。项目管理者联盟
比如我们接到一个需求说需要在你们页面上加一个数据来展示，此时要我们在展示页面时调用他们的接口拿到数据然后展示，此处存在的问题是：我们如果强依赖他们，那么他们的抖动将影响我们页面的体验，虽然可以降级，但是我们也不能容忍一点点抖动;因此我们提供的方案还是异步通知+拉取数据，将数据存储到我们自己这边;或者前端异步加载。项目管理者联盟
心中有原则，即必须有一个或几个中心原则指导我们的架构不偏离航线，否则项目将朝着腐朽的方向发展，越做越烂，最后没有几个人能维护这个项目。也不能因为图一时之省事，而为未来埋坑。项目管理者联盟
代码规范化
在写代码时也要有一些原则或规范化的东西来指导。比如我们的项目也分了什么DAO、Service、Controller;而每个人可能叫的名字/开发时思路不一样，那么我们必须统一起来，如：项目管理者联盟
1、没必要一上来就抽象什么DAO、Service的接口，我的原则就是就一个实现类，因为我项目90%以上情况不需要接口这个东西，为了接口而接口只能使类的数量暴增;项目管理者联盟
2、所有类名必须见名知意，不能表达含义的全部重构;项目管理者联盟文章
3、配置文件的规范化，其实就是分类，按照功能分类配置;项目经理博客
4、比如spring bean的名字可以带上后缀， **Service、**Dao、**RpcService、**HttpService、**DataSource，见到名字后缀就知道这个功能是什么实现的。项目管理者联盟
不同公司的规范化可能不一样，遵循自己公司的一套规范化让代码朝着好的方向发展。项目管理者联盟
代码审查转自项目管理者联盟
|
