幸存工程师律法

我知道大部分人并不想当专职的工程师，但是，如果你的工作里有一部分是用文本编辑器写代码、并用这些代码跟别人交流的话，应注意一些最基本的规范。使用“幸存”这种耸人听闻的字眼是为了强调，这些是下限。

我认为这些小的细节背后的原因是如此不言自明，是一眼区分一个人是否适合将代码作为职业生涯的标准。但让我沮丧的是很多人可能一辈子都在业余的沙漠上打转、写着没人在乎的代码、因为缺乏起码的规范而在调试上浪费了无数时间、出了问题会抱怨“这谁能想到啊”，最后依然理直气壮地反问“又不是不能用”。

额外说一句，下面都是零碎的知识点，我建议每个人都能完整读完《程序员修炼之道》，而进读一读《代码大全》。

编辑器

首先，不限编辑器种类，但要确保你的编辑器有最基本的功能

不限语言，纠正最基本的格式问题：超过三个连续 \n 应控制为三个，删除结尾空白字符，尤其是，任何经编辑器修改过文本文件，保留最后一行的换行，即文件最后一个字符是 \n。
你的编辑器应该能识别各类代码质量工具，如 editorconfig、black、eslint、shellcheck 等，且能自动执行，或者能够在保存时执行。

确保自己了解密钥对，把公钥以自己习惯用户名为文件名，保存在 ssh-key 目录

如果需要给某人开通某台机器的权限，也直接在 ssh-key 目录找对应公钥并添加在目标机器的 ~/.ssh/authorized_keys 文件中

擅用 .gitignore，确保不会提交不该提交的文件，如 .DS_Store、*.pyc、*.swp 等。

通用模板在 github/gitignore 中，拿来并针对自己项目作修改。

提交时应认真检查添加、修改了哪些文件，如果提交了带冲突标记的文件、或者无关的临时文件，会显得自己很不专业，应尽量避免。

了解你的 ~/.gitconfig 文件，有用户/邮箱的配置，且在所有工作机器上统一，如

[user]
	email = [email protected]
	name = Zheng Kai

这样当你在不同机器上提交时，不会出现各式各样的名字。

确保执行过如下命令，以便在 git pull 时自动执行 git rebase，且自动保存当前工作区，不然 commit 会很丑。

git config --global pull.rebase true
git config --global rebase.autostash true

其实更正确的做法是维护一个统一的 ~/.gitconfig，但略麻烦，上述命令只是个简单有效的补救。

尽量让各种配置多走 ENV

Dockerfile 应关注镜像大小、打包速度

（TODO：具体例子以后补）

应该用 nginx 管理自己机器上的所有对外服务（即所有服务只监听 127.0.0.1，由 nginx 控制哪些可以对外访问）。这样做的好处是有非常完整的 log 方便调试、可以自定义 CORS 等 Header、如果更换服务可以只改 nginx 而不用改所有配置里的地址。

代价是有些场合需要额外调整配置项，如 websocket、长连接、大文件上传等，但熟悉后都不是问题。

注意 access_log 和 error_log 都要保留，因为验证是要交叉的，例如你发现某个网址没法清缓存，有可能是压根不是那台机器，从 access_log 就能看出来压根没有访问记录。

我个人习惯是用个脚本每天 23:59 执行，把 access_log 和 error_log 分别切割为日期文件名的文件，方便查看历史。

各种环境变量原则上全大写、下划线分隔，如 MYSQL_HOST、REDIS_PORT 等。

从项目创立之初，就应该考虑各种配置进环境变量，通过覆盖本地配置文件的形式来部署到不同环境。

不要把任何敏感 key 放进代码库。如果一个代码库跟工作相关，不要放到任何开放的代码库中，如 github、gitlab 等，私有的也不行，因为一旦设错权限，你压根不会察觉，而网上的各种爬虫在你上传的几秒内就可能读取完毕，你根本没时间反应。