职场10年之如何做一名合格的程序员(下)

上一部分中，Aicken介绍到成为合格程序员的四个努力方面，接下来继续为大家介绍。

5.安全第一

    我指的安全性，不是指如何防止程序代码被人破解，而是如何保护业务数据的安全性。

    为了提高安全性，就要加密，如何加密，在哪里加密，加密后如何解密，就成了问题的关键。

    在可配置性那一部分，我提到了配置文件中的密码，这就是首先要考虑的一个需要加密的地方，因为那是想找麻烦的人首先想到的一个地方。说到这里，我想起几年前，我觉得QQ的密码是存储在本地的，我就想法找、找、找，终于有一天，我觉得密码可能存储在某个文件中，于是花了一点时间，把文件解开了，发现里面写着一句话“别找了，密码不在这里!”我觉得我们做程序都要向这方面努力，哈。

    第二个要考虑的就是用户的密码。在会员管理系统中，都有会员账号和密码，这个密码不应该存储明文，而应该存储密文，而且最好用MD5等单向加密码算法，与配置文件中的不太相同。如果用单向，那么怎么解开再比较呢？答案是不需要解开，我们在登录的时候，把它输入的密码按同样的算法加密，直接比较加密后的字符串即可。只要比较成功，和用原码比较的效果是一样的。这样，即便有人攻破了你的数据库，也很难用会员账号模拟登录了。有人说MD5也是可以解开的，我想这我就暂时不考虑了，有更好用的，更简单的算法我再替换吧，终归现在很多企业都在使用MD5算法。

    第三个考虑的是业务数据的加密。以前接触过一个中原地产那类的房屋中介，他们的数据库里存储的是房源信息，他们的竞争比较激烈，谁拥有那些信息，谁就占有了市场，所以他们对数据的管理非常严格，要求在数据库即使被攻破之后，里面的数据依然不可读。其实这个问题在很多企业都存在，在企业中，DBA可以管理数据，只要他们感兴趣，他们可以看到很多不该看到的信息，虽然数据库厂商想了很多办法，但是权限从根本上就给了DBA，还是很难处理的。我处理这种问题的方式是对部分字段数据存储再加一层密，当然是双向的，存储的时候，把明文加密后存进去，读取的时候，先取出数据库的内容，然后在我的程序里解码，这样，只要是用我的系统，不存在乱码的困惑，但是如果直接查看数据库，对不起，什么也看不出来。

    再有就是考虑加密狗之类的硬件加密了，那个东西我没太用过，不发言了。嘿。

6.层次分明

    听说最早的开发模式，叫Host模式，可能就是完全在主机上运行吧，后来有了CS模式，BS模式，DNS，MV，MVC，三层架构，四层架构，N层架构等。每种模式的产生和持续都有它的历史背景，不能用哪个好哪个坏来评论。我们暂时抛开历史不谈，也不考虑未来，只谈现在，我们应该采用什么方式呢?作为一个健康的系统来说，我建议采用分层的方式，分多少层，怎么分，我不觉得有什么太多的条条框框，只要能分开职责就可以了。

    分层有哪些好处呢？它可以使各个层面之间的耦合度降低，可以使各个角色的人各司其职，只要中间的接口合理，就可以实现一个良好的组合，就像PC机一样，在中关村买一些配件装起来就行了。这样在出了问题的时候，我可以选择换CPU或硬盘，而不至于把整个PC扔掉。

    我现在的程序一般这样分：

    展现层+框架层+数据库层

    因为我用C#开发，展现层指的就是IIS，也就是指asp.net的容器，展现层和框架层实现了代码分离，我会把大部分的业务逻辑或常用的控件封装在框架层，由展现层来调用，这样，就可以在人员配置上，把前端和后端分开了，人们可以各干个的工作，前端发现任何问题，交给后端去检查，然后发布一个新的DLL即可搞定刚才的问题。而且在系统更新的时候，也比较方便，可以找相应的DLL进行更新，不需要全部整个部署。

    数据库层指的是除了数据存储外，在数据库中再写一些程序和逻辑，我用Oracle，那么语言就是它专用的PL/SQL，也就是在我的框架层中，大部分和数据打交道的东西，也全是交给数据库去处理，可以利用视图，存储过程等方式，在C#代码里尽量少的出现数据库里相关的内容，这样一是可以提高效率，二是把耦合度再次降下来，当你把有些业务逻辑写在数据库层的时候，这种优势特别明显，业务上的任何风吹草动，可以在数据库里轻松搞定，而且数据库位于中央，不需要什么发布的动作就可以了。

    任何事物有好的一面，就会有坏的一面，分层也不例外，所以大家要根据情况自己选择合适的方式就行了。不要太过教条。

