Matt Rickard 是在谷歌从事 Kubernetes 开源工作的开发者，主要负责构建和维护 Kubernetes 开发者工具，例如 minikube 和 skaffold。此外他还作为 Kubeflow 项目的维护者负责机器学习管道方面的工作。

根据 Matt 的介绍，他已刻意投入了一万小时用于训练编程技能。Matt 拥有大约 15 年的编程经历，目前在谷歌 Kubernetes 和私募股权公司 Blackstone 担任专业软件工程师。在此之前，Matt 在大学的大部分时间都在图书馆为自己的项目编写程序。而在更早之前，他尝试过各种各样的事——在 RuneScape 上运行一个僵尸网络、为 iPhone 编写一个拉丁语翻译应用、编写自己的配置语言、创建一个网络剪辑器，或者深度定制自己的桌面环境。

在这一万小时的编程训练中，Matt 最近的工作与分布式系统相关，但他曾经编写过许多技术栈的代码。编程语言方面使用过 PHP, JavaScript, Go, Ruby, Python, C#, Java, Swift，技术领域曾涉猎过前端、后端、移动端、内核、云、运维等。他还曾参与过像 Kubernetes 这样的大型开源项目，并维护过子项目。

对于编程一万小时的反思，Matt 强调这次的总结是纯粹的关于编程的思考，不会讨论技术管理、职业发展相关的话题。

以下就是 Matt 编程一万小时后的 31 条反思：

• 阅读源代码常常会比在 Stack Overflow 上更快找到答案
• 大多数情况下，如果你正在做的事情无法在互联网上找到答案，那么这通常意味着这个问题很难或者很重要，或者两者都是
• 尽可能多地删除代码
• 语法糖通常是不好的
• 简单往往是最难的
• 拥有各种各样的工具，并知道该用哪些工具来完成工作
• 了解最常用的工具的内部结构，如 git 和 bash
• 为重复的工作流程构建自己专用的工具
• 从最好的资料中进行学习(这里 Matt 举例称他在学习 Go 时阅读了标准库)
• 如果代码看起来很丑，那很可能是一个严重的错误
• 如果必须编写不是文档字符串 (docstring) 的注释，则应该考虑对这段代码进行重构
• 如果不了解所编写的程序是如何在生产环境中运行的，那就说明不了解程序本身。优秀的工程师知道他们的程序在各种环境中是如何运行的
• 上面这条经验对于构建管道也适用
• 谨慎使用他人的代码
• 互联网上找到的代码大多数都很糟糕，有时候自己写一个更好的版本会更容易
• 永远不要直接依赖自己可以轻松重写的小型库，或本应很小的大型库
• 知道什么时候该打破规则。对于“不要重复自己”这种规则，有时候重复比使用依赖要好
• 将代码组织成模块、包和函数很重要。了解 API 的边界位置是一门艺术
• 大多数情况下应选择最有效的工具，但也要选择自己所知道的。Arch Linux 是现代开发者最高效的操作系统吗?对我来说，是的，但对大多数人来说，可能不是
• 避免圈复杂度 (Cyclomatic complexity)
• 避免多层嵌套条件
• 正确命名变量，这也是一门艺术
• 虽然很少见，但有时报错可能确实是编译器的问题
• 谨慎使用深奥的语言特性，但在应该使用的时候还是要使用
• 技术的传播并不均衡对等。例如，前端开发者可以从负责底层技术的工程师那里学到许多东西，云工程师可从 JavaScript 开发者身上学到用户体验和可用性方面的知识。但反过来却未必成立
• 因此，不同类型的工程师看待世界的方式是不同的
• 部分程序员的效率是其他程序员的 10 倍
• 成为 10 倍程序员与 10 倍员工这两者之间没有相关性(或许是负相关)
• 好的 API 易于使用且难以误用
• 配置七边形(Matt 自创的术语)从硬编码值开始，到环境变量、CLI Flag、配置文件、模板化配置文件、DSL、通用 bash 脚本，再到硬编码值。开发者应了解这个七边形中的各个位置。

• 所有抽象层都是可改变的。如果遇到了根本性的问题，有时答案就是往下再抽象一层，不要局限于表面

本文转自OSCHINA

本文标题：编程一万小时的反思

本文地址：https://www.oschina.net/news/154219/reflections-on-10000-hours-of-programming

资讯来源：https://matt-rickard.com/reflections-on-10-000-hours-of-programming/