我们是否需要更多的新技术？

今天写的 blog，大家评论一下。

我向来不是一个惟技术论者，可能也是因为我的技术不够好。《软件创新之路》、《软件工艺》告诉我们软件开发最终的目的是什么：为用户建造真正令他们满意的软件产品。一个软件从业者的信用建立于持续为用户建造令他们满意的软件产品的履历。
学技术有两个方向，求广和求深。求广就是学习更多新的技术，求深就是尽量在现在掌握的技术中寻求答案。从求广的角度，我认为我们很多时候并不需要更多的新技术才能达到上述的目标。从求深的角度，我认为我们确实需要更多的技术，我们需要对现有技术更加深入的掌握。

要建造真正令用户满意的软件，就要了解清楚用户真正在关心什么。下面我按照一般情况下用户关注的优先级排了序：
1、真正实现了用户的业务需求，而不是错误地实现了业务需求。用户得到了他们真正想要的东西。当然用户真正想要的东西并不一定就是他最初告诉你他想要的东西。你要想办法去理解他的思路、理解他的思考方式（最好能和他交上朋友）以了解他真正想要但没有表达出来的东西，也许你可以很轻易地为他提供比他的期望更多的东西，为什么不去做呢？如果你做到了，你将获得人际关系方面的巨大成功，有一天他可能都离不开你了。
2、界面的美感，包括界面的布局、配色、漂亮的图片、按钮。这个很多时候超出了我们作为程序员的能力限制。当然，美工能够帮助我们。但是美工不是我们的救世主，我们有能力做好的还是应该尽力作好的。
3、系统的易用性，要从一个普通用户的角度去思考系统如何被使用，而不是作为一个程序员来思考。要想尽一切办法来改善产品的易用性，要让用户的生活更加轻松而不是体验到艰苦和挫折。
4、系统的性能，如果一个页面刷新需要十几秒种，毫无疑问用户是不会认为你建造了一个成功的软件的。为了改善性能，甚至你需要写大量“邪恶”的存储过程，只要能令用户满意，管他某大师如何说呢。
5、系统的稳定性，三天两头出故障的系统肯定是不能令用户满意的。而且你也要不断去救火不是？这些工作对你来说难道是有很多回报的吗？
6、系统的安全性，容易被攻破的系统用户是不会满意的。
7、系统的可扩展性（scalability），能够保护用户的投资，平滑过渡到将来更大规模的 IT 方案。

这几点做好了，就完全可以说就是一个成功的软件了。我对成功软件的界定就是令用户满意的可以良好运行的软件。这些标准很容易达到吗？不是那么容易吧？
软件的质量分为外部质量和内部质量，程序员往往只关注软件的内部质量，而忽略了很多软件的外部质量。这几点基本上就是我所理解的用户所关心的软件的外部质量。
至于你用什么技术，Java、Python、C# 都无关紧要，你是否用了很时髦的设计模式、AOP、MDA、IoC、TDD 同样也是无关紧要的，因为这些用户都看不到。那么你是否需要明天就为这些用户看不到的东西投入 sink lost 呢？还是可以慢慢来，先把手头的急活干完呢？我要是明天不把用户提出的这个问题解决掉就会有麻烦了，而我明天不懂 AOP 却没什么要紧。
我喜欢 KISS。傻并不是我的错，虽然我懂的很少，但是我却每天都在做事情。我喜欢当一个做事情的人，而不是当一个做学问的人。你懂的很多，写写文章还可以，但是你从来不为用户建造令他们满意的软件产品，因为那些都是脏活累活。“我可比他们光鲜的多啊”，你常常这样想。但是我敢说未来是我的而不是你的。呵呵，不出所料，你不信，你愤怒了。那我们走着瞧吧。Mono 1.0 出来了，不过才两三年时间，这些源代码难道都是靠理论堆出来的吗？

有一本书《面向使用的软件设计》（Software For Use）可能是最接近我的想法的书了，有空了找来读读。还见过几本人机界面设计的书，挑一本经典的读一读。Alan Cooper 的书国内只出了一本，实在是很可惜啊。

