标签：
通常编程情况下，会导致软件项目变坏的一些列反应
原文：The five shouts of good programmers
在任何一天，在这个世界上都有软件项目正在失败，这很常见。常见到当软件产品按照预期发布时人们都会感到吃惊。这不是什么新鲜事，基于被广泛引用的Standish Group的Chaso报告，这种事情已经已经发生了几十年了。但是现在，在很多情况下，人们试图尽最大努力去避免这种悲剧，但是经常公司的政治总是会比实用主义更具优先级。只要不要太晚，这都是可以通过简单的延迟来避免。
在这种情况下，程序员作为战场的一线战斗人员，会比其他人都更早的看到这些问题。但是，程序员都会缺乏以一种简单的方式解决此类问题的技能，这也就意味着很多情况下他们都只是在一个已经注定命运的项目上埋头苦干。
通过一次又一次的观察到这种情况，我意识到程序员们需要一个高效的回退机制，这也就是为什么我写这个文章的原因。这些“呐喊”都只是隐喻层面的。也仅仅是当以下谈及的问题场景出现的时候，你可以告诉自己的一些话，使得你有力量将一些不好的情况往好的方面发展。
假想一下你处于这样一种情况，你需要去写一些特定功能的代码，但是同时类似的代码已经存在。很显然，最好的方案是修改已经存在的代码，让这些代码对新的场景能够兼容。同时，这需要你将老的和新的测试场景都进行测试，以确保没有引入任何回归Bug。项目管理人员为了时间考虑，会建议你简单的将代码拷贝一份，然后进行修改，此时只需要测试新的应用场景。在这种情况下，你需要使用此条规则。“Don’t Repeat Yourself!”。
其中一个主要原因是，重复的代码是Bug的主要来源地之一。当有两个函数或模块，都实现几乎相同的任务，在某一时刻业务发生了改变，此时很有可能程序员只会记得更新其中的一个，而忘记了另一个，这就产生了Bug。同时这也降低了代码的可理解度。如果当新人碰到这两个几乎相同功能的代码时，会好奇究竟选择使用哪个，甚至更糟的是，会两个都用上。写相同功能的代码可能是中捷径，但是最终还是会为此付出代价的。
第二个场景涉及到重复性的工作。程序员经常可能想要将重复工作自动化，但是管理者经常不会为此投入相应的资源，相反还会以“只需要几分钟”为借口进行争论。这些人经常不会意识到，重复性的工作很容易出错，并且花费的时间会增长。5分钟的工作可能会变成10分钟，10分钟的变成15分钟，等等等等。很快，就会看到程序员疯狂敲击键盘，看上去很忙的样子，但实际上并没有完成什么有意思的工作，很像一只敲键盘的猴子。
此时，程序员就可能需要使用“No monkey business！”了。程序员的职责就是编程，如果让他们做一些欠考虑的，无意思的重复工作就是浪费他们的能力，最终会导致负面情绪的增长。除此之外，将一项任务自动化会让程序员以一种批判的眼光去看着这件事，可能会在这个过程当中发现一个漏洞，而这个漏洞可是是之前被忽略的。
在公司层面，很多活动中更倾向于规避风险。比如在广告中，可能因为一句错误的台词导致公关危机；在财务中，一个错误的财务计划可能会导致公司破产；在市场调查中，一件新产品需要被公众所接受。然而，在谈及技术上的规避风险是，公司通常会有很大的欲望去冒风险。通常表现在通过减少或免去测试来节约成本。尽管类似测试驱动开发这样的工程实践会带来一些好处，但是我依旧听到很多关于说服程序员不要写自动测试用例来减少时间的争论。一些人会说，真正的程序员是了解他们在做什么，所以他们不需要测试；另外一些人会说，测试的结果最终不告知用户，因此它不是产品的一部分，这就意味着测试时可以在程序员的私人时间内完成。
事实是，忽视安全在实际中太普遍了。人们不会意识到他们是在一个不安全的环境中（译：个人觉得是开发流程中的不安全性）工作。但是，你可以通过在一个项目的事后分析的典型结论中来证明这个事实。他们通常会将失败归结于糟糕的需求或者糟糕的预估，但是永远不会归结到不安全的环境上。他们永远不会说“我们失败是因为我们的开发环境出的问题，它没有预防一些错误的发生”。这就是为什么我们需要使用“Safety first！”
相对于其他的系统的工程来说，软件开发时一个比较年轻的系统工程。自然，也从其他的工程学里借鉴了一些东西到软件工程学中。其中一个就是试图去预测未来的需求。
假设你现在是一位市政工程师，你被要求去建设一座双车道的大桥。在任何时候，都值得去思考，这座桥需要四车道，因为这样才能把基础建的更牢靠，并且在未来想拓展成四车道也变得方便。按照这个逻辑，项目就有一个额外的，没有人要求的需求了。它是基于设计者的假设而加入的，同时设计者认为早做比晚做成本更低。
第一个问题是，没有任何迹象表明在需求出现前而去臆想需求会使得成本更低，尤其是我们使用现代的、迭代的实践方法。第二个问题是，每当非被要求的功能性的需求被提起时，管理者通常决定不会解决。这就导致了一个这样的企业文化：代码的质量参差不齐，有些会变“腐烂”直到完全没用。更糟的是，它会降低程序员的士气，因为他们所工作的内容是之后从不会被用到的，因此会变得沮丧。
如果是在这种情况下，当不必要的需求浮现时，程序员此时需要说“YAGNI！”。
这是为最喜欢的一条。编程是一种持续冒险的活动。你可能需要去查看一些几年前由你不认识的人写的代码。这些代码可能运行在一些特定的场景下，你永远不会知道你在此过程中会遭遇什么，可能是一段很优雅的代码，也有可能是完全无法工作的代码。这才是编程的乐趣！
假设你现在是名厨师，你到了一个一团糟的厨房里。可能你有种立马把里面清理干净的冲动，然后才进行工作。作为一名程序员，当你遇到一团糟的代码时，你也会有那样的冲动。可能代码的清理工作并不是项目的一部分，你这种好的想法也有可能被礼貌地推到一边。“那是个好主意，但是我们现在不用去做它。”。此时，你需要说“Yes Now！”。
一个成功项目的最重要的文化氛围就是，一旦出现了问题，立马修复。如果没有这种文化氛围，那么就会出现“破窗”理论。然后程序员就习惯工作在那样设计很垃圾的代码之上。这样团队士气就会受到伤害。因为是我将代码搞得很垃圾和代码本来就很垃圾就变得很重要。“Yes Now！”帮助团队集中焦点在对的事情上，而不去关注是谁让事情变得糟糕。
最后一条警告…
这五声“呐喊”是很有用的工具，但是和任何工具一样，滥用会适得其反。这些建议通常是用在当出现了一些坏的决策时，有些时候可能会导致一些冲突。冲突有时是个很好的提示，提示我们需要在多个选项中选择一个最好的方案。同时也意味着要小心使用这五声“呐喊”。
维持常态是拒绝改变的一种心理倾向。当开始使用这五条告诫时，决策的思路也开始改变，很多人最初都会去拒绝。出于这个原因，最好的方案是温和地使用这个五条告诫，同时在最关键的情况下使用它们。当改变发生后，其他人就会慢慢地注意到它带来的好处，然后就可以在更多的场景进行应用。
改变很难。尤其是要改变我们使用了几十年的习惯时。明智地使用者五条告诫，你会发现你的代码和项目在逐渐地往好的方向改变。
标签：
原文地址：http://www.cnblogs.com/navono007/p/5568092.html
