读《程序设计总结》有感

读《程序设计总结》有感

今天读了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，然后才考虑一些局部的问题。对一个系统来说，设计才是最重要的。