请关注我的微信公众号
个人微信公众号
技术交流群 (仅作技术交流)：642646237
请关注我的头条号：
代码治理
让各个服务中的开发人员遵守相同的开发规范。
使用范例
编写文档是有用的，或提供一系列的代码范例。
如果在系统中有比较好的代码范例可以模仿，那么开发者也就不会错得很离谱。
理想情况下，提供的优秀范例应该来自真实项目。
裁剪服务代码模板
当开发人员想要实现一个新服务时，所有实现核心属性的那些代码都应该是现成的。
针对自己的开发实践裁剪出一个服务代码模板，不但可以提高开发速度，还可以保证服务的质量。
裁剪服务代码模板——使用Dropwizard或Dropwizard微容器（从命令行启动的嵌入式servlet容器）
Dropwizard和Karyon都是是基于JVM的开源微容器，都会自动下载一系列第三方库，通过这些库可以提供一些特性，比如健康检查、HTTP服务、提供指标数据接口等。
在实际工作中，以Dropwizard和Karyon为基础，然后根据自己的上下文加入更多的定制化特性。
裁剪服务代码模板——注意事项——所有技术栈都需要各自定制服务代码模板
如果使用多种不同的技术栈，那么针对每种技术栈都需要这样一个服务代码模板。
裁剪服务代码模板——注意事项——共同创建服务代码模板
有一点需要注意的是，创建服务代码模板不是某个中心化工具的职责，也不是指导（即使是通过代码）我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践，所以你的团队也需要负责更新这个模板（内部开源的方式能够很好地完成这项工作）。
裁剪服务代码模板——注意事项——避免服务代码模板过重
基于代码重用的目的，越来越多的功能被加到一个中心化的框架中，直至把这个框架变成一个不堪重负的怪兽。
如果决定要使用一个裁剪的服务代码模板，一定要想清楚它的职责是什么。理想情况下，应该可以选择是否使用服务代码模板，但是如果强制团队使用它，一定要确保它能够简化开发人员的工作，而不是使其复杂化。
裁剪服务代码模板——注意事项——避免因为重用代码引入服务间耦合
把服务代码模板简单地做成了一个共享的库依赖，必须小心地防止对DRY（Don't Repeat Yourself，避免重复代码）的追求导致系统过度耦合！
网友评论