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