1.兴致盎然
写程序和其它事情一样,最好是带着兴趣去做,不要太勉强,人的兴趣点都是不同的,如果仅把它当做吃饭的一个工具,那可能做着会很累,比如我做开发这么多年,除了觉得有些累外,对开发的兴趣是一直没有减的,一直关注新的技术,一直不断的对它们进行尝试,要能做到这一点,必须有兴趣在后面做支持。
如何做到有兴趣呢?首先就是要知道程序是干什么的,我用它们能做什么,又能为其他人带来什么好处。早在上大学的时候,老家的一个朋友在我回家的时候问我,你们都学什么呀,我提了计算机,写程序之类的,他就问,写程序能做什么呀,我就开始努力想,想到了什么呢,可以计算1+1=2,可以算老母牛生多少小牛儿,可以做什么汉诺塔之类的,可程序除了这些又有什么用呢,当时真把我问住了,我不知写程序到底有什么用。那就是我在上学时对程序的理解。
后来好多了,在校期间帮人家写软件,有些还很有实用价值的,再后来就更多了,走上了工作岗位,天天都在写程序,也知道程序可以控制航天飞机啊,卫星上天啊,什么都能做。当然这些范围太大,不是我们处理的范围,简单一些,可以做财务电算化,可以做ERP,可以做小游戏等,可以处理很多事情。
程序员学会了写程序做什么呢,我觉得除了应用于工作外,还可以在自己生活中体现一下自己的专长,比如在家中,已经是爸爸的人了,就可以给孩子写一些小软件,帮他学习啊,帮他游戏啊,很有意思的,有时并花不了太多的精力,但是能收到不错的效果。当然也不能指望你的作品的生命周期有多长,因为孩子的心思是会很快变换的。
总之,我个人认为,写程序要带着兴趣去写,要把心思钻进去,那里面是别有洞天的。也许我们那时候还早,和现在不一样,现在我看到很多小程序员同志们,写程序纯是为了一份工作,并看不出来太多的兴趣在里面,全部是为了写程序而写程序,这样就造成心态不是很好,责任心也会有所不同。当然,生活最重要。
2.完美主义
任何一个稍大一点儿的系统一般都会经过什么设计呀,开发呀,测试呀之类的流程,而且一般的系统这些角色都是分开的,设计人员先设计一个XXX,开发人员会去做一个YYY出来给测试人员测试。设计人员一般应该懂得开发,这样保证他们设计的是能被实现的,如果设计人员是从空中降落下来的神仙,那么有可能开发人员看不懂他们的天书。尽管设计的很完美,但是如果无法实现的话,就等于零了。
我以前有个同事,他本身就是做技术的,技术做的相当牛,牛的不能再牛了,我们全体都很佩服他,在我们公司,任何解决不了的问题,只要找到他,一般都可以搞定。后来我们做一个项目,也用到分层次的概念,他负责做业务层的设计,当时觉得他设计的就特别好,好的不能再好了,好的可以成为一个专门的产品了,因为他开始自己设计脚本解析器,就像VBScript那样,但是语法是他自己创造的,和ASP类似,但是又不完全一样,展现层必须按他的语法去写程序,然后他的中间层负责解析。一开始,加了一些 for/while if else之类的语法,后来发现还有其它的语法需要处理,因为不加上这些,就不能实现所有的业务,于是一直添加添加再添加,一直到有一天,他忽然发现,呀,要是我用ASP的话,这些我都不用处理了!于是最后改用asp.net来开发,前期设计及开发全部不用了。这就是追求完美的一个体现。
在中国,很多小软件企业一般都是拿到了项目就做,项目做完了就关门儿,和微软等财大气粗的企业不一样,我们没有足够的经费去做研究,如果我们一直追求完美,可能会影响整个公司的生命。尽管我也觉得对于一个民族来讲,这种研究很有必要,但是让我们先生存下来再说后话吧。
3.可配置性
程序对用户来说,只要能运行,只要能有结果,并且结果正确,所占用的时间他们能接受,一般都被认为是过关的,在验收的时候一般难度不会太大。但是考虑他们在运营过程中,可能会随着业务的调整,对程序提出一定的修改意见,这时,对程序就有了一定的考验,你的程序是否可以很快的适应业务的变化呢,为了这个业务变化,程序要做哪些调整呢?可能有以下几种可能性:
程序已经无法修改,全部扔掉重新开发一套
找到开发人员,对部分业务变更在程序上加以实现,重新编译,重新发布
对程序配置进行调整,不需要编译程序,即可直接使用
在编程比较“简单”的情况下,可能对业务使用者的需求变更方向并不太确定,所以会出现第一种情况和第二种情况,当然有时也是业务提出者的需求不明确造成的,有时他们会很明确的说“就这么多,不可能再修改了”,但是后期他们一般不会认账的。前面两种情况无法离开程序开发人员,所以在实际运营过程中,有可能造成系统的延误,甚至更可怕的后果。
第三种情况,对应用系统更加“礼貌”,业务部门的工作人员,可以在经过适当的培训后,自己对配置加以调整,完全适应新的需求。
举个例子,做一个数据同步的小程序,需要从一个库中导出数据,放入另一个库中,源数据库可能是Access,FoxBase,目标数据库可能是MSSQL,Oracle,数据库的字段也有可能一直在变,这时就要考虑配置的灵活性,尽可能考虑全面一些,能写在配置文件里的,不要写在代码中。我身处甲方公司,曾经有些公司给我们开发软件,我一再告诉他要做配置,可就是不听,造成后面比较麻烦的局面。
配置可以有多种方式来支持,我记得我最早用VB的时候,好像习惯用INI文件,因为MS有专门的API来读写INI,效率非常高;后来又都开始搞XML,好像INI就不太流行了,大家纷纷开始解析XML去了,听说那东西的效率比INI那种方式要低一些,不过其实也无所谓,一般都是系统加载的时候读出来就OK了。还有一种方式就是把配置信息存储在数据库中,数据库有一些优势,当然和XML具体哪个好,我觉得并不重要,根据个人喜好和实际情况就可以,比如存储数据库连接信息,此时还没有连接到数据库,当然要写在XML等外部文件中了。
配置文件也有一定的安全性要求,一般在配置文件,会存储一些密码,如果用明文存储,有可能会造成一定的隐患,我一般是用双向加密算法,用的时候自己再解开,算法并不一定要很严格,差不多就行了,因为我们做的系统也没什么太保密可言。但是我看过一些比较大的系统,如OracleEBS,他们的配置文件,就直接存储明文密码,并不做加密处理,反正他们也知道,谁能找到这个配置文件已经相当不容易了,隐藏的非常深。总之,我觉得在程序设计初期就考虑一下配置的灵活性,对后期的维护会非常有好处。
另外关于O/R Mapping,在开发简单的和专用的程序的时候,很多问题都是不需要考虑的,这种程序的设计,是相对“规范”的,只要能满足当前的环境,100年可能不需要调整,对于这种案例,我觉得就没有必要设计的太复杂,能用就行了。但是对于大部分案例来说,特别你想做产品化的时候,必须要考虑的事情就会多起来。比如我们做一个会员系统,会员会有很多的属性,如“会员号”,“密码”,“姓名”,这几个可能是常用的,然后当你的系统推广到不同的公司甚至不同的行业的时候,你会发现,同样是会员管理,他们所提出的要求也不是完全一样的,有些要生日,有些要身份证,有些还要老婆孩子的信息。这时就涉及到数据库里的存储字段和你的程序是如何对应的,也就是所谓的O/R Mapping,我还是以C#为例吧,我听说JAVA界有很多这方面做的相当不错的框架,我没有资格去评论。对于这种O/R Mapping的实现,我认为有两种方式:
用类的属性去实现对象与数据库字段的一一对应
实现更灵活的对应
对于第一种方式,无论数据库增加了什么字段,就需要马上修改相应的程序,在类中添加新的属性,实现与数据库一一对应,这种方式比较麻,它涉及到代码的重新编译与发布,但是听说现在有些代码生成的比较好的工具和方式,可以快速的实现这一点。但是我还是觉得有些麻烦。这种方式的好处很显然,对客户感觉比较“礼貌”,他们使用的系统,完全是给他们定制的,他们看到的,正是他们需要的,一般二次开发的时候,出错的几率都会下降。也就是把难度留给开发商,把好处留给客户,只要客户日后不做修改,还是不错的方式。
第二种方式,也是我常用的一种方式,在类中,设定一个通用的Properties属性,在系统读取的过程中,把所有和用户属性相关的字段全部读入这个大的集合中,它是一个hashtable,然后使用的时候,只要按Properties["NAME"]这样的方式即可,可以看出,无论客户化如何实现,这种方式都不需要改变代码即可实现。
以上的Mapping信息,具体是存储在XML中或数据库中,并不太重要,重要的是实现这个思路就行了。
4.国际应用
目前大部分开发可能都是在中国本地运行,但是也少不了有些是需要考虑国际化的。
在N年前,做国际化听说是很烦人的,那时我反正不需要考虑这种事,后来好像Unicode,UTF8等编码,解决了这个问题。现在VS2010里添加Item,都直接存储为UTF8格式,在VS2003里,还是GB2312格式吧,反正不行的话,自己转存一下就可以了。
对于多语言程序的检测,最好能在当地语言的操作系统里安装测试,仅在中文或英文环境下测试,理论上没什么问题,但是有些时候可能还是存在偏差的。最早用C++开发程序的时候,应该是有个什么资源文件,把所有的字符串都放入那个地方,所以很多做汉化的,直接把那个文件翻译一下就可以了。
我也看过有些公司做PHP的,做多语言也是用资源包,到时把它搞一下,重新编译一下就行了,我不确定是不是所有的大公司都用这种语言包的形式来实现多语言,不过肯定有他的好的地方和优势。
采用语言包的形式,要求所有的语言信息必须下载到客户端,由客户端来解析,如果语言包需要做任何更新,那么客户端必须每次更新下载,这种方式的特点是速度快,一次下载,终身脱机,但是,如果我们开发的系统并不是太健康,需要频繁更新,就会比较麻烦了。
我经常采用的是另一种方式,即所有的语言翻译资料全放在服务器上,一般是存储在数据库中,客户端联机后,从数据库中先读取语言包信息,直接在内存中使用,不需要下载到本地,这样保证不会因为下载错误而造成信息不准确。有人觉得每次下载太浪费时间,其实想一下,一般的系统,能够储10K的语言资料,已经很大了(因为我的系统也不大,一般是菜单及按键等简单的文字)。这点带宽,在联机一瞬间可以完成。
为了适应多国语言,我在系统里建立了语言列表,表示所支持的语种,客户端或IE里,可以去选择。
在数据库存储方面,有这样一个例子,比如产品:有中文名和英文名,有些公司做的系统就是加两个字段,分别存储中文和英文,后来又要繁体中文,就再加一个字段,我说我们需要全球N多个语言的支持,你怎么办呢,确实,这种情况下就不行了,双语不等于多语言支持。对于多语言支持,应该在“数据行”上想办法,而不是“数据列”,也 就是分别存储多条记录,这样根据语言去取相应的记录就可以了。
对于多语言,我相信大家各有个的高招,只要适用自己的项目就算过关了。