我们是否需要更多的新技术？没看到你关于这个问题的答案啊。到底是求广还是求深？二者不可得兼吗？假如我比较贪心，又想有点广度，又想有些深度，是不是就不好呢？而且我想大部分人大概都和我差不多，一样得贪心。

每一种新技术的出现并且被一些人推广流行，并不是因为这个技术时髦，或者说这些人无聊，而是它的的确确可以比另外某些技术更好的解决某个领域里的问题，于是某些人们接受了它，直到另一种更好的技术出现，并且替代它为止。

有些人不停的学习各种新技术，我想大概也不是说仅仅为了赶时髦，可能他只是愿意比别人懂得更多，以便在做的时候，能够掌握更多的解决问题的途径，并从中选择更佳的解决方法，比别人更出色。

对新技术的掌握和使用，会因为个人的领悟不同而有所不同，一些人彻底使软件为自己所用，可以在使用技术的时候一直的保持KISS，并且在适当的时候这些人会在实践中感受现有的各种技术的优缺点，于忍无可忍之际，便自己开始创造了，最近在看Stroustrup的《The Design and Evolution of C++》，真是一本好看的书啊，可惜翻译的不太好，偶准备买本影印版的瞅瞅。

至于和用户的交流以及设计出符合用户满意的软件，我想跟我们是否需要更多的新技术大概应该是两码子事情，应该分开来讨论，混为一团的话，别人就不知道你到底要说什么了。

这也不是一个非黑即白的问题。解决手边的问题和研究使用新技术，两者并不矛盾。建造可用的软件和讲理论写文章，两者并不矛盾。说到底，知和行，两者并不矛盾。我的母校是育才，陶行知办的学校，所以我从来都知道知和行是要并重，不可偏废的。

客户的需求可以分为业务需求和功能（技术）需求。
技术需求相对容易解决，业务这一块比较烦，也没有什么好的工具。需要从流程梳理入手来做。而且业务这一块也并不是说客户认为某件事情在他这个阶段应该怎么做，而是实施方通过建模以后给出一个应该怎么做的选择模板。
现在谈的大多数东西都是属于技术需求。

一个可以良好运行的系统的价值是无限的（然后我们才有可能去做重构不是吗？）。这就是为什么对于初学者，写出"Hello world!"是非常重要的一步。一个可以运行的系统可以提高他们对自己的信心和对技术的兴趣。以前我总是喜欢推荐一大堆书给初学者（当然都是我读过的），希望他们能够迅速理解大师们的思想，非常遗憾事实证明我做错了，这样做的效果是非常差的。经验就象你练武功时的真气，虚竹可以练灵鹫宫的高深武功，因为他身体里有无涯子 70 年的真气；他的手下练习之后则走火入魔，因为她们的真气还不够。
一个刚参加工作的程序员，如果不能够想办法从工作中提高自己，那么他是不可能成为一个好的程序员的。
开源软件教会我们早发布常发布的价值，所有的敏捷方法也教我们要早发布常发布。我最钦佩的还是 Linus、Miguel de Icaza 这样的人。Linus 没有写过多少书，但是他为我们建造了一个伟大的操作系统。我们现在多次以低廉的成本为客户成功实施 MIS 系统都是拜 Linus 所赐。

非常感谢 gigix 为我们翻译了如此重要的一本书《重构》，而且翻译的是如此的流畅。我其实不太满意侯先生的《Java 编程思想》第二版中的台湾译法，这种情况在《重构》中完全没有出现。以前我常常为自己不合“软件工程”的野路子而惶恐，现在《重构》解救了我。重构为我们更加深入地掌握现有的技术提供了所有必要的手段。大家殊途同归，我们现在已经可以很自信地为用户建造他们真正需要的软件了。

在一个很长的时间段，比如 3 年，是可以兼得的；但是在一个非常短的时间段，比如这个月，你就必须要有所取舍了，毕竟都要花时间啊。从我现在的角度，我认为尽量利用好现有的技术是更重要和回报更大的事情。

Dlee,坛子里关于软件开发的讨论有很多,我也从一开始的每帖必看到了现在不怎么关注.但是看到你依然在孜孜不倦得地讨论和思考.我觉得实在是过了一点.

