关于开发规范的一些想法

最近协助整理组内的开发规范，整理思考了一段时间之后梳理出了一个初版，自己也来总结下这期间的一些想法。

规范到底需不需要

有规范或是没规范，这个应该不难得出结论。有比没有好，有了规范即使没有执行也不过就是和没有规范一样，所以还是要有。

规范的好处在于明确一个方向，“取乎其上，得乎其中”，也是在面临一些问题判断时的抉择依据。

提升专业性，提升质量，避免可能重复出现的低级问题，提升全局效率。

之前对所谓规范不置可否的原因在于很多规范是不易落地或是过于麻烦的。如果想让规范能够去实施，那么按照个人的理解，规范必须简明。不要在细节以及容易产生个人偏好的问题上去纠结。抓大放小，只关心核心问题。

如果在项目之初就有一份成熟的规范，那么可能可以更有针对性的去把控。但实际往往都是在一定时间后，根据现实遭遇的一些问题而整理出规范，在这种情境下，规范关键点的输出结果会比规范如何去做的流程会更容易被接受或实施。

一是参考能了解到的优秀团队的做法，二是调研周边团队实际落地了的做法，三是从已有未明确化的工作流程中梳理。

对于一些强势管理风格的团队，可能自上而下强制推行。但如果不采取那么生硬的方式，那么规范必须要在团队内达成共识。

首先是目标的共识，其次是方式的共识，再次是推进手段的共识。

否则定义的规范再多也只是空文，甚至带来比较不好的负面抵触情绪。

对于一些遗留项目的处理也是规范能否落地的关键，例外不是不能有，但一定需要是必要的。否则例外多了，例外就成了常态，规范反倒成了例外。

推进需要落实到具体的任务中，设置改进的时间点并进行追踪。改进的工作要计入工作计划中。

能与工具自动化结合的尽量结合，不能的也定期抽查检验。

规范需要是活的，需要根据项目的实际运行情况来进行调整与进化。