编程时尚

一个朋友在写程序时，碰到一些选择方面的问题，不知道要用哪个方法来解决问题会比较好。我跟他说不要想那么多，随便选一个可行的方法做下去就是了，在实践之前分析几种解决方法的优劣很可能会得出错误的结论。实际的情况往往是你想到的问题没有发生，没想到的问题却发生了。

他说：总觉得如果不事先想透的话。写的代码感觉改来改去的怪怪的。

我跟他说：

所以说需要Agile，需要TDD，而且那也不叫改来改去，那个叫做Refracting。

貌似偶现在程序写得少，谈起编程来却很“时尚”嘛。

令狐对此有一段评论：

那天在写Barcamp总结的时候，我就说过，为什么老外说的话别人就很容易理解，而我们就喜欢动不动就冒出专业的术语呢？
其实仔细想想，跟一个对专业一点都不了解的人说术语，会给他带来多少帮助？答案是一点都没有。因为你用他不懂的话向他解释他不懂的东西，他怎么可能弄懂？
对话的目的是为了交流而不是炫耀，如果使用术语达不到交流的目的，那还不如不用。为什么现在有人说不用模式，不用框架，不用这个不用那个，因为在他们的团队里，大多数人不懂这些，跟他们说这些没用，那还不如不要用。

──好吧，我承认上面的这段话跟这个blog没有什么关系。

下面说点正题的。

但凡选择，肯定是有目的的。比如说为了效率，为了一些处理一些特殊情况，为了节省空间，为了让代码清晰可理解，等等等等，诸如此类。如果完全没有目的，那么当然，很显然不需要考虑，闭上眼睛随便抓一个拿来用即可。如果是有目的的，那么很简单，我们功利一点，做一个简单的运筹考虑：选这个方法，实现复杂，但是很通用，效率很高；选那个则简单明了，但效率低而且不够通用──那么，请思考一下，你的项目里，对“通用”有多少需求？对“效率”有多少需求？如果用一个适合于百万级数据处理的算法，解决一个在99%情况下都不会超过1000个数据的应用，显然是太浪费了。──永远选择你目前可以接受的最简单的方法，是不会错的。将来怎么办？将来的事情，将来再考虑啦。但是，如果将来发生了情况B，你可不能只考虑解决情况B，而是要将目前的情况A和情况B进行综合考虑，寻找一个适合于他们的“通用”解法，用这个解法，可以解决类似的情况C、情况D……，这样你才不会变得太被动（为什么要这样，因为情况A的时候，你面对的只有情况A，而发生情况B的时候，事情已经变化了，它既然会变化到B，为什么不会变化到CDEFG，所以就必须为可能发生的变化做准备了）。这个其实就是传说中的敏捷开发方法。

──相信我，上面这段话的术语已经够少了。