程序员7年和我的7点感想

发布日期:2012-08-30 14:44:52

  我是1986年第一次接触计算机的,当时刚上大学,用的是VAX11-780小型机运行Basic程序,一个学期下来,算是学点皮毛。1989年,在大学因《微机原理》课补考,反而认真学习了一下计算机的知识(第一次考试前都没有看过书,虽然开卷考试也没有pass,不过在考场上现场发挥,将最多分的一道题完整拿下,其它的基本就完全放弃,当然结果就。。。)。后来由于使用计算机绘制线路板,逐渐学习了一些DOS知识和常用软件,并在此后一年多的时间学会了C、BASIC、PASCAL等语言。

  大学毕业设计的时候,我分到一个软件设计的题目,是用BASIC语言实现DES加密算法。当时记得非常清楚,为了凑过论文要求的40多页,我把程序打印了30多页,DES加密的各种算法表打印了6页,实际真正论文只有可怜的4页纸,最后终于交差。好在程序功能完整,还实现了当时比较新的下拉式菜单操作,评分老师居然给论文的评语是“言简意赅”,真是喜出望外,还因为这个论文得了唯一的一次奖学金。

  自从大学后三、四年纪接触计算机以后,我也象当时大多数学生一样,经常赖在机房蹭机上,虽说有点赖皮,但也学到不少编程知识,当时已经将PC机上的各种编译器尽数收录,在这个过程中,也越来越喜欢编程,觉得很有兴趣。

  毕业后第一份工作虽然和程序设计没什么关系,但也比较认真的学习了一些计算机的理论知识。工作两年后,和象当时的很多人一样来到广东工作,主要从事软件开发工作,先后也换过两个单位,都是从事一些基本的开发工作,在这个过程中,对编程也有了更进一步的认识,基本上也能够熟练的利用C语言进行开发。

  由于将近两年的长期开发,疲劳的我后来换了一份计算机系统维护的工作,这一做就是三年。在这三年中,由于维护工作本身工作量不是很大,我总结自己毕业以来的开发经验,业余编写了一些通用的开发模块,包括数据库接口到各种常用的公共模块,基本上还可以算是一个简单而完整的开发包。

  所幸当时已经意识到很多编程技巧并养成了比较良好的编程风格,其中的模块虽然全部是在DOS下完成,但后来移植到Win32和Linux系统的时候居然也只是简单的调整了一些include文件就基本上编译通过,当时确实得意了一会儿。

  在这一时期,由于思考编程的事情比较多,也阅读了不少资料,所以我也对当时国内的软件开发环境有了一个自认为比较清醒的认识,这个结论就是软件开发是一个有光明没前途的工作,所以后来换工作的一个先决条件就是不从事编码工作。

  结束了三年的维护工作,我来到广州,找了一份技术支持的工作,这个工作虽然比编程轻松,但自己也逐渐陷入对前途的迷茫之中。这段时间我从事过技术支持、售后服务、售前支持、系统集成、综合布线等各方面的工作,但始终没有体会到以前编程时那样信心十足的感觉。这段时期大约又是三年,这三年也是我的心情起落最大的一段时间。一方面觉得各种尝试都无功而返,内心非常郁闷;另一方面心里也始终对编程工作有一种恋恋不舍的感觉,总觉得应该做点什么。

  由于在这个时期接触的用户范围比较广,也见识了不少令用户和开发商头疼的项目,使我对政府机构和各种企业的IT使用情况和存在的问题有了比较深刻的了解。我觉得虽然IT技术发展飞速,但说到具体的实际应用,一个简单的开发甚至简单的需求变更,对用户和开发商来说都挺不容易,用好系统就更加不容易,真是象部分用户说的那样,“电脑成了电烦恼”。我结合自己的开发经历,萌生了开发一个简易的企业应用开发平台的想法。

  这段时间我在广州也换过不少住的地方,后来基本固定住在天河棠下,大约是2001年底或2002年初的时候,有一天我在小区门口的地摊上乱翻,看到了几本《程序员》杂志,当时随便翻了翻,觉得内容不错,就全买了下来。其中的一篇文章给我的印象非常深刻,具体内容不记得啦,只记得作者说过一句话,大意是“不论什么开发语言,所实现的功能虽然在编程方法方面有所不同,但实际上底层的数据交互原理和设计思想完全是相通的”。当时对这句话深有同感,后来又特意找《程序员》以前各期来看,觉得许多文章的技术水平都比较高。虽然其中也有一些为厂商吹牛的文章,但相比其它的杂志,文章内容确实丰富的多,也实用的多,更可贵的是技术含量挺高。比较适合有一定开发经验的人员开拓思路,提高技术层次。

  在之后的几年,我都从小区的书报亭购买《程序员》杂志,同时也在工作之余坚持开发我心目中的企业应用开发平台――MCIS中间件系统。由于以前开发的程序模块很多,在完成了socket通讯、socket线程、http协议处理等几个主要模块后,这个软件已经基本开发完成。主要开发工作基本在不到一年的时间内就全部完成。

