《编程一万小时的反思》阅读心得分享
原文参见：
英文原文：https://matt-rickard.com/reflections-on-10-000-hours-of-programming/
中文译文：https://www.oschina.net/news/154219/reflections-on-10000-hours-of-programming
近期认真阅读了一下 Matt.Rickard 总结的《编程一万小时的反思》， 并且和几位同学进行了一些交流。
把我们交流的一些非常有共鸣的点简单总结如下。
核心要点
官方文档和源码是最重要的，如果二者有冲突，以源码为准。
- 原文内容：阅读源代码常常会比在 Stack Overflow 上更快找到答案。
- Browsing the source is almost always faster than finding an answer on StackOverflow.
- 原文内容：从最好的资料中进行学习（这里 Matt 举例称他在学习 Go 时阅读了标准库）。
- Only learn from the best. So when I was learning Go, I read the standard library.
- 对于使用到的各种软件和工具，尽量多看官方文档、少看他人解读的”二手资料”
- 请记住：源码一定是对的；如果发现资料/书籍有问题，请看源码；如果发现官方文档有问题，请看源码。
代码如果不好写单元测试或者不好测试，一般代码可能也不够好。
- 原文内容：如果代码看起来很丑，那很可能是一个严重的错误。
- If it looks ugly, it is most likely a terrible mistake.
- 如果代码不好写测试，往往也是设计或者实现上还有优化空间（非绝对）。
KISS原则：Keep it Simple and Stupid.
- 原文内容：尽可能多地删除代码。
- Delete as much code as you can.
- 原文内容：简单往往是最难的。
- Simple is hard.
- 尽量保持代码简单、可读性强，不要炫技、如果可能尽量不要用复杂方案。
- 每多一行代码，就多一个出错的可能性。所以可要可不要的代码就不要。
- 建议阅读《Unix编程艺术》，微信读书有电子版、或者可以买纸质版。（豆瓣评分9.0）
最好的注释即代码。
- 原文：如果必须编写不是文档字符串 (docstring) 的注释，则应该考虑对这段代码进行重构。
- If you have to write a comment that isn’t a docstring, it should probably be refactored. Every new line of comments increases this probability. (For a more nuanced take, the Linux Kernel Documentation)
- 只添加必要的注释；千万不要觉得注释越多越好，阅读注释也有成本。
- 如果你的代码可读性足够强，那么大部分地方不需要注释；此外，维护注释也需要成本，容易出现改了代码忘改注释的情况。
命名非常重要，命名做好了，代码已经成功了一半。
- 原文：正确命名变量，这也是一门艺术。
- Name variables correctly. Again, an art.
- Bob大叔在《代码整洁之道》一书中第2章即花大篇幅介绍”有意义的命名”，所以命名的重要性可见一斑，建议阅读该章内容。
- 命名要点包括：
- 名副其实
- 避免误导
- 做有意义的区分
- 使用读得出来的名称
- 使用可搜索的名称
- 避免使用编码
- 避免思维映射
- 类名、方法名分别有约定
- 每个概念对应一个词
- 别抖机灵、别用双关语
- 使用解决方案领域名称、使用源自所涉问题领域的名称
- 添加有意义的语境、不要添加没用的语境
- 我们不要认为自己只是个码农，而应该是个”代码艺术家”，要对代码之美有追求。
努力成为10倍工程师。
- 原文：部分程序员的效率是其他程序员的 10 倍。
- Some programmers are 10x more efficient than others. I know because I’ve been both a 10x programmer and a -1x programmer.
- 原文：成为 10 倍程序员与 10 倍员工这两者之间没有相关性（或许是负相关）。
- There’s no correlation between being a 10x programmer and a 10x employee (maybe a negative one).
- 虽然是否真的存在10倍工程师还有争议，但是此处重在强调应该成为一个专业的、有职业素养的优秀程序员。
- 可以搜索”10倍程序员”看看相关内容。
- 建议阅读 Bob 大叔”整洁之道四部曲”：《Clean Code》、《Clean Coder》、《Clean Architecture》、《Clean Agile》
- 这4本书直译过来叫做：代码整洁之道、程序员整洁之道（实际中文译本叫做：《代码整洁之道：程序员的职业素养》）、架构整洁之道、敏捷整洁之道。
- 针对如何成为一个有职业素养的专业程序员，尤其推荐首先阅读《Clean Coder》。
防御性编程：不要相信任何输入，所有的输入都要设想可能是非法输入。
- 原文：好的 API 易于使用且难以误用。
- Good APIs are easy to use and hard to misuse.
- 原文：避免多层嵌套条件。
- Avoid nesting conditionals deeply. Have common sense about your conditional tests and naming convention.
- 好的 API 易于使用：命名合理、可读性强，输入输出设置合理且扩展性好。
- 好的 API 难以误用：针对各种可能的误用情况进行必要校验并给出可读性强的报错信息提示。
代码与配置分离，一般不要硬编码
- 原文：配置七边形（Matt 自创的术语）从硬编码值开始，到环境变量、CLI Flag、配置文件、模板化配置文件、DSL、通用 bash 脚本，再到硬编码值。开发者应了解这个七边形中的各个位置。
- The configuration cycle goes from hardcoded values to environment variables, to CLI flags, to a configuration file, to a templated configuration file, to a DSL, to a generic bash script, and back to hardcoded values. Know where you are on this Heptagon of Configuration.
- 可以采取的策略包括：使用常量、使用环境变量、使用配置中心等。
小结
- 要成为一个优秀的、有职业素养的专业程序员绝非易事。
- 作为一名程序员，应该对代码之美有高追求。
- 为了写出优雅、具有美感的代码和成为代码艺术家，推荐阅读：
- 《Unix编程艺术》
- 《Clean Coder》
- 《Clean Code》
- 《Clean Architecture》
- 《Clean Agile》
