某人职场10年之如何成为一名合格的程序员

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多个语言的支持，你怎么办呢，确实，这种情况下就不行了，双语不等于多语言支持。对于多语言支持，应该在“数据行”上想办法，而不是“数据列”，也 就是分别存储多条记录，这样根据语言去取相应的记录就可以了。
对于多语言，我相信大家各有个的高招，只要适用自己的项目就算过关了。