警惕最优方案

1 原文信息 

1.1 标题 

The Dark Side of Best Practices
Petri Kainulainen: August 8, 2013

1.2 地址 

http://www.petrikainulainen.net/software-development/processes/the-dark-side-of-best-practices/

2 警惕最优方案 

寻找最优解决方案是开发软件中的理念（或者别人经常这样告诉我们）。每一名开发者都有着他对于软件开发进度，架构和编程的独特观点。

这些方案是基于教育经历、个人经验以及同行影响形成的。

这些方案也被称作最优方案，几乎每一个软件公司都有着自认为为最优的解决方案。

那么，最优方案肯定是一种最优的解决方案吗？不完全是，我认为最优方案也有着容易被忽略到的、需要注意的地方。

2.1 警惕最优方案的另一面 

最优方案本身是不具危险性。他们之所以变得危险是因为他们被误解了或被错误地使用了。不幸的是，这种情况出现得相当普遍。

以我的经验来说，如下三种最容易造成错误使用最优方案：

2.1.1 把最优方案当作万能药 

当最优方案被当最终解决方案，并不允许提出任何质疑时。如果我们不能质疑这个的最优方案的话，那么，我们就没有机会知道为什么这种方案会比其他可用方案更好的原因了。

这意味着我们失去了学习和改善当前问题的机会。

如果我们生活在一个静态不变的世界中，这完全是个正确且有效的策略。当然，这是不可能的。我们都知道新技术正以非常快速度增长并改变着整个世界。

那么，我们会愿意落后于别人吗？(译注：不会，所以需要有对最优方案挑战的精神)。

2.1.2 最优方案被当做公司制度来执行 

在某些情况下，一个项目小组被强制使用某种最优方案来完成任务。通常这种情况，大多是由这两种原因引起的：

首先，最优方案用来确保高级开发者和架构师在公司的地位和著作权。整个项目组不得不使用高级开发者和架构师所熟悉的技术和编程语言。所有新的技术和编程语言都被以太新或不成熟等理由而被拒绝。

然后，最优方案被当做市场工具来使用。他们的目的是为组织创建一个可供参考的软件开发流程说明。他们唯一最关心的事情是有一个光彩的门面，因为：

这让客户觉得公司非常棒。
这让上层领导觉得中层管理阶层做得非常好。

然而，现实是没有谁会真正关心现在所使用的方案是否真的适合解决当前的问题呢。

好吧，上面所说的也不是全部。开发者也会对现在的方案进行考虑，不过所关心的地方通常是局限于他们“被问”到的地方，然后解决了被问到的问题，在团队中实现了一种新的解决方案。

将现有最优方案设定为公司制度，将使得那些勇于创新的员工变得不积极，因为他们得不到什么好处。这样，把最优方案定为公司制度，是否值得我们追求呢？

2.1.3 实现最优方案易于造成过度工程 

有些时候，最优方案概念容易造成一种过度工程的情形，会考虑到架构、设计模式和组件重利用等各种因素。这些程序（或组件）通过如下原则进行扩展，非常容易造成过度工程。可以想象，如果由一个全部由架构师组成的团队，设计软件该会达到多么令人惊讶的复杂啊！

这种情形是因不能懂得一个可重复利用组件（框架，库，或者服务）和应用程序之间的区别所引起的。其实，这些区别是非常明确的：

当我们正创建一个可重复使用的组件时，我们不得不考虑，将它设计得可以被重复使用。
当我们创建一个应用程序时，我们必须关注，当前应用程序需要达到哪些前提条件上才能实现。
过度工程很有可能产生永远也不会被使用的复杂代码，这显然是没有实际意义的。如果我们按照这个原则来设计软件：在任何情形下都使用同样的设计原则来设计软件，就很容易出现过度工程的情况。

2.2 接下来我们应该怎么做呢 

首先，我们应该做好我们的工作。如果最优方案是正确的方案，然而我们却没有按照它的要求来做的话，那就不太好了。这可能听起来有一点激进，但是我们应该懂得：新想法是为了找到最好的可能实现的方式来开发软件。同时，这也说明了，如果按照一个对实现我们目标没有帮助的“最优方案”也是没有任何意义的。

我们必须懂得永远是没有“银弹”的（译注：一种完美的解决办法）。这意味着没有一个可以考虑到所有情况并解决所有问题的简单办法。我们中大部分人都多多少少懂得一点这个道理，但当我们听到最佳解决方案这个词时，经常忘记了这样一个简单的道理。

相对于把最优解决方案当做银弹，我们应该明白：一个最优解决方案中的方法是在某些特定条件下才是正确的。如果我们明白了这一点，那么，很显然：

我们必须不断地为我们现在的问题来寻找最好的解决方案。我们每天都会学习到新的事情。我们可能觉得今天这个最优解决方案非常的完美，但下一周后又可能觉得实现得非常愚蠢。我们必须记住没有任何东西可以永久地持续下去。当然也包括最优解决方案。我们必须在当前最优解决方案不起作用时勇敢地去挑战它。当然，很有可能我们是错误的。但是如果我们不去挑战最优解决方案的权威性，我们将永远都不知道真相。难道我们要一直活在这种不明不白之中吗？

我们不会使用一个解释得不详细的最优解决方案。相反，我们有一种要求详细说明的需求。如果什么都没有给出，我们就该忽略它。也只有傻子才会使用一个他自己都不懂得的方式。

最后，最佳解决方案仅仅只是一个观点而已。一些最佳方案确实比其他方案更好，也有些最优方案被证明是错误的。我想这是我们的责任来推翻这错误的“最优方案”，尽我们最好通过做多的练习来找到更好的解决办法。

为什么？

它帮助我们找到更好的办法来完成手中的工作 。

3 关键字 

Best practice 最佳实践，最优解决方案，涉及开发进度、架构和代码编程

A method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark.

一种证明比其他更好、更优的方法或技术解决方案，并且被定义为一种权威标准。

facade 假的
entirely 完整的，彻底的
bend over 弯下腰
demotivate 失去动力的
inability 无能力的
radical 激进
overthrow 打倒、推翻

4 译者感悟 

花费大量的时间在立即“Best practice”，从百科、Google等上搜索这些信息，推测“Best Practice”应该是代表解决某个问题时的最优解决方案。
"几乎每一个软件公司都知道这个观点"，我做软件开发者三年了，居然现在才知道这个观点，都怪之前努力得不够呀，这些东西都没有接触过。通过翻译这篇文章，又让我学习到了新的知识。

初步阅读这篇文章时，觉得文章比较短小，翻译起来应该会很简单的。初读一遍，大体意思都好像都清晰了，而真正翻译时，才发现原来文中的很多概念很抽象，理解起来比较困难。

作为一个软件开发程序员的我，很多时候会有这样一种感觉，觉得自己编写的代码是最完美的，就是最优解决方案，但实际上是这样的吗？大多数情况下都不是，挑战最优解决方案，是前进的动力，也是提高技术的最好办法。

“我们必须懂得任何时候都是没有银弹的”，名言呀，不管遇到什么事情，保持好随时准备接受变化的心态。

最近感冒了，工作效率没有那么高了，但心态反而平静了很多，只把时间用在最必须的地方；另一方面，因为知道效率不高，反而完成任务时就不那么着急了。就像翻译这篇文章的时候，不仅仅是要完成一个任务，而是享受这篇文章带给我思维的碰撞，美美的感觉。