转：我的野蛮成长

因为博文视点的周筠老师约稿，我就写了这么一篇，一时没有收住，写得多了点，先发出来吧。

小学五年级的时候，我第一次接触到了计算机，到现在，已经23年了！
和许多许多人一样，从10岁那年起，我就确信，计算机，是我的最爱！（当然，老婆、孩子、家里人除外！）

因为我的个性以及各种偶然的因素，我的成长那是相当的野蛮，不合常规、不守规矩、不走寻常路，
现在回头看来，那些令人难忘的熬夜加班、纠缠于技术难点导致的彻夜难眠、在公司里与人争到面红耳赤、在BBS上与人唇枪舌剑，就是我成长的方式。

很难说能够给读者什么启示，只能说作为一些小故事和一些零散的思考，也许还是挺有意思的。

一、1986~1993：大学之前
１、吸引力
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，但是，现在我也越来越发觉，这样漫无目的的阅读，容易消耗大量的时间，而且容易令人迷失，往往得不偿失。
总之，成长虽然野蛮，但是的确是一路成长过来了。