软件开发中一个经常发生的常见错误是太关注于技术、架构、中间件或者其他技术细节。我们忘记了任务是产生一个出色的应用程序，而不是我们用了最强劲的工具。

下面是我列出的一些反模式。

反模式1：基于知道的技术数量来选择人

在选择人才方面一个最常见的情况是我们让技术来驱动我们的决策，这是非常不保靠的。我们不能只关心候选者知道多少技术，而不去他们有什么好的编码设计技能，其实后者是更重要的。

反模式2：选择技术不是基于有用与否

我们都准备差不多了，项目就要开始，我们做的{dy}件事是罗列出觉得适用于这个项目的技术、框架。这就像是列一个要去超级市场时用的购物单子。我认为一开始越简单越好，只在必要的时候，确定新技术能够增加生产力的情况下，再加入新的技术、框架。

反模式3：过度使用新技术（炫技）

”你拿着锤子，什么东西看上去都像是钉子”。设想一下决定使用“Spring”作为依赖注入架构。接下来你会想，Spring可以创建应用中所有的对象，然后配置文件相应的就增加了上千行代码。

反模式4：用技术细节掩盖设计上的瑕疵

当我们讨论这个反模式，性能问题立刻浮现出来。当应用程序性能非常糟糕的时候抱怨或者关注于相应的技术细节是很常见的，但是我的经验是，性能问题常常产生于设计层面。

反模式5：一直倾向使用新技术而不是平常方法

一些开发人员一旦发现他们能够用到某种新技术，立刻就对简单常用的方式弃如敝履，通常情况下这不是什么好现象。值得记住的是技术、架构、中间件都可能是项目中的负担，它们需要维护、学习、支持、配置等等。

反模式6：即使没必要也拔高扩展性的优先级

我听到的一个很常见的使用酷炫的新技术的理由是他们有良好的扩展性以及其他平常方法做不到的可配置能力。听上去很酷是不是，其实大多数情况下对于项目来说这都不是必须的，使用它们只能增加项目工程完成的风险。

反模式7：MDT-领导层驱动技术

这个反模式常常是这样的：你的领导读了一篇杂志或文章，谈论到某个高超的技术，他感到很兴奋。隔天到了公司以后他决定说：“我发现了针对我们所有问题的解决方案，从现在起我们都要开始使用xxx！”

1）我需要管理一个很“性感”的项目来提升我的职业经验。

2）它要听上去不错，而且在我得到提拔之前不能失败。

3）“反恐纳米干细胞”，这个怎么样？O-O-OKAY.