去年12月份，和Pluskid、Quark以及马铃鼠一起合租了DreamHost的虚拟主机。然而付款的过程却极其地蜿蜒曲折，在被我无能地拖沓了漫长的整整一个季度后，借助远在美国本土的Victor同学的帮助，终于以支票支付的方式艰难地画上了句点。于是也就有了liancheng.info这个域名以及这个blog。啊……在此向Kid和Quark谢罪 :-(

2008年是本命年。迷信说本命年会发生很多不顺的事情，是韬光养晦的年份。这一年确实碰到了很多非常有挑战的事件，在此一件件总结一下：

跳槽前的挣扎

这件事严格来说是从07年下半年开始，到08年初结束的。从网易杭研院跳槽到百度，其实07年10月就已经是板上钉钉的事情。但是却一直到08年2月才正式离职。之所以拖了这么久，原因是在于想尝试着推动几件事情，以尽力改变一些当时所面临的，同时也是促使我不得不选择跳槽的负面（技术）问题：

• 在开发人员和测试人员比例严重失调的情况下代码质量低下；
• 拿Java当作带GC的C++，完全无视Java开源社区的丰富资源、开发工具以及开发方法学的辅助作用；
• 代码风格混乱、可重用性差、可测性差、可维护性差；
• 文档严重缺失，导致在人员流动性高的情况下，新人难以快速接手遗留任务，青黄不接；
• 版本管理不规范。

---

在加入网易之前，我并没有什么实际的项目工程经验，然而在浙大MSTC的社团活动组织经验以及在这个家一般的优秀团队中的合作经验却给了我莫大的帮助。起初只是觉得碰到很多让人不爽的事情。摸爬滚打了一段时间之后，逐渐意识到了问题所在。其实根本原因还是在于管理层面，在此也就按下不表了。作为一个一线的研发人员，无力撼动其根本，于是也就只能在技术层面尽量地去做一些改良，以期能在阻止情形进一步恶化的同时让更多人意识到问题所在。

当时的局面很不理想，一方面存在管理上的原因；另一方面，保守的思想观念以及恶劣的习惯也造成了极大的障碍：即使大家知道这样是错误的，也知道怎样是正确的，却也没有改正的动力。

我当时的想法很简单：尽力而为。离职的意向已经跟经理表明，没有什么心理负担，能做成做好，做不成也没有什么遗憾。加之我当时所负责的工作相对繁杂，交接过程很长。不妨就在这段时间内去尝试推行一些我认为是正确的做法。

其实在决定干这件事情之前，我也已经花了大半年的时间来准备。我原本并不是一个熟练的Java程序员，但做完这些准备工作之后，这门语言已经用得相当顺手了。当时入手的方面有如下几条：

• Java开源社区成熟组件的应用：
  • 使用Apache MINA替代土制山寨版NIO网络框架
  • 使用JMX + Cacti完成服务监控、运营数据采集和数据可视化
  • 使用Spring在保证低耦合的前提下完成应用组装
  • 使用iBatis替代土制山寨版DAO框架
  • 使用OpenLDAP完成集群配置的集中管理
• 因地制宜地推行敏捷开发方法
  • 极力澄清“重构”与“重写”的区别（似乎国内的很多公司都有这样的误区，拿重写当重构），借助IDE（eclipse）快速重构
  • 基于JUnit、DbUnit的单元测试
  • 规范基于SVN的SCM
  • 推行Trac
  • 基于Maven2的项目规范化组织和基于Maven2 + Continuum的持续集成
• 借助binghe同学超群的系统管理技术尽量将开发层面的复杂度降解至系统管理层面：
  • 借助Linux HA Heartbeat解决单点可靠性问题
  • 借助cfengine + SVN完成集群配置的自动分发和版本管理

划掉的四条最终很可惜没能完成。尤其是最后两条，甚至没能来得及做深入的了解，尤为可惜。由于当时除了承担一部分服务器项目的研发工作以外，还负责一整套旧版本服务器集群的运维工作，实际上成了半个SA。于是，既出于工作需要，也出于兴趣，我经常会泡在SA的办公室里向binghe他们几个SA兄弟讨教系统管理技术。在binghe的熏陶之下，我逐渐深刻地认识到：优秀的系统管理工具和技术不仅可以大大简化大型服务器集群的日常运维，在化解研发复杂度方面，往往也可以出奇兵奇效。而Heartbeat和cfengine，正是杭研院SA的两大利器。只可惜我所负责的集群，跑的都是极老的FreeBSD 4.x，当时FreeBSD官方已经停止维护，想装个软件都得满互联网找上大半天。出于服务稳定性和风险考虑，最终还是没能深入实践一下。

所幸对于其他各个条目都有所斩获。我按照手头掌握的工具和方法重写了之前负责的一个模块，在可重用性、可测性、代码可维护性、服务可维护性、模块耦合性、持续集成等方面都有了明显的收效。在做完所有这些之后，我开始拿这个项目为模板，向周围的同事逐个“传教”。在这期间，针对不同的人，我也总结了不同的游说方法：

• 对于观念开放和激进的人，比较好办。只要稍加推荐，他们便会主动地去尝试。当他们发现这些工具和方法确实行之有效时，便自然而然的接受了。
• 对于观念保守的人，在他们碰到头大的问题的时候杀入，尝试向他们介绍在正确的工具和方法的帮助下，如何轻松地化解这些问题。有了亲身体会，便可以相对容易地让他们从心理上接受这些新的工具和方法。
• 对于经理，除了要向其阐明利害关系，最重要的是给出从当前情况逐步迁移到理想情况的循序渐进方案。

不可忽视的一点是：在技术性团体里，做永远比说要来的有效。在想法成熟之前就贸然游说，往往会招致相反的效果。大家都是工程师，不会贸然接纳陌生事物。如果自己都还没有想清楚就开始大肆游说，往往会被大家提出的实际的工程问题驳斥地体无完肤。当你哑口无言之时，大家也已经对你的方案产生了难以磨灭的“不靠谱”的第一印象，这时要再想咸鱼翻身，可就没那么容易了。

相对的，首先自行查阅文档资料并进行试验，制作demo，通过试验发现和解决实际出现的问题。在想法基本成型时，和个别观念开放的同仁进行探讨，这时往往可以发现大量之前自己没有考虑到的问题，再转而细化方案。这个过程反复迭代几次之后，方案和demo逐渐成熟，同时也潜移默化地达到了传教的目的。等到方案完全成熟之后，再拿出实际可工作的demo开始游说，这时自然就成竹在胸了。

好吧，我承认，当时我就是抱着以上这些的想法在做这件事情的。然而，最终还是没能把整件事情做成。原因是我忽视了两件事。

第一件事，是习惯。鲁迅大叔不是说过么，中国的惯性太大，挪个桌子都要流血。加上当时的杭研院还缺乏绩效考核机制，能够在原来的基础上完成工作就不错了。即便是大家都说好，也还是难以改变大家长久以来养成的习惯。实际表明，仅仅是把eclipse从3.1升级到3.2，也是让人难以忍受的。

第二件事，是学习成本。在紧张的工作进度压力下，原本就没有多少人把精力投入到技术、方法改良方面。自己去学习和摸索各种工具和方法，和让团队中的每个人都掌握这些工具和方法，完全是两回事。授人于渔也不是谁都能轻易做到的呀……

最终，到我离职时为止，虽然我所尝试推行的方法和工具都得到了认可，但最终残留下来的只有：

• 基于Maven2的项目组织方法和自动构建
• 基于JMX + Cacti实现的服务监控和数据可视化系统。
• 基于Continuum的持续集成服务还半死不活的跑着，但是已经无人问津
• 一套被荒废的Trac

这件事情给我带来了相当大的冲击，同时也学习到了大量技术方面和非技术方面的知识。所谓团队合作，如果仅仅只是默契地配合他人，那么只能算是个合格的团队成员。要称得上优秀，同时也必须要能够在团队陷入错误时大声地喊出来，并且以实事求是的态度给出可行的解决方案，同时还要能够随机应变、因地制宜，切实地将方案贯彻下去。

尽管在网易时碰到了很多不如意的事情和现象，让我抱怨多多；但是回想起来，作为我所就职的第一个公司，它带给我的更多的是极其广阔的学习机会，无论是技术方面还是非技术方面。所幸，我也没有荒废这大好的机会。