以文本方式查看主题

-  计算机科学论坛  (http://bbs.xml.org.cn/index.asp)
--  『 科研生涯 』   (http://bbs.xml.org.cn/list.asp?boardid=70)
----  程序设计经验总结 [转帖]  (http://bbs.xml.org.cn/dispbbs.asp?boardid=70&rootid=&id=56916)

--  作者：DMman
--  发布时间：12/18/2007 9:56:00 PM

--  程序设计经验总结 [转帖]
程序设计经验总结
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)越早让你的程序投入调试越好.
一般而言,写好一段代码比调试一段代码的时间要少的多,而许多许多的问题也是在你写代码的时候所不能发现的.

--  作者：DMman
--  发布时间：12/18/2007 9:57:00 PM

--  
读《程序设计总结》有感
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，然后才考虑一些局部的问题。对一个系统来说，设计才是最重要的。
--  作者：DMman
--  发布时间：12/18/2007 10:03:00 PM

--  
1 两个作者都强调了测试的重要性。测试需要及时，而且，测试也能反映项目的全貌。
虽然软件工程强调文档，记得课本上说 "程序=数据结构+算法+文档" 我觉得，大多数程序员是不愿意写文档的，写的早了，以后有变化还得改；写的晚了，可能前边的就忘了...
Java的javadoc用注释取代文档，JUnit用测试用例（TestCase）代替文档，把编程人员从word中解放出来，在programing的同时为程序做好了“类文档”，真是太棒了。
2第二个作者说
“ 4.    尽量使用基本的方法解决问题。
        俗语说：简单就是美。虽然我们现在接触的编程手段一般都是OOP，继承，多态在很多人心里会是编程时的第一选择，而为了表现自己技术的全面，往往还要加入设计模式show一下。其实，最美的程序还是由基本的数据结构+算法组成，继承，多态，设计模式只是在我们没有其他方法可用的时候的一种妥协。
”
我觉得并非如此。“Make it simple”的前提是：简单的是好的，复杂是多余的。如果设计模式、OOP方法更能提高代码的可读性、复用性、效率，后者应该是首要的选择，而不是妥协，尤其对于架构来说。
W 3 C h i n a ( since 2003 ) 旗 下 站 点
苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》
 31.250ms