发信人: i_am_trueman(粗蚊)
整理人: i_am_trueman(2003-11-24 08:54:17), 站内信件
|
【deminy】
jimyhsu兄的大作《ASP的末路》（http://fe2.gz.163.com read?b=ASP&t=84794&i=84794&al=5&n=120&l=40&back=6）说出了目前Web开发的一个热点问题：将Web应用的表现层和逻辑层分开（他的观点是“无法将Web服务应用的表现层和逻辑层（数据逻辑）完全分开”）。我想这并不能代表ASP（或者其它WEB语言）在走向末路。
目前几种主流Web开发语言（ASP，PHP，JSP，CGI(Perl)）的技术都比较成熟了，熟悉他们的人也比较多。现在需要解决的重要的问题中，有一点是如何快速开发和健壮的开发。这2点需要很多方面的努力。
快速开发中，需要代码共享，代码模块化（比如在PHP中引入类，大量生成类似于phplib这样的类库、函数库）。将很多Web显示、操作等封装起来。web语言中大量使用include这个函数来include各种文件就是这种思路的具体体现。
健壮开发，需要我们的程序结构化，规范化。而规范不光是变量名定义这么简单的。还包括程序流程的书写方式等复杂一点的问题。包括整个web开发中某些技术方案的详细确定。
举个例子来讲，就说jimyhsu兄说的将Web服务应用的表现层和逻辑层（数据逻辑）分开（这里暂且不说“完全分开”）。这是web开发中很重要的一个问题，也是我较长一段时间在考虑的问题。略微欣慰的是目前在其他三种语言（除ASP）的应用中我都看到了一些成熟的这方面的经验（我的开发一般不用ASP）。
其基本思路非常简单。这里以perl为例，制作一个.htm作为web显示模版。在perl中将相应的事务处理后，读入该.htm数据作为一个变量的值（字符串类型），然后将该变量中的特殊字符用相应的数据替换后输出，就得到用户看的界面了。
在这个流程中，.pl程序文件中完全是代码，几乎看不到任何html方面的代码。显示方面都由那个.htm模版文件负责。这样一来，就基本上实现了将Web服务应用的表现层和逻辑层（数据逻辑）分开。至于数据逻辑方面的进一步细分，那就另外再说了。
XML的引入将会更加出色。因为XML+XSLT的组合让人感觉到真正实现了数据和显示的分离，在数据交换方面的优势非常明显。但是使用 数据库+web语言+XML 来做web开发开发整个网站的少之又少（国内常看到的也只有www.csdn.net在其论坛中的某些页面使用）。这几天我正好要开发一个网站，我的考虑是尽可能完全使用XML+XSLT的组合来做显示这一块，但是后来发现这样做并没有给开发带来多少好处，而且有些画蛇添足。在我看来，XML在Web开发中的引用只能够是有限范围内的，如果考虑整个网站基于XML的基础而非传统的HTML，将会背弃引入XML的主要意图。数据处理方面可以使用XML，但是在显示这方面，页面元素复杂程度颇高的HTML不是XML+XSLT的简单处理就能够完全实现的。
我觉得目前开发中的热点、难点、重点不应该是用JavaScript做什么很难的特效，用页面语言步别人的后尘写什么Email系统，你所能想到的复杂的程序，网上都能找到这类的源代码，写代码不再是多大的难事（新手除外）。目前开发中的热点、难点、重点之一应该是如何做到快速、高效、健壮的开发，如果把别人开发的很好的代码模版利用起来，设计整理出一套、多套开发模式。
举一个关于快速、高效、健壮的开发例子。 客户端的数据校验（这是目前很多程序员做得挺差的一方面，也是让很多网民抱怨网站垃圾的，不一定是技术方面的问题，有些是做程序的习惯问题）。都是用JavaScript，但是对于各种表单元素的各种处理，你在写代码的时候有统一的完善的处理方式呢？你是否做了数据校验？你的数据校验处理流程对用户友好吗？？你的数据校验部分的代码重用性如何？进一步的，你的将要进行数据校验的表单的HTML格式的产生方式如何？是否具有重用性？？……
最直观的例子就是网易论坛发表新帖子或者回复帖子的页面，典型的用户界面不友好（请不要以为这是故意挑刺，只是一个例子）。用户可以不写任何内容就可以提交一个非法表单，然后得到一个“ Bad file descriptor”的错误提示，如果用户真的想发帖子就得被迫后退填写，浪费用户的时间。如果再进一步的讲来，就是程序员在写这个坛子的时候没有好的开发模式，属于随心所欲天马行空的写法，完全靠程序员自己的把握了。
（不过网易这个坛子开发技术方面的确不错，速度快，比起国内其他大型坛子来讲技术优势明显。我觉得充分体现了网易技术人员的开发才智。）
目前开发中的另外一个难点是文档编写（主要是网站结构分析）是个麻烦事，我到现在还没有找到一个满意的分析方法和文档编写方式。我个人认为用完全UML来分析网站架构得不偿失，会把网站结构弄得非常复杂而无意义。
最后我也来说一下关于语言方面的比较。因为工作需要，我有幸曾经用asp，php，cgi，jsp这四种语言做过专门的web开发工作。所以我相信自己在这方面有一定的发言权。这四者当中，如果谈论方便、适用，对于准备入道的程序员来讲，我的感觉排序顺序是php，jsp，asp，cgi。越在前面的越适用。
cgi资源消耗较大，程序语言学习较为复杂，虽然在这四种语言中，纯语言方面来讲功能最强大，但对于准备在web开发中快速成熟的技术人员来讲，不适用，也不必要。
asp比较简单，而且背靠微软这棵大树。但是这个语言写的东西兼容性，扩展性差，处理特殊问题的功能弱！且不说IIS和WPS的易被攻击性（安全系数不够，而且服务器的稳定性也是一个问题）。ASP傍上COM、COM+让很多人觉得ASP变强了，但是这也正是ASP的弱处：源代码的不公开！网上到处可以找到用Java、PHP写的功能棒、流程结构出色的代码（因此Java、PHP的程序员可以比较快速的提高，开阔眼界），但是ASP的就很少。找个能Upload组件还需要crack，还不能修改成符合自己需要的。ASP最后要死，也就死在这方面了。
当然，对于一般的网站开发，asp绰绰有余，完全能够胜任。我一开始就是学asp的，这是一门非常适合刚入门的人学习的语言。asp和php都容易学，但是asp更容易熟悉并进一步发展。
JSP主要是Java Web Server对程序员不友好，尤其是在错误处理方面，常常要考虑很多种错误的可能性（包括最简单的数据类型不一致这类问题）才有可能避免给你出现一个满屏错误信息的结果页面。但是它有2个好处。一个就是傍上Java了，代码编写方面比较公式化，能够借用很多Java写的现成的东西，可移植性、扩展性都很好。在一个复杂的系统中，用java开发然后用jsp来做web现实工作最能体现它的优势。另外一个好处就是，jsp(java)是源代码开放的。对于一个程序员来讲，源代码开放是非常重要的。从语言学习的角度来讲，仅比cgi容易学一些。
jsp还有一个弱处是，其web server处理效率相对要低一些。如果仅仅是做网站，选择jsp不如选择asp。
综合来讲，PHP是最好的。好处太多了，一时还很难说全，慢慢说吧。PHP本身是完全源代码开放的（比Java还彻底）；PHP在网上的各种优秀代码非常多；用户可以自己开发PHP新模块；PHP支持众多的第三方软件并可内置相应的处理函数（比如，PHP支持GD库，可以在线可以生成图片或处理图片；PHP可以支持在线对文件压缩处理的直接操作等。当然，别的部分语言也可以做这种工作，不过相对要复杂多了）；PHP代码编写的通用性非常好，非常容易学；PHP可以作为一种shell语言来应用；PHP编码效率高；用PHP可以更灵活多变的确定网站开发的结构……
不过如果PHP跑在Windows平台上，我想可能就像一个法拉利的车子安上了夏利的轮子，不能够充分发挥它的优势。
我这是抛砖引玉，请大家指正，讨论，交流。
【yahao】
好文章，已经打包！:)
如果经常都有这样的帖子出现，我就有必要常来看看了，呵呵。
其实如果只是做一个编写代码的技术人员，学习哪一种语言都是一样的！如deminy所言，几种Web开发语言都是旗鼓相当、不分伯仲的，不同的在于它所在的环境和相关的技术。
在99年的时候，我的asp也是刚开始接触，那时也想过多学几种编程语言，而且或多或少的都尝试过。用perl+gd在web页面上做走势图，当然是结合asp的，只因asp做这样的东西太复杂。php则是买过书，也看过不少别人的代码。jsp就没实际动过手了，只是向往过一段时间罢了。
到了2000年的时候，事情开始多起来，学习的时间与热情就都少了许多。鉴于那时在用vstudio98+access/ms sql server/vb做开发，所以就坚定的选择了asp，现在看来我的选择并没有错。
我并不想只做一个coder，而且认为语言和程序设计技术、思想可以是分开的，asp只不过是一个表现形式而已。过多的把注意力集中在语言上，反而容易忽略了本来的目的：客户或者老板并不在意你使用什么语言开发，能满足业务需求、能让公司赚钱就是好的，反之再好的语言也是摆设。
就同一种语言来说，不同的人和不同的设计方法都可能有千差万别的结果，换句话说，人的素质是很关键的因素。我前面提过的那个商城的网站，在我接手之前页面执行时间普遍要800以上，最慢的一个显示商品详细资料的可以打10000多。做了全面改版之后，页面执行时间一下子降到了平均60左右，网站首页的请求数是之前的9倍。
但是asp也不是万能的，很多弱点是无法避免的，这个就是deminy提到的那些了，而且短期内也不可能得到解决，php在这方面的确要比asp强上许多！再说那个xml，单纯的应用效果我觉得一点也不好，csdn那个和垃圾没什么区别，每打开一个页面，数据都是滞后一些时间才出来，而且cpu占用都是100%，响应时间也很慢。个人认为，做的最好的还是微软自己！最新版的在线更新网站和platform sdk的安装程序都是xml技术的完美体现，不得不佩服人家。
现在流行的综合实力，单单比谁写的代码漂亮已经不合时宜了。谁的解决问题的能力最强，谁就是胜者！同样的一个功能，如果你的代码执行需要100毫秒，而我的只要20，那么很明显你是失败者。
我的定位是解决问题能力最强的人，并不会拘泥于任何一种语言上。asp只是因为用的久了，比较熟悉，而且也积累了不少成熟的代码和应用框架，比较适合以后的项目开发而已。简单的说，如果只靠asp，可以做的事情将是很少的，必须要结合其他方面的技术才能最好的实现业务流程和满足业务需求。
对于在座的各位asp-er们，我想说不要把眼光仅仅停留在语言本身，那样你只能永远做一个coder！要注意培养自己解决问题的能力，当然，编码这一关是基础，是必须要先做好的。譬如说良好的编码习惯和一贯的风格、高度的可重用代码等等，如果这个做不好，就称不上一个好的coder了。
总结一下，如果只想做coder，学哪个都一样。如果想做更多的事情、有更大的发展，那就先问问你自己想做什么咯？！:)
【liangzy】
好文章，不过不太同意你关于jsp异常捕捉部分的观点，其实在jsp和java中进行尽可能多的异常捕捉，对于初次接触java编程的人可能感觉会非常不习惯、麻烦，但是这样做的好处也是非常明显的：将各种可能发生的异常在编程阶段就设置如何进行捕获、处理的手段，这样客户端看到各种服务器错误提示的几率就会大大降低，程序的壮健性也会相应提高，这也就是为什么m$在他的最新语言C#上也采用了几乎完全相同的异常处理机制的原因。
另外就是关于jsp web server处理效率低的观点，我实在不敢苟同。众所周知，jsp页面在执行前，自动由web server编译为一个servlet类，页面请求都由这个编译后的bytecode处理，除了第一次请求可能因为要编译生成这个类而速度降低外，以后的请求处理都会因为执行编译后的代码，所以其执行速度比asp的解释性执行方式要快得多，所以我很不明白您说得asp处理效率高的理据何在。同样比照微软的最新的asp.net,我们会发现它与jsp相似的地方相当多，包括采取这种编译后执行方式运行，而不是解释方式运行，以提高执行效率。
至于php,我也粗略的看过一下，理解很粗浅，下面是我的一些看法：我的感觉是要用好php，必须熟悉php里面的一大堆函数，包括数据库操作在内，必须按顺序调用一个个函数，不同的数据库使用的函数也不同（比如mysql和oracle各自使用一系列函数），整个体系结构构建在这些函数之上，没有asp和jsp这么严整、层次分明、有条理。php的open source \free特性吸引了很多web开发使用它，但它的扁平体系结构，让更高级的应用开发难以展开（企业级应用几乎不见php踪迹），不过php优胜在完全的open source，这样如果需要，你可以自己修改它的内核，加入自己的功能模块，丰富它的内涵.甚至重新编译生成“你自己”的php服务器，不过这恐怕只有少数高手可以做到了。
另外，相比较asp\jsp背后的几大巨头的技术支持，php的后盾就显得相对薄弱了很多，这也是它的一处硬伤。
不过我非常同意yahao的看法，其实用什么编程语言并不是最重要的，语言只是一种工具，并非决定性的因素，花太多精力在不同语言的学习上面，并不一定是明智的做法。
以上也是我的一家鄙见，班门弄斧罢了。
【deminy】
我在使用jsp开发的时候也曾了解了他的有关机理，但是遗憾的是在实际应用中（包括观摩别人的应用），觉得他的速度的确是明显的差。我实在没有看到jsp速度上的优秀表现，所以对它的感觉比较差。有可能的话讨教讨教。
另外jsp的异常捕捉非常全面，但从另外一方面来讲这也可能成为弊病。有利有弊。我光说弊了。 :-)
php对于企业级应用来讲可能有点难于登堂入室。但是相对而言，绝大部分的应用php还是足够胜任的。不过我好像没有说过"asp处理效率高"，我也没有这样理解。
大家选择的路不同罢了，对于我来讲，open source非常吸引我啊 :-)
【liangzy】
呵呵，刚才仔细看了一下你的原文，关于asp的效率，确实有点误解你的意思了，不好意思。
关于jsp的速度问题，可能我做的东西都比较小，所以虽然用tomcat也没感觉到他速度慢，另外关于jsp的web server，sun只不过制定了一个开放标准，比如jsp2.0 、servlets 2.4，各厂家只要达到sun的标准，解决方法、效率与速度都是各自厂商各出奇谋了，选用不同的web server，效率自然有差别。如果有兴趣,我们甚至可以自己编一个这样的web server，8-）
因为java的运行基础都在于jvm，而jvm是架设在操作系统之上的，执行效率也有赖于操作系统的支持。jvm的效率也会对jsp web server有很大影响，这也是java的硬伤，没什么好办法，我想你觉得他速度慢，这也许是其中一个重要的原因吧。
【gzcjh】
deminy说得很精辟，也道出了很多人的心声，但有些地方我有不同的意见。第一个是IIS容易被攻击只是因为网管配置的不好而出现的，不能作为IIS/NT/2000安全性不好的证据，就好像说因为刀子可以杀人就说刀子是坏东西一样。第二个是ASP写的东西兼容性，扩展性差，如果仅仅说VBSCRIPT是这样我没意见，但配合上COM和COM+就肯定不是这样，但目前的情况主要是ASP的开发者大部分都仅仅是使用VBSCRIPT来写，就算是COM的也很多用VB来写，用来只是处理数据库相关的东西（我这里并没有贬低处理数据库逻辑的意思），而这些东西恰恰又用VB来处理来的快，但要真正实现底层的功能需要的是用C/C++来实现的，结果就出现了因为ASP=VBSCRIPT=VB所以ASP没用没前途的结论。第三个是源代码不公开也是冤枉，网上GNU的东东太多了，但一个很重要的情况是这些东西大都是用C/C++写的，由于上面说到的原因结果，大家找到这些东西都没用，或者根本没有想到往这个方向上找。
【yahao】
兼容性往往都是有代价的，而且也不是绝对的。
java是很好，你说它是跨平台的，可是偏偏微软就不给它好脸色看，这样等于说在Windows平台上跑java应用的可行性会越来越小，直至不能运行。以微软的实力和财力，斗斗太阳微还是绰绰有余的，不信我们就走着瞧。微软自己的java和Sun的java味道是不一样的，至少花样要多出好多，最后就变成微软的java和Sun的java两种版本，之间并不兼容。你还能说java是跨平台的么？即便是这样，java在某些方面的应用还是不容忽视的，只是这个跨平台的意义要小很多，多半还是用于广告宣传吧。
com/com+是二进制兼容的，和用什么开发工具所开发没有什么关系，至于性能上或许有明显差别但是判断的标准应该是投入与产出的合理性，而不是性能。试问半年用c++开发一个商业组件，只能用在一个2万元的单子上，哪个老板会答应这样做呢？同样的，即使用vb开发的性能上差了一些，只要在可以接受的范围内，都是首选。当然，有些东西是vb所不能及的，那自然就是该c++施展拳脚的时候了。不管是国内还是国外，可以见到的书上，都主张用vb开发商业应用组件，用c++开发系统级的或实用工具类的组件。乱用只会增大成本，根本不划算。
btw.数据库相关的商业组件，在网站上用的，几乎清一色都是用vb开发的(ms.platform)！:)
再说源代码公开，这个和得不到的东西都是好的是一样的道理。就算微软把windows2000的代码都给你，你又能看懂多少呢？我看只会造就更多的国产的、“拥有自主知识产权”的windows变种，就像现在流行的各种linux。或许有自主知识产权没有问题，但明眼人都知道，有哪个linux的内核程序不是老外的？改一改界面动点小手术就叫自主知识产权，你不觉得这样称呼很牵强么？
我认为不是所有的东西都适合做源代码公开的，系统级的可以考虑，应用级的就不大适合。如果我辛辛苦苦做出来的一套商业系统代码免费送给你，那不成了免费的午餐了？现在可以找到的源码，和应用相关的都只是些片段，完整的一般就是某些人以某种方式得到的非法版本了。
现在的一部分人，可能都着想不动手就有人把代码送上门来，然后改一下甚至改都不改就可以拿去卖钱，这样该多好啊！更狠一点的就改点皮毛的东西然后换个名字当成自己的作品了，美其名曰：自主开发。不得不承认，现在这样的人很多很多。
【qcrsoft】
跨平台统统狗Ｐ，不过是每个平台都写个解释器而已，微软想跨，只消多写几个版本的编译器，VB、VC立刻也跨平台
【deminy】
网站应用方面，需要跨平台的地方的确太少了。即便碰到，而还是容易处理的。跨平台应用在那些规模庞大、多种终端类型的系统比较适用。就此而言，其实跨平台的需求是有限的，大部分应用开发根本涉及不到，也不需要。但由于该卖点非常响亮，因而引起广泛关注和跟风，情有可原。
看来我们以后做东西也应该少考虑这些跨平台的问题才是。这个讨论对我颇有收获。
【deminy】
没有深入过COM技术，更别提用C++写的了。后面还要好好了解了解。
MS是伟大的，坚持GPL（http://www.gnu.org/copyleft/gpl.html）理念的技术人员同样伟大。
觉得在源代码公开的条件下，能够更快地加速中国技术人员的成长。能够让中国的技术人员更快的接近世界的脚步，进入更深一层的领域，而不是在MS后面亦步亦趋。我在Linux下和Java方面的工作经验告诉我，MS在技术资源方面的保守行为不是技术发展的好方向。
在代码开发和系统规划方面，劳动成果固然可贵，大家都很心疼。但是技术方面的各自为政还是很容易导致不能整体发展的。在我看来，大部分代码其实没什么值钱的。我能写出来，基本上别人也能写出来。我写出来的好代码给别人看，如果别人有能力，自然能够很好运用；如果没能力，就当没给。技术人员之间的竞争不在于技术的互相保守，而在于技术share（当然，不是像共产主义那样，所有的都share），共同进步。如果大家多跳几次槽，大家可能就会发现，同事之间的技术保守没有多少必要，而之间的互相交流，才能更好的促进自己的技术进步和以后的同事友谊。在技术上，我们还需要大方一点。给别人做项目，就是把其他人曾经做好的整合一下，然后花点苦功新写一点东西就完了。如果我们重新开发，我们会发现我们所做的绝大部分工作别人已经做过了并且可能源码共享了，而且很可能比我们做得更持久，更专业。这样的情况下何必花费这些时间呢。我们需要考虑的是如何利用这些现有资源，而不是重新做一套系统。我们可以把节省下来的时间干点别的（比如休息，或者研究新技术）。
我现在做一个项目之前，先会考虑一下要做什么，用什么技术（由于公司的乱七八糟，所以有时每次做的东西用的都不是一样的技术内容），然后就开始在网上浏览浏览别人的专业的源代码（国内的几乎根本不看），测试、比较一下，选择看上去最适用的代码。综合综合，再解决掉某些特别的问题，差不多剩下的就是按部就班的完成琐碎的工作了。一个项目的难点，往往就是整个技术方案的组织和几个特别的技术方面的难点而已。
换一句话说，既然代码本身不怎么值钱（但写代码还是值钱的），那么什么东西更值钱？我认为以下2个应该算是更值钱的：
1. 服务。服务是有价值的。代码是现成的，但是怎么运用，怎么修改，怎么维护，怎么升级，怎么具体落实到一个新的系统中，还是需要我们做的。我觉得就像IBM理解的那样，服务是应该值钱的（就像现在流行的咨询顾问一样）；
2. 对于系统/项目开发能够给出高于代码编写方面的思路/指导。此处略。
又抛一次砖头。
【yahao】
呵呵，砖头蛮多的嘛～
:MS是伟大的，坚持GPL（http://www.gnu.org/copyleft/gpl.html）理念的技术人员同样伟大。
同意这个观点。
:觉得在源代码公开的条件下，能够更快地加速中国技术人员的成长。能够让中国的技术人员更快的接近世界的脚步，进入更深一层的领域，而不是在MS后面亦步亦趋。我在Linux下和Java方面的工作经验告诉我，MS在技术资源方面的保守行为不是技术发展的好方向。
源代码公开确实可以使一部分人少走许多弯路，gpl在这方面做的非常出色！遗憾的是有些人总是轻易的就违反这个协议，这点是个很大的问题，尤其在国内。在asp方面，我不喜欢源代码公开只是不想让某些人不劳而获，用了别人的成果不说，转手就成了他的作品了，这样的结果我想是每个原创作者所不能接受的。都说长江后浪推前浪，难道前浪就真的就要死在沙滩上？
ms的技术垄断是个不争的事实，这个我们也无能为力，对个人而言，能实现比较好的经济效益就很不错了。不能因为这个就抵制它的全部，毕竟现实就是这样的，你无论如何也不能逃避。美国炸了中国的大使馆，都知道鬼老在撒谎，明明就是瞄准了炸的，但是现实情况告诉我们：没有实力总是要被人欺侮的，不是在这里空喊两句爱国打倒鬼老就可以解决问题的。等到了中国的航母舰队也可以到处耀武扬威的时候，看看还有谁敢不把我们放在眼里？！当然，现在还远不是时候。
:在代码开发和系统规划方面，劳动成果固然可贵，大家都很心疼。但是技术方面的各自为政还是很容易导致不能整体发展的。在我看来，大部分代码其实没什么值钱的。我能写出来，基本上别人也能写出来。我写出来的好代码给别人看，如果别人有能力，自然能够很好运用；如果没能力，就当没给。技术人员之间的竞争不在于技术的互相保守，而在于技术share（当然，不是像共产主义那样，所有的都share），共同进步。
对我来说，这个要看人。在某种条件下，我是不反对代码共享的，怎么说做出来的东西都已经是过去的东西了，在脑力里的才是最新的。换句话说，如果你想看我的代码，我可以给你看。如果要我提供公开下载，那是不可能的。再如果你把我共享给你的代码拿去给人任意下载，那么只会让我看不起你，并且不会再有下次了(举个例子而已，不要介意)。
还在公司的时候，我都是尽量把所有能共享的资源都共享给同事，包括软件、工具、文档和一些代码等。这些资源，可以说是很好的，多数都是同事没有的。然而效果并不怎么好，我知道这已经与技术本身没有关系了，因为他们大多缺乏主动性，当一个人总是被动的接受时，他/她是很难学到很多东西的。
不过也不是一点作用都没有，至少当我把我的编程规范和编码规范以及editplus的专业使用说给他们听时，大家都很感兴趣，算是小小的开了把眼界吧。:)
我是抱着授人鱼不如授人以渔的态度去做上述事情的，在我看来，教会别人一个好的获取知识和进步的方法远比直接告诉他/她一些tips要有用的多。当然，在他们遇到问题需要help的时候，我也总是尽力耐心的帮他们解决问题，以至于后来在一些同事看来没有我解决不了的问题(自己心里明白的很，这是不可能的:p)。
适当的交流可以促进交流的双方共同的进步，可以说是双赢的！
不过在web开发这块，现在能够交流的人不多，至少现实生活中比较少，网络上又得看机会了，不是每个人每一次都可以交流的。这一次的讨论应该说是很好的，虽然技术细节上的不多，但是作用还是很显著的。可能是自己走的太远了，缺少水平相当的同路人(我是指现实生活中而非指网络上)吧，反正一直觉得自己是个孤独的行者。努力着、进步着、孤独着。
btw.我相信我的代码和我的理念都是值钱的，因为稀缺所以珍贵 :)
:换一句话说，既然代码本身不怎么值钱（但写代码还是值钱的），那么什么东西更值钱？我认为以下2个应该算是更值钱的：
:1. 服务。服务是有价值的。代码是现成的，但是怎么运用，怎么修改，怎么维护，怎么升级，怎么具体落实到一个新的系统中，还是需要我们做的。我觉得就像IBM理解的那样，服务是应该值钱的（就像现在流行的咨询顾问一样）；
:2. 对于系统/项目开发能够给出高于代码编写方面的思路/指导。此处略。
在asp上面，你可以找到的代码99%都无法通过我的标准(不是片段而是全部系统的程序，国外站点上的那些代码多数都是很好的，我所说的不包括那些)，所以可用的可以说是甚少。这个和个人的经验以及遵循的标准有很大关系，高标准写出来的代码必定是合格的。其实如果是养成习惯的话，高标准也并不会多占用多少时间，而得到的却是很好的可重用的、易于维护的代码。遗憾的是很多asp-er都没有自己的标准，“能用就行、够用就好”不是标准，只能算处事的方式而已。你提到的这1和2我觉得都很重要，也是我们以后努力的方向吧！
【gzcjh】
相信 yahao 兄理解错我的意思了，COM 是跨语言的，对于能够使用 VB 来实现的东西，绝对不应该用C++去搞，那是浪费时间，特别是操作数据库这些VB天生的强项上。我所说的是大家都抱怨ASP能实现的功能太少，只不过是因为大家还没有看到ASP和COM的配合以后的强大，就老是在说用XXX就能怎么怎么样，而你ASP（仅仅是VBSCRIPT）就不行。但这些往往需要做到底层才能体会到其博大精深。
对于2万元的单子，一般都是只需要实现一些很简单的功能就可以了（例如简单的网上选单），肯定不需要做很深入的开发商业组件，但一个200万的单子（例如网上购物、加上在线支付、还要什么短信通知的），要实现的就不是简简单单功能了，首先就需要研究清楚银行的接口是走什么协议的，移动局的短信网关又是遵循那个标准的，接着还要去刨一大轮RFC什么的，最后这些的实现就不是简单的用VB就可以了（可能用VB也可以，但就效果刚好和用VC去写数据库操作的效果一样），因为为了实现跨平台（这个不是指JAVA那一种，而是Source一级的）使用这些协议的实现都是用C写的，当然了，这个例子极端了一点，但目前也很多有这样需求的系统。
顺手抛一块砖头，一般来说实现底层协议的COM我都会用C/C++来做，而实现中间应用层的COM（如调用底层API，操作数据库等）都会用VB来做，最后的表现层就直接用ASP来实现，也很想听听各位高手的指点:)
【liangzy】
关于跨平台，我很同意deminy的观点：不同的应用境况有不同的需求。
关于可能需要跨平台的应用，我觉得有两个方面：第一个就是大型应用系统开发、部署阶段需要在不同的系统平台上展开，这时候跨平台的需要必然是强烈的，这样的开发如果没有跨平台能力支持是难以想象的：因为大型应用开发常常并不局限于某方面功能的程序编制、部署，还常常包括了对操作系统功能的较全面的应用与交互，这时候不同的操作系统之间的协调将变得异常艰难。这时候拥有跨平台能力的语言就为不同系统之间的交互与协调提供了更简单的途径。
第二个可能需要考虑跨平台的情形是，要为你的操作系统、系统应用环境可能的变化作准备。比如原来你的应用系统是基于winnt4.0的，但将来也许你的系统需要升级到windows.net或ｕｎｉｘ系统，这时候，早期部署的应用系统是否有跨平台的能力就意义重大了，因为如果你早期开发的系统具有跨平台能力，那么就意味着，操作平台升级对原来的应用系统的重新部署方面的影响非常小，而与平台结合得过于紧密的应用系统，在新的操作平台下可能几乎无法部署，甚至需要重新编制，如果这个系统还相当复杂，那么跨平台与否就意味着巨大的成本差异和时间效率差异。
跨平台是否很重要？是否有意义？
这样的问题对不同的应用系统答案是不同的，对于相对简单的系统，与其他系统的交互和升级操作系统获得更多功能的需求本身就很小，或者这些功能的获取并不需要programmer考虑(比如升级你得apache服务器或iis服务器获得的新功能已经足够了），这时候跨平台与否根本无关痛痒，如果一定要强调什么跨平台能力，就未免“自作多情”了。
而如果你的系统是大型系统，不同平台之间的交互需求或平台升级的潜在需求一直存在，应用系统开发时考虑跨平台能力就是必要而有益的了。
从软件业发展的角度来说，跨平台能力是否重要，我以为这是不辨自明的：微软的.net系统的一个重要目标就是跨平台，如果跨平台能力真的如此“可有可无”，m$投入如此巨大的资源意义何在？而且m$的跨平台，可能比sun更加彻底（如果微软声称的目标达到的话）：只要程序兼容于微软的.net平台，就可以运行在各种具有.net runtime的平台环境下，甚至不需要理会程序编制时使用的语言，在.net环境下不同编程语言之间的交互变得更加简单、透明——不但跨平台，更跨语言。
但作为一个程序开发人员，是否需要掌握一种跨平台的开发工具，就要视乎你的个人情况了，重要与否，因人不同。
所以我以为，跨平台是否有意义，是否重要，要从不同的角度看问题，对于一个简单的应用系统或是一个必须倚重某种操作平台才能提供的一些功能，考虑跨平台能力几乎没有意义，但如果你的应用系统（也许）要部署在不同的操作平台上，在开发前考虑跨平台能力就会对你有明显的好处。当然也要考虑技术人员的情况，如果整个team都是vb程序员，讲什么要跨平台就是想招人白眼了，8-）
还有一点我们应该明确的是：不论是java虚拟机还是微软的.net frameworks，因为它们成为应用程序和操作平台之间的“中间层”，所以（潜在的）具有了“跨平台”能力，这不过是它们具有的优势、能力之一，要把这个能力和他们提供的其他能力一起放入整体需求中分析才可能客观、合理地看待“跨平台能力”；而且作为“中间层”，总有一些操作平台的某些功能是它们无法或难以实现的，这是无可避免的，因此而贬低“跨平台能力”并非理性的做法。
另外就是关于yahao关于java跨平台的观点我不能同意，其实m$的j++并非java，原因很简单，J++不符合java标准，所以讲"m$的java"没有意义，应该说m$的j++与java不兼容，而其他公司如ibm,borland,bea他们的java开发都是符合标准，保证了彼此程序的兼容性的。而且j++也很不成功，再m$最新的.net 里面我们已经看不到它的踪迹了（刚出的J#和j++什么关系我还不太清楚）。
btw,说一下com的问题，以我所知，微软开发com标准的一个目的其实就是希望以其二进制兼容性达到跨语言甚至跨平台的能力，不过效果并不理想，首先是com标准太复杂，开发、部署的技术难度高，比java的bytecode生成、部署难太多，其次就是com无法继承，这样要利用已有的com组件创建自己的com组件就相当困难，只能把这个com封装到自己的com中，并实现其所有接口，一个字：难。所以com功能虽然强大，但在技术实现和复用性方面的表现却太不如人意，这就是为什么.net颇有抛弃com体系的态势的原因吧。所以我以为，除非必需，现在返回头深钻com，恐怕益处不大。
一家之言，望各位斧正
【gzcjh】
我想也不应该把 COM 一棒子打死，毕竟存在了这么多年，正在用它的系统成千上万，要转换成.net也不是一件容易的事，而且正在运行的系统追求的不是技术的先进，而是稳定，所以起码还有很长的一段时间内 COM 还会继续扮演重要的角色，就好像MFC当年很多人都说要过时了，但到现在还没过时。话又说回来，COM实在是很复杂，可以说它体现了C++编程的精髓，但目前还不完善，如果没有了微软的大力支持以后的情况也就很难说了。
【yahao】
是非常的难！vb只能些简单的和商业上的应用，系统级的和底层的都只能用c/c++，这样一来复杂程度一下子就上去了。
呵呵，通过上面的几轮“舌战”，我学到了不少东西，在认识上也有了一些加深，谢谢各位了！:)
btw.再讨论下去我想就超出我的能力范围了，所以后面几个帖子都是发表一下简短的意见而已。我的“势力范围”很小，而且也不想搞的太大，以免分散了过多的精力无法做到精深。再次感谢。
【yahao】
c++的com开发难度是我所无能为力的，所以到现在为止，我只是用vb做一些简单的商业组件。也因为不想只是蜻蜓点水，所以不会轻易开始进入c++的com开发，直到有了充足的准备以后。:)
【gzcjh】
deminy说得很精辟，也道出了很多人的心声，但有些地方我有不同的意见。第一个是IIS容易被攻击只是因为网管配置的不好而出现的，不能作为IIS/NT/2000安全性不好的证据，就好像说因为刀子可以杀人就说刀子是坏东西一样。第二个是ASP写的东西兼容性，扩展性差，如果仅仅说VBSCRIPT是这样我没意见，但配合上COM和COM+就肯定不是这样，但目前的情况主要是ASP的开发者大部分都仅仅是使用VBSCRIPT来写，就算是COM的也很多用VB来写，用来只是处理数据库相关的东西（我这里并没有贬低处理数据库逻辑的意思），而这些东西恰恰又用VB来处理来的快，但要真正实现底层的功能需要的是用C/C++来实现的，结果就出现了因为ASP=VBSCRIPT=VB所以ASP没用没前途的结论。第三个是源代码不公开也是冤枉，网上GNU的东东太多了，但一个很重要的情况是这些东西大都是用C/C++写的，由于上面说到的原因结果，大家找到这些东西都没用，或者根本没有想到往这个方向上找。 |
|