time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 软件过程 > 职场10年之如何做一名合格的程序员(下)

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

时间:2010-04-16 23:55 点击:2326次 字体:[ ]




上一部分中,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,认为这样就是合作开发了,哈。不过同事们都不太买账,我规定的每天签入,也很难实现,所以在最后合并的时候都有不小的麻烦。刚才还和项目组开会,也讨论了怎么样进行有效的团队开发,人虽然不多,但是意见都不统一,我这种老传统的,就认为以企业需求为主要原则,指哪打哪,因为我认为设计都是为了业务提供服务的,但是一些同事就认为,凡事必须从头到尾进行规范的设计,一步步的来,公司给我的工期只有一个月,要按规范根本做不完,他们就说要变成两个半月,其中拿出足够的时间来做设计。其实我以前也一样,一直认为技术是最重要的,后来慢慢的在工作中,转变自己的观点,慢慢的接受业务为主,特别我们甲方,一般来说并不是在做产品,就是很明显的在做项目,而且只是为自己公司使用的,必须听从公司的大方向安排。

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



本文地址 : http://www.fengfly.com/plus/view-173350-1.html
标签: 程序员 合格 职场
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: