[译]好程序员的五声“呐喊”

一般编程状况下，会致使软件项目变坏的一些列反应

原文：The five shouts of good programmers

 

      在任何一天，在这个世界上都有软件项目正在失败，这很常见。常见到当软件产品按照预期发布时人们都会感到吃惊。这不是什么新鲜事，基于被普遍引用的Standish Group的Chaso报告，这种事情已经已经发生了几十年了。可是如今，在不少状况下，人们试图尽最大努力去避免这种悲剧，可是常常公司的政治老是会比实用主义更具优先级。只要不要太晚，这都是能够经过简单的延迟来避免。

      在这种状况下，程序员做为战场的一线战斗人员，会比其余人都更早的看到这些问题。可是，程序员都会缺少以一种简单的方式解决此类问题的技能，这也就意味着不少状况下他们都只是在一个已经注定命运的项目上埋头苦干。

      经过一次又一次的观察到这种状况，我意识到程序员们须要一个高效的回退机制，这也就是为何我写这个文章的缘由。这些“呐喊”都只是隐喻层面的。也仅仅是当如下谈及的问题场景出现的时候，你能够告诉本身的一些话，使得你有力量将一些很差的状况往好的方面发展。

 

1.不要作重复的工做（Don’t repeat yourself!）

      假想一下你处于这样一种状况，你须要去写一些特定功能的代码，可是同时相似的代码已经存在。很显然，最好的方案是修改已经存在的代码，让这些代码对新的场景可以兼容。同时，这须要你将老的和新的测试场景都进行测试，以确保没有引入任何回归Bug。项目管理人员为了时间考虑，会建议你简单的将代码拷贝一份，而后进行修改，此时只须要测试新的应用场景。在这种状况下，你须要使用此条规则。“Don’t Repeat Yourself!”。

      其中一个主要缘由是，重复的代码是Bug的主要来源地之一。当有两个函数或模块，都实现几乎相同的任务，在某一时刻业务发生了改变，此时颇有可能程序员只会记得更新其中的一个，而忘记了另外一个，这就产生了Bug。同时这也下降了代码的可理解度。若是当新人碰到这两个几乎相同功能的代码时，会好奇究竟选择使用哪一个，甚至更糟的是，会两个都用上。写相同功能的代码多是中捷径，可是最终仍是会为此付出代价的。

 

2.不要作无心义的工做（No monkey business！）

      第二个场景涉及到重复性的工做。程序员常常可能想要将重复工做自动化，可是管理者常常不会为此投入相应的资源，相反还会以“只须要几分钟”为借口进行争论。这些人常常不会意识到，重复性的工做很容易出错，而且花费的时间会增加。5分钟的工做可能会变成10分钟，10分钟的变成15分钟，等等等等。很快，就会看到程序员疯狂敲击键盘，看上去很忙的样子，但实际上并无完成什么有意思的工做，很像一只敲键盘的猴子。

      此时，程序员就可能须要使用“No monkey business！”了。程序员的职责就是编程，若是让他们作一些欠考虑的，无心思的重复工做就是浪费他们的能力，最终会致使负面情绪的增加。除此以外，将一项任务自动化会让程序员以一种批判的眼光去看着这件事，可能会在这个过程中发现一个漏洞，而这个漏洞但是是以前被忽略的。

 

3.安全优先（Safety first！）

          在公司层面，不少活动中更倾向于规避风险。好比在广告中，可能由于一句错误的台词致使公关危机；在财务中，一个错误的财务计划可能会致使公司破产；在市场调查中，一件新产品须要被公众所接受。然而，在谈及技术上的规避风险是，公司一般会有很大的欲望去冒风险。一般表如今经过减小或免去测试来节约成本。尽管相似测试驱动开发这样的工程实践会带来一些好处，可是我依旧听到不少关于说服程序员不要写自动测试用例来减小时间的争论。一些人会说，真正的程序员是了解他们在作什么，因此他们不须要测试；另一些人会说，测试的结果最终不告知用户，所以它不是产品的一部分，这就意味着测试时能够在程序员的私人时间内完成。

      事实是，忽视安全在实际中太广泛了。人们不会意识到他们是在一个不安全的环境中（译：我的以为是开发流程中的不安全性）工做。可是，你能够经过在一个项目的过后分析的典型结论中来证实这个事实。他们一般会将失败归结于糟糕的需求或者糟糕的预估，可是永远不会归结到不安全的环境上。他们永远不会说“咱们失败是由于咱们的开发环境出的问题，它没有预防一些错误的发生”。这就是为何咱们须要使用“Safety first！”

 

