编程一万小时的反思
发布时间：2025-11-05 01:02:43 来源：云智核 作者：人工智能
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/
- Copyright © 2025 Powered by 编程一万小时的反思,云智核 滇ICP备2023006006号-28sitemap