wega1975
2008-08-15 16:00
不管什么框架,入门至少半年,别说精通呢!

现今流行快速建模,快速开发!

OO语言越简单越好,oo语言本身就是直接面身客户。想了解底层的复杂,学汇编、C就好了。

浪费我时间的东东,通通是垃圾!!!!!!!!

打死活到100岁,笑死


caideyuan
2008-09-11 15:24
中国的程序员要做的事情太多了~~~
程序员(统称)没有合理的分工
很多时候,我们并不明确,
那到底是不是该我来做的事情?
看看现在的程序员,
什么都要学,什么都要做
(多学点知识,总有用的吧。
但不能什么事都要程序员来做)
能不复杂么?
是不是该考虑下,
如何分配管理细化精炼程序员呢?

leou2008
2008-09-16 17:31
我的经验是不断总结可以复用的技术,例如我们觉得获取数据库连接比较麻烦,那么可以封装一个固定的类来获取数据库连接,为了提高性能,那我可以让这个获取的连接从连接池里面获取而不是直接创建,这个时候工作就变成了两个部分,一个是前台使用获取数据库连接的类的程序,这些程序无需改进,第二部分就是将链接的直接获取改为从池中获取,这是属于后台工具类的修改工作。
对于开发来说也许作为一个针对数据库的WEB应用项目,大多数程序都在如何对数据库的数据增删改上面,我们要考虑的应该是如何压缩这部分的工作,而把其中通用的和具体的数据库、表无关的东西总结出来,因此你的简单还需要稍微再复杂一层,至少要把里面的那些和你具体的业务有关的东西要剥离出来。

还有一点需要指出的就是说到底数据库是面向关系的,可以思考一下关系和对象还是有很大区别的,数据库如果要面向对象来设计自然无法满足范式的要求,而导致大量的冗余数据,如果硬要把每个表都变成bean
也不一定是好的思路,因此任何框架我想应该在解决对象和关系的矛盾上面。

对于程序的维护来说也不是说只修改XML就简单,编译也不是什么难事,关键还是在于采用统一的开发模式和框架,包括一层层对技术的抽象,难的东西被逐步排除到业务之外,集中形成了框架或者API,而他们的稳定性可以由高端的技术人员来更新和维护,对前台保持良好的有效的接口,一方面保持了稳定性和高可用性,另一方面也使得每次技术的革新不会影响已经开发的业务程序。对于普通技术人员只要能够理解相对简单的程序和配置,就可以进行调试和修改就可以了,无论是改你的java程序还是XML文件,都没有难易高低之分。

freebox
2008-09-16 19:54
不同意楼上所说的面向对象设计就会导致冗余,面向对象设计恰好是消除了冗余,我在另一篇帖子里(http://www.jdon.com/jivejdon/thread/34663.html)也提到关于第三范式和冗余,有兴趣不妨共同讨论一下。

hhhsir
2008-12-13 09:42
看把你急的,一下就冒出了这么多名词。这些名词我都懂,但我不以为然。看来在一个“以复杂性为生”的人云亦云的行道里,连回复的贴子也是这么复杂,好象只有“复杂”才能体现项目价值,才能糊弄客户以赚取更多的利润,所以容不得一点“简化”的声音的。说那么多有什么用,只说当一个数据表增加两个字段后,你的增删改功能要改几个文件,几行代码。
**********************
lz 的这个问题 谁给说说?

byduke
2009-04-17 00:58
大家要明白很多情况下SRC文件下载修改必须在本地完成,然后把编译好的CLASS文件传递到远程覆盖原来的文件,覆盖过程中可能会导致一些失误,因为在远程没有编辑器帮你去分析代码到底哪里有运行错误,可能因为你一个不小心就把类的名字改错了 ,而察看CLASS文件很不方便,所以粘贴CLASS文件的方式有一些不确定因素,而且也有点危险.XML可以在不粘贴CLASS文件的同时改变类的指向和引用,可以改变一些业务的运行方式,最小限度来说可以直接更改数据库联接操作,同时方便快捷,而且如果一旦改错了还可以直接按CTRL+Z还原回来,其实也挺方便的 赫赫

usejava
2009-04-20 10:34
现在的框架XML多到都可以算作源代码的一部分了,修改起来一点也不简单,而且没有编译器检查错误。

退一步讲,就算XML改起来很容易,派个技术一般的去改一下就可以。问题是,企业应用中,真正改代码的时间占的很少,更多的时间花在测试和批准修改上。

顺便问一下,对于一个已经存在的系统,如何ORM?难道要重构数据库结构?

猜你喜欢
4Go 上一页 1 2 3 4