代码最重要的读者就不再是编译器、解释器或者电脑了，而是人。写出的代码能让人快速理解、轻松维护、容易扩展的程序员才是专业的程序员。
在代码阅读过程中人们说脏话的频率是衡量代码质量的唯一标准。 —— Clean Code
为人写代码，而非机器。真正高手所写的代码，像水晶一样晶莹剔透，还配有文档。
编程工作的特殊性
- 老板无法强迫你成为优秀的coder
- 这是一个无法监督的工作，没人真正知道你在干什么
- 不同人编程的时间差异可达10:1;
好的编程实践
- 将系统分解，为了使之更易于理解
- 进行复查（评审），和他人沟通，减少人为失误，提交代码质量
- 将子程序写得短小，以减轻大脑负荷
- 基于问题而不是底层实现细节来编程，从而减少工作量
- 通过各种各样的规范，将思路从相对繁琐的编程事务中解放出来
求知欲
- 每两个月阅读一本计算机热门书籍
- 学习成功的项目开发经验
诚实
- 不是高手时不要假装自己是高手
- 乐于承认错误
- 力图理解编译器的警告，而非弃之不理
- 透彻理解自己的程序，而不要只是编译看看能否运行
偷懒
- (Low)拖延不喜欢的任务
- (Good)迅速做完不喜欢的任务，以摆脱之
- (Cool)编写某个工具来完成不喜欢的任务，以便再也不用做这样的事情了
坚持
- 根据环境或场景的不同，坚持可能是财富，也可能是负担
习惯
- 习惯的力量
线上Bug
- 犯错不是罪过，从中学不到东西才是罪过
高质量业务代码
- 业务代码编写范式
- 常见的 js 业务场景分析以及解决思路
- 解耦你的业务 js 代码，如何在业务中使用设计模式
- 常见的一些业务优化方法总结
- 增加你的项目可维护性和代码可读性
代码书写层面优化
Bad
- regxz.san
- appLine.san
- data.san
- …
命名的优化是最简单有效重构
- 找到更有表现力的词
- 这个名字会被别人解读成其他的含义吗？
- bad: get , fetch / download
- stop: kill / pause
1
2
3
4
send: deliver dispatch annouce distribute route
find: search extract locate recover
start: lauch create begin open
make: create set up build generate compose add new
把信息装到名字里
- 选择专业的词
- 避免空泛的名字，像tmp和retval，除非使用它们有特殊的理由，使用专业的单词——例如，不用Get，而用Fetch或者Download可能会更好，这由上下文决定
- 避免泛泛的名字（或者说要知道什么时候使用它）
- 使用具体的名字来更细致地描述事物——ServerCanStart()这个名字就比CanListenOnPort更不清楚
- 用具体的名字代替抽象的名字
- 给变量名带上重要的细节——例如，在值为毫秒的变量后面加上ms，或者在还需要转义的，未处理的变量前面加上raw
- 使用前缀或后缀来给名字附带更多信息
- 决定名字的长度
- 为作用域大的名字采用更长的名字——不要用让人费解的一个或两个字母的名字来命名在几屏之间都可见的变量。对于只存在于几行之间的变量用短一点的名字更好
- 利用名字的格式来表达含义。
- 有目的地使用大小写、下划线等——例如，你可以在类成员和局部变量后面加上”_”来区分它们
代码逻辑层面优化
最小化嵌套
- 通过提早返回来减少嵌套
- 在循环中，与提早返回类似的技术是continue：
拆分超长的表达式
- 用做解释的变量
- 总结变量
德摩根定理
1
2非(P 且 Q) = (非 P) 或 (非 Q)
非(P 或 Q) = (非 P) 且 (非 Q)拆分巨大的语句
缩小变量的作用域
- 使用“闭包”解决作用域问题
重新组织代码
抽取不相关的子问题
- 看看某个函数或代码块，问问你自己：这段代码高层次的目标是什么？
- 对于每一行代码，问一下：它是直接为了目标而工作吗？这段代码高层次的目标是什么呢？
- 如果足够的行数在解决不相关的子问题，抽取代码到独立的函数中。
从逻辑到代码
- 把想法变成代码，拿出纸和笔，从逻辑到函数的映射
- 纯工具代码
- 创建大量通用代码
使用npm包解决问题
- date-fns
- share-config
- 熟悉你周边的库
关注页面性能
- 文件（图片、js文件）的大小
- 是否请求太多
- 后端响应速度
- …
代码评审
- 代码阅读的顺畅感
- 代码的重复性、复用性
- 业务逻辑的理解性
- 关键设计的遵循度