论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2007-11-21 22:34 |只看该作者 |倒序浏览

程序设计经验总结
在这个行业里做了快4年了,多少总结了一些东西,成功也许很难复制,但是失败却时常被人们重复,我不敢说我做的很好,但是我希望总结出以前失败的一些教训,时不时看看,提醒自己以后再也不要犯类似的错误.这篇文章会不定期的更新,可能就是简短的几句话,但是,也是我实践和思考的结果.

1)程序不会出错,出错的肯定是人;如果程序出错了,那也一定是人的错误.
我时常在编码调试的时候出现这样的一种心理:出现问题的时候总是认为不是自己的错误,而认为可能是系统的错误.其实,久经考验的系统出错的概率几乎很小,大多数的情况下出错的肯定是编写代码的人,所以你的程序出错了一定是自己的问题,有了这个观念会十分有助于早点发现并且改正BUG.

2)程序就是用规则处理数据,规则包括:算法,数据结构,系统API,协议,语言,设计模式等等.
这句话很浅白,我想很多人一看就能明白,其实学习编程的过程就是在学习怎么去用规则去处理数据,想想看一路过来学过的课程都是如此:算法数据结构教会我们在什么情况下应该选取怎样的方式去处理数据,操作系统教会我们系统如何处理数据,编译原理教会我们编译器如何处理数据,网络协议,语言,正则表达式等等的更不必说了.至今我已经很少去关注什么语言之争的无聊话题,因为我相信语言也是一种处理数据的工具,没有哪种工具是万能的,只有合适的场合采用合适的工具.同时,以后再学习一种新的"规则"时,也需要抓住这些重点:这个规则适用的场合,适用的数据,处理数据的方式.

3)Make it work, make it right, make it effective.
我已经忘记了在哪里看见的这句话(请知情者转达一声,谢谢

.中文的意思也很浅白:先让它可以运行,然后让它可以正确的运行,最后再去提高效率.我想,这应该是编写大部分代码的顺序,这也是把一个问题从简单慢慢的一步一步进行到复杂的过程.在你的代码没有正确的运行起来之前,暂时别做优化(当然了很显然的优化是可以的),只有当程序正确的运行起来时,你通过测试或者工具发现了瓶颈所在再去考虑优化.

4)越早让你的程序投入调试越好.
一般而言,写好一段代码比调试一段代码的时间要少的多,而许多许多的问题也是在你写代码的时候所不能发现的.

文库|博客

converse

荣誉版主

论坛徽章:: 0

2楼 [报告]

发表于 2007-11-21 22:35 |只看该作者

抛砖引玉,欢迎讨论/补充/分享.

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

chenzengjie

稍有积蓄

论坛徽章:: 0

3楼 [报告]

发表于 2007-11-21 22:43 |只看该作者

看上去有几处和《程序设计实践》很符合呀，看来你是悟着道道了。

第一点说得有点偏激吧，有时候并不是你自己程序错了，只是你所认为理所当然的环境不是你想象的那种样子。

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

cugb_cat

版主

论坛徽章:: 0

4楼 [报告]

发表于 2007-11-21 22:46 |只看该作者

第一条、第二条已经领悟到了
第三条可能和我的做法不太一样，我是先把设计中设计出来的东西的代码全都写出来，有的时候甚至写几千行，而这时有可能这些代码还编译不过去，把整个逻辑的代码都写完后，便开始处理编译错误，然后开始调试，当然，编译错误很快就处理完了，调试，则需要花N多时间，可能我这种做法不好，不过我觉得如果不把已经形成好的思路落实到代码上，我怕我会忘记如何去写，即使已经做好了流程图。