程序设计经验总结
论坛链接
在这个行业里做了快4年了,多少总结了一些东西,成功也许很难复制,但是失败却时常被人们重复,我不敢说我做的很好,但是我希望总结出以前失败的一些教训,时不时看看,提醒自己以后再也不要犯类似的错误.这篇文章会不定期的更新,可能就是简短的几句话,但是,也是我实践和思考的结果.
1)程序不会出错,出错的肯定是人;如果程序出错了,那也一定是人的错误.
我时常在编码调试的时候出现这样的一种心理:出现问题的时候总是认为不是自己的错误,而认为可能是系统的错误.其实,久经考验的系统出错的概率几乎很小,大多数的情况下出错的肯定是编写代码的人,所以你的程序出错了一定是自己的问题,有了这个观念会十分有助于早点发现并且改正BUG.
2)程序就是用规则处理数据,规则包括:算法,数据结构,系统API,协议,语言,设计模式等等.
这句话很浅白,我想很多人一看就能明白,其实学习编程的过程就是在学习怎么去用规则去处理数据,想想看一路过来学过的课程都是如此:算法数据结构教会我们在什么情况下应该选取怎样的方式去处理数据,操作系统教会我们系统如何处理数据,编译原理教会我们编译器如何处理数据,网络协议,语言,正则表达式等等的更不必说了.至今我已经很少去关注什么语言之争的无聊话题,因为我相信语言也是一种处理数据的工具,没有哪种工具是万能的,只有合适的场合采用合适的工具.同时,以后再学习一种新的"规则"时,也需要抓住这些重点:这个规则适用的场合,适用的数据,处理数据的方式.
3)Make it work, make it right, make it effective.
我已经忘记了在哪里看见的这句话(请知情者转达一声,谢谢:).中文的意思也很浅白:先让它可以运行,然后让它可以正确的运行,最后再去提高效率.我想,这应该是编写大部分代码的顺序,这也是把一个问题从简单慢慢的一步一步进行到复杂的过程.在你的代码没有正确的运行起来之前,暂时别做优化(当然了很显然的优化是可以的),只有当程序正确的运行起来时,你通过测试或者工具发现了瓶颈所在再去考虑优化.
4)越早让你的程序投入调试越好.
一般而言,写好一段代码比调试一段代码的时间要少的多,而许多许多的问题也是在你写代码的时候所不能发现的.
1)程序不会出错,出错的肯定是人;如果程序出错了,那也一定是人的错误.
我时常在编码调试的时候出现这样的一种心理:出现问题的时候总是认为不是自己的错误,而认为可能是系统的错误.其实,久经考验的系统出错的概率几乎很小,大多数的情况下出错的肯定是编写代码的人,所以你的程序出错了一定是自己的问题,有了这个观念会十分有助于早点发现并且改正BUG.
2)程序就是用规则处理数据,规则包括:算法,数据结构,系统API,协议,语言,设计模式等等.
这句话很浅白,我想很多人一看就能明白,其实学习编程的过程就是在学习怎么去用规则去处理数据,想想看一路过来学过的课程都是如此:算法数据结构教会我们在什么情况下应该选取怎样的方式去处理数据,操作系统教会我们系统如何处理数据,编译原理教会我们编译器如何处理数据,网络协议,语言,正则表达式等等的更不必说了.至今我已经很少去关注什么语言之争的无聊话题,因为我相信语言也是一种处理数据的工具,没有哪种工具是万能的,只有合适的场合采用合适的工具.同时,以后再学习一种新的"规则"时,也需要抓住这些重点:这个规则适用的场合,适用的数据,处理数据的方式.
3)Make it work, make it right, make it effective.
我已经忘记了在哪里看见的这句话(请知情者转达一声,谢谢:).中文的意思也很浅白:先让它可以运行,然后让它可以正确的运行,最后再去提高效率.我想,这应该是编写大部分代码的顺序,这也是把一个问题从简单慢慢的一步一步进行到复杂的过程.在你的代码没有正确的运行起来之前,暂时别做优化(当然了很显然的优化是可以的),只有当程序正确的运行起来时,你通过测试或者工具发现了瓶颈所在再去考虑优化.
4)越早让你的程序投入调试越好.
一般而言,写好一段代码比调试一段代码的时间要少的多,而许多许多的问题也是在你写代码的时候所不能发现的.