什么是好技术

什么是好的软件技术？

    什么样的技术才叫好？ 究竟是什么样的因素让人选择了这种技术而没有选择其他的？在一个好的软件设计师构建一个库或者框架的时候，他应该考虑什么才能让他设计出来的东西更成功，更受欢迎，更“好”？我今天想粗浅谈谈对这方面的认识。

推向市场的时间（Time To Market）

    当我开始评判一个软件技术的时候，我一般会采用的步骤是：下载，安装，然后开始弄一个hello world。如果这的过程就像点击软件向导中“下一步” “下一步”的话，我会这种技术的最初印象就会很好。当然，我说的只是最初的印象，因为这只是到Hello World阶段的感受，从hello world到final release还有很长的一段路。

     以Ruby on Rails为例，从下载安装到创建你的第一个网站，你需要做的就只是在shell里输入一个命令然后写一个再简单不过的Controller最多几秒钟 你的网站Version 0.90就算大功告成。哪个网站开发者会说这样的技术不酷，就让去想想他第一次弄一个WAR包他干了多少事吧。

     另外一个关于Time to market的重要认知来源于对这样一个软件技术的“无知”（不是贬义）。这种无知就是说你采用这套软件库或者框架的时候，你不需要去预习大量的相关资料，当你写代码的时候，你不需要去读整套API的的源码。总而言之，这项软件技术的使用门槛越低，学习曲线越短，就能取得更佳的Time to market。

     我们在设计自己的库的API的时候能从其他的成功案例中得到啥启示呢？ 1.用起来得容易（上手快）2。便于引导，不至于用户在hello world突然迷失 3.最好是自解释的（self documenting）。.、换言之，我我们直接参考Ruby on Rails的做法吧：有模板，教程，预制的实例，这些方便使用又不需要特别深的背景知识，它们都是一个好的软件技术的评判标准。

总体拥有成本（Total Cost of Ownership，TCO）

     一个软件产品的生命周期是不会在释放第一个版本后就戛然而止的，特别对于一些成功的软件产品它会陆陆续续释放很多歌版本并且持续很长时间。对于多个历史版本的软件产品，创建新版本不光光是对现有技术提出新需求那么简单。这时候除了新版一些很显眼的需求像是能更高效快速的开发代码之类的，更为重要的需求会变为现有的代码的更改会不会破坏可读性，可维护性，可调试性，会不会因为因为版本更新造成重大的功能倒退，会不会因为新的版本的升级造成用户的向后兼容问题。

     与仅仅考虑造出第一个软件版本相比，考虑到整个软件产品的生命周期事情就变得复杂多了，你至少必须要把上面我说的考虑进去。再加上多版本由不同的开发者提供代码的质量会远远高于可读的程度，代码作者必须通过代码的编写形式明确告知以后的维护者代码的意图和目的。

      需要特别指出的是，版本的升级不能造成老用户的升级恐慌。

够酷（Coolness）

     一个软件技术看起来够酷绝对是一件好事，软件技术更新之快就像流行音乐，人们天天谈论并且热衷于向别人展示他们是如何与时俱进，够酷就意味着这是一个很好的市场推广的起点。

     变酷的形式多种多样，可以紧追cool的趋势，可以用一些流行词来谈论这些技术甚至给你的技术取一个够酷的命名...

     但是从长期的成功，长远的发展来看，如果不具备前面两点的话，你的软件技术再怎么看来够酷就也只是个花瓶，逃不过失败的命运。