伴随开发人员成长的问题：工程重要，还是算法重要？细节重要，还是架构重要？

为了考虑一段代码中的字符串处理效率问题，我写了一个测试程序来检测字符串引用，然后把它贴在delphibbs里(http://www.delphibbs.com/delphibbs/dispq.asp?lid=1220572)。随后这引起了对软件工程和开发技巧的争论。下面的文字很大程度上代表了我当时(2002年中)对开发技术、技巧的观点，我想这与现在的很多开发人员的观点是一致的：

========================

说实在的，现在越来越多的人员都在说要重工程，而不要重算法，不要重技巧；陷于程序的枝节，不如跳出来考虑总体结构。

看起来说得很对，但问题是，为什么到现在M$的编译器的速度都比Borland的慢？M$在这上面追了这么多年，什么样的软件工程没搞过，却怎么还是比人家的慢？

现在个人机越来越高档，对于个人而言，好象是永远也不用到CPU极限一样。但是，服务器呢？成千上万个人在用，服务器端的软件不讲求效率和性能，面临的可能就是不断地找机房管理员重启服务器！

在大谈软件工程的时代，我来追求一两行代码的性能，可能是老土，但如果做服务器程序的人，没有土一点的思想，不明白编译器的细节，可能是行不通的。

早些日子一个知名的程序员(我的同事)说他的程序象美国造的军用匕首，精巧好用，科技含量十足，而另一个程序员写的程序象前苏联的坦克，耗油、声音大但用三十年不会返修，连螺丝钉都不会掉一个。

我就说，前者适合做个人工具软件，后者适合做服务器端……

========================

基本上，即使是现在，我仍然不会去否定这种“出自程序员”的观点。但站在另外的角度，例如“软件工程的实践者”，我却在思考“语言只是工具”以及“语言只是工程中的细节”这样的问题；或者站在架构师的角度，开始思考“如果有性能需求，那么就在技术细部做处理”、“不要把‘新技术’与‘好方法’给等同起来”这样的问题。

我开始否认技术与技巧，是与承认它们、思考它们同时并进的。在《Delphi源代码分析》的前言里头，我就写过：“通常，如果你发现‘必须使用技巧来解决问题’，那么你应当考虑‘是否方案设计错误’”，而写这句话的同时，我正在自相矛盾地研究着Delphi内部的细节与技巧。

而现在，我一面在如同2002年持上述现点一样地用技术和技巧来实现一些架构的细部，同时又在实践着我在《大道至简》中写过的言论：语言只是工具。

我们对于事物的认识总是渐进的，你不能指望孔子、老子、庄子这些先贤们在二、三十岁的时候就有如今我们所知所见的思想深度，因而你也不能期望没有软件开发实践的新手们去相信你对工程和架构的理念。如同我在三年前固执于效率、技巧与细节那样，我们总能看到开发人员最正常、最真实以及最可爱的一面：持着与细致。

然而我现在的观点是：“如何做”只是手段问题，“做什么”，才应当是关注的焦点。

因而我还想问的是：为什么到现在M$的编译器还是比Borland的慢，然而VS.NET已经绝对占领了未来Windows平台上开发的市场？