按原先的计划,MCIS中间件软件的主要目的是屏蔽具体技术细节,让对计算机有一定基础,了解SQL语句和html文件的人能够从事基于数据库的应用开发。并根据数据库表的定义生产基本的数据增删改查的功能,将基于数据库的应用开发转换为SQL语句的开发。对单表和基本主从表则根本不需要任何编码工作,直接生成应用,实现其所需要的业务功能;对复杂数据表之间的关联处理,也仅仅需要编写一些SQL语句或存储过程;至于程序界面的美化,则主要利用html模版文件实现。后来又增加了WebService支持和Cache支持,可以将某个业务逻辑封装为一个WebService来进行发布,或调用其它WebService服务器的功能;还可以自动识别数据的变化情况,大大减少大量用户并发访问时对数据库的访问频率。

  在这一阶段,我从《程序员》杂志上学习到不少知识和思想,也觉得很多文章中所涉及的观点、方法非常有道理,对这本杂志越来越喜欢,后来也从经常购买到每期必买,到最后自己订阅,去年底我就一次订阅了三年的杂志。

  可能是有些自负的因素吧,我常常觉得《程序员》杂志上的很多观点和我不谋而合。我一般喜欢看的是人物介绍、产品的底层实现方法等文章;对其它的新名词倒不是很感兴趣;最不喜欢的栏目反而是几个人不断的在说各家产品的有什么新技术、新趋势的文章。

  在接触《程序员》杂志的这七年,也是我从迷茫走向成熟的七年,至少我能明白我现在在做什么,也能够承担因此而引起的后果,不论是苦还是甜。

  这几年来,我也发生了很大的变化,各种生活也逐渐定型,虽然开发不是一个很好的工作,但对我个人来说,技术(特别是开发)仍然是能最发挥我的特点的一个职业。随着年龄的增长,我也能坦然接受自己对这个工作的喜爱,并感受到其中的一点乐趣。

  粗粗算来,已经工作快十八年了,接触计算机也有二十年的时间,其中用于编程的时间大概也有十年,在这里将我的几点体会和大家分享一下。如果您是一个程序员、或者打算做一个程序员,或者打算开一个公司从事软件开发方面的工作,希望这些观点能够对您有所帮助。哈哈,如果要拍板砖,估计也砸不到我脑袋上。

1、开发规模问题

  对于目前业内的一些观点,我并不认同。例如在各种报刊杂志上,经常有专家教授唠唠叨叨在说现在的软件开发已经进入工业化时代,要多少多少人团队开发,才能如何如何。

  但是,基于国内的实际情况,其实许多1000万元以下的项目完全是几个人的小团队开发模式,即使大到规模上市的软件公司,具体到每个定制开发的项目,实际项目组的开发人员,也经常只有不到十个人的规模,三、五个人的情况更是多如牛毛。

  再看看国际上,我们所使用的一些著名的产品,如unix系统、C语言、notes系统、java语言、甚至最早的windows、dos很多都是几个人的小组所完成的开发。

至于这些产品的推广完善,所需要的巨大人力资源和开发之初的人力投入完全是两回事。在开发阶段,人多不一定就是好事,甚至肯定要坏事。

  这就像生小孩一样,只要一男一女两个人就完全足够啦,其它的人只有干瞪眼的份。但是,将这个孩子养大成人,除了他的父母,整个家庭、学校、社会等其它各色人等也直接或间接付出了很多。但这个孩子仍然只是他父母开发出来的,其它人只是起一个推波助澜的作用。

2、技术与思想问题

  综合分析目前国内的软件开发方法(甚至包括其它IT技术),不难发现,我们总是热衷于技术,而不注重标准。从Basic、C、C++、一直到java、C#等语言,再到.Net、J2EE等架构,多少技术在我们眼前晃来晃去,有些人也以掌握这些技术为目的,甚至洋洋得意。

  其实,冷静下来分析一下其中的核心技术内容,现在的Web开发和早期的CGI方式的Web开发,只有方法上的不同,没有实质上的区别,所遵循的数据标准也没有任何变化。

  整天只沉迷于片面的技术,使我们离核心技术越来越远,根本谈不上什么创造性。现在国内很多电子政务的项目在投标时均要求必须基于J2EE或.Net技术,完全拒绝LAMP和其它技术,估计很多美国公司老板做梦都要笑出声来。

重要的是思想而不是工具,就象毛泽东打败蒋介石是依靠思想而不是武器一样,技术并不起决定作用。

