1.沟通效率问题
有协作必然就有沟通，提升沟通效率最好的办法就是构成默契，要构成默契就要经过规范和商定等伎俩把大家圈在同个言语频道上。需求阶段的沟通比较多，如统术语，需求结构化表达，统业务身份。
（1）统一术语。这在一个公司非常重要，比如在某些公司，“PM"这个词是指产品经理，而在另外些公司是指项目经理；还有诸如应用，系统，模块这些基本的称谓，假设大家理解不一样的话会很糟糕。
在公司中构成术语也有些技巧。比如给产品取一个好名字，名字既可成为术讲也可以是很好的传播符号，像滴滴的个效劳框架叫DiSF （ didi service framework，滴师傅），这个名字有内容、有含义很容易被记住。在公司中与人沟通也是一样，假设很难一句话向别人说清楚某个产品或者项目，那么推行起来就会比较费力，因此，把自己的产品，项目或任何需求向别人表达的事情术语化可以减少沟通的成个。
（2）结构化表达需求。互联网公同中都是需求驱动产品和技术的，提出需求的人大多都是运营和产品经理而非技术人员，这就不可避免地存在不同岗位人员的沟通理解问题。需求的结构化表达就是把需求用“ 系列的术语、图标、页面等可以更好理解和呈现的方式（普通产出就是PRD）在同一个语境中表达出来，让对方更好的理解。沟通需求的过程就是把不肯定性肯定下来的过程，需求越细致沟通越容易。把需求结构化，和把系统中需求经常改动的逻辑配置化要抵达的效果是样的，最终产生的结果就是一个变卦记载。
（3）统业务身份。业务身份是管理一个业务在各个业务城中定义的业务规则索引，是一串平台可识别的编码，该编码由构成业务的要素经过一定组合关系运算生成，在平台的运转城中，各个业务域的系统根据输人的参数条件，中止业务身份判别运算，最终根据识别出的业务身份结果，执行该业务在本系统定义的业务规则。要完成统一业 务身份必需求处置：
系统之间同一项业务的联通性问题，让系统自动呈现业务整体视图；
业务条件没有生命周期管理、系统长期维护困难的问题，要统一业条件识别；
业务上下线相互影响、回归工作量大和效率较低的问题。这就要对业务逻辑中止才干笼统，树立封锁性，从而隔离业务。
对业务身份中止统一管理，需求完成：对业务身份标识的统一注册和管理，普通需求构建一个运营平台；有业务规则的配置界面；规则的执行引擎，所以统一业务身份需求人口的注册管理、规则的配置与变卦，以及规则的运转域，缺一不可。
2.开发效率
如何高效地写代码是程序员永世的话题。这触及很多要素，如程序员对代码言语本身的控制程度（比如JDK8中引人闭包代码可以使代码更简约），写代码所用的IDE以及快捷键的运用程度，等等。笔者在这里先抛开这些问题，阐述下从开发到测试再到运维的整个效率问题。
开发，人员都不希望别人乱碰自己写的代码，对代码有绝对的控制权，所以普通都喜欢掌控（Owner）系统，即这个系统我说了算。在这种情况下，曾有一段时间我们把系统拆得很小，结果降生了很多同质的系统，越来越多地在做重复的事情；此后又阅历了系统兼并的阶段。但是，系统兼并也会带来新问题，即开放过程中抵触比较凶猛，包括打包部署的效率都很低，在这种情况下会有两种处置方案：一是开发态和运转态分别；二是对系统中止分层和笼统建模。
所谓开发态和运转态分别，就是大家线下的开发都是独立中止的，包括打包和部署，接口的调用分开，走远程调用。但是在线上部署时，都是部署在同一个容器中，把远程调用变本钱地调用。这种思绪我们在“兼并部署”一章中有引见，本质上可以做到开发态和运转态的分别，同时统筹开发效率和运转效率。
3.测试效率
整个软件生命周期触及很多环节：需求、开发、测试、上线、运维…触及很多协作。这些环节都会对效果有影响。其中，测试效率非常重要，由于测试花费的时间几乎和开发所花的时间是一样的。关于如何提升测试效率，我们总结了一些理论阅历，分述如下。
（1）全链路Beta测试
继续坚持Beta环境与线上环境的分歧性，将中心链路上的应用，Beta环境HSF打通，减少90%由于环境问题招致的P1、P2缺点。
打通之后，可以完成以下效果
测试环境可以做到召之即来，挥之即去；
在分批发布前，可以在极短的时间内有针对性地考证中心功用；也可以选择性地屏蔽 Cache的访问；数据轨迹可以实时显显露。
4.运维效率
运维包括线上和线下两部分，运维效率会在两个环节表现得最明显，一个是线下的打包编译步骤、代码分发步骤；一个是线上的下线一重启一上线步骤、发布检查步骤和回滚步骤。下面我们分别看看在这些环节有哪些中央可以优化。
1）打包编译环节
优化流程。环境分配，可以预先分配好代码copy，要主动准备而不用每次编译代码时再做环境方面的准备工作；
预处置。监控代码版本修正，当代码被修正后，自动触发代码兼并抵触检查做代码编译和打包操作，不要等到用户点击再触发；每个分支代码更新主动和主干做 Merge，发现有抵触要主动通知相应开发人员修正，不要等到打包部署时再暂时修正；
代码编译优化。规则检查，业务依赖的包要做依赖规范化管理，经过工具识别依赖；减少应用依赖 SNAPSHOT版本Jar，可以俭省 Maven编译时间； Maven打包优化，优化 Maven配置减少不用要的消耗；
增量编译。减少编译时间的办法之一就是只编译变化的部分；比较代码修正时间和编译的代码更新时间可以区分那些修正的类，并针对它们做增量编译，大大减少编译时间。
打包机器硬件升级。提升编译速度的另一个办法是升级机器硬件，运用更多的CPU或者更多的内存可以明显提升编译速度；多组机器 standby以处置并发修正情况，并不断坚持应用处于可用状态，减少开发上厕所的次数。
（2）代码分发步骤
代码分发主要思索两个问题，一个是代码的下载，最好是支持P2P下载，这样的下载效率最高（固然大部分情况是HTTP下载较多，但真心不建议采用）；二是假设代码包比较大且同时下载的机器比较多时，要思索下载机器的网卡流量能否满足，这点必需特别留意。
（3）下线、重启、上线步骤
下线环节。下线被动等候15秒安康检查失败，能否主动通知LVS下线，而不是被动等候3次3秒的检查失败后再下线；
重启。初始化各种效劳，去掉不用要的效劳初始化，将一些效劳改成慢加载，部分效劳可以并行初始化。
（4）回滚
回滚等于重新发布，直接应用本机的老war包快速重启，不需求再走包分发网站树立步骤，要有手动回滚脚本。假设回滚时间长则减少回滚批次，采用发布一批机器就下线一批机器的方式：下线的机器坚持 standby，老代码不提供效劳，呈现问题后再立即下线新发布的机器，将 standby的机器立即上线。这样可以快速抵达回滚的目的，在30秒内就能完成回滚。
