首先 规范不是无中生有，它是在一定条件下产生的，如果大家都有标准的认知 约定习惯，则规范可能并不需要明文规定，由于小组成员擅长的语言和领域不同，专业和培训 学习 履历经历不同，工作经验积累层次不同，经过三个月的磨合，发觉大部分工作中 仍旧存在一些糟糕混乱的现象，这些混乱虽然不至于导致项目彻底失败，甚至在庸碌的开发和低效固执的沟通中侥幸维持项目正常运行的局面。
小组中成员大部分所遇到的冲突为工作中认知冲突，由于大部分时间成员或固守己见，则由认知冲突又极其容易上升到个人的情感对立，使项目的有效推行又添加了阻塞。
所以为了解决一系列冲突和借鉴成熟应用广泛的开发模式，将对冲突的反思 梳理为规范，最后行程小组乃至整个团队的工作行为规范，特制定 小组代码规范，规范最终的目的不是为了撰写 是为了 贯彻落实执行，为项目 稳定高效运行提供最优解，为团队 组织沟通开发提供高效模式，为公司和股东节约时间按和成本带来更高的效益
以下规范 不代表最终规范，由于 认知冲突隐蔽性很高，每遭遇一次影响到高效开发的认知冲突都可能被规范约定起来，规范会不断迭代，不断添加更新更多内容
规范的制定不是为了限制团队成员的自由，规范是对自己的保护，当别人按照一定的秩序规范操作 有底线 有章可循，则自己受伤害的程度和可能性才能降低到最小。
需要解释的内容
1.这个规范是针对某些人而“量身定制”的吗？
回答：不是，首先前提内容已经说过了，原来的正规开发就是这样，现在没有规范，所以混乱，不是说谁暴露出来，规范就是针对谁的，暴露不按规范操作的成员其实只是一个不规范的载体而已，工作做事不是要针对个人，规范不是为了挑刺和整人，因为受害者和施害者都挺可怜的。
我们在公司沟通只有工作上的交集，单个违反规范的成员会影响到我和团队的整体工作效率，首要考虑的最终目标是优质产出，次要保证产出的前提下再谈团队友谊和感情，同样的错误，你会犯 我会犯 大家 不熟悉规范都会无意识触犯，在没有规范前，大家的冲突只是认知有分歧，在有规范后，再犯可能就是疏忽和没有遵守，如果某些成员 能感受到 某一条是为【“我”】量身定制的，说明你在进步，你已经意识到自己行为对团队整体认知和流程中带来的冲突，可以选择的方式是融入和抵制，如果你有更优秀的规范可以阐述，非常欢迎来补充我们现在这份比较初级的规范，让他更丰满更具有操作性。we are the team ,规范的作用统一思想 统一大家的认知 更好的产出
2.这个规范是个人臆想出来的吗？
回答： 工作五年 经历和教训很多，总结和反思的内容很多，每一条都是切身体会到遵守后带来的高效开发 的成就感不遵守带来种种开发事故 的苦果。每一条都是有充分的理由 背后的场景支撑，不保证是最有效的规范，但是他在规范无秩序的初始化状态是完全有效的，
每一条都可以在现实中找到 国内互联网公司在应用的实例和技术管理书籍 博客中类似思想的规范
3.规范制定的标准和原则都有哪些
回答： 1.是否有国内现在成熟的互联网公司在应用开源组织在使用 2.是否代表较为先进的生产方式或生产力 3 是否可以有效解决团队成员认知冲突和情感冲突 4.是否符合现阶段公司技术团队水平要求，是否会给大家带来沉重学习负担
5 如何督导检验规范团队成员的执行标准 6 每一项规范要求是否有足够的说服力和有效降低风险和开发成本及沟通成本 6.对规范操作是否设置了一定的激励机制和惩罚机制，如何规范团队每一个人的责任和义务
7 规范操作推行中会与旧的开发模式的抵制冲突，如何有效推行 8 如何解决规范执行中客观环境不友好支持的状况 9每一项规范都是要解决现实和未来要遇到的问题和风险，对应着具体要解决的问题
4.关于规范中频繁出现的情感词
规范中出现 【必须 需要 不允许 不承认 不接受 推荐 建议】等词 是为了告知和强调 每一条规范在执行中的迫切性程度 ，情感词不针对团队成员单个人，他只是一个语气词
5.这些规范会给我带来学习负担吗
回答：肯定会的，尤其当你刚开始很多无意识的开发习惯都与规范冲突的时候，他会给你带来一定的压力，但是学习是一种过程，当你不断通过自身努力，一条条实现了，成为一种习惯，反而它会成为你的一种软性资产，会在未来的工作和挑战中受益匪浅
1.etl_ml 相关的 java python 逻辑代码 需要使用公司的git 做版本管理【保证多环境部署时 所有环境下单一项目的代码是完全一致的】 这个是必须的
2.所有涉及到 接口 的请求使用统一 restful post 方式，不推荐使用get 方式 ，如果data 内容是 数组 或列表 ，必须使用post ，涉及敏感信息 外网可触达 必须使用post 返回报文格式 必须是
{
"flag":
{},
"data":
{},
"msg":
{},
}
或
{
"status":
{
"msg":" ",
"code": "200"
}，
"data" :
{}
}
其中 flag 必须是 整型数字，如果是 true false ，则使用 1 代表true ，0 代表 false，不可以是整型数字字符串 例如 “1”，错误异常 有标记 不可为空
msg 是字符串，必须是英文 或者 字母拼音，不允许使用汉字，错误异常 有标记 不可为空
data 返回请求的逻辑数据，合理装配，错误异常及无数据 返回为 null
flag 和msg 必须是一一对应的 kv 结构
msg和code 必须是 一一对应的 kv 结构
3.所有的接口 被调用方【生产者】， 自己的接口 必须自测 自检，自检自测 必须是发送真实 restful http请求，不承认不接受 jupyter zeppelin ipython 的notebook 测试方式【会与接口调用真实的标准输出的有较大格式和编码差异】，承认标准的 浏览器chrome fixbox safari 等 url 测试 和 专业的 接口测试工具 Postman等 接口测试，
接口测试成功 后需要将 测试的 url header 和参数 及返回结果相关 测试用例 以文本txt 或 word 文档形式 发送给调用方 【下游消费者】验证并写在wiki上,多个部署环境 需要说明 具体机器和测试环境 等相关参数，推荐包含阈值和状态临界值 的测试用例验证
4.接口被调用方 必须有标准的日志，按天分割 存储日志文件，不接受 nohup.out的日志查验 【无法做到日志分割，精准查验非常繁琐】
5.项目相关的java python scala 代码，每个业务类都需要有日志属性，每个业务方法都必须至少一行 有日志输出，开发模式 写代码-->添加日志-->单元测试
6.日志的输出格式 ，三类 info warn error，
日志内容【打印执行时间 | 记录的逻辑类名称 | 输入参数变量列表|日志特殊标记内容| 输出参数列表|异常打印内容】，日志可以使用中文，推荐全部内容使用英文
例如：
2018-10-30 09:48:54.093 INFO 134270 --- [lTaskExecutor-5] com.rms.quartz.Config.PredictVariable : 125527 mate file path : /data/rms/rms_train/rms_plus/saved_pmmls/pms/dt=all/mat/rule_125527.txt
2018-10-30 09:48:56.123 WARN 134270 --- [lTaskExecutor-5] com.rms.service.HttpReq : json body data some part : "flag": 6, "data": [{"hotel_id": "125527", "observe_date": "2018-10-30", "live_dt": "2018-10-30", "
8.单项目的日志不可以存放归档于项目根目录，必须有单独的 ./logs文件目录存放，且推荐归档压缩为 .zip gz 或 tar.gz
9.日志记录变量中含有数组变量 非常庞大的，推荐 对其做字符的截取，比如只记录前一百个字符，或者只记录关键状态信号量
10.接口生产者 需要对因为调用产生的异常 进行 try catch 捕捉，可以返回 异常信息的 输出，但必须保证 返回的格式不变，不可以将异常抛给下游调用者 或返回异常错乱信息，导致下游无法解析
11.接口调用协议 可以 是 restful http socket tcp ，可以是protobuffer grpc 可以是 thrift ，restful http 协议数据传输数据必须是json 格式
11.逻辑代码 涉及到打包，在不影响生产服务的情况下推荐在服务器打包，减少 本地到服务器 的流量传输，及部署环境差异带来的不稳定性，使用git 管理项目 ，git pull后然后打包
12.测试部署和正式部署的流水线操作 归一为一个bash shell 脚本，每次执行时 使用脚本运行代替 一些繁琐批量的操作
13.项目在多个环境 部署时 ps -ef |grep ** ,必须可以看到 全局机器机器变量，
例如 39 就是机器代号 test 是测试环境
nlpdev 168248 java -jar etl_ml-0.1.0.jar --spring.profiles.active=39-test
14.正式部署 的python 脚本 java jar 不允许出现类似 test snapshot 等非正式字眼【防止被其他人错误kill】
15.未来每个角色对自己负责的项目 需要撰写和维护自己项目的相关 调试部署文档，写明相关的具体变量和可能需要注意点 及异常情况的处理，检验标准是：团队成员可以通过你的部署文档可以独立部署 服务不出问题，部分还可以根据文档定位问题的位置
16.所有涉及到 具体可以修改 可以配置的常量及敏感信息 ，必须脱离业务逻辑代码，写入到配置文件文件并读取，多个环境则必须有多个一一对应的配置文件，不允许多环境共用同一个配置文件。
17.团队成员沟通 不允许使用不礼貌 不友好用语 比如【然后呢】，或带有个人偏见情绪 挑衅 用语，不允许答非所问，不明白不清楚用意，可以直接礼貌询问
18.代码必须模块化 必须是面向对象或面向函数式编程，模块必须封装为 class 或 namespace 或module ，生产环境不允许使用面向过程调用，测试 和单元测试可以面向过程
19.代码必须时刻保有重构的想法，自己有意识做code review，单一函数 不允许超过60行代码，if else 有四个连续 必须使用 switch case ，单个控制流程片段不允许超过25行代码
20 项目有高并发请求场景的，自己必须做高并发压力测试
21.项目结构 要有意识 使用成熟的设计模式来替代无意识松散的代码结构，推荐 单例模式 工厂模式 生产者模式 策略模式 装饰模式 观察者模式在代码中的应用
网友评论