发表评论
一时兴起,望原谅。
在一个棚子里面,发现窗子破了,于是就拿一个锤子乱钉钉子。
最后棚子塌了。
无奈只好替人遛狗狗,狗狗拉肚子,到处放水。
深有体会!我天天在制造和修改垃圾代码,我们做的项目没有一个说是顺利漂亮的完事的
不同的项目 有不同的开发方式
个人的观点, 100w以下的项目 SQL语句直接写在界面层 都不为过
SQL语句直接在界面层 并不意味着没有层次和封装
做项目,不能太要求完美
一个处处要求完美的项目,注定要失败!
一个处处要求做到分层、封装、面向对象的项目,也许可以成功,但代价是沉重的!
SQL语句直接在界面层进行调用,在大部分做项目的软件公司都是这样,
特别是针对需求变更频繁、开发时间紧迫、公司人员变动频繁、人员水平参差不齐的情况下
我刚毕业的时候 也是极其讨厌SQL语句直接在界面层的做法,但经过几年的项目实战,发现以前的观点是错误,目前的公司经手的2个50w的项目 1个400w的项目(业务极其复杂的一个项目,光表就300多个),都是SQL语句写在界面上的
系统运行到现在,中间出现过一次问题,但和sql无关,其它倒是没出现过什么大问题,相反优点倒是体现出来了
要提高每一个组员的能力才是最重要的。
但是怎么提高呢?
公司里的高手是义不容辞的。
看来让高手带新手是重要的。
那么怎么带呢?
培养高手(也包括其他人)的团队意识是必须的。
看来要多讲课了。
那么有谁来讲?怎么讲,讲课的效果 又如何判定。
讲团队意识,讲高手的经验,讲程序技巧。
怎么样,乱了吧。
@看客
只能说你还停留在asp时代,SQL语句直接在界面层进行调用,并不见得方便。
说得有道理。。
如果刚加玩班回来,明天还要加班。。
就只想糊窗子了
不是最严重的,最严重的是上面要你做的时候,你根本不知道是什么,上面也不知道做什么,“看到效果再说”,当你完成一个版本的时候,上面“发现”了一个更好的思路............
比喻很形象.
Sql语句直接写在界面层,那对于数据库变更这种情况,只有痛苦了
另:
'一个函数居然超过3000行' 我见到上帝了````
楼主提出的问题挺好,但只是提出了问题,而没有给出解决的办法。最好能提出问题,然后解决问题,那样对大家的行动才会有个指导。
@看客
我不完全同意看客的说法,确实一个项目要完全实现面向对象需要付出一些代价,但绝不是沉重的代价。在项目开始之前项目负责人拿出一个好的解决问题的标准,然后大家就都按着这个标准去写代码,那样怎么会乱呢。
“SQL语句直接在界面层进行调用,在大部分做项目的软件公司都是这样,
特别是针对需求变更频繁、开发时间紧迫、公司人员变动频繁、人员水平参差不齐的情况下”这句话我比较同意。
楼主不改回车的地方乱回车,这个习惯就是非常不好!!!
多花点时间改自己的毛病,少说些酸溜溜的话。。。
花两分钟改改吧
我现在在擦屁股,做收尾工作,这帮人干的活太LJ了,以上6点都要做!!!
400w的项目....光表就300多个....
____________
不能说你们的程序NB,只能说你们的市场人员NB
注意养成良好的编程习惯,这个自然没话说.
项目要不要花时间去设计分析,这个很大程度上是公司管理上的问题,国内公司都存在这个问题,还是一切从实际出发吧
人有时候总是被习惯性思维束符 为什么不能打破固定思维模式的限制 从事情本身的角度去思考解决的办法 有时候事情就是那么简单 只是我们做着做着 想着着 就越来越复杂了
我觉得lz说的这些问题或多或少的存在与每一个项目内;但是这些问题lz是看到了,能够有一些切实的做法来避免这些情况的发生吗?我在文章里面看不见。项目是由资源、质量、资金三部分组成的,片面地强调质量是不现实的;拿多少钱做多少事便是这个道理。
sql语句写在界面层,维护起来不觉得太麻烦了吗.封装起来,以后在维护的时候不就方便些了啊.
说的比较有道理, 一个大型项目, 如果没有一个优秀的设计, 写
代码将是一件痛苦的事情, 不过这还不算最痛苦, 最痛苦的是那些
后来维护这些垃圾代码的程序员.
写程序就像做人,当然我们不能追求完美,但是我们也要尽力走得规范.
我现在的习惯在小的项目也要认真设计,我希望得到的是对得起自己的一双
手,辛苦的敲了这么多代码,我必须每一次都感觉更上一层楼.
我们必须要认识到,学习永远不能停止.
我刚刚参加革命,楼主说的毛病我发现我有好多,
我这个人不善于交际,只能之际摸索,好多东西也不知道什么是对什么是错,
哎!
。。。
。。。
#42楼 [
楼主]
2008-06-15 19:28 |
@凋落的雪
多学习就好。