软件工程师！
分类： 项目管理
2015-08-13 16:23:35
作者：张开涛
说起项目，每个程序员都应该搭建过自己的项目，而我也搭建过数十个企业级或互联网级项目；在做企业级项目时也抽象了一套通过的开发脚手架ES方便开发，也做过一些通用的代码生成工具来生成通用项目架子或一些CRUD的代码。做这些平台或项目的时候或多或少给我一些启示和原则，而这些启示和原则一直指导着我内心方向，时刻指导我不偏离航线。
我认为这是搭建和维护项目的灵魂，失去了灵魂，项目虽然能运行，但是未来是没有方向的。来了需求就接，最后就是修修补补。其实我个人认为心中有原则就是有未来预见性，能根据现有需求预见到未来的需求发展。
比如我做过的一个项目是需要依赖数十个系统，那么之前的做法是让所有我依赖的系统在变更时调用我的同步接口把数据同步过来，此处存在这么几个问题：假设IP或域名变了，需要通知所有依赖方；假设我们出问题了，各个依赖方需要自己进行重试；假设数据出问题了，需要通知依赖方再同步一下数据；这种方式产生了严重的耦合。因此在设计新架构时我们要完全摒弃这种方法，改用异步通知+拉取依赖数据的方式，如通过MQ通知我们数据变更了，然后通过依赖方提供的接口拉取数据；这种方式的好处：和依赖方松耦合；假设数据有问题再调用下依赖方接口拉取下数据修复即可。因此这个项目的原则就是异步通知+拉取数据。而如果依赖方不提供这种接口我们就无法满足他们的需求。还有一种特例就是有些依赖方的数据可以一天全量同步一次，那么可以使用定时任务每天跑一次；即定时任务+拉取数据。也就是说最糟糕的情况就是使用定时任务+拉取数据机制。
比如我们接到一个需求说需要在你们页面上加一个数据来展示，此时要我们在展示页面时调用他们的接口拿到数据然后展示，此处存在的问题是：我们如果强依赖他们，那么他们的抖动将影响我们页面的体验，虽然可以降级，但是我们也不能容忍一点点抖动；因此我们提供的方案还是异步通知+拉取数据，将数据存储到我们自己这边；或者前端异步加载。
心中有原则，即必须有一个或几个中心原则指导我们的架构不偏离航线，否则项目将朝着腐朽的方向发展，越做越烂，最后没有几个人能维护这个项目。也不能因为图一时之省事，而为未来埋坑。
在写代码时也要有一些原则或规范化的东西来指导。比如我们的项目也分了什么DAO、Service、Controller；而每个人可能叫的名字/开发时思路不一样，那么我们必须统一起来，如：
1、没必要一上来就抽象什么DAO、Service的接口，我的原则就是就一个实现类，因为我项目90%以上情况不需要接口这个东西，为了接口而接口只能使类的数量暴增；
2、所有类名必须见名知意，不能表达含义的全部重构；
3、配置文件的规范化，其实就是分类，按照功能分类配置；
4、比如spring bean的名字可以带上后缀， **Service、**Dao、**RpcService、**HttpService、**DataSource，见到名字后缀就知道这个功能是什么实现的。
不同公司的规范化可能不一样，遵循自己公司的一套规范化让代码朝着好的方向发展。
代码审查对于一些新人我个人觉得是有必要的，因为新人来了不了解我们的原则、不熟悉我们的代码规范；此时应该通过代码审查机制来纠正或着带领着他们朝着我们一个共同的方向发展。通过代码审查可以纠正一些错误的或者不好的实现，找出一种当前最优的方案；还可以让新人意识到一些他觉得无所谓的问题。
发现不好的或者坏掉的代码必须重构，因为如果觉得这段代码有问题，只要这个项目活着，未来的某一天肯定会出问题。一个没事或以后改吧可能导致一个重大的线上事故。因此发现不好的代码应该找时间立即重构。重构的目标也是架构原则指导的，不符合原则的就应该重构掉。
很多人可能不屑于写注释，觉得代码就是注释；那我觉得可能是他没见过变态的业务需求，在我们项目中总是存在一些非常变态或着说是魔法代码，这些代码只有当时写的人理解，如果没有注释，你是不了解他那么做的意图的，会觉得很不可思议，但是实际上那就是业务需求。还有一些是我们依赖别人的接口，而这个接口也是非常不可接受的，但是已经有非常多的部门依赖不可能改的，此时也只能默默接受。对于这些变态的需求或者不可理解的需求写注释吧。
抽象是非常重要的一个过程，把项目中一些共性、经常用到的功能做抽象，抽象成公共代码或基础组件，这样对于这些功能就可以反复使用，这个过程是持续的，发现到共性就考虑重构抽象。这种方式可以提升我们的开发效率，简化业务逻辑实现。比如我们做的消息处理系统，只需要简单配置下就可以工作了。
在项目开发过程中，要带领团队成员使用常见的工具类，如apache commons、google guava等。使用这些工具类可以使得代码bug更少（最常见的如空指针异常）、代码更短、更易懂。
我们在做项目时发现有人把一个大项目分拆为多个子系统，然后这些子系统作为独立项目，然后当新人来的时候总摸不着头脑。因此我的做法是使用如Maven构建一个大项目，然后拆成各种子模块，整个项目都在一起的。
技术每天都在发生变化，因此我们要持续学习，了解目前对于项目来说最优的解决方案，然后适当的应用到项目中，进行项目的持续改进，有时候就是需要革自己命，持续发展；但是一定要有好的回滚策略，任何改进不能牺牲稳定性或增加事故率为前提，这个风险要有很好的把控。
对于一些运维或者业务相关的功能我们需要自动化完成；如果我们经常处理一些问题，那么可以考虑为这些问题构建一个自动化工具，减少我们的重复劳动。
我个人认为要搭建一个好的项目，就是要有好的价值观，不打破自己设立的原则，自觉自律朝着好的方向发展，不偷懒；任何人破坏我的代码我都要想办法纠正过来。
