论程序员的自我修养
论程序员必备的最最基础知识
1 字符编码
2 技术名词
要专业
3 语义化版本
（1）版本格式
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的API 修改。
次版本号：当你做了向下兼容的功能性新增。
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
（2）“依赖地狱”
概念：
软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的套件越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。在依赖高的系统中发布新版本套件可能很快会成为恶梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个相依套件改版才能完成某次升级）；而若依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。
当你专案的进展因为版本相依被锁死或版本混乱变得不够简便可靠，就意味着你正处于依赖地狱之中。
解决方案：
使用语义化版本控制规范
（3）语义化版本控制规范
1 . 使用语义化版本控制的软件“必须MUST”定义公共API。
2 . 标准的版本号“必须MUST”采用XYZ的格式，X是主版本号、Y是次版本号、而Z为修订号。每个元素“必须MUST”以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.1 1.0。
3 . 标记版本号的软件发行后，“禁止MUST NOT”改变该版本软件的内容。
4 . 主版本号为零（0.yz）的软件处于开发初始阶段，一切都可能随时被改变。
5 . 1.0.0 的版本号用于界定公共API 的形成。这一版本之后所有的版本号更新都基于公共API 及其修改内容。
6 . 修订号Z（xyZ | x > 0）“必须MUST”在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
7 . 次版本号Y（xYz | x > 0）“必须MUST”在有向下兼容的新功能出现时递增。在任何公共API的功能被标记为弃用时也“必须MUST”递增。也“可以MA Y”在内部程序有大量新功能或改进被加入时递增，其中“可以MA Y”包括修订级别的改变。每当次版本号递增时，修订号“必须MUST”归零。
8 . 主版本号X（Xyz | X > 0）“必须MUST”在有任何不兼容的修改被加入公共API时递增。其中“可以MA Y”包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号“必须MUST”归零。
9 . 先行版本号“可以MAY”被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII码的英数字和连接号[0-9A-Za-z-]组成，且“禁止MUST NOT”留白。数字型的标识符号“禁止MUSTNOT”在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。范例：1.0.0-alpha、1.0.0-alpha.1、 1.0.0-0.3.7、1.0.0-x.7.z.92。
10. 版本编译信息“可以MAY”被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须MUST”由ASCII的英数字和连接号[0-9A-Za-z-]组成，且“禁止MUST NOT”留白。当判断版本的优先层级时，版本编译信息“可SHOULD”被忽略。因此当两个版本只有在版本编译信息有差别时，属于相同的优先层级。范例：1.0.0-alpha+001、1.0.0+20130313144700、 1.0.0-beta+exp.sha.51 14f85。
4 命名规范
目录：最好全部小写
文件
变量：可以用驼峰式
5 书写文档
待完成
6 目录结构
src：源码
dist：编译生成目录
test：测试目录
doc：文档说明
其他根目录文件
7 正则表达式（程序员必备基础知识）
待好好学习
数据结构与算法
代码架构（非常重要）
1 设计模式
可以参考我写的关于设计模式的博客：
2 面向对象编程
3 面向接口编程（IOP）
4 面向切面编程（AOP）
代码评审
1 六种量化你代码的方式：
Think in percentages
Get involved with open source projects
Measure progress, not just products
Keep a work journal
Communicate in two languages
Collect recommendations
2 程序员必备的代码审查（Code Review）清单
常规项
代码能够工作么？它有没有实现预期的功能， 逻辑是否正确等。
所有的代码是否简单易懂？
代码符合你所遵循的编程规范么？这通常包括大括号的位置， 变量名和函数名， 行的长度， 缩进， 格式和注释。
是否存在多余的或是重复的代码？
代码是否尽可能的模块化了？
是否有可以被替换的全局变量？
是否有被注释掉的代码？
循环是否设置了长度和正确的终止条件？
是否有可以被库函数替代的代码？
是否有可以删除的日志或调试代码？
安全
所有的数据输入是否都进行了检查（ 检测正确的类型， 长度， 格式和范围） 并且进行了编码？
在哪里使用了第三方工具， 返回的错误是否被捕获？
输出的值是否进行了检查并且编码？
无效的参数值是否能够处理？
文档
是否有注释， 并且描述了代码的意图？
所有的函数都有注释吗？
对非常规行为和边界情况处理是否有描述？
第三方库的使用和函数是否有文档？
数据结构和计量单位是否进行了解释？
是否有未完成的代码？如果是的话， 是不是应该移除， 或者用合适的标记进行标记比如‘TODO’？
测试
代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
是否存在测试， 它们是否可以被理解？比如， 至少达到你满意的代码覆盖(code coverage)。
单元测试是否真正的测试了代码是否可以完成预期的功能？
是否检查了数组的“越界“错误？
是否有可以被已经存在的API所替代的测试代码？
3 代码审查过程
总体分三大流程： 代码审查流程（Code Review）→ 用户体验评估（UX）→ QA审查
WIP：work in progress 半成品
必备的网络知识
得懂点设计
得常常写点东西
团队合作
关注健康
提升效率
SOHO
