转载

请不要让程序员在黑暗中摸索

  英文原文:Don’t leave developers in the dark

  不知道各位有没有玩过魔兽、X-COM、文明帝国、红色警戒之类的策略游戏。

  这些游戏使用了所谓的“战争迷雾”。刚进入游戏的时候,每一个玩家的地图都是被黑暗笼罩的,想要前行的唯一途径就是不断的摸索。随着我们不断地移动,地图越来越可见化。

请不要让程序员在黑暗中摸索

  这种战略的劣势是:玩家看不到周围的危险、障碍以及机会。每一次的成功都需要一点点的运气。

  有木有感觉这种情景有点熟悉?

  “战争迷雾”完美地形容了开发人员的工作处境。他们总是被要求去搞定某一段特定的代码,但是却不告知任务的相关情况,等于是在让他们自己在黑暗中摸索。

  对于开发人员,看到“整个的游戏地图”很有必要。对全局有一个清晰的把握有助于他们做出正确的决策。下面这些问题是他们所需要知道的:

  • 为什么要创建这个功能?它为客户提供了哪些方便?
  • 围绕这个功能的代码经历了怎么样的一个发展过程?
  • 此功能会影响应用程序的其他哪些部分?
  • 这是否会影响业务的其他部分?
  • 我们如何衡量这个项目的成功(或失败)?

  当开发人员掌握整个框架之后,才能有针对性地开始工作。他们的深思熟虑谋定而后动非常有助于项目的成功。

  同时也有巨大的激励效应。Joe Stump 总结道:

开发人员对于任务背后的问题往往得自己摸索,这意味着对于给定的对象可能开发人员并不能真正地思考到点子上。

但是如果够负责的话,开发人员会沉浸于这个问题的思考,因为其工作具体说来,更为依赖于在商业上的成功。

举个例子,如果我是后端开发人员,你告诉我去实现一些 API 端点,我需要考虑一下为什么你需要这些端点。

  这突显了了解每个项目背后的目的和任务的重要性:

  • 目的:我们为什么要这么做?
  • 任务:目标是什么?做到怎么样的程度算完成?

  在了解了目的和任务之后,开发人员也就成为了规划进程中有价值的合作伙伴。他们可以预见一些潜在的“地雷”,以免你踩到从而付出高昂的代价。在一篇杂志文章中,Paul Boag 描述了将开发人员摒弃在一些相关会议之外的危险:

在 Digg 的鼎盛时期,Daniel Burka(Digg 的首席设计师)和 Joe Stump(其主要开发人员)之间就一个 Digg 按钮曾举行过一次会议讨论。Daniel 想要更改其设计,因为从他的角度看,变化不大。但是对于 Joe 来说,他发现这个小设计将会对网站的性能产生很大的影响,迫使 Digg 因为这么一个按钮而升级它的处理能力和服务器架构。

  你能做什么

  首先我们应该负责任地参与到产品、支持和工程规划的会议讨论中去。

  会后,我们可以创建接下来所需要的有关规范文件。

  管理人员不是将军,开发人员也不是战士

  有时候,管理人员搞的好像这个项目是什么紧要机密一样,只给出一些“需要知道的基础知识”。

  但是这种保护措施却不会导致更好的代码、更受欢迎的项目,也不会增加销售。不要让开发人员在黑暗中摸索,应该邀请他们一起参与到整体的战略讨论中来。

  译文链接:http://www.geekwww.com/dont-leave-developers-in-the-dark.html

  翻译作者:极客网 – John

正文到此结束
Loading...