网络编程的几个准则-经验之谈
一、先写个程序规划和数据库规划。比较小的程序没这么麻烦,程序大的时候是必备的,一些功能没弄好结果导致后续功能无法实现,搞到推翻重写,实在不值。数据库文档是必写的,必须要写明白表跟字段的类型和用途,不然数据库字段多了连自己都搞不清楚。另外很重要的一点是,程序是你写的,在碰到一些状况的时候,完全可以通过新加数据库表、字段等方法来解决,都是你设计开发的,主动权都在你手里,还怕什么?当然,新开发可以,升级要考虑的情况就很多了,呵呵。
二、程序缩进和变量命名一定要规范。程序缩进规范了,差错可以少很多功夫,以后修改起来也方便。变量命名随你喜好,但是至少要自己能看懂某个变量是做什么用的,给定义个i1,i2,i3,i4,i5,过个两星期你自己都搞不懂这变量是干嘛用的。
三、先实现功能,后优化。有时候写程序一下子无法很简单的实现,这里有两种可能,一种是有好方法未发现,一种是就这么麻烦没办法,在这个时候可以先把功能实现了,以后再来改进。这样做主要是为了避免在某一个功能上花费太多时间而导致整个程序进度被拉下。写程序没有一次性到位的,不需要每次都考虑要做到多少完美,完美是没有底线的。
四、实现完整功能,保证无错。某一个程序,就是为了实现某个用途而编写的,脱离了这个用途,哪怕做的再好,没用上也是白搭,程序写好后只有最终产生效应了才有价值。哪怕功能写的简单一点,丑陋一点,只要实现功能能够用就是成功。功能不完整或者一堆错误,除了锻炼了你的写作能力,我不知道还有什么价值。
五、倾听用户意见,但不一定就要按用户说的来。这个准则有个度的问题,首先是倾听用户意见,程序是给用户用的,用户的意见才是最真实的,一些特殊流程和情况没有实际碰到是很难想到的,闭门造车目前来讲还不现实,除非你是写给自己用的,大多数情况都能考虑到。其次是不一定要按用户说的来,用户是不懂编程的,他只能说明他需要什么样的功能和什么样的结果,具体开发实现还是由你来做的,只要实现他的功能,用什么手段什么方式完全可以由你来决定,当然,决定之前要跟用户商量下是否可行。假如不是定制的程序,是你自己写的玩的,假如用户的意见与你的规划有冲突且那个功能不影响使用的,可以不理会,当然,需要给用户稍微解释,这样大家都开心。
六、稍微注重下用户体验。在写程序的时候要换位思考下,你不能要求用户跟你一样懂电脑懂程序,下至六七岁的孩童,上至八九十的老人,不同的人群有不同的特点,所以该加大字体的时候加大字体,该给提示的时候要给提示,该限制的时候要给限制,你可不能担保用户会做出什么事情来,反正给用户需要的最小权限就好了。
七、考虑其他因素的时候不要忘了功能实现。这点比较难讲明白,举个例子吧。比如安全中的防注入,很多人会用所谓的防注入系统,判断是否有select之类的字符串来实现,假如我要写篇文章《论Mysql中select语句的应用》,会出现什么效果呢?其实防注入只需要做到是数字就进行数字判断或进行强制转换,是字符串的时候就要强制转换单引号就OK了,在考虑其他因素的时候尽量不要影响功能实现。有人说,进行数字强制转换可能报错,你管他呢,正常情况下通过页面链接点击会出报错情况么?不正常的情况下报错就让他报好了。。
八、只要可能出现的问题,就一定会出现。这点我深有感触,即使再难以发现的问题,都会被用出来,所以在编程的时候不要吝啬那么几个语句,一定要把已知问题扼杀在发布之前。
九、写好程序后根据情况给写个帮助吧,哪怕没时间,把流程截几个图都好。用户在使用的时候不可能像你一样熟练的,尤其一些技术名词,用户并不认识,你只需要简单解说下就好了,大家都看得懂,就不会一个个来问你了。
十、还有十么。。似乎有,程序正式使用后,肯定还会有这样那样的不足和问题,这时候要用一种乐观的心态去看待。没有一个程序敢说自己第一版发布就没有任何问题的,即使是正式使用之前经过了严格的测试。程序出了问题不可怕,出了问题不弥补才只最可怕的。