3、技术沉淀的重要性
  由于不注重核心技术(其实那怕是一个小小的strcpy都是核心技术的一部分),很多公司没有任何技术积累,也没有可重复使用的底层开发库,更谈不上编程方法和思想上的积累。

  因为工作的关系,我曾经接触过不少项目,这些项目都是号称采用了何等先进的技术云云,但实际上很多项目即使一个简单的按钮修改都需要在每个JSP文件中逐个修改。看了这样的代码,你真的不能不相信,语言是一个项目中最不重要的技术。

4、面向对象的是与非

  我始终认为翻译“面向对象”的那个人是一个典型的老光棍,整天想着找对象,所以就想当然的这么翻译,其实我觉得“面向对象”应该是“面向目的”才对。所谓面向目的,说白了就是黑猫白猫的一句话。

  其实“面向目的”(而不是“面向对象”)更多的是一种思想,而不是一个所谓的编程方法。所谓的抽象,固然有其必要性,但到处都是对象的说法,往往只是一些外行说出的内行话。难怪Torvalds对C++批的一无是处。

  真正的“面向目的”,就是对一个项目的各个部分采用最适合的方法以达成目的。

5、大道至简

  我越来越相信“大道至简”这个哲学观点,从设计产品、系统分析、模块划分,一直到做饭洗菜、吃饭睡觉,甚至到人际交往,这个道理都是相通的。从程序的角度也是如此,一段好的代码大多都是一个简洁的代码。

  就像做人一样,简单做人,自己不辛苦,别人也不辛苦。同样一种开发语言、一种技术、一种开发工具、一种框架平台也是如此。

  我个人认为C语言几十年不倒的主要原因,主要就是因为其结构简单,扩充方便。n年前玩音响的时候,很多发烧友也一致认为,在价格相当的情况下,一个旋钮最少的音响基本上就是最好的音响,也是同样的道理。

6、责任心和细节

  其实大家都知道这一点,但是实际操作起来往往又根本不在乎。做项目需求时,有些人往往只是考虑实现客户要求的功能,而不是从客户要求的内容去思考和分析,甚至因为工作量的关系,故意避开一些问题。但是这些问题仍然存在,最后仍然会逐渐暴露出来,反而自讨苦吃。
其实,对客户而言,能有更好更完善的方案一般都会乐意接受,如果能本着对客户负责的精神,客户才能真正信任你;你和客户谈起价格时也才能有理有据。

  很多时候只要负起责任,就会有助于发现所有的问题,并提出一个妥善的解决方法,注意到每一个细小的问题。其实大到卫星上天,小到刷锅洗碗,最根本的关键不是什么技术,而是在高度责任心的基础上对细节的把握。

  我曾经在跳蚤市场买过一个七十年代的收音机,是春雷703,一个很古老的上海牌子,其信噪比和灵敏度比现在的集成电路的高出很多,原因无它,每一件细小的功能都做到最好而已。其实看一个程序员只要看他对程序跳格的处理,就可以决定90%的情况。

7、坚持熬下去

  前几天看一个关于抗战的记录片,老毛对抗战相持阶段的说法是熬下去,当然是积极的熬法。其实不仅是做程序,做其它事情又何尝不是这样。

  如果一天写100行代码,10年下来就是30多万行,记得好像unix最早的代码也不到40万行,30多万行代码,可以做多少事情呀。

  有一天和一个朋友谈起代码量,他说最近在招人,要求曾经独立写过1万行代码,我后来仔细算了我开发的MCIS中间件系统,在代码最多时也才5万多行,后来不断调整优化,现在只有4万行不到。再统计一下数据库接口部分,每个数据库接口只有可怜的400行代码不到,但就这简单的400行已经可以完成一个数据库接口应具备的完整功能。

  这几天刚好赶上亚洲杯,中国队0-3负于乌兹别克斯坦,又一次在打平即可出线的时候情况下完蛋。看看中国足球队的窝囊,其实就是没有认真对待场上的每一分钟,姑且不论技术和意识,只要场上每个人都能坚持90分钟不停的奔跑拦截,估计在亚洲也可以独立独行。最根本而又最简单的没有做到,又何谈胜利。

总想写一些东西,但因时间的关系,一直拖了下来,这几天刚好朋友约稿,就写一点自己的想法。从职业的角度而言,每个职业都有不同的酸甜苦辣,相比而言,选择一个自己比较喜欢的职业,也确实是一个不错的选择。可能是年龄的关系,我反而觉得生活才是最重要的,当然最好能在工作中保持乐趣,在生活中享受乐趣。在《程序员》杂志7年之际,写下这点东西,希望《程序员》杂志能够成为更多程序员的朋友。