关于需要不需要新技术,我作为对底层比较了解的人来讲两句,可能和各位关心programm不同,我比较关心trouble shooting和performance tuning.

下面是MS在WHDC中windows storage roadmap 的PPT,这个图片是关于windows 2003 server的stoarge 的 volume snapshot的技术实现方案.
请关注最下面的一句:

关于这个问题,我觉得根本没有必要讨论.技术是用来解决问题的.  否则就像知识不是力量,  只有有用的知识才是力量一样明白.

to jebtang：
我并没有发现我发的帖子和你说的这段话有任何矛盾之处啊。下周约个时间我们当面聊聊，呵呵。

呵呵！  我好想看不出你的观点。 只是我觉得在这个“软件工程”上你费得口舌属于过多了。

我的观点很简单，也很短。 “软件工程”从来都不是一个技术的范畴，她是一个管理学的范畴。

我觉得软件工程是分成两部分的，偏重于技术（工艺）的部分和偏重于管理的部分。如果你读了庄以前的文章你会发现软件工程实际上很少有一个精确的定义，很多时候就是一个“隐喻”，以至于 10 个不同的人就会有 10 种不同的看法（社会主义初级阶段就是一个筐，什么都可以往里面扔）。我这里也只是自己的一家之言而已。
如果说《人月神话》开创了软件工程的研究道路的话，自《人月神话》以后，有很多人在寻找“银弹”。寻找“银弹”分成两种思路，有些人从技术的角度入手，有些人从管理的角度入手。从管理角度入手的以 SEI 为代表，但是 SEI 的成果（如 CMM）在学术界是有很大争议的。我的老板 ly 的爱人在加拿大滑铁卢大学念计算机系的博士生，他们学校里的人都是不大瞧的起 CMM 那一套东西的。他们研究的是一些实打实的，能转化为代码和具体生产力的东西。CMM 在国外学术界的地位是很低的，确实如 o6z 兄以前所说，CMM 从来就没有成为软件开发的主流方式。现在的各种敏捷开发方法在我看来还是偏重于从工艺角度解决问题的。如果说在学术界有些什么定论的话那就是自动测试确实可以提高软件的生产力和质量，TDD 现在越来越流行也证明了这一点。

我对软件开发的看法比较赞同以下几本书中的观点：
《人月神话》、《人件》、《软件创新之路》、《软件工艺》、《解析极限编程》、《规划极限编程》、《测试驱动开发》、《重构》
我觉得这几本书对于组建一个精干的小团队是非常有帮助的。希望你有空了找来读读，否则我们很难有讨论的共同基础。我说的话全部代表我真实的想法，树立一个靶子也有益于大家的思考。我觉得我说的话还是务实的，不知道你为何以为我全部是在务虚？具体工作上遇到的技术难题我自己全部都解决了，我跟你谈你能帮助的了我吗？我下次 show 一段我写的 JS 代码，你来告诉我如何做自动测试好吗？

看了整篇帖子,觉得心又被狠狠地戳了一下,和你站在天平的两端,可能我属于唯技术论者,如果一定要这样来划分的话,关注使用技术,当然也关注工程技术.(可能就是你所说的工艺的部分)使用技术这部分,我想我就不谈了,很大的原因是因为我本身的技术不够好,这部分留给大牛去阐述把.之所以我现在一定要来谈这个问题,因为我现在真的是非常反感现在越来越多的人在不了解新技术的时候,就拿没有银弹这个词来进行搪塞,而且这3年以来更是越演越烈
.无数次的在和公司接触中,觉得大家对于软件的认识是越来越肤浅了,甚至出现了所谓7分管理3分技术,9分管理一分技术的所谓软件公司.遗憾的是,仗着他们自身的地位或者是和客户的关系,他们现在活得很好,听着他们口中所谓的技术无用论,蓝领工人的词汇更是层出.我向在座的都是坐过项目的,这种体会应该比我深刻的.
ps:从不反对管理在真实项目中的推动地位，有的时候甚至是决定性的，可是当先进的工程技术，设计思想被拒之门外，还要被冠上很多莫须有罪名，眼睁睁的看着人狼的诞生的的痛苦，这种苦恼不知道有多少人和我同感的