程序员：脚下的路在何方？一个奋斗者的感受！(转载。。。)

单枪匹马

我是一个可以单枪匹马解决很多问题的程序员，事实上，很多时候我确实是在单枪匹马的工作。

历经中国十几年的“标准”教育，我学会了独立解决问题。在学校里，很多时候协作行为都会被视为不正当的行径而遭到批判，比如考试时候的协作会被称为作弊。掌握了独立思考能力的同时，协作能力一点点的流失着。协作能力的流失往往伴随有自私的产生，我历经千辛万苦解决的问题为什么要告诉你，这可是我值得炫耀的资本啊！个体对面的集体也时常被人忽略，“鹤立鸡群”的感觉可远胜于“共同富裕”。

软件开发的历史几乎就是一部个人英雄主义的连续剧，从Bill Gates到Linus Torvalds，哪个不是可以凭借一己之力就让世界改变的人物。试问，我们这些作为后来者的程序员，哪位心中没有几个用来崇拜的高手，也许差别就是水平越高崇拜的越少罢了。和那些成为追星族的懵懂少年一样，对偶像崇拜带来的常常是对偶像的模仿，有意或无意。对个人英雄的崇拜带来往往是希望自己拥有独立创造一个世界的能力。

校园的氛围鼓励这种“独立”，而真实世界的软件开发更多的需要“协作”，毕竟我们面对的问题已经不是一个人可以在最后期限之前能够解决的。虽然我处在一个需要协作的环境之中，但由于工作分配的原因，我很少与人协同开发，因此，大多数时间里，我依然处于独立工作的状态之中。也正是由于独立工作，锻炼了我解决问题的能力，随着对我解决问题能力的放心，负责人更多让我负责一个单独模块的开发，于是我也就越来越“独”。

近来和几个朋友合作开发一个东西，考虑这几个朋友的实际水平和对目标的了解程度，在前期，需要我带领他们一起来做。和平时一样，我一开始就进入到解决各种疑难杂症的阶段，之后，我会把自己的心得告诉他们。

一天，我问其中的一个朋友，对我讲的东西有什么感觉。出乎我意料的是，他给我的答案并不是关于我所讲解的内容：“我觉得你太累了”。这倒是引起了我的兴趣。他认为，既然是大家合作开发，就应该大家共同来承担责任，现在的情况是我一个抗起了所有担子，而其他人则处于一种比较闲的状态，对于一支团队来说，这绝对是一种不合理的。在目前的状态中，我实际上担当的是一个负责人的角色，应该懂得把工作分配给别人，而不是一力承担，这样会造成累死一个、闲死一群的悲惨结果。

他的话对我打开了一扇门，让我进入到一个完全不同的世界。之前，我从未想过这样的问题。我从未真正承担过负责人，从未考虑过把工作分配给别人，在我原来的视野里，我所遇到的问题都需要我自己解决。经他点拨，我豁然开朗。固然，我相信我可以解决自己遇到的绝大多数问题，但并非所有这些一定要自己来做。

在实际的工作中，我也确实感觉到自己的时间有些不够用，既要设计，又要编码，还要考虑下一步的方向。

从另一方面来看，这种做法也是对同伴的不信任，虽然可能是无意识的。在一支团队中，彼此的信任才能让大家来共同承担责任。对于现在的开发，同伴目前的能力并不足以很好的完成，但如果不给他们足够的机会，他们永远不能达到要求，差距只会越来越大。个人能力也是在开发过程中逐渐提高的。

最终，我决定接纳这个朋友的建议，把自己承担的一部分工作完全交给他们负责，而我则继续向前走，为下一步工作做一些技术上的探索。软件开发并不是一个人的工作，独立解决问题并不等于一切由一个人来做，一个人的小聪明无法与集体智慧媲美。

新的开始

