本站首页    管理页面    写新日志    退出



公告


 求真务实打基础,
 宁缺毋滥读好书。

数据挖掘青年(DMman)


我的分类(专题)

日志更新
问君能有几多愁,恰似一群太监上青楼
我和僵尸有个约会:灵异世界或真实存在?
赤壁(下)观后小感:雷人
英科学家:酒精和烟草的危害大于大麻和摇头
只有社会主义才能拯救世界(由金融危机引发
求职心得(非名牌院校 硕士 计算机)
省外就业协议录入
数据挖掘方面的资源、期刊、会议的网址集合
面试心得(摘)
为学
EI收录中国期刊-核心(2008-5)
混沌理论:随机世界的建模
分子计算机已经问世,纳米计算机指日可待?
绝对好用免费的网络电话
NLP:基于机器学习的人类思想及行为建模
Weka中用于组合多个模型的的装袋、提升
数据挖掘在企业中应用的四种途径
(转)几点做人做事的建议
大学计算机软件专业生应该学什么(转)
一个程序员对学弟学妹建议(转)

最新评论

留言板

链接

Blog信息
blog名称:DMman(数据挖掘青年)
日志总数:102
评论数量:564
留言数量:57
访问次数:1561714
建立时间:2007年4月9日




[程序人生]程序设计经验...
网上资源,  心得体会

数据挖掘青年 发表于 2007-12-18 22:08:16

 先贴两篇文章: 《程序设计经验总结》 http://www.cppblog.com/converse/archive/2007/11/21/37107.html        在这个行业里做了快4年了,多少总结了一些东西,成功也许很难复制,但是失败却时常被人们重复,我不敢说我做的很好,但是我希望总结出以前失败的一些教训,时不时看看,提醒自己以后再也不要犯类似的错误.这篇文章会不定期的更新,可能就是简短的几句话,但是,也是我实践和思考的结果. 1)程序不会出错,出错的肯定是人;如果程序出错了,那也一定是人的错误.我时常在编码调试的时候出现这样的一种心理:出现问题的时候总是认为不是自己的错误,而认为可能是系统的错误.其实,久经考验的系统出错的概率几乎很小,大多数的情况下出错的肯定是编写代码的人,所以你的程序出错了一定是自己的问题,有了这个观念会十分有助于早点发现并且改正BUG. 2)程序就是用规则处理数据,规则包括:算法,数据结构,系统API,协议,语言,设计模式等等.这句话很浅白,我想很多人一看就能明白,其实学习编程的过程就是在学习怎么去用规则去处理数据,想想看一路过来学过的课程都是如此:算法数据结构教会我们在什么情况下应该选取怎样的方式去处理数据,操作系统教会我们系统如何处理数据,编译原理教会我们编译器如何处理数据,网络协议,语言,正则表达式等等的更不必说了.至今我已经很少去关注什么语言之争的无聊话题,因为我相信语言也是一种处理数据的工具,没有哪种工具是万能的,只有合适的场合采用合适的工具.同时,以后再学习一种新的"规则"时,也需要抓住这些重点:这个规则适用的场合,适用的数据,处理数据的方式. 3)Make it work, make it right, make it effective.我已经忘记了在哪里看见的这句话(请知情者转达一声,谢谢:).中文的意思也很浅白:先让它可以运行,然后让它可以正确的运行,最后再去提高效率.我想,这应该是编写大部分代码的顺序,这也是把一个问题从简单慢慢的一步一步进行到复杂的过程.在你的代码没有正确的运行起来之前,暂时别做优化(当然了很显然的优化是可以的),只有当程序正确的运行起来时,你通过测试或者工具发现了瓶颈所在再去考虑优化. 4)越早让你的程序投入调试越好.一般而言,写好一段代码比调试一段代码的时间要少的多,而许多许多的问题也是在你写代码的时候所不能发现的. ***************************** 读《程序设计总结》有感 http://www.cppblog.com/jasson/archive/2007/12/08/38055.html今天读了converse的文章《程序设计总结》,感触良多,说出了很多程序员经常遇到的问题,而像作者那种时常反思自己工作过程的习惯是值得我们学习的。(文章地址:http://www.cppblog.com/converse/archive/2007/11/21/37107.html)我进入这个行业也有很长一段时间了,也有一些很深的体会,希望能够跟大家分享。 1.    在完成自己的工作之后,一定要double check自己的作品,确认自己真的完成了任务,而且采用的是最好的解决方案。        刚刚开始工作的时候,很喜欢追求所谓的effective,但是对effective的理解仅仅存留在了quick对层次上,对质量则报了一种比较放任的态度。结果,自己经常提交一些自己认为已经完成了的工作,结果往往会在被他人review的时候指出多处错误,颜面尽失,而因为过于追求进度,代码质量很差,经常会写出一些学生代码。鉴于此,在submit你的工作之前还是务必认真check一下,确认自己真的很好的完成了工作。 2.    把一个feature当成一个完整的作品来做。        往往我们拿到的工作只是一个系统的一个feature,这样我们会抱以一种这只是一个模块,做得怎么样都只是一个feature而已,在这种情况下,我们的提交往往都是灾难。所以,如果大家都把一个feature当作一个完整的作品,一个真正由自己完成的作品,那么你就会真正把这个feature当作自己的孩子一样对待,仔细揣摩,认真编码,最终,我们完成的会是一个质量很高的作品,而你也会为此自豪。 3.    当你不了解一个系统是如何运行的时候,建议尽快进入debug,而不只是钻进文档的海洋。        通过debug,你会很清晰的把握住一个系统运行的详细过程,这将对你掌握这个系统很有帮助。 4.    尽量使用基本的方法解决问题。        俗语说:简单就是美。虽然我们现在接触的编程手段一般都是OOP,继承,多态在很多人心里会是编程时的第一选择,而为了表现自己技术的全面,往往还要加入设计模式show一下。其实,最美的程序还是由基本的数据结构+算法组成,继承,多态,设计模式只是在我们没有其他方法可用的时候的一种妥协。 5.    考虑问题尽量从大的方面开始,先把事情的骨架勾画出来,再fresh out。        很多人在考虑一个问题的时候往往会钻进一个很小的角落,把所有精力集中于一个局部的问题上。其实,在我们刚刚开始考虑一个解决方案的时候,最好的办法还是先考虑High Level Design,然后才考虑一些局部的问题。对一个系统来说,设计才是最重要的。 **********************************************我的不成熟看法 1 两个作者都强调了测试的重要性。测试需要及时,而且,测试也能反映项目的全貌。虽然软件工程强调文档,记得课本上说 "程序=数据结构+算法+文档" 我觉得,大多数程序员是不愿意写文档的,写的早了,以后有变化还得改;写的晚了,可能前边的就忘了...Java的javadoc用注释取代文档,JUnit用测试用例(TestCase)代替文档,把编程人员从word中解放出来,在programing的同时为程序做好了“类文档”,真是太棒了。2第二个作者说“ 4.    尽量使用基本的方法解决问题。        俗语说:简单就是美。虽然我们现在接触的编程手段一般都是OOP,继承,多态在很多人心里会是编程时的第一选择,而为了表现自己技术的全面,往往还要加入设计模式show一下。其实,最美的程序还是由基本的数据结构+算法组成,继承,多态,设计模式只是在我们没有其他方法可用的时候的一种妥协。”我觉得并非如此。“Make it simple”的前提是:简单的是好的,复杂是多余的。如果设计模式、OOP方法更能提高代码的可读性、复用性、效率,后者应该是首要的选择,而不是妥协,尤其对于架构来说。  


阅读全文(4899) | 回复(4) | 编辑 | 精华
 


回复:程序设计经验...
网上资源,  心得体会

放飞心情发表评论于2007-12-24 20:00:59

仔细拜读之后,虽然不懂编程序之类的,但还是很欣赏你的认真。 这个世界怕就怕认真两字。  以下为blog主人的回复: 谢谢~


个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除
 


回复:程序设计经验...
网上资源,  心得体会

烟雨朦胧发表评论于2007-12-20 20:04:49

《程序设计总结》?我看不懂,羡慕你

个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除
 


回复:程序设计经验...
网上资源,  心得体会

数据挖掘青年发表评论于2007-12-20 8:34:55

以下引用netjian在2007-12-20 8:30:55的评论: 对于: “3.当你不了解一个系统是如何运行的时候,建议尽快进入debug,而不只是钻进文档的海洋。通过debug,你会很清晰的把握住一个系统运行的详细过程,这将对你掌握这个系统很有帮助。”    有些时候并非如此,就像我现在在弄的一篇关于加密的论文,单纯DEBUG你根本无法理解其中的原理,不像C++能调试到底层的汇编,单看表面的API永远无法理解它的核心加密算法。你说的有道理,原作者可能侧重指包含业务逻辑的程序罢

个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除
 


回复:程序设计经验...
网上资源,  心得体会

开花的芝麻发表评论于2007-12-20 8:30:55

同意你的两个看法:    1.我也不怎么喜欢写文档,写文档往往只是想着为以后写论文打基础,以前写C#的时候,还常用一个Ndoc来自动生成文档。    2.“如果设计模式、OOP方法更能提高代码的可读性、复用性、效率,后者应该是首要的选择,而不是妥协,尤其对于架构来说。”,严重同意。对我来说,选择这些方法还有一个优点:看得清晰。再加入分层,组件,就是一个很舒服很有条理的程序了。    另外,对于: “3.当你不了解一个系统是如何运行的时候,建议尽快进入debug,而不只是钻进文档的海洋。通过debug,你会很清晰的把握住一个系统运行的详细过程,这将对你掌握这个系统很有帮助。”    有些时候并非如此,就像我现在在弄的一篇关于加密的论文,单纯DEBUG你根本无法理解其中的原理,不像C++能调试到底层的汇编,单看表面的API永远无法理解它的核心加密算法。  

个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除
 


» 1 »

发表评论:
昵称:
密码:
主页:
标题:
验证码:  (不区分大小写,请仔细填写,输错需重写评论内容!)



站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.063 second(s), page refreshed 143984591 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号