偏爱工具是糟糕的工程 (2018)

今天我想谈谈糟糕的工程师，特别是他们的一个方面——解决方案偏袒。但首先，让我再次提醒您工程应该如何工作。你遇到了一个问题——这可能是任何问题——你可能需要一个新的数据库、一个新的前端框架、一个新的包管理器，或者更抽象的，你可能需要一种新的方式在用户方便的时候向他们显示数据。哎呀，它甚至可能不是软件，你需要从水龙头里出来水，你需要一个新的淋浴装置，你需要一座过河的桥，你需要为偏远地区供电。然后，你深入研究这个问题。您会查看子问题、该领域的独特限制、您的公司、您的员工和团队、您的未来计划、您过去的计划等等。这些都很重要。从那里，您尝试一些解决方案。你依次尝试你能想到的每一个解决方案，通过小的概念证明 (POC) 或实验，最终你会看到什么最有效。您可能会排除一些，因为它们不适用于您的独特约束。您可能会进一步测试其他人。这是一些解决方案知识可以派上用场的地方，但稍后会更多。从那里，你解决关系。如果一种解决方案看起来与另一种几乎相同，那么您就继续前进。寻找其他独特的约束，直到出现明显的赢家。从那里，您可以继续实施解决方案。如果您发现问题，那么您的 POC 不够好，您需要退后一步。它发生了。没关系。就是这样，这是作为一名优秀工程师解决问题的（简化）方法。糟糕的工程正在进入解决问题的阶段，偏向于您最喜欢的潜在解决方案。这绝对是荒谬的，但它一直在发生，尤其是在软件工程领域，尤其是在线领域。这已成为非常普遍的在线，这是超级超级痛心地看到。让我列出一些我认为是不良工程迹象的短语：“我想使用 X，因为我想今年去 XCon 并做一个演讲”“我使用了架构 X，所以我们将在这个项目”我想走得更远。我想说它糟糕的工程甚至喜欢一种技术或工具。如果您喜欢它，那么在解决问题时就会偏向于它，并且您将成为一个更糟糕的问题解决者（又名工程师）。当然，我发现 Swifts 的语法令人愉快、可读或可维护。但归根结底，当它是解决问题的最佳方式时，我会使用它。在 iOS 应用程序的上下文中，考虑到正确的限制，Swift 可能会输给其他可能的解决方案，从任何对象到 Objective-C、React Native、移动网站、在地图上更好的谷歌列表，再到简单的传单一个局部区域。 '我们是工程师。我们解决问题。我们不会带着一盒解决方案四处走动，然后将它们扭曲成我们遇到的问题。我们查看手头问题的独特约束并从那里开始。 “但是 Sam，我擅长 X，这就是我喜欢它的原因，所以我可以更快地做事，而且业务也喜欢我”。没关系。擅长特定的工具或技术很好。但是，如果约束是正确的，这只是一个很好的解决方案。可能倾向于这些情况的一些（常见但不是恒定的）约束是： 你已经有一个 X 的代码库，所以你添加了更多的 X（例如 Ruby 到 Ruby 代码库）

交货日期临近和/或成本必须保持较低 - 因此您在寻找解决方案时强调您/您的团队当前的技能组合。作为一名优秀的工程师，您会警告管理层不以正确的方式进行长期风险。参见：初创公司。该项目是短期的，例如用于技术演示、临时使用或类似用途。所以，总而言之，有几个关键点我想开车回家并说清楚。从问题开始。努力消除偏见，并使用良好的科学和工程原理进行公平评估 注意博客和在线内容销售解决方案作为解决您独特问题的方法。这可能是一个解决方案，但我可以保证它不是每个人的解决方案。深入研究并掌握一项技术固然很好，但最好的工程师或开发人员的头衔中并没有工具名称。高级 Java 开发人员听起来和高级 PVC 管道工一样荒谬。最好从问题开始，并为它找到最佳解决方案。一些专注于某种工具的博客和在线内容通常可以让您更熟练地使用它们，但请注意您现在知道的在智力上不诚实和糟糕的工程的断言。

祝这一切好运！如果我们继续关注问题并提出最佳解决方案，未来将是惊人的。如果我们继续使用我们现在拥有的东西，我们将陷入困境。我们不希望那样。