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