Matt Rickard 是在谷歌从事 Kubernetes 开源工作的开发者,主要负责构建和维护 Kubernetes 开发者工具,例如 minikube 和 skaffold此外他还作为 Kubeflow 项目的维护者负责机器学习管道方面的工作,今天小编就来说说关于我的世界编程一小时?下面更多详细答案一起来看看吧!

我的世界编程一小时(编程一万小时是种什么样的体验)

我的世界编程一小时

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 脚本,再到硬编码值。开发者应了解这个七边形中的各个位置。

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