这是我参与「第五届青训营 」伴学笔记创作活动的第 4 天
编码规范
代码是写给人看的而不是写给机器看的，所以代码的“质量”，决定了一个软件的生命周期、利润率以及人力资源利用率，本部分实质上属于项目管理的质量管理范畴。软件项目难于管理是导致“软件危机”的主要因素，其中软件的质量管理又是决定项目成败的重要部分。而所谓高质量的代码，是指能为项目带来正向促进的代码，即具备“简单性”、“可读性”及“开发的高效率性”。
代码格式
每个团队往往会设计实现自己的格式检查插件，将代码自动格式化为团队统一的结果。可以参考Google等公司的编码规范。
注释
注释的作用就是What，Why, How和Error, 另一种理解的方式，对于一个函数黑盒，我们需要解释黑盒的输入输出（包含错误情况的解释），以及黑盒的内部构造，以及黑盒的作用。
其中What一般用来解释公共符号，因为公共符号往往无法仅仅通过函数名确定其功能。 How一般用来解释函数的实现过程，当然过于简单的实现过程没必要加注释，好的代码本身就是注释。 why一般用来为不太常见的功能实现过程提供额外的上下文，解释代码这样实现的原因。 Error用来解释代码可能出错的边界条件，主要是为了便于错误处理。 ! 注意：公共符号一般情况下都需要注释。命名规范
变量名与函数名能提供更多的上下文信息，好的命名方式可以提高团队编码的效率，所以越是被远距离调用的变量越是需要更长的变量名来提供更多的上下文信息。所有命名规范的规则的核心就是在该提供语义的地方提供合适长度的语义，在不该使用长变量名的时候缩短变量名。好的命名就应该像一个浅显易懂的笑话。
控制流程
原则：避免嵌套，保持到正常执行代码的路径最短，减少复杂的循环和条件语句
错误和异常处理
错误处理针对错误的不同类型使用不同的错误处理资源，小的错误简单抛出即可，需要注意对错误链的链式错误抛出，方便Debug，由于panic的严重程度高，所以只有当出现可能导致程序崩溃的情况下再去使用panic。错误处理使用recover要注意recover生效的条件和范围。
性能优化
Benchmark
性能优化使用Golang中提供的Benchmark来试验不同的调用方式可能导致的性能的差异
切片优化
切片的底层实现是可以扩容的数组，所以对于切片最好做到预分配合适的大小，减少扩容的时间消耗，由于切片存在复用的现象，所以小的切片最好不要去通过引用大的切片实现，因为这样底层的大切片无法被释放，白白占用了内存。
Map优化
Map的优化和切片类似，最好提前分配好大小。
字符串处理
字符串的处理Sting.Builder的效率最高，bytes.Buffer次之，最差的是直接使用+，因为+每次都会重新分配内存，bytes.Buffer也会重新分配一次内存。
使用空结构体作为占位符
空结构体不涉及内存的分配，但是同时又具有语义信息。
引入atomic包
sync包中的功能最好是对于大段代码实现同步与冲突处理时使用，因为他们涉及到了系统调用，而atomic是通过硬件实现的。
性能优化是建立在可靠的高质量的代码之上的所需要完成的需求，过度的优化会加高系统的维护成本，也可能导致系统出现Bug。重要的是根据项目需求找到平衡。
