程序员能写的最佳代码，就是无码
【导读】；昨天国外程序员在 Hacker News 上热议一篇文章，《你不是在写代码，是要解决问题》。
英文作者是 Raul，我们先来看看他是如何陈述其观点的。我们是程序员，所以写代码是我们的工作，不是这样的吗？正如标题所示，我们的工作比整天在屏幕前敲键盘上要复杂一点。如果你超越了编程语言、框架和流程，超越了测试套件、Sprint 和 Jira 工单等，你总会发现需要解决的问题。作为程序员，我们是解决问题的人，拿到别人遇到的问题，使用所有可用的工具，来找到解决方案。软件不是目的软件本身并不是我们工作的目的。编写的软件必须与现实世界的问题/需求相连接，否则即便代码写得再漂亮，那它还是一个没啥用途的绣花枕头的程序。更重要的是，你编写的软件应该能通过评估，它是否能很好解决待处理的问题/需求。软件是用来解决特定需求的工具。以你能想到的最佳软件为例：它很整洁、易于阅读，而且设计模式也都用对了。但如果它无法完成你需要它做的事情，那它就没用。理解问题/需求软件开发的第一步应该是理解问题/需求。花再多的时间去做这事都不为过。这同时适用于小任务和整个项目。我认为它甚至更适用于整个项目。没正确理解需求，由此引发的问题，不管怎么勤奋，都很难解决了。大多数时候，它们涉及到大量的重构和大量的工作。你还得客户解释为什么整个程序是错的，你所面临的尴尬，就别提了。完美是你的敌人前面已经说明了应该专注于解决问题/需求，而不是写代码，我还要提一下「二八法则」。作为程序员，我们有时会被正在解决的难题所困扰，以至于忘记问自己“我的解题方向对了吗？” 我们要时不时地休息一下，看看自己为什么要这么做。遇到难题困扰时，或许下面这些问题可以帮助你：解决这个问题有多大价值？还有其他更快的方法吗？是否还有更容易实施的折中方案?这些问题并不总是你可以自己解决的（除非你是在做个人项目）。和利益相关者聊一聊，看看他们真正关心什么。如果可以，收集用户的反馈。通常来说，快速 A/B 测试对你下一步该做什么大有帮助。多试验和迭代！你的项目不需要完美才能成功。你能写的最佳代码，就是根本没有代码/无码并不是每个问题都需要一个技术解决方案。你不需要一个应用程序来处理所有其他事情。一切都是有代价的。你编写代码，就要消耗你的时间和资源。此外，你拥有的代码越多，需要维护的代码就越多，出错的可能性就越大。我相信你现在已经注意到了，添加代码是有风险的。错误迟早会出现。你拥有的代码行数与维护它所涉及的工作之间存在非线性关系。换句话说：更多的代码意味着更多的问题。试着把你的代码变成别人的需求。我发现，通常情况下，花时间能寻找现成的解决方案。在软件开发中，我们已经达到了这样一个阶段：很多东西都有一个现成的库或 API。对常见的问题/需求，我建议使用现成的解决方案：比如身份验证、支付等。此外，为整个项目寻找现成的解决方案也是值得的。以 WordPress 为例，我的博客就是基于 WordPress 上运行的，我没有写一行代码。网友评论Raul 的文章在 HN 引发了热议，我们摘翻几个：程序员 muglug ：Raul 的文章抛出了一个稻草人论点——几乎所有的程序员都在解决某种类型的问题。最大的问题是：你在为谁解决问题。当我还是单兵作战的自由职业者之时（就像他文章假设的那样），我总是在为客户和他们的客户解决问题。当我与其他程序员一起工作时，我也对解决他们的问题感兴趣了。有时是以大型重构的形式来改进代码，但也会开发一些工具来大规模地改进代码库。Ozzie_osman：我喜欢这篇文章，但是它忽略了一点，那就是应该采用一种（更利于将来解决问题）的解决方案，很多人在这个点的权衡上犯错了。例如，编写良好的、可维护的代码很重要。因为如果你不这样做，将来需要解决的问题可能发生变化。这些变化可能会降低你解决更多问题的能力。代码本身可能很难理解、推理和修改，因此很难做更改。花在维护上的时间就多了，你向前进展的时间相应就少了。liquidify：我觉得取决于语言。我发现用 C++ ，我花了很多时间来研究语言，而用 Python，我花了更多的时间来解决实际的问题。carlsborg：优秀的软件是由一系列好点子组成的。对计算机科学、工具和框架以及问题领域（包括市场机制）的深入了解，都可以扩展潜在想法。
发表评论 (审核通过后显示评论)：