代码优先与产品优先

一般来说，有两种程序员。有更关心代码的程序员，也有更关心产品的程序员。前者——我称他们为”代码优先”的程序员——痴迷于代码的架构、使用什么工具、库和语言，有多少测试覆盖率——诸如此类。代码优先的程序员在签入完美的抽象、使用最新的语言功能、删除死代码时会很兴奋。也就是说，他们喜欢自己编写的代码——代码就是事情。

产品优先的程序员也关心这些东西，有点，但只是作为达到目的的一种手段。对于产品优先的程序员来说，代码是脚手架、支撑、建筑物中的钢梁，而不是最终产品。最终产品是产品，而不是代码，对他们来说重要的是该产品实际上解决了潜在问题的程度。建筑物是否保持直立？电梯好用吗？空调是否正常工作？人们喜欢在那里吗？以产品为先的程序员喜欢构建和发布并看到用户使用他们构建的东西。产品就是事情。

任何在谷歌这样的地方工作过的人都会遇到很多代码优先的程序员。他们是总是在你的函数注释中重构代码和挑剔拼写的队友。他们在微型厨房里抱怨”意大利面条式代码”、“技术债务”以及其他团队的代码审查流程缺乏严谨性。他们可能不会修复错误或启动功能。您可能会说我不是代码优先方法的忠实拥护者。

当我采访程序员时，我总是惊讶于他们中有多少人似乎认为代码优先方法是我正在寻找的。为了给我留下深刻印象，他们问：“你的单元测试覆盖率是什么样的？” 非常接近于零；这是一家初创公司。“你们使用热门新技术X吗？” 还没有，不，这将如何帮助我们更快地构建正确的东西？“有很多技术债务吗？” 我们将不得不在某个时候重写所有内容，但这并不重要，因为我们甚至还没有找到正确的构建方式。

他们对编程的意义有一个可以理解但基本的误解。编程是关于构建为用户解决问题的产品，而不是为了自己编写漂亮的代码。

需要明确的是，这在堆栈的所有级别都是如此，无论您的用户是外部客户、第三方开发人员还是 API 的内部消费者。重要的是代码是如何工作的，而不是代码的外观。

这是否意味着我鼓励编写糟糕的代码？我不关心我们使用什么技术或软件是如何构建的？绝对不是——我很在乎！但我很在意，因为我相信如果你做出正确的工程选择，你最终会得到更好的产品。

我最近有一位我正在管理的工程师问我他的代码如何。我回答了两个问题：“这个功能效果好吗？” “你建得很快吗？” “这对我来说很重要，“我说。

通常，如果这两个问题的答案是肯定的，那么很可能（尽管不确定）代码实际上非常好，因为好的产品通常意味着好的代码。顺便说一句，相反的情况并不存在——没有好的代码会产生坏的产品。

我把这称为我的好代码规则：

如果产品不好用，代码不好。

换句话说，抽象中没有好的代码。好的代码只有在产生工作产品时才能存在（再次，在这里松散地定义产品以表示堆栈任何级别的产品）。

我一遍又一遍地看到一些工程师快速生产出伟大的产品，当我看到代码时，它通常是经过精心设计和巧妙构建的。这并不奇怪，因为在一个复杂的系统中很难快速构建出好的产品，而且代码的架构、分解或未经测试。

相反，当我看到程序员没有快速启动功能时，问题通常是过度设计。或者当工程师确实快速启动但质量很差时，那么问题通常是工程不足或草率的代码。

这里没有零和游戏：你应该争取好的代码，快速生成，产生好的产品。这就是伟大的程序员所产生的。

我认识的最好的程序员都是产品优先的，但实际上比编码优先的程序员有更多的编码知识。他们知道何时使用电锯、手锯和凿子。当你需要真正做正确的事情时（通常是你在堆栈中的更深）与你可以假装它并快速移动的时候。什么时候最好只编写一个普通的 for 循环而不是自定义迭代器。这些选择和权衡是成为一名优秀程序员的全部意义所在，最终的反馈机制是产品的运行情况。

原文引用：https://thezbook.com/code-first-vs-product-first

如有侵权，请联系删除