今天是新项目开始的日子，我企盼已久的新开始。 我们项目2.0版从去年年底一直做到今年年中，因为是我第一个担纲设计的项目，我对它有着非同一般的感情。也正是因为是第一个，所以，难免会存在一些不甚理想的地方。之前的1.0版中，我只是覆盖到自己所负责的几个模块，对于系统整体虽然有着一定的了解，但毕竟那不是自己亲历亲为，所能看到的问题非常有限。2.0的设计中，我竭尽所能把我所能看见的1.0中存在的问题一一避免。从后来的实际情况来看，相对于1.0，2.0确实是一个进步，无论是整体结构还是开发方式上。虽然2.0向好的方向迈进了，但由于我缺乏对整体的认识，现在看来2.0系统依然存在着许多让我心痛的问题。对于我们的系统，我心中最大的理想便是开发3.0。 软件行业似乎存在着一个第三个版本才能走向成熟的规律，Windows的火爆是从3.0开始，Unix前面也倒下了两位前辈。由此推算，我们系统的第三个版本还是非常值得期待的。 为了给自己一个新的开始，项目负责人希望给项目起一个新的名字。下午的会上，一个议题就是给项目起名字。早上翻字典的时候，翻到了一个单词“LAMA”（喇嘛），这也是我觉得今天所有名字中最具搞笑意味的。不过，这个名字没有最终入选。入选的名字是“CLAP”（鼓掌），基于这个名字，我做了一次顺水推舟的选择，再下个项目叫“CHEERS”（干杯）。给项目起一个比较有意思的code name可是一个非常不错的开始。 不管名字是什么，在我心中，它依然是我的3.0，我会把2.0中的积累在3.0中释放。除了编写针对3.0的代码之外，这次项目我最大的目标就是形成一个可以从项目中分离出来进行重用的框架结构。在我们部门中，C组有一套比较稳定的开发库，而Java组则一直没有形成很好的复用，所谓的复用更多停留在代码级上。之前的一个同事进行了一定的尝试，只是后来离开了部门，所有的工作便也停止了。 在我看来，通常所说的框架，包括基础库和框架两个部分。基础库可以简化代码的编写工作，而框架则相当定义了一套开发模式。基础库和框架最大区别便在于谁调用谁：基础库通常是我们来调用，而框架则是调用我们的代码。正是因为这样，Martin Fowler才会说是个框架都是IoC，才会为“IoC”改名为Dependency Injection。 这次目标之一便是形成一个这种框架——既包括基础库，也包括框架。框架是不能凭空产生的，因此，我会依托于3.0来产生这个框架，并在开发过程中对其逐步的完善。我曾经在项目组内部提到过一个复用资产生成的过程，其中包括一个孵化过程，借鉴于Apache的Incubator。任何进入准备复用的内容必须经过一段时间的孵化，在代码稳定文档完备之后，才能成为正式的复用内容。 在这次开发过程中，我依然会承担主要的设计工作，不过这次的范围要更大一些，面对的是整个系统，而不仅仅是原来的业务系统。对我而言，这又是一次意义非凡的锻炼。也许经历了这一次的开发，我对软件开发会有一个更加完整的认识。 身体最重要 近来身体不是很好，其实身体不好不是一天两天了，只是从不在意而已。原因很简单，年轻，之前身体一直不错，小病小灾的根本不放在眼里。直到不得不会一会大夫的时候，才发现两年的程序员生活让我失去了许多。 记得刚到公司报到的前几天，一坐一天还真坐得浑身不舒服，没过多久，习惯了，有时坐下都懒得动。因为住在软件园里，出去一趟要花费许多时间，所以，晚上就习惯了在大厅里继续面对电脑，因为与电脑之间有着深厚的感情，所以，每天十几个小时面对它，我丝毫不觉得厌倦。就这样日复一日的坐着，缺乏锻炼，身体的机能也在下降。去年体检的时候，身体已经不是100%健康了，医嘱是多锻炼。我属于不见棺材不落泪的类型，由于没有觉得自己哪里不好，根本没有把医嘱放在眼里。就这样，我依然继续着自己的作息习惯。 去年年底的疯狂编码终于赶在了最后期限之前把项目送上了线，但连续十几天的高强度工作让我的身体明显开始有了反应，后背经常会觉得疼。忙过之后，休息了一段时间，身体的反应没有那么强烈了，加上过年的欢乐，便把这事也就抛到了九霄云外。 说到这，我不得不提一下凳子的问题。读Kent Beck的《敏捷软件开发》时，让我感触最深的并不是测试驱动开发的理念，而是关于凳子的问题（第26章，Cheap Desk, Nice Chair）。我们公司的凳子虽然不是那种硬板的凳子，但是坐起来非常不舒服，怎么靠怎么觉得别扭，坐高了，顶着腰，坐低了，顶着肩胛骨。编码时间长了，难免不习惯性的靠在凳子上，长时间让身体处于一个不舒服的状态，不出毛病才怪。 前一段时间又是一段的忙碌，身体又开始出现了反应。如果不是后来踢球伤了膝盖，我可能都不会去见大夫。 算起来膝盖的伤是七月底的事，距离现在也有三个月了。起初也是不在意，刚刚好了一点，一个同事离职的告别赛，就迫不及待的上场了，结果还没踢五分钟就又伤了，当时逞强，一瘸一拐的踢了半场才下场休息。 以为休息两天就没事了，没想到一拖三个月不见好。一个与我受到类似伤害的同事，伤得时间比我还长，养了一年不见好。前不久，按摩了一个月终于治好了，经他推荐，我终于做出面对大夫的决定。 当咬牙坚持完大夫给我按完膝盖，我想起了自己的后背经常疼的事。经大夫一看，原来腰也出了问题。没办法，有病一勺烩了。 按摩一次三十大洋，加上腰一共六十。这样的日子至少要坚持一个月，算上药钱，一下子就要扔进去两千大洋，这还是往好的方向想了。两千是什么概念？考虑打折因素进去，两百大洋可以买一套《计算机程序设计艺术》，两千可是十套Bible的价格。平时买本几十块的书还要仔细评估一下，这一下子就扔进去两千大洋。哎，花钱容易挣钱难啊！ 经常听人说：“有啥别有病，没啥别没钱”，以前只是对没钱有所感觉，现在知道了有病的痛苦。有钱给自己买点东西好不好，给大夫送去真是觉得心不甘情不愿。 身体是革命的本钱，谁愿意做蚀本的生意呢？这话说起来容易，我们这种程序员解决起问题来，一高兴经常是记不起还有身体这么回事。谁没有连续几个小时斗一个bug的经历？谁没有连续几个小时编码的疯狂？谁没有后半夜战斗甚至到清晨的历史？ 如果你和我一样是个程序员，看到这里时已经在坐了有一段时间了，那么，请站起来活动活动。身体最重要，不是吗？ 梦想归来 距离上一篇的blog已有两月有余，如果除去那两篇“转载”自己的文章，这个时间大概已近两个半月。这是自我成为blogger之后，离开blog最长的一段时间。其间，许多关心“梦想风暴”的朋友问我，怎么不见你有新的blog，我的回答再通俗不过，“忙”！这是一个几乎可以搪塞一切的最佳接口，我也不能免俗。 这两个多月的时间里面，发生了许多事。 远在天边的有，从无人问津到万人空巷的亚洲杯，让无数中国人扬眉吐气的奥运会，令中国计算机人振奋的MD5破解…… 近在眼前的有，我学习了Web开发的基本技术，第一次走上讲台真正给别人当老师，我们的产品经历了几个月的进化终于结项…… 这期间，脑子冒出过各种各样的奇怪想法。想法，有如流星，若未能及时的记录下来，便也烟消云散了。这个时候，我最想念的便是我的“梦想风暴”。blog已经成为我生命中的一部分，每每思维激荡，我的第一个想法便是，这是一个不错的话题，我可以再写一篇blog。没有blog的日子里，生活中少了许多乐趣，没能及时对自己总结，让我总有虚度光阴的遗憾。在这段日子里，我却没有忘却为blog做做广告。与人聊天之时，常常将blog作为一种对行为进行记录的最佳实践推荐给别人，虽然收效甚微，但我依然乐此不疲。 软件开发中最困难的是什么？在我看来，不是技术，不是过程，而是坚持。激情的开始不等于顺利的完工，程序写到一半，解决了最初的技术难题，剩下的只是无边无际的纯粹编码了，失去了激情动力的时候，最需要的就是坚持。半途而废的人很难成为好的程序员。记忆中，除了学习和编程，blog是我为数不多愿意坚持东西，我可不愿轻言放弃。 “梦想风暴”回来了！ 今后的日子，希望可以继续在这条我这个小程序员信口开出的“河”中，与朋友们分享我的快乐！ 项目坚壳 项目伊始，来自五湖四海的兄弟姐妹为了一个共同的目标走到了一起。正常情况下，一个项目组很难从始至终由同一批人完成，对于项目组成员的进进出出，大家也就习以为常了。如果这是一个有生命力的项目，随着项目一天天的进行，一群所谓的“项目主力”逐渐露出水面，虽然项目组的其他人有如走马灯一样，来了又去，但这些项目主力基本上如果不是自己提出，领导不会选择让他们进入走马换将的行列。项目主力稳定的存在于一个项目之中，彼此之间的交流和协作给了他们一种难得的默契，一个眼神，一个动作，几个词语，无需完全的表达，大家便已心领神会。正是这种默契，使得项目组成员之间的交流省去了不少的麻烦，也正是这种默契，无形之中形成了一种坚硬的外壳。对于任何新加入项目的成员，如果不能打破这层坚硬的外壳，他便只能徘徊在项目之外，无法真正融入项目之中。 我们项目从去年年初开始，人员不停进进出出，算起来，在项目里面挂过名的也有几十号人了。到现在，在项目早期进入项目而一直坚持下来的，总共有三个人：负责管理系统的开发的项目负责人和我，负责管理系统开发的一个兄弟。 现在参与业务系统开发的第三个人是去年年中加入到项目组里来的，最初负责测试，直到年底，2.0系统的开发，他才正式加入了开发业务系统的行列。私下里的聊天，他对我说，自己最初进入业务系统开发时遇到了种种困难：项目文档不完整、对项目理解很浅薄、开发工作不明确……当时，我确实没有意识到这些问题的存在，因为对我来说，一切都很清楚，我和负责人讨论项目中遇到的问题很容易，因为彼此心知肚明。但这一切，对于刚刚加入到我们行列中的这个兄弟，没有那么简单，我们的话对他来说，可能像天书一般，因为没人告诉他应该知道的一切。 不过，他总算是苦尽甘来，融入到项目组之中，而另外的一位就没那么幸运了。 也是去年年底，鉴于管理系统只有一个人苦撑，而新需求又压了下来，一个同事进入到项目组中，加入到管理系统的开发队伍中。前前后后，他在我们项目组里干了半年。遗憾的是，他最终没能融入到项目组之中。 由于对管理系统不是很熟悉，分配任务的时候，负责人常常会把管理系统相关的内容交给负责管理系统的那个同事那里，对于这位新同事的任务，顶多也只能布置一个大概，他期望的是负责管理系统的同事可以把工作更好的布置下去。不过，这种想法并没有得到充分的交流，而那位同事只是管理系统的开发人员，而没有真正的“官衔”顶在头上，所以，他没有义务去完成“负责”工作。这样造成的结果是，这个新同事往往是很长一段时间不知道自己该干什么，常常是工期临近的时候，才猛然发现自己居然有这么多东西要做。终于，在一次项目组会议中，他爆发了。 现在，他离开了我们项目组，换到了其它的项目组。 在这里讨论人们之间的对错是非没有任何意义，发现问题之后，我们需要的是解决问题。俗话说：“一个巴掌拍不响”，有了问题通常是双方做得都不甚理想。 不知是幸还是不幸，迄今为止，我从未半路加入一个项目之中，我总是清楚项目组中一切的来龙去脉，于是，我暂时还没有机会与那层坚硬的外壳正面交锋。 或许，以我的经历而言，讨论如何打破坚壳有些站着说话不腰疼，不过，既然我无法保证以后自己不能半路出家，能以人为鉴，又何乐不为呢？让问题消弭于无形之中，总比自己碰得头破血流要好。作为现在的壳内人员，如何帮助新成员打破坚壳，也是个有趣的问题。 我的那个同事为什么不能很好的融入项目组之中呢？前面说过的交流问题固然是一个原因，对项目的不甚了解也是重要原因。对其他人来说，基于对项目的了解，即便负责人没有做好工作的分配，大多数情况下，我们也知道自己该干什么，知道那有问题需要自己去处理。而这个同事做不到，他根本不知道项目进行到什么程度，哪是他可以自由发挥的。我们项目的文档工作完成的并不理想，这位同事无法通过文档对项目有一个完整的人士。不过，话又说回来，即便有完整的文档，以我们这里文档的质量，读了之后有多大帮助谁又能知道呢？这其中牵扯到了“不但要有文档，而且文档要有效”，这不是这次的话题，让我们暂时忽略它。 这个同事和我聊天的时候，也曾希望对项目有个完整的认识。他的想法很好，不过，他更多的时候是在期待别人把知识送过来，而不是主动的获取。基于我们的现实情况，项目的一切，大多数时候靠的彼此之间言传身教在大家之间传递。因此，交流是必不可少的。在一个新成员进到项目组中，我们会把项目的一个概况告诉他，对于一个希望对项目有个大概认识的人来说，这就已经够了，但作为开发者，这只是一个入口点，真正工作会要求我们尽可能了解一切的细节。作为项目组的“老”成员，那些细节是埋藏在大脑深处，没有人问起的时候，它们基本上不会主动走出来，缺省情况下，“老”成员会认为这些东西大家都知道。因此，如果想了解尽可能多的细节，只有靠新成员自己去发掘。 我的这个同事本身就是一个非常内向的人，他很少主动和别人交流，我们脑子的这些东西始终无法传递给他，他的大脑中就无法形成一个完整的项目视图，而在他看来，是我们这些人不主动把信息告诉他，这样造成的结果就是，在我们无知无畏的时候，他却感到非常的不舒服。最后对于任务分配理解的差异只是让他这个前期积累爆发的一个导火索。 写到这里，我突然觉得，虽然我们可以鼓励项目组完成更好的文档，项目组其他成员应该多多与新成员交流，但归根结底，要想融入一个项目组，更多的还是要靠新成员自己的努力。毕竟大多数情况下，我们无法改变环境，而只能去适应环境。