最新评论
其实以前dos和linux也差不多,并没有复杂到哪里,那时候用dos觉得挺轻松的
Re:工资翻倍的秘诀--努力提高代码的质量 张晓亮(David) 2011-11-11 13:31
楼主没有把握到重心,更多的在描述:我们与国外程序员的区别,代码的质量的高低,看起来很华丽。但重点的地方去泛泛的列举了几条,太虚!可以用小程序来增加你的说服力,和加深读者理解!
Re:愤怒的小鸟的究竟有没有很高的技术含量? FreemanLS 2011-07-26 11:01
我认为LZ说的还是很有道理的。
至于下面人怎么捧场的。我想论原因跟过程,都是否有点过于搞笑了。
Re:工资翻倍的秘诀--努力提高代码的质量 害虫儿 2011-06-14 18:11
@zhaohua_wang
兄弟,我就在你说的传说中的500强, 没觉得怎么样。个人感觉面试有运气的成分,大家看着舒服就要你了呗。
Re:工资翻倍的秘诀--努力提高代码的质量 reinstallsys 2011-06-05 10:43
赞同楼主的观点,在任何一个行业中的优秀人员和公司都应该不断追求自己所在行业的完美性,不论是在传统行业还是新兴行业,高端的人员和公司都是在不断追求完美的,就像劳斯莱斯在目前机器化生产的时代还在手工打造汽车,甚至会追求车门把手上所用木材图案的对称性,我觉得他的价值也是在于其追求完美和品质。
当然我们可以很多的理由来推脱对完美的追求,比如项目进度紧、原有的代码就是个垃圾堆、公司领导根本就不知道啥是重构,出活才是硬道理等等,但是就像EricZhang兄弟说的,可能目前我们做不到或者在某个项目中由于各种困难做不到,但是不能就此放弃最求完美的心态,“哀莫大于心死”。
最近换工作的过程中参加了几家公司的面试,我也体会到了这一点,一些程序员当听到我说软件设计中的一些基本思想时就会呲之以鼻,并且说这些玩意只是摆设、理论罢了,这些都是不现实的。
今天看到这篇文章让我想起老子说的那段话,“上士闻道勤而行之,中士闻道若即若离,下士闻道大笑之,不笑不足以为道!”
Re:工资翻倍的秘诀--努力提高代码的质量 xpx888 2011-05-25 14:42
@一杰
顶!
[quote]无色:
[quote]淫光初学者:
@kiler
哦我用过一些orm,包裹linqtosql不过NHibernate没用过
可能是比较垃圾的orm吧,那些是要在内存筛选的所以我对这些印象比较差也就没用了。。
NHibernate 也就网上学了下,看看其实也就是个语法的问题和linqtosql
更模拟sql 的语法
最后还有我在性能只要可接受就行,其次最大考虑开发效率, 我是追崇orm的,具体还是要看需求![/quote]
NHibernate,是.net中最好的orm,但非常的难用,学习成本高,性能低,配置麻烦,概念n多,不适合在工业环境下运行,高并发搞个报表那是相当的麻烦。
我觉得or...[/quote]
我用NHibernate处理过每日插入20w条记录的系统,每一条记录的插入都要读取到6个配置表的数据做业务判断,未做缓存,这个系统就在一台1w不到的dell服务器上跑了一年。我不觉得NHibernate性能有多差,做报表不方便用sql就是,没什么大不了的。
" 而微软的linq,完全是“无厘头”的风格 " 读到这句我笑出声了。 真是这样的,最近在用entity framework,被他搞崩溃了。比如,我只想查询表一的字段的内容,本身一句简单SQL完成的任务被ORM了之后,变得异常复杂。 (代码大概是这样的http://www.cnblogs.com/dudu/archive/2011/03/28/1997735.html) 要控制它的细节,你得绕很大个弯,不好用。
我觉得linq本身还是不错的想法,内存中的数据能够做Join的查询,这挺方便的。 但是微软做过火了,linq to SQL本来就应该是个实验室里的项目,他却要大肆推广,再混合上ORM后的entity framework,完全是个怪胎啊!!!
我承认,我对entity framework熟悉程度很低,但是我不想花一大把时间在连接数据库操作的部分,从ADO到ADO.net到各种ORM工具到entity framework,我已经花太多的青春在熟悉各种新工具来完成我本来就能完成任务了。
[quote]木漂流:
1.首先linq只是一种查询的语法,生成表达式树,不是你说的ORM或者是RRM之类的,entity framework才是微软的orm框架,实际上微软本身是不想ef变成一个纯粹的orm框架而已
2.orm的产生是站在更高的抽象角度而已,所以更符合面向对象的思想,更加能贴近业务分析。
3.说到性能,数据库本身也是有IO瓶颈的,所以单纯的从执行的角度没什么可比性,毕竟ORM也可以产生预编译的代码
4.orm是可以跨数据库的。
5.orm的确可以提高开发效率,,这个对于企业应用来说很重要,,尤其是对私企老板来说,当然前提你要跟他熟悉。[/quote]
你说的很好!
其实sql, sp,orm本质是一样, 要更上一层楼就要连orm也不用,彻底摆脱sql的束缚。我准备就此写一篇, 欢迎你再来评论。
1.首先linq只是一种查询的语法,生成表达式树,不是你说的ORM或者是RRM之类的,entity framework才是微软的orm框架,实际上微软本身是不想ef变成一个纯粹的orm框架而已
2.orm的产生是站在更高的抽象角度而已,所以更符合面向对象的思想,更加能贴近业务分析。
3.说到性能,数据库本身也是有IO瓶颈的,所以单纯的从执行的角度没什么可比性,毕竟ORM也可以产生预编译的代码
4.orm是可以跨数据库的。
5.orm的确可以提高开发效率,,这个对于企业应用来说很重要,,尤其是对私企老板来说,当然前提你要跟他熟悉。
[quote]淫光初学者:
@kiler
哦我用过一些orm,包裹linqtosql不过NHibernate没用过
可能是比较垃圾的orm吧,那些是要在内存筛选的所以我对这些印象比较差也就没用了。。
NHibernate 也就网上学了下,看看其实也就是个语法的问题和linqtosql
更模拟sql 的语法
最后还有我在性能只要可接受就行,其次最大考虑开发效率, 我是追崇orm的,具体还是要看需求![/quote]
NHibernate,是.net中最好的orm,但非常的难用,学习成本高,性能低,配置麻烦,概念n多,不适合在工业环境下运行,高并发搞个报表那是相当的麻烦。
我觉得orm不适合在工业环境下使用,还是老老实实的用sql或sql包过ilist<t>实在。
orm现在还是学院式理论产物和uml差不多,中看不中用。
我是从追求完美的orm到回归sql的。
@kiler
哦我用过一些orm,包裹linqtosql不过NHibernate没用过
可能是比较垃圾的orm吧,那些是要在内存筛选的所以我对这些印象比较差也就没用了。。
NHibernate 也就网上学了下,看看其实也就是个语法的问题和linqtosql
更模拟sql 的语法
最后还有我在性能只要可接受就行,其次最大考虑开发效率, 我是追崇orm的,具体还是要看需求!
我只在两种情况下会考虑用SP:
1,报表
2,性能到了非用SP无法接受的地步(其实没碰到过)
事实上sql维护性最好,是人都懂.
orm是高科技,没有几人玩得转.
sp是没落的高科技,也没有几人玩得转.
@栖山
哦那1是我理解错了,2我觉的判断这样个东西的好坏应该和判断算法差不多吧,1待解决问题的规模2时间复杂度3空间复杂 就是这个意思
[quote]栖山:
[quote]Mainz:第二段性能,ORM比存储过程还快吗?有没有测试过?[/quote]
用了ORM,就留下了使用cache和queue这两大神器的天然接入点。[/quote]
@栖山
我用EF,楼主能否指点一下cache和queue如何能比存储过程还快,给个例子下载也好, 急用!
@淫光初学者
第一个问题就不说了,但第二个,LINQ TO SQL有延迟加载吧,不存在这个问题
[quote]淫光初学者:
“ORM的性能取决于ORM的Sql生成算法”
我只想说orm 生成sql 的损耗只是orm性能的九牛一毛,
再烂的生成sql算法也不及大数据量的查询损耗!
”微软的linq从某个角度类说,也是一种ORM, 它的设计思想可能是因为它觉得写sql语句比写c#代码效率高“。。。至少我认为C#比写sql开发效率很高。。而且我认为微软也没那么蠢认为C#比写sql 开发效率低。。
linq 不只是只有linqtosql,linqtoEntity是什么
sql 没有预编译差错能力差,linqtosql只是保留了sql 的灵活取字段
对于大数据量你把所有字段数据都取得了然后在筛去你觉得这样效率...[/quote]
对于大数据量你把所有字段数据都取得了然后在筛去,
orm是这样做的吗?首先筛选条件都会转换成where的,不是查出所有的数据到内存在筛选,其次orm一样可以控制查出字段多少的,不是一定都是查出所有的字段。
[quote]淫光初学者:
“ORM的性能取决于ORM的Sql生成算法”
我只想说orm 生成sql 的损耗只是orm性能的九牛一毛,
再烂的生成sql算法也不及大数据量的查询损耗!
”微软的linq从某个角度类说,也是一种ORM, 它的设计思想可能是因为它觉得写sql语句比写c#代码效率高“。。。至少我认为C#比写sql开发效率很高。。而且我认为微软也没那么蠢认为C#比写sql 开发效率低。。
linq 不只是只有linqtosql,linqtoEntity是什么
sql 没有预编译差错能力差,linqtosql只是保留了sql 的灵活取字段
对于大数据量你把所有字段数据都取得了然后在筛去你觉得这样效率...[/quote]
1,这里说的是生成的sql本身的质量,不是说的生成本身的损耗
2,什么大数据量?
“ORM的性能取决于ORM的Sql生成算法”
我只想说orm 生成sql 的损耗只是orm性能的九牛一毛,
再烂的生成sql算法也不及大数据量的查询损耗!
”微软的linq从某个角度类说,也是一种ORM, 它的设计思想可能是因为它觉得写sql语句比写c#代码效率高“。。。至少我认为C#比写sql开发效率很高。。而且我认为微软也没那么蠢认为C#比写sql 开发效率低。。
linq 不只是只有linqtosql,linqtoEntity是什么
sql 没有预编译差错能力差,linqtosql只是保留了sql 的灵活取字段
对于大数据量你把所有字段数据都取得了然后在筛去你觉得这样效率高吗
linq和orm没关系linq to sql才有点关系
[quote]Mainz:第二段性能,ORM比存储过程还快吗?有没有测试过?[/quote]
用了ORM,就留下了使用cache和queue这两大神器的天然接入点。
"刚开始的时候,sql的维护性看起来是最差,因为它往往散布在程序的每个角落。"
"存储过程完全可以照搬到C#中,sp的名字直接变成method的名字,sp的参数表直接变成method的参数表,(其实就是Command模式)。"
----------------------------
这就是[b][url=http://www.cnblogs.com/bluedoctor/archive/2011/05/07/2039527.html]SQL-MAP[/url][/b]出现的理由啊,将SQL集中管理,将SQL映射成DAL类的方法,参见 [url=http://www.cnblogs.com/bluedoctor/archive/2011/05/06/2038727.html]抽象SQL(参数化)查询[/url]
[quote]Leepy:
在我的理解,使用存储过程,对于系统的扩展性不是很好,会牵扯到有些业务逻辑写到存储过程中;
至于性能上,实际上现有的数据库引擎都做了优化,就比如SQL2005以上版本,对于SQL语句已经能够做数据库级别的缓存了,不需要重新对SQL语句编译,所以性能上两者不需要过多考虑。建议要使用存储过程的场景放在非常复杂的业务处理,比如数据统计等等。[/quote]
完全同意。
[quote]一个人失眠:不知道楼主做项目是用sp sql 还是orm???[/quote]
ORM或者是自己定义的数据结构,或者nosql。
sql在大型项目中一般都是瓶颈,所以要去之而后快。
第二段性能,ORM比存储过程还快吗?有没有测试过?
在我的理解,使用存储过程,对于系统的扩展性不是很好,会牵扯到有些业务逻辑写到存储过程中;
至于性能上,实际上现有的数据库引擎都做了优化,就比如SQL2005以上版本,对于SQL语句已经能够做数据库级别的缓存了,不需要重新对SQL语句编译,所以性能上两者不需要过多考虑。建议要使用存储过程的场景放在非常复杂的业务处理,比如数据统计等等。
不知道楼主做项目是用sp sql 还是orm???
[推荐]ORACLE PL/SQL编程详解之三:PL/SQL流程控制语句(不给规则,不成方圆)
http://www.cnblogs.com/huyong/archive/2011/05/13/2045407.html
Re:工资翻倍的秘诀--努力提高代码的质量 非设计不生活 2011-05-12 12:45
全国程序员 平均收入水平 ¥ 2,680
有关工资水平 数据还是比较真实的
http://www.sogongzi.com/china/salary_463.html
这里的一些数据你可以参考一下 希望对你有所帮助!
Re:谈谈我设计的Web 3.0,以及让程序员富起来的路线图 banana.totolv 2011-05-06 13:21
good
Re:Rants to 老赵 banana.totolv 2011-05-05 20:55
GOOD
Re:Hacker传说之不能说的秘密 banana.totolv 2011-05-05 20:39
GOOD
Re:Hacker传说之不能说的秘密(2) banana.totolv 2011-05-05 20:38
GOOD
Re:工资翻倍的秘诀--努力提高代码的质量 banana.totolv 2011-05-05 20:14
GOOD
很多次想学习linux,但看到那么多的命令和目录不得要领而退缩,谢谢楼主的文章,清晰的描述,让我收获颇多,谢谢
Re:工资翻倍的秘诀--努力提高代码的质量 take it and go 2011-04-27 14:21
工资翻倍的最好方法不是跳槽么?
[quote]17playcoding:这番理解让小弟觉得之前啥解释执行和编译执行都成了变异执行了。看完了兄弟的文章,小弟更加弄不清楚OO的思想了![/quote]
解释执行和编译执行对于程序员来说可以看成黑箱, 因为即使是解释执行也可以进行即时编译(所谓的jit)。这和OO完全没有关系。
现代的javascript引擎也是基于jit的,这就是javascript引擎大战的原因,比谁的jit算法更加优化。
这番理解让小弟觉得之前啥解释执行和编译执行都成了变异执行了。看完了兄弟的文章,小弟更加弄不清楚OO的思想了!
[quote]栖山:
[quote]Jerry Chou:
其实是基于类的OO和基于prototype的OO区别
周爱民的Javascipt语言精髓对此有着深入的探讨
http://blog.csdn.net/aimingoo/archive/2009/03/12/3983975.aspx[/quote]
我个人觉得正是prototype这个术语妨碍了理解, 其实本质就是一个对象同时继承另一个对象(父对象)的结构和状态。
[/quote]
我不敢苟同。他们实现OO的方式有着本质区别,而不好这么类比。
只是,我现在一下子也阐述不清 :)
javascript的问题是Dom还有browser的兼容