delphi的价值，很多人还是没看到。。。。。。。

讲起delphi，现在很多人已经不知道它了，

知道的人里，多数人也是只知道它是RAD，开发效率高，然后就是：拖放、拉伸、堆叠控件，低技术含量！

【delphi就是RAD开发MIS系统，一大堆的控件可以用，像搭积木一样，能值钱吗？
MIS系统本身就不需要很多技术的】

可怜做delphi的自己也看不起自己
delphi的高效开发解放了开发者，
但是如果开发者是到此为止，那么，自然是没给用户带来什么价值，也就是值搭积木的工夫钱；
但是，如果开发者因为开发效率高了，从而能有精力去理解、挖掘、解决用户的问题，
甚至对于中国特色的需求老变也能应付自如了，才是真正实现了用户的需求
这样，整个事情就不一样了——国内MIS的失败率奇高与你没有关系了！

到这一层，讲起来好像与什么语言、工具没有关系，

其实大不然！如果不是开发效率这么高，开发者很难把用户真正的需求诱导出来，

很难让用户边“用”边完善需求，最后的产品必然是与用户越错越远了。

看来，看不到这一点的，不但是追赶时髦的用户，连很多delphi开发者也是如此啊
难怪delphi也该绝了。。。。。。。。。。。。。。

 

 

读 http://topic.csdn.net/u/20090425/08/265d5e22-960a-4510-8981-6b05b05bad00.html 有感

 

2009.5.3补充：

引用 37 楼 lee576 的回复:
还有人断章取义的，我不想说，每种语言有适合的领域，我就说delphi游戏开发值钱，有它的原因！
MIS 用到的技术就那么多，估计又有人看到这句会不爽,你不服可以看看招这两种领域开发的人员，他们的薪水是否一样！！一种技术掌握的人多，会的人多，自然就贬值了！
需求和管理完全是另外一会事，在哪种项目里都很重要，如果非要扯到delphi上，那么OK你也是正确的。
现在delphi的需求量小，工资偏低，我不能说它是个别现像，大…

本来看到这样的语气，是不想再说的了，只是看到“断章取义”就多说几句：
的确，【需求和管理完全是另外一会事，在哪种项目里都很重要】，不一定就是delphi才最强
我的经验告诉我，做MIS，用户是“易变”的，尤其是中国的用户，自己都不清楚自己要什么，或者清楚但是说不清楚
所谓易变，其实也就是开发者在理解、了解用户的需求上的困难，
这种困难导致开发者在不同阶段对需求的理解、认识不一样，所以才觉得需求又变了！
其实，变的不是需求，而是自己的认识！
只要不是故意跟你过不去的用户，谁愿意变来变去，
尤其是项目的开发实施这么个时间段内，变化的可能性本来就是很小的
而且，真正成功的MIS，应该能考虑到用户应用的发展趋势，他们合理的小的发展变化，应该是要考虑进去的
——到这里，的确都不是delphi特有的。
但是，要做到这一点，如果没有RAD且数据库支持得好的语言、工具，那只能是开发人员的一种奢望。
而delphi，就正好是很好地满足了这2点！
（这一点，有人可能会举vb甚至vfp的例子：它们岂不是更好！
但是，一般而言，它们这种语言，更适合高素质的业务人员学习后建立方便自己、部门的小型应用，
用于构建较大的系统时，可能会遇到一些瓶颈。相对而言，delphi在这方面的瓶颈更高一些。
不用说vb也有大应用的例子，行行出状元，各个语言都有把它发挥到极致的高手。
但我现在在这里只是说主流开发人员的应用水平）


所以，在游戏方面，我倒是不完全看好delphi。除非游戏开发的前期也需要大量的原型用于开发者与策划者甚至游戏用户的交互、沟通。

至于说delphi开发MIS不用什么技术，更是无法认同。
delphi只是细节开发上帮你省掉了很多琐碎（同时仍然保留深入的能力），
而真正的企业应用框架，由于delphi出的早，没有直接提供（的确如上面有人说的：C#反而有！）
这一点，做delphi应用的公司，需要有人能创建出一套成熟的框架，从建立到完善，这个才是需要技术含量的
（公司的其他人在这个框架下进行开发，才能又省事（这时才可以说没有技术含量了）又高效（能应付更远更大的压力））

至于认为我被什么一两套商业公司的东西所误导，实在是令我摸不着头脑：
一两套商业公司的东西，是指什么公司的哪方面、环节的东西？
开发工具、环境、平台？还是最终的MIS产品？还是系统集成公司的？？