语言|转(我的野蛮成长)

因为博文视点的周筠老师约稿,我就写了这么一篇,一时没有收住,写得多了点,先发出来吧。
小学五年级的时候,我第一次接触到了计算机,到现在,已经23年了!
和许多许多人一样,从10岁那年起,我就确信,计算机,是我的最爱!(当然,老婆、孩子、家里人除外!)
因为我的个性以及各种偶然的因素,我的成长那是相当的野蛮,不合常规、不守规矩、不走寻常路,
现在回头看来,那些令人难忘的熬夜加班、纠缠于技术难点导致的彻夜难眠、在公司里与人争到面红耳赤、在BBS上与人唇枪舌剑,就是我成长的方式。
很难说能够给读者什么启示,只能说作为一些小故事和一些零散的思考,也许还是挺有意思的。
一、1986~1993:大学之前
1、吸引力
1986年,小学五年级的时候,我第一次看到了计算机。Apple II是一台相当漂亮的机器,在少年宫的一个很大的房间里,放了10多台。少年宫的老师,用苹果机,教我们学习Logo语言和BASIC语言。用小海龟画一些小房子之类,或者在报纸上找到当时很流行的“BASIC一行程序”,在计算机上执行,看看各种有趣的效果,比如输出一个乘法口诀表。
这样的机器,带给我极大的乐趣,那是一个全新的世界,拥有无限的可能,只要我肯花功夫下去,我就能够成为那个世界里的上帝。
有一段时间,我很沉迷于对那种单音喇叭的发声模拟研究,因为只要掌握好单音喇叭的触发间隔,他就能够演奏出不同的音调,能够演奏乐曲,甚至模拟人声。。。
当然,最重要的是,计算机可以用来玩游戏!当时我找到过一本书,里面是用汇编语言印出来的游戏程序,初三以后,父母给我买了一台中华学习机,我就会花大量的时间在计算机前,把那些汇编代码一句一句的输入到机器里,大半天甚至一天的时间,才能玩上一个小游戏。而且无法保存(当时的机器没有硬盘,只能外界磁带机,而且我当时还没有。)玩上最多一个小时,就只能关机了。
如此低的投入产出比,依然让我乐此不疲。更不要说,随着计算机的能力越来越强,更由于互联网的出现和日益丰富,计算机,对我的吸引力,始终是有增无减啊。
2、1991年的红警
当然,红警不是那时候出现的,根据网络上的资料,《命令与征服》的最初版本发布于1995年,而我在大学时期最热爱的游戏《红色警戒》,则发布于1996年。但是,早在1991年的时候,我和几个朋友在空想的一个游戏,就非常类似于后来的“红警”。我们当时设想了一个小岛,上面有两个国家,他们有各自的资源,可以建造自己的各种工厂、矿山、船坞、兵工厂,然后再进一步制造出各种兵种的战斗单位和武器。可以打地面战争,也可以打海战。
当时,我们的讨论相当的深入,甚至还去查找了很多相关武器的技术资料,做了笔记,画了地图等等工作,做了很多。代码,的确是一行都没有写过。现在回想起来,以我们当时的能力,见识,机器条件,要想开发红警那样的即时战略游戏,是完全不可能的。
当然,这并不能算是一个失败,与朋友热火朝天的讨论这样一个游戏的过程,已经带给了我极大的快乐。
3、两大弱点
我从小学5年级开始,就参加各种计算机竞赛了。比赛的成绩,始终处在中上的水平。一般来说,我的书面试题的成绩都不是太高,但是我的上机试题却能够做得飞快。总结下来,我通常都能够得一个2~3名的名次。编程快枪手的毛病,就是那时候养成的。这个弱点,直到我参加工作以后很多年,才逐渐的被我克服。
另外一个弱点,也可以说是一个不幸。在我小学考初中的时候,因为一时粗心,数学被扣了20分,原本想进“一中”的,结果只能通过关系进了“九中”。更糟糕的是,那时候,正好是中苏关系回暖的时期,教育局居然在全市找了两个学校,各开了两个俄语班。而我就是那个不幸被抽中的,学习俄语的小朋友之一。英语,始终是我最大的弱项。直到现在,我在工作当中遇到问题,首选的办法,是去阅读源代码,而不是去阅读文档。塞翁失马焉知非福,阅读源代码得来的知识,确实牢靠得多,毕竟文档会骗人,代码可不会骗人。
4、神气的计算机课代表
在中学的六年中,有两年我特别神气。初一和高一,我们开设计算机课,而其他的四年,是没有计算机课的。给我们上课的老师,同学们都称其为“庄表伟的干爹”。一方面当然是因为我的计算机竞赛能够出成绩,老师一直会让我在课余时间自由进出机房。另一方面,则是因为我在班上几乎就成了半个计算机老师。每次上机课的时候,我从来都不坐在自己的座位上,而是在教室里晃来晃去,帮助同学们解答各种问题,最夸张的是,最后的期末考试,老师也随便我在教室里走来走去,帮同学们做考卷。那是何等的神气,何等的威风啊!
现在想起来,那样的成就感,被人崇拜的感觉,是我热爱计算机的重要动力之一。
二、1993~1997:大学四年
1、不走寻常路
这个故事发生在大二的时候,我读的专业是电子信息技术,所以软件开发相关的课程开得很少,C语言还是必修的。在最后一个大作业的时候,老师的题目相当简单:用绘图函数,实现8个标准的三角函数,将函数曲线绘制出来。这个题目实在太容易了,很多同学,都尝试锦上添花。
老黄的做法非常的赞,他用纯C,在DOS下做了一个图形界面,支持鼠标指针。在给定的函数曲线画出来之后,可以操作鼠标,在界面上任意点击,查看(x,y)的坐标值。后来,老黄很早就在某软件公司做到了CTO的职位。
老刘的做法也很出彩,他找到了一个漂亮的JPEG风景图片,作为软件的启动界面,给老师留下了深刻的印象。后来,老刘工作不久就自己创业,而且是同学中最早开跑车的一位。
至于我呢,却不甘心只实现那8个函数,而是下大力气做了一个任意表达式解析的模块,支持键盘输入任何公式,就能够绘制出曲线来。这个作业,老师只给了我“60”分,原因是:没有按照题目的要求去做。
虽然,我的那个做法,是技术难度最大的。。。
【语言|转(我的野蛮成长)】2、第一桶金
说是第一桶金,其实相当少,也就是2000块钱,当然,这在当时的确算是一笔巨款了。我们的系主任对我那是相当不错,当时他教我们数字逻辑电路,我学得挺好,给他也留下了不错的印象。因此,有一次他就把我找去,问我是不是能开发一个软件,是饭店的点单系统(其实类似于现在的POS机,客人点菜后,打一个条子出来,可以凭票付钱。后来还加了一个统计报表的功能。)饭店老板是系主任的一个亲戚,饭店开在外滩附近,他们店里有台挺破的486,连着一台针式打印机。我 当时除了C语言,和小学时候学的Logo、BASIC,其他啥也不懂。但是也硬着头皮,壮着胆子跟系主任说:“没问题,我两个礼拜就能作出来。”
回到学校以后,就赶紧去图书馆找FoxPro的书,连夜开始学,然后一边学,一边在机房里试着编程序。(那时候的条件远不比现在,寝室里没有一个同学有电脑的,更不要说联网了。)
两周之后,顺利交付,那钱来得可真是爽啊,能够做自己最喜欢的事情,还能赚到钱,这样的事情,我愿意干一辈子!
3、一夜狂啃toolbook
大二开始,我就在外面找一些活来做,一开始是做图书推销员。就是包里背着那种大部头的企业用的图书,比如《公司法实务全书》、《合同法全书》,售价200~300多的那种。然后骑车到浦东去,一家一家的敲人家公司的门,进去就推销。那时候大多数公司还不设防,看到大学生上门推销,还有新鲜感,就算不买书,也会跟我们聊聊天。我只要“很憨厚的跟他们谈谈学习和生活”,就行了。卖一本书,我能赚到50块~100块,每次骑车出去,大概能卖掉2~3本的样子,最多一次,我卖掉了7本,后来还做了销售代表,在学校里发展下线,让他们出去推销。
到大三的时候,我就不再做推销员了,一方面是赚钱不容易,另一方面也觉得有点不走正道的感觉。后来还是出去找编程的工作来做。有一次一家做教育课件的公司,来我们学校招人。他们那个是计件制的,做一个课件拿一笔钱,还是挺不错的。跑去应聘,那个公司的人,也没问我多少东西,就发了一本toolbook语言手册,让我回来先自学。
还得再说说那时候的计算机条件,同学自己是没有电脑的,机房要排队,去晚了就没法上机了,而且就算能上机,机器也很差,还不能乱装软件。寝室里11点就熄灯了,没法看书。那天晚上,我就找了一间实验室在里面熬夜看书。toolbook是一个专业做教育课件的编程语言,跟VB非常像,但是不可能让我带回来装在自己的机器上。
于是,我就只能看书,看Sample Code,然后尝试在脑子里跑代码。然后,逐步的展开思维,推演用这个语言,能够做哪些事情,该怎么去做。
一夜没睡,到第二天,我已经成为一个挺熟练的toolbook程序员了。
4、月薪800的项目经理
当时国内的软件开发企业,还是很不正规的,我能够以在校生的身份,当上所谓的项目经理,就是因为进了一家特别能唬人的公司。我那时候读大四,在外面找了一家“软件公司”,公司实际的老板是一个姓蔡的四川人,我们都叫他“老蔡”。后台据说是“上海市计算机技术研究所”,我们计划开发的,是一个叫做“新奥2000”的行政办公管理软件。老板把我招进去以后,就扔了一本大书给我,叫做《行政办公管理表格大全》,然后我们就从这本大全里,挑出一些常用的,看上去有用的表格,做数据库设计,然后再做功能设计,界面设计。后来为了有销路,还在软件里打包了3个小游戏,和一个生活常识大全之类的数据库。
就是这么一个四不像的软件,由我带着5个同样是在校的学生,在那里没日没夜的开发。没有什么测试人员,那些功能,也就是老板大概点一点,不报错就OK了。最难的一个模块,是一个“工资管理模块”,当时我设计了一个可以任意分级分层的工资项结构,从数据库来说,处理起来还容易,但是要显示一个树状结构,就太难了。ForPro 2.5当时没有没有现成的树状控件,我只能自己用字符来拼出一颗树的样子来。要考虑各种各样的分支情况,那个功能,我是在有一天的凌晨4点多的时候做完的。。。
诚实一点说,那样的项目,简直就是垃圾,虽然老蔡非常牛的把这个软件卖出去了,但是据说后来接到了很多投诉和退货:p
对于我来说,这是一次非常难得经验,我参与了一个完整的商业项目的所有流程,从前期设计到开发、测试(虽然极其敷衍)、代码打包、软盘加密,到最后对销售人员的培训。还有在项目开发过程中的分工与合作,出bug、查bug、帮人改bug,接客户投诉等等。
最后,我离开了这家公司,但是他们还欠了我3个月一共2400块的薪水,因此,我还积累了非常宝贵的“欠薪”、“讨薪”,最后“讨薪成功”的经验。
5、我的毕业论文课题
我就读的是华东师范大学电子科学技术系信息处理专业。毕业的时候,系主任刘必虎老师是我的论文指导老师。我当时给老师申报的课题是《尝试破解FPGA/PLD开发软件的试用版限制》。当时系里搞可编程逻辑器件(PLD),从厂商那里拿到了一套开发工具的试用版,功能受限。我就向刘老师提出试着破解一下这个软件,同时作为我的毕业论文。
现在看来,这是多么不靠谱的一个毕业课题啊!与电子系专业毫无关系,还有犯法的嫌疑。老师居然也就同意了!
当时,我其实完全不知道破解软件该怎么弄,找了一些资料,找到了一些软件,其中有一个非常强悍的软件,叫做SoftICE。然后就开始了兴致勃勃的跟踪之旅。当时的资料也非常少,很多地方只能靠猜,从一头雾水,到逐渐摸到一些门道,到逐渐理解了那个程序的执行过程、系统结构。然后再进一步理解汇编语言、内存管理、WIN32API等等等等。
时间就那么匆匆的过去了,好多事情都来不及做,还要分出很多时间去打红警,还要和同学出去喝各种规模、各种级别、各种名目的告别酒。。。到最后,我的破解任务,并未完成。。。
。。。N天以后。。。
论文我敷衍了30多页,然后进去答辩,系里的老师,其实没有一个懂软件破解是怎么回事。。。在我口若悬河,滔滔不绝,信心十足,意犹未尽的讲完之后,只有一个老师,提出了一个问题:“那么,按照你的思路,这个软件能够破解掉吗?”我回答到:“那当然,肯定就是这样去破解的”。答辩结束。
。。。N天以后。。。
同学们告诉我,我的论文,获得了优秀论文奖。
真的,我特别感谢我的母校,我们的电子系的老师。在这样一个特别宽松的环境里,我获得了自由的,甚至是肆无忌惮的成长。现在想来,真是觉得难以置信!
三、工作以后的成长
1、软件开发的目标变化
最早我开发软件,很少会考虑bug的问题。不是说不出bug,而是只要手脚够快,代码写得够快,bug出得快,改得也快。因此,软件开发的目标,首先是速度。就像我以前写过的一篇《关注软件开发中项目的人》中所描述的那样:
我最初就是个快枪手,能够快速的完成主线功能,但是却从来不考虑例外情况。完成了给定的功能需求,但是代码却只有我自己才能看懂(1天之内)。新的技术,我也是很快就能上手,“Hello World”转眼就能跑出来。但是要再进一步深入专研,我的兴致就不高了。一个团队有一个这样快枪手,真是要非常的小心,才能用好。你可以分派给他各种类型的任务,但最好不要给他太关键的功能点。因为究竟会不会出bug,他是无法保证的。要花更多的时间,并且更加频繁的检查他的工作,以确保他不仅仅是完成了表面工作。更为重要的是,要不断的敲打他,督促他,逼他更加用心,努力提高。一个快枪手,也是有可能成长为独当一面的将才的。
在2000年的时候,我进了一家互联网门户网站。刚开始的时候,老板还雄心勃勃的想要做一个虚拟城市的项目。正好我之前有Flash开发Web Multi Game经验。但是3个月不到,冬天就来了。公司开始艰难转型,我们开始去接很多企业上网的项目来做。几千块的单子的,都先接下来再说。老板在销售方面是一把好手,项目源源不断的进来。开发的目标,自然就发生了变化。开始追求效率,当时应该有很多中小型的软件企业,开始搞自己的山寨快速开发框架,我们自然也是其中的一家。只是,我的思路比较邪门,在我看来,不同的项目开发,最影响工作量的,其实是底层的数据结构,每一个项目,一套数据库表设计,然后再一层一层的写上去,还要为不同的项目写各自不同的后台管理界面,实在是太麻烦了。如果每一个项目的数据库结构都一模一样,数据库访问层都不必重写,那么,开发工作,几乎就只剩下在“静态页面”上修改一下,插入一些数据库访问的代码就OK了。在这样的指导思想下,我做了一个PHP框架,设计了一张超多字段的表。大多数项目,都可以用这个表结构,而且,相应的后台管理界面,完全可以一模一样,前台开发,几乎可以立等可取。总的效果,还是很令人满意的。
到了2002年左右的时候,公司开始主攻电子政务市场,再用PHP去谈项目,就相当困难了,因为PHP给人一种相当随意简陋的感觉,在政府那边,拿不出手。再加上EJB当时已经如日中天,各大厂商都在不遗余力的鼓吹。重新做一套java版的框架,成了我的首要任务。而在此之前,我从来没有接触过java。
在此之前,我几乎从来不买任何软件开发相关的书籍,但是Java似乎不是一个可以随便翻翻手册就能学好的语言,于是,我买了两本对我产生重大影响的书《Thinking in Java》和《Java与模式》。在看了这两本书,尤其是在对面向对象和设计模式有了较为深入的了解以后,我才意识到,追求可重用性,其实一直是软件开发的重要目标,而我原来的那些PHP语言作出来的山寨框架,实在是太不入流了。再后来,我又看了《重构》,于是:追求可重用性,追求代码的简洁美观,追求漂亮灵活的设计模式与架构,成为一段时间内我的目标。
在现在的我看来,这段追求代码质量的日子,可以说是一段弯路,当然,也非常有价值,回头在讨论面向对象的时候,再深入分析一下。再后来,我有加盟了另外一个做P2P视频软件的公司,后来又在一家做手机网络游戏的公司里干了三个月。在网络编程的领域内,系统性能,负载能力,健壮性,容错能力等等要求,变得非常的重要,而代码美观程度,只能是作为次要考虑了。
在我的开发经验中,一直存在着一个重大的缺憾,那就是没有机会去接触算法密集型的项目。在我从事的这么多工作和项目中,几乎没有需要我去研究算法的问题。要么是业务上的,要么是功能上的,要么是架构上的,总之不是算法上的。也不知道什么时候,才有机会补上这一课。
2、对于开发语言的一些认识
对我语言的认识,分为三个阶段,在初学编程的时候,“看山是山,看水是水”。BASIC是BASIC语言,Logo是Logo语言,C是C语言,各不相同,需要分别学习、记忆和掌握各自的知识点。
等到渐渐地运用纯熟了,可以触类旁通,才发现以前学过的那些语言和将要新学的,总有这样那样的相通、相近、相似之处。任何一门语言,我都能快速上手。在意识里语言已没有差别,无非是语法与关键字的区别而已。然而,过了很长时间我才发现,那时的自己远没有到达最高境界,最多也不过是“禅有悟时,看山不是山,看水不是水”了。
大约在2002年的时候。我看了《Thinking in Java》这本书,进一步深入了解到Java语言的许许多多的细节和深刻的内涵。才醒悟到我以前所谓的掌握多种语言,其实还是只掌握了一门语言,就像《天龙八部》里的鸠摩智,以小无相神功,耍那少林七十二绝技,其实却都不过是一套本事罢了。而且更为重要的是他更加意识到要真正用好一门语言,发挥一门语言的长处,理解这门语言的思想内涵,实现细节是非常关键的。而实现细节是各个语言自身的特色,到头来还是要把不同的语言,当成不同的语言来使用。看山仍然山,看水仍然是水。
在此之后,我又接触了Ruby语言、Delphi语言、C++语言还有Pyhton和ActionScript,在不同项目里穿插使用,用不同的语言。目前我的观点是:日常工作可以用ruby,特殊的日常工作可以考虑JRuby,Web应用当然是Ruby,桌面应用首选依然是Delphi。实在不行了,万不得已也只能用C++。
另外,目前有一个相当明显的趋势,就是多语言混合编程的项目,越来越多,这方面我也没有太多好的实践经验,但是从直觉上来看,我认为还需要等待总结出新的开发范式,从理论的高度,来指导今后更加复杂的开发。
3、有关面向对象的话题
关于面向对象,我有很多可以说的内容。从2005年5月到8月,我写了一个相当长篇的连载论文,叫做《敲响OO时代的丧钟》,在JavaEye论坛引来了众多的围观者和探讨者。原文实在太长,总结一下的话,就3句话:
1、以静态类型为定义基点,将数据与操作封装在一起,称其为类型。是一种错误的做法。
2、OO在封装类型的基础上,逐渐发展起来的继承、多态、重用、泛型、原则、设计模式、重构乃至AOP等等小手段和大名词,都是在错误的道路上,越走越远。
3、我设计了一种基于消息通知的新的语言DJ,将数据与操作,动态的绑定在一起,既满足了灵活性,又考虑了概念的自洽性。
在此之后,北京的徐昊发了一篇长文:《丧钟为谁鸣?》深入的分析了我的谬误,基本上,当初我的批判对象,实在是过广了。OO的领域其实非常的大,而我对于OO的了解,却始终不出Java、C++的范围。后来我才逐渐理解到,我所向OO开的炮,90%只应该打在Static Type OO的身上。当初夸下了海口,如今只能羞愧万分,还是学习得不够多啊!
在学习了很长一段时间的Ruby之后,我对面向对象的概念又有了更加深入的了解,但是,在目前多核与并行计算逐渐兴起的情况下,又逐渐发现,动态类型OO语言在追求高性能目标时,同样不是最好的方案。详细的讨论,可以在JavaEye搜索Trustno1的众多文章。
总之,学无止境,还需努力啊!
4、有关软件架构的一些经验
在工作的经历中,我主要做过5类软件:IDE、Web门户网站、企业与政府信息化应用、P2P网络应用和桌面软件。在做IDE和Web门户网站的时候,我从来没有思考过软件架构的问题。而在做P2P网络应用和桌面软件的时候,由于工作的关系,我也没有再深入的、集中的思考过软件架构的问题。因此,关于架构的很多看法,我的经验基础,是来源于WebMIS类应用的。
1、绝大多数信息化管理,面对是能够以树状形式组织起来的各种信息。对于一个企业或者政府的需求调用,应该先从对于“信息”、“数据”、“资料”、“文档”的整理、分类、分析开始。
2、能够明确决定归属的信息节点之间,存在着明确的“父子关系”。但是除了父子关系,节点之间还存在着其他可能的关系,比如“参照”、“引用”、“相关”等等关系,需要进一步分析和规范化。
3、对于每一个信息节点,不同的人、不同的角色、在节点所处的不同的状态下,能够对之进行不同的操作。这就是自然浮现出来的“权限管理”与“工作流”的概念。
4、基于这样的一种架构设计,前期的需求调研与后期开发维护,也会变得非常的自然,开发效率也会大大的提高。
基于这个架构,我用Java语言做了一个名叫iMIS的框架,也就是“集成管理信息系统”的意思。基于这个框架,我除了做了一些企业和电子政务的项目,还用它开发了一个房地产的门户网站,还有一个主题词管理的工具。在自己已经有了一套自己的思路之后,我才看到了《企业应用架构模式》一书。说实话,颇不以为然。
但是,在开发P2P软件的那段时间,我非常有幸,招到了开发Java NIO框架“Cindy”的作者陈睿,来做我们那个软件的网络部分开发。在深入阅读NIO源代码和Cindy的源代码之后,我逐渐发现,这个一个完全不同的架构领域。其中的思维模式,关注焦点,常用技巧,与我以前的信息系统的开发经验,是完全不同的。而且,在我看来,网络应用编程这个领域,架构的模式,要比信息系统领域,成熟得多。也轮不到我来贡献些什么,深入理解、灵活运用就行了。
在转入桌面软件开发之后,我们当时选用的是Delphi语言。由于深受测试驱动开发思想的激励,我也一直希望能够在桌面软件开发中,引入测试驱动的做法。但是却很不成功。Delphi作为一个被Borland经营多年的语言与开发工具,已经形成了一套非常完整的开发模式与架构模式。而这些模式,是在设计模式、重构、测试驱动等等思想成为潮流之前,就已经成熟了。因此,要引入基于设计模式的测试驱动方案,就非常困难。我们在网上找到了一个叫做eMVC的Delphi MVC框架,但是这个框架在2006年以后也就停止开发了,本身用起来也非常别扭,有很多画蛇添足的地方。所以,后来也就只能放弃了。
再后来,又接触了Ruby语言,在Ruby的环境下,考虑软件架构,又有很多不一样的问题,这里就不再展开了,说说我的一些观点总结吧:
1、软件架构与应用领域,严重相关,很难跨领域的沿用类似的软件架构。
2、软件架构的设计,与语言严重相关,好的软件架构,应该是充分利用了这一语言的特性,同时也充分尊重这一语言的特性,也有助于充分发挥这一语言的特长。
3、测试驱动开发的思想,发源于企业应用领域,但是在图形用户界面(GUI)类的项目方面,存在一些固有的困难,很难被优雅、完善的解决。这也同样影响了架构设计时的考虑。
4、从Java语言出发的,企业应用架构模式,过度主导了目前的软件架构观念,这不是什么好事情。
5、开发管理方面的一些经验
我在管理方面的经验历程,相当古怪。大四的时候,我就当上了项目经理,管理5个人。工作以后,6年半的时间里,我一直战斗在第一线,最多带两个弟兄,一起去拼项目,连项目经理都算不上,最多是开发小组长。接下来的两年半,我摇身一变,成了CTO,却始终只有两个手下。再后来,做了3个月的架构师,然后当上了印客网的技术总监,到现在已经快3年了。要说正儿八经的管理经验,我只有3年。之前的时间,可以说一直是以一个团队成员,最多是TeamLead的身份,来看待管理、思考管理的。
在真正担当IT管理者的角色之前,我的想法很多。我看了很多的管理学的书籍,心理学的书籍,经济学的书籍,企业战略学书籍,反正是作为知识储备和思考的参照物,我看了很多,也因此对于当时所在公司的各个阶层的管理,有很多很多的不满。总觉得他们应该如何、如何,就能够做得更好。也经常在设想,如果我是管理者,就会如何如何。
在当上CTO以后,我开始有权力招人了。按照自己的设想,订立自己的规则,也果然招到了非常非常优秀的伙伴。当时我的确是相当的得意,还特别写了一篇文章,叫做《招人不难》。当然,现在回过头来看我的那篇文章,也还是相当有价值的,没有什么太大的问题。
不过,在管理的问题中,招到人,只是一个开始。真正困难的是,把人招进来以后,该怎么管理。后面的一大堆问题,其实要困难得多。
首先面对的问题,就是在快速变动的需求与频繁发布的压力之下,在有限的时间和人力的限制之下,如何控制项目风险。后来经过思考与总结,形成了一篇文章,《知易行难的软件开发风险管理》。说的其实是最简单的道理:风险无处不在,时时小心才能减少风险带来的损害。一篇文章,说了四个部分,其实最重要的一点没有说清楚:“知易行难!”
后来,在我的Google Docs,一直存着一篇未完成的稿子,标题是《Check-Driven Management》,开篇的第一句话就是:“纸上得来终觉浅,绝知此事要躬行”。大概的思路是,在软件开发中的TDD(测试驱动开发),引申到管理上,就可以称之为“检查驱动管理”。之所以一直没有完成并发表,主要还是因为,这始终是一个程序员转型为管理者过程中的一些不成熟的东西。对于整理自己的思考有价值,但是对于他人,价值寥寥,不发也罢。
到现在,我对于开发管理的看法,可以说是相当看不上理论的东西。因为,那些高深繁复,精致优美的理论,并不是为我所准备的。我现在自己面前的那碗饭,都还没吃干净呢?要说现阶段最为重要的任务,那就是培养自己形成一些有效的管理习惯,如此而已。
6、杂感
杂七杂八的感想,还有很多。能够归入“成长”的却不多了。想到哪说到哪吧。
一直有这样一种感觉,技术方面的东西,往往是“知难行易”。理解起来很困难,一旦理解了,其实很容易做到。而管理方面的东西,却往往是“知易行难”,都是些常识性的东西,但是要坚持做到,却非常的困难。不过,后来读到了一些有关王阳明的“知行合一”的理论。似乎在他看来,如果是行得不够好,那就肯定是知得不够深。而且,要知得够深,也一定是不能脱离行的。想来也的确有道理,但是也还远没有参透。
程序员的成长,有很多偶然性的因素,其中可以明确的一点是:通常程序员都是伴随着企业一起成长的。我有一个朋友,7~8年前去了美国,进了当时的新蛋公司。那真是只有三五个人,七八条枪。但是到了现在,随着新蛋的发展,她也随之不断的成长,现在已经是美国新蛋总部,独当一面的技术主管之一了。这其中当然有很多运气的成份,假设她当时进了以后2~3年后倒闭的公司,也未必能有现在这样的成就。但是,另一方面,她的成就从根本上还是源于她的努力。如果不是持续的努力,一个逐渐不能胜任的“元老”,早就被快速发展企业给淘汰了。还是那句老话:“机遇总是垂青有准备的人。”
“地图意识”非常重要。我一直以来的观点是,世界是一个整体,在这个巨大的世界之中,任何事物、任何知识,任何观点,都有其合理、自然的位置。理解这个世界的过程,就是逐步将需要了解的各种事物,在作为整体的一个世界中,找到其位置。了解这个位置的前后左右,相互关系,相互影响。这样的理解世界的学习方式,我认为是最为有效的。对于程序员而言,我推荐阅读《代码大全》,因为这是软件开发的世界地图。
在网络上与人争论,在某一个阶段,能够让人飞速的成长。前提是:任何争论都不要抱着死不认输的心态。但是,在一定的程度以后,网络对人的帮助就不大了。无论是争论,还是网上的文章,大多都是给人一些“点”上的知识,很少能给人以“面”上的知识。零散与不成系统,是网络知识的特点。在工作中,可以拿来应急,但是不适合用于深入的学习。现在写blog的人越来越多,我也订阅了很多的blog,但是,现在我也越来越发觉,这样漫无目的的阅读,容易消耗大量的时间,而且容易令人迷失,往往得不偿失。
总之,成长虽然野蛮,但是的确是一路成长过来了。

    推荐阅读