坚持最高标准
道德经里有句话叫：“取乎其上，得乎其中，取乎其中，得乎其下”。
如果我们以最高标准为目标，可能只达到中等效果，而如果以中等标准为目标，却只达到很差的效果。为什么？因为人都有惰性，很难做到善始善终。所以制定目标一定要标准高要求，注意，“高”并不是不切实际的“空”。具体到工作中是如何体现高标准的呢？这里我从软件生命周期入手来说明如何确保各个阶段的高标准。
设计阶段-让项目的每个人都了解你的设计细节
当我收到新的项目时，我会先对项目本身做充分的了解和研究，并基于当前需求跟架构师进行讨论，确定架构风格和技术栈。然后对任务进行分解。我会让每个模块的负责人负责设计和具体实现。在设计的过程中要充分保证项目组的每个成员都了解你的细节，如果有一个人不了解，你就要重新讲，直到所有人都了解。
为什么一定要所有人都了解你的设计细节？我们从实际的设计过程来看，首先我们要在自己的脑海中梳理思路，梳理完成后会落到书面上，然后基于书面化的设计跟大家分享。但是实际上一个设计从你的脑海中落实到书面，再从书面通过你的声音传播到其他人的脑海里，每个过程都会丢失信息。也就是说你脑子里想的设计跟其他成员脑子里想的设计在很多细节上可能对不上。
所以在设计分享的会上，我会鼓励大家积极提问，不懂就问，No stupid question, only stupid anwser。这样就会强迫分享人去不断细化，而再细化的过程中可能就会发现自己的设计漏洞。一般经过两三轮的讨论，我们的成员对于整个项目的设计就都保持在统一的理解基础上。那这样有什么好处呢？不浪费时间吗？不会的，不光不会反而且会节约后面的沟通成本。举例来说，基于统一一致的理解后，当别人review你的代码时，会更理解你的实现思路。另外，QA同学越能更早的设计有效Case。这都大大减低了后期的沟通成本
编码阶段-单元测试的覆盖率一定要达标，否则代码不予合并
纵观整个软件生命周期，真正的开发时间不足40%，其他的时间都在分析问题，重新测试，重新打包部署等等。如果我们在开发阶段把单元测试的质量提升到更高标准，是可以大大降低后期的维护成本的。举个简单例子，如果我们在写单元测试时都能多考虑一些边界条件，异常情况，少出一些bug，那么项目的整体质量和维护成本都会得到保证。所以我个人比较看重单元测试，如果测试覆盖率不达标，代码不予合并
测试阶段-严把集成测试和性能测试
测试阶段我重点关注集成测试和性能测试。集成测试的质量能如实的反应各模块的开发进度，发现模块交互时才出现的各种问题，所以越早集成越好。
而性能测试则是可以量化的指标。在做性能测试时常见参考指标如下：
- 系统吞吐量（
TPS，QPS） - 并发用户数
- 并发请求数
- 平均响应时间
- 错误率
- 平均传输带宽 对于上述指标，我们测试初期就要根据用户的实际使用情况设置参考值，参考值的设立也是要从高从严，从而保证系统在极端情况下的可用性
总结
上述三点分别对应开发周期的设计，实现和测试阶段。每个阶段尽量设置可量化的指标从而最大程度的保证项目的质量和进度。我喜欢前紧后松的风格，前期对项目进度和质量从严要求，从而在后期不至于让大家太紧张焦虑，大家都能明显感觉越到后期压力越大，所以我愿意把这种压力分摊到前面的阶段。我的成员在切身感受到这种方式带来的好处后也会更加积极配合，从而形成一个良性循环。
