这是RAD的弱点但在现在的商业经济环境下, 这是许多客户需要的。
技术只有放到特定的语境中才会被客户接受。个人也是喜欢语言的优雅, 也会在业余使用机器代码(这个真的是恐龙中的恐龙了)。但爱好与商业是两件事。
譬如一个大的企业, 即使在新加坡也有数百个电脑系统,每当一个企业级的change发生时,如何在短时间内用RAD的方法实现就是个现实的问题。又譬如如何在一天得时间链接以下4个applications of SAP, Oracle, MSSQL, MySQL以及构建light weight web and mobile app, 就需要用RAD思维和相应的innovative ESB工具迅速实现。又譬如如果都不知道上述4个程序的数据接口和数据库内部结构, 但需要在一天内链接, 也是要用RAD思维配合相应的innovative 工具实现。传统的工具不会都丢掉但如果想做些革新(也多赚些钱,嘿嘿),多学点新的工具是必须的。btw, 上述案例使用不同的工具。未必是最佳的,just keep learning new skills by google。不是吗?
大侠,我没看错吧?
什么企业级的变化需要在短时间内用 RAD 方式实现?
都很了解那些 RAD 通用库里都包含了哪些完全没必要的东西吗?就敢直接用?
一天内连接各个数据库?这种东西表面上能用,但是敢用吗?
数据库连接的 redundancy 各不相同,靠谱的都要在底层代码实现,什么 RAD 通用库可以通晓各种冗余方式?
如果说业余开发者或者新手,拿 RAD 当捷径来丰富履历,倒还情有可原。正儿八经的大企业或许可以拿来做个 proof of concept 之类的演示程序,但是正式部署也用 RAD 弄出来的东西?深表怀疑啊。
都很了解那些 RAD 通用库里都包含了哪些完全没必要的东西吗?就敢直接用?
一天内连接各个数据库?这种东西表面上能用,但是敢用吗?
数据库连接的 redundancy 各不相同,靠谱的都要在底层代码实现,什么 RAD 通用库可以通晓各种冗余方式?
如果说业余开发者或者新手,拿 RAD 当捷径来丰富履历,倒还情有可原。正儿八经的大企业或许可以拿来做个 proof of concept 之类的演示程序,但是正式部署也用 RAD 弄出来的东西?深表怀疑啊。