7.拿来主义

    所谓参考，又谓之学习，还可称之为拿来主义，我这里指的拿来主义，并不是指直接使用其它第三方的控件，而是学习其它系统的实现及设计思路。

    在IT生涯中，有一部分时间您可能是在自己写代码，部署自己的系统，还有可能参加实施一些其它厂商的产品，特别是国外的一些产品（不服不行），他们多在中国设有代理机构或实施商，协助他们进行产品实施，之所以他们这样做，有多种原因，一种可能是出于法律原因，再有就是他们的产品标准化做的真的不错，实施厂商完全可以根据他们的培训去帮他们实施，所以很多国外企业在中国的人并不多，但是挣钱反而不少，一度有个说法“中国IT在为海外做嫁衣”，这也是其中体现之一。不管怎么说，人家的大系统是有它们自身的特点和优势的，所以谁能取其精华，谁就能得到益处。

    所谓大的系统，到底大在哪呢，一是代码量肯定不小，再有就是适应性肯定比较强，有些是行业性的，有些甚至是跨行业的，要做到适应性强，那么系统中的考虑就必须很周到，考虑很周到，系统就会变得越来越庞大。

    我所说的向他们学习，并不是我们一定要做那么大，作为我们的能力来讲，必须现实的考虑问题。但是在这些系统中，确实存在很多标准的东西，如订单管理，进销存管理，到底他们是怎么做的，可以看一下，国外在这方面行业内都比较规范，软件实现的也比较规范，而且都是在国外经过多年考验后进入中国的，这时向他们学习一下，能省我们很多事情，当然要考虑怎么样去做有中国特色的软件了，这个另说。

    当你去实施一些产品的时候，你会发现除了业务的考虑外，在技术上，同样也有一些让我们兴奋的亮点。为了实现一个功能，条条大路通罗马，我们有我们自己的方式，他们有他们的方式，多向他们学习一下。在数据库方面，因为基本都不存在什么加密和编译的说法，所以很容易知道他们是怎么样做的，可以很快学会，将来即便不用它们的产品，把设计思路用在大家自己的产品中，也是个很不错的选择，何乐而不为呢。

    取其精华，去其糟粕，让我们放下架子，尽情去学吧(注意合法性噢)！

8.学会说话

    从我们刚开始学写程序那天起，就被告之，有什么机器语言，汇编语言，程序语言之类的，具体我也分不清，反正就是觉得机器语言就是给机器看的，汇编语言的可读性稍强，后期的第三代，甚至第四代语言的可读性更强。

    但是这几代语言，我觉得都可以算做机器语言，即机器都能很好的认识，当然他们是照着你说的去做了，如果你说对了，他们就能做的对，如果你说错了，他们就会做错，你必须用 if else 之类的机器能够识别的代码去告诉他们，如果你想用“如果你饿了就去吃饭”告诉它，它恐怕是听不懂的（E语言例外），在这种情况下，造就了一批优秀的程序员，这些程序员整天和机器对话，和机器打交道，有些甚至和人类的交流都少了，所以有些小MM曾说，嫁人不能嫁给程序员，还有人说，电脑就是程序员的情人。

    现在来说人类语言：这是专门用于和人类沟通的，如果机器语言被认为是“数字艺术”，那么人类语言可以说为“模糊艺术”，两种语言看起来并没有直接的关系，一般人看不懂机器语言，一般的机器看不懂人类语言，但是对于我们程序员来说，我们是比较特别的一个群体，我们既懂机器语言，又会人类语言，我们所做的工作就是把人类的语言转成机器语言，让机器能明白人类想做什么，从而去正确的实现人类的想法。

    以上说了两种语言的关系，从而我想说一下什么是好的程序员。好的程序员必须熟练使用两种语言，不一定精通，但是绝对不能偏腿，散文写的特美，但是不会写程序，不行！代码质量非常高，但是不会表达？不行！前者一般比较认同，但是后者也是很重要的。现在的时代一直在变化，现在都是合作开发，我们写的代码，需要其它相关的人员来看懂，并且有专门的人员来保证你代码的质量。暂且不说别人，对于自己来说，一个没有注释的代码，过一段时间后，有时真的看不懂了，我想很多人会有这种经历（强人除外）。除了程序的注释是人类语言外，就是专门的文档，我以前对文档就是深恶痛绝的，我一向认为文档只是给别人看的，自己不需要，直到有一次，需要修改两年前的一段程序，才觉得没有文档真是痛苦。在中国做项目，很多代码再被其他人接手的时候，接手人都认为自己重写一次比修改更高效，如此反复大家都在重复做一件事情，所以很难搞出像样的产品来。

    回过头来再看一下国外的大公司，比如MS，Oracle，看看他们的MSDN,OracleDocument，都几个G的文档，虽然大部分文档开篇处都有不少费话,但是这已经成为他们的一种规范，一种文化，对于初次使用者来说，想查什么资料都可以查到，对公司内部，肯定也起到很好的作用。

    说了半天，我就是觉得人类语言很重要，我们不能只为了学习机器语言而忽略了我们的母语。齐头并进吧，这样会有更大的成绩！

9.大局为重

    在之前的若干年中，我做了不少的开发，大部分都是单打独斗，都是自己从设计到开发一人完成（小项目），只是最近，在公司内部进行开发工作，成立了一个小的团队，但是因为人手有限，除了做项目管理外，还要兼顾开发工作，整的头晕脑帐。因为一直是个人战斗，所以对团队开发并不太熟悉，所以组建团队初始，建立了公用的VSS，认为这样就是合作开发了，哈。不过同事们都不太买账，我规定的每天签入，也很难实现，所以在最后合并的时候都有不小的麻烦。刚才还和项目组开会，也讨论了怎么样进行有效的团队开发，人虽然不多，但是意见都不统一，我这种老传统的，就认为以企业需求为主要原则，指哪打哪，因为我认为设计都是为了业务提供服务的，但是一些同事就认为，凡事必须从头到尾进行规范的设计，一步步的来，公司给我的工期只有一个月，要按规范根本做不完，他们就说要变成两个半月，其中拿出足够的时间来做设计。其实我以前也一样，一直认为技术是最重要的，后来慢慢的在工作中，转变自己的观点，慢慢的接受业务为主，特别我们甲方，一般来说并不是在做产品，就是很明显的在做项目,而且只是为自己公司使用的，必须听从公司的大方向安排。

    说了半天，除了团队管理以外，也涉及到对开发的一个思路问题。有些人认为现在有很多流行的工具，流行的就想都能引入到项目里来，这样可以提高这个，提高那个的，当然都有道理，但是如果想控制整个项目的全局，必须在这上面做些让步，我也是做技术的，也喜欢一些新的技术，但是真的没办法，也希望做技术的朋友都能以全局为重，这样可以尽量“造就”“成功”的应用系统吧。