框架是银弹？还是可能是？如果永远都不是，是应该改改方向啦
框架不是解决问题的银弹，我们必须另寻出路；2000年开始用Struts，而后再也不理会什么框架，那不是提高效率、赚取利润的办法；我们要的是终极武器，不是修修补补的膏药；
做一套软件要用上多少概念、技术、框架、组件？哪个东西能够解决90％的问题？
[该贴被coolzhu于2007年08月30日 18:10修改过]
框架不是解决问题的银弹，我们必须另寻出路；2000年开始用Struts，而后再也不理会什么框架，那不是提高效率、赚取利润的办法；我们要的是终极武器，不是修修补补的膏药；
做一套软件要用上多少概念、技术、框架、组件？哪个东西能够解决90％的问题？
[该贴被coolzhu于2007年08月30日 18:10修改过]
评估下开发这套系统需要用到哪些框架、概念，用到哪些技术，还有最重要的是你得写上多少行代码，花上多少的时间；
我不否定框架的作用，可我想说的是，我们要另寻出路，不能只是一味的寻找框架和概念来解决某个局部的问题，我们要的是终极的方案；
要看得更远些，只要我们还在代码中纠缠，一切努力都不是革命性的
追求银弹的最终，我们可能还要依赖复用这一思想，但真正的变更是复用方式的革新，虽然各种框架和技术都在解决复用的方便性和灵活性，可复用还远未变得简单；
各种框架、技术都尝试提升复用的级别和灵活度，而且都做的不错，可在真实的开发中又从另一个方面带来复杂度，想尝试足够灵活、充分复用吗？那你就要足够复杂、掌握足够多的技术和开发配置参数；现实世界的复杂性让基于简单规则的软件技术永远不可能鱼和熊掌兼得；可我们还是在努力；
真正努力的方向不应该是寻找一种框架或找寻一种技术达到完美；我们应该中庸的做些让步，让复用和复杂性达到平衡，更重要的是寻找种方法让软件开发的每个组成部分都简单些；没有任何法律规定，软件开发必须学会这个技术哪个框架，研究的够深就是最好吗？
软件本质上是要卖了赚钱的，所以根本上讲我们不能让他复杂；是需要放慢学习脚本，对新的框架技术概念淡薄些，更多的去思考如何让软件开发更简单而不是功能更强大
但是，个人认为，不能将框架和银弹挂上勾，因为银弹这个字眼本身就有问题，就象大同社会或人人平等这些字眼一样，只是理想，现实中永远不可能达到。
框架只是一个很详细的技术路径，只不过有实用效果，但不能太抬举它。
以后发展方向，只能在框架基础上再进行前进，而不会拘泥於框架这个具体层面。围绕客户需求快速开发确实是发展方向，所以，DDD等领域建模方法又显然很重要，这篇文章有讨论以后方向：DSL MDA/MDSD等，当然还有厂商说界面快速开发也是一个方向，权当参考：
银弹是存在的，我们在这个方向上已经努力了6年；
重要的是，如果我们站在技术或者说Coding的角度来看，可能会失望，基于代码层次的复用有太多的不足和局限；
MDA等新想法个人感觉也是难以攻克现实世界的高度复杂性这一难题；
但这不意味着没有办法找到银弹，银弹本质上并不是说要找到一种技术来解决效率问题，只要是软件工程方法，甚至管理学方法都可能成为银弹，我们应该拓展思路，而不只是局限于开发或设计技术；
太阳下面没有新的东西，无论是那种思想、模式都在朝快速软件开发努力，而所有的努力无不着眼于软件复用，如果我们能够寻找到一种更好的方法能够有效提高复用，在复用粒度和复用复杂度之间寻找到良好的平衡，我们就能够实现快速开发；
这一直是我们的主功方向，我们的努力至少可以证明银弹的可能性；
banq如果有兴趣也可以看看我们在这方面努力的一些效果；
http://211.152.42.214:8855
这个演示系统是基于快速软件平台(Java语言)开发的软件系统；
没有采用任何框架、也没有Ajax；
更重要的是我们这个系统的开发工程师都不会Java语言；
软件复用的对象和层次是寻找银弹很至关重要的问题，复用必须能够覆盖从设计到逻辑功能到界面表现的所有方面而且无缝衔接才能达到最佳效果；
而框架所带来的东西仅仅局限于逻辑的处理，而忽略表现层，这是致命的问题；无论你采用怎样的框架和设计模式，解决数据在界面上展现和操作的问题都是大量工作量的问题；越复杂、交互性越强，越是如此；
技术工程师往往忽略界面展现，认为没有技术性，没有挑战性，但一个交互性强、使用便捷的人机交互其实对所有框架和技术都是挑战，再好的框架在复杂交互面前都是无助的，Ajax应该是业内解决展现和逻辑集成的一个努力，但远远不够；我们认为谁解决啦界面复用，解决了逻辑、数据和界面的无缝集成，就打开了珍藏银弹房间的大门，虽然要找到他还需要更多努力；
非常高兴又在这里遇到能够逐步讨论的高手，有可能我一些用语不当，也请雅含，重要的是能够给双方或更多人启迪。
>只要是软件工程方法，甚至管理学方法都可能成为银弹，
可能是我技术出身缘故，也可能我是实用主义的信奉者，一直觉得工程管理是锦上添花的事情，打个比喻，传统工厂，只有工厂生产设备变成自动化以后，管理才能得到量化，才能锦上添花；如果是一个小作坊式的生产流程，显然再好的管理和工程方法都无法显示威力。
我一直信奉“创新的技术可以挑动整体上层的变革”，比如蒸汽机和电技术的发明，已经更改整个文明，但是我们解读历史时，常被误导为这些变革不是技术创新的结果，而是xxx等其他原因。其实某个技术的创新表面上是具体技术，但是它折射的思想却是反传统，革命性的，所以，技术创新才能带来大的革命。
我想：如果银弹存在，就象外星人如果存在的话，它必然是伴随一个创新技术革命的到来而降临人间。所以，我也有对银弹存在的信念，所以，我才在软件方面和你一样一直苦苦寻求。
不但你们努力6年，整个业界可能都在为银弹努力，但是可以假设一下，反向思维，如果银弹找到了，软件下一个目标是什么呢？
在软件这么大的一个领域要找到一个可以射杀人狼的银弹，我个人觉得就象寻找一种能包治人的百病的灵丹妙药一样，是不太现实的。那么我们面对软件那么多的复杂问题是不是就真的束手无策了呢，难道真的只能疲于奔命地应付不断象水泡一样冒出的问题？显然也不是，我们还是可以有所作为的，而且是大有作为。想必大家都听过一句话：“以不变应万变”。用户需求是快速变更的，而且你不知道它要变成什么样，可以对应这句话的“万变”，构建灵活、稳定、可扩展的架构来应对需求的变化，这样的架构可以对应这句话的“不变”。而楼主所说的框架是什么呢？框架是比架构低一个层次的东西，是解决架构中某一层面问题的一种比较优雅的解决方法，而要组成一个架构，除了框架还有很多重要的因素，如框架与框架的交互等等。所以单从这么一个层面去寻找银弹，不从全局着眼，只能是徒劳的，我们要跳出框架看框架，以一种从上往下看的角度才能真正了解架构是什么东西，软件是什么东西。真正的具体的银弹是不存在的，这也是迄今我们也做不出完美的行业架构的原因，我们所能做的而且是应该做的只能是以不变应变，以变应万变，这里的“不变”是指我们的思维，从多角度多层面看问题，从整体看问题，角度决定深度，思路决定出路，这里的“变”是指各种问题的解决方法，“万变”是指各种软件开发所碰到的问题，驱动关系应该是这样的：思维方法--->问题解决方法--->问题。这样的“不变”也许才是你真正想要找到的银弹。
所以，学点哲学，方法论，启发自己的思维，对于真正地解决问题是非常有用的，不要太纠缠于细节。学习要抓住主轴，看准大方向，这叫收敛，学习的过程中多角度、多领域探索，这叫发散，相辅相成！
[该贴被banq于2007年09月05日 15:49修改过]
软件本质上的范畴已经远远超过软件本身，作为要解决现实问题的抽象工具，真的很难用软件这一词来概括；但对于银弹是否真的存在其实也不用过于去考虑，其实银弹是什么也没人能够说的清楚，重要的是找到方法解决我们面对的软件困境；
对于killer的“以不变应变，以变应万变”，我不支持也不反对，因为有些抽象啦；但从软件面对的现实复杂度来说，要到达银弹的目标的确不易；但也不见得不可以，当然前提是我们要能够共同确立，银弹找到后该是怎样的景象，即我们要有一个共同的标杆来衡量银弹的效果；这是个蛮讨厌的话题，不易沟通清楚；
软件本质上只不过是数据处理和数据展现的交替出现而已，但想想看，我们花在这核心需求上的工作量到底有多少呢？又有多少时间被我们用在了为开发而开发上？
其实提升效率的最简单的方法就是让工程师工作量只用在实现核心业务逻辑功能上，而尽量少去编写一堆有一堆的边缘代码；如何做到？把一切非核心的东西都准备好，然后尽量做到0代价的复用；
我们现在基于平台的软件开发已经能够做到无需编写代码，进行高度复用；系统开发，无需编写java代码，也无需设计jsp页面，所有展现和逻辑都通过复用实现；有兴趣可以看看我们开发的系统(上面帖子有系统地址)；访问另一个端口http://211.152.42.214:8844可以看看我们基于平台开发的一套简单的内部使用的客户关系管理系统；这两套系统差别很大，但都是基于平台构造，没有java代码，都基于复用实现；有兴趣可以看看页面的源代码，分析分析页面链接；
我对各种框架不感兴趣，有一个很大的原因就是感觉框架固然带来更好的灵活性，但也为开发本身增加了复杂度；
不是说框架不好，但总感觉框架让软件复杂，也许是做平台太久，对一切让软件开发复杂的东西都很敏感；
banq其实说的很对，对于技术的进步肯定带来效率的提升并让我们离银弹更近没有异议；但对非技术性的因素对软件开发的影响上和banq存在差异，我始终认为，管理方法、工程学方法、甚至一些简单的软件开发规则都有可能对软件开发的效率产生很大的影响，特别是在面对一些不熟悉的领域的时候；好的管理模式、一个优秀的经验丰富的项目经理，即使采用较为原始的技术，也往往能够开发出高效的高质量的软件产品；当然，如果采用更好的技术，产品应该能够做得更好；
但我对是否有种技术能够带来革命不是非常乐观；就像我们多年的努力，其实不是在技术上的前进(当然不意味着我们的技术不好，呵呵)，而是对软件开发模式和经验的理解，对软件工程学上的分析，外加一些持之以恒的决心；
而我们在平台推广上遇到的最大障碍就是太多人有同样的观点，认为没有可能....
听完我们对平台的介绍，80％的软件工程师说的第一句话是“这是你们做的吗？你们是海龟吗？”，一种悲凉，是否我们这个行业已经不自信了太久？
这个行业不缺技术和想法，缺的是耐心和脚踏实地的精神
耐心和踏实一定需要，可是适当时候务虚也需要，看看这个方向是否真的有希望...