4.YAGNI!（You Ain't Gonna Need It!）

      相对于其余的系统的工程来讲，软件开发时一个比较年轻的系统工程。天然，也从其余的工程学里借鉴了一些东西到软件工程学中。其中一个就是试图去预测将来的需求。

      假设你如今是一位市政工程师，你被要求去建设一座双车道的大桥。在任什么时候候，都值得去思考，这座桥须要四车道，由于这样才能把基础建的更牢靠，而且在将来想拓展成四车道也变得方便。按照这个逻辑，项目就有一个额外的，没有人要求的需求了。它是基于设计者的假设而加入的，同时设计者认为早作比晚作成本更低。

      第一个问题是，没有任何迹象代表在需求出现前而去臆想需求会使得成本更低，尤为是咱们使用现代的、迭代的实践方法。第二个问题是，每当非被要求的功能性的需求被提起时，管理者一般决定不会解决。这就致使了一个这样的企业文化：代码的质量良莠不齐，有些会变“腐烂”直到彻底没用。更糟的是，它会下降程序员的士气，由于他们所工做的内容是以后从不会被用到的，所以会变得沮丧。

      若是是在这种状况下，当没必要要的需求浮现时，程序员此时须要说“YAGNI！”。

5.从如今开始！（Yes now!）

      这是为最喜欢的一条。编程是一种持续冒险的活动。你可能须要去查看一些几年前由你不认识的人写的代码。这些代码可能运行在一些特定的场景下，你永远不会知道你在此过程当中会遭遇什么，多是一段很优雅的代码，也有多是彻底没法工做的代码。这才是编程的乐趣！

      假设你如今是名厨师，你到了一个一团糟的厨房里。可能你有种立马把里面清理干净的冲动，而后才进行工做。做为一名程序员，当你遇到一团糟的代码时，你也会有那样的冲动。可能代码的清理工做并非项目的一部分，你这种好的想法也有可能被礼貌地推到一边。“那是个好主意，可是咱们如今不用去作它。”。此时，你须要说“Yes Now！”。

      一个成功项目的最重要的文化氛围就是，一旦出现了问题，立马修复。若是没有这种文化氛围，那么就会出现“破窗”理论。而后程序员就习惯工做在那样设计很垃圾的代码之上。这样团队士气就会受到伤害。由于是我将代码搞得很垃圾和代码原本就很垃圾就变得很重要。“Yes Now！”帮助团队集中焦点在对的事情上，而不去关注是谁让事情变得糟糕。

 

      最后一条警告…

      这五声“呐喊”是颇有用的工具，可是和任何工具同样，滥用会拔苗助长。这些建议一般是用在当出现了一些坏的决策时，有些时候可能会致使一些冲突。冲突有时是个很好的提示，提示咱们须要在多个选项中选择一个最好的方案。同时也意味着要当心使用这五声“呐喊”。

      维持常态是拒绝改变的一种心理倾向。当开始使用这五条告诫时，决策的思路也开始改变，不少人最初都会去拒绝。出于这个缘由，最好的方案是温和地使用这个五条告诫，同时在最关键的状况下使用它们。当改变发生后，其余人就会慢慢地注意到它带来的好处，而后就能够在更多的场景进行应用。

      改变很难。尤为是要改变咱们使用了几十年的习惯时。明智地使用者五条告诫，你会发现你的代码和项目在逐渐地往好的方向改变。