时间过得很快,距离加入厝边已经两年有余。期间也确实有过几次离开的念头,唯独这次告别的决定来得太突然、太莫名,以至自己都不能对选择离开厝边的理由说出个所以然。
回想之前几次打算离开厝边,大都源于身边人对自己工作的不认可,这些我都能找到理由说服自己留下来。而这一次不同以往。
感觉自己是一个不善于描述现状的人—— 曾经多次试图分析处境,事后看来都与当时实际情况有所偏差。 所以现在感觉视野不足以看清当前所处环境时,会倾向于用时间来换取视野。

离职前的工作交接主要分两个方面:

一是自己主要负责的JS部分——考虑到短期内较难找到接手的人选,目前在做的是文档化现有代码;
第二部分是服务器管理工作的交接——之前是因为团队中没有专门设立运维的角色,而自己有着网站架设经历以及网络工程专业的背景,所以服务器环境搭建和管理一直由我负责。考虑到厝边网功能扩展伴随的业务逻辑复杂化,后端对服务器功能组件定制需求也会增加,故将服务器管理工作交接给PHPer 平辉,这一决定也事先获得老大的认可。

至于离职时间节点的选择,可以说这不是仅基于个人利益最大化的考量而做出的选择。
一方面,年前开始的活动也开发已接近尾声,而新的项目还在筹划阶段。承前启后之时,工作量较轻,减少新项目对交接工作的参杂;
厝边技术团队近一年多来一直稳定在“前前后后”【两个前端两个后端】的四人团队规格,每个人的分工也相对明确,按理说是一个低巴士因子的项目。得益于团队成员对项目整体把握和开发框架、流程的熟悉,而小团队背景也已将大家历练成能够独当一面的多面手。在我病假一周的时间里,除了一些增强效果的实现,活动页的开发整体进度几乎未受影响,熊熊和平辉的表现尤其让我印象深刻。这种情况下离开厝边,也许团队会暂时面临一些困难,但相信这也只是让团队能够走得更好的一次历练;

最初选用Mootools 作为项目基础类库,考虑的是模块可扩展性问题。《Pro JavaScript with MooTools》一书对Mootools 的Class 和Type 概念做了重点介绍,其中Class 的代码组织方式让我印象深刻。 合理利用MT的类继承机制(Extends 和Implements) 可以实现代码高复用, 让我们开发的模块符合开闭原则, 从而后期扩展模块功能时不直接修改前期开发的、可能已在使用的模块。
比如厝边弹窗组件, 最初的需求只是取代iWebSNS 系统本身的弹窗(zDialog、浏览器原生弹窗混搭 :P),只要开发警告弹窗(alert)和确认弹窗(confirm)两种。而到了后期, 尤其是活动页、专题页出来以后, 对弹窗组件的定制性要求越来越高, 产生了登录弹窗、定时关闭弹窗等新的需求, 不同的样式、按钮数、按钮功能的组合可能导致开发工作和代码量难以控制。而通过MT的类 继承机制,我们只是对LightFace 根据具体功能需求进行相应的扩展就能满足需求, 避免了重复开发的工作。更保证了全站UI 和操作的一致性。

厝边讲堂是大家分享知识的例行周会,分享的内容可以是自己感兴趣的或擅长的领域。 由于所有人都参与, 大部分听讲的并不具备你专业的知识, 所以分享内容不能太深入本专业, 以确保所有人都能从中有所收获。还记得自己第一次分享主题数《自行车》那以后除了乔乔和老大,全体技术男都改骑车上班, 二逼杰居然入手和我同款 连颜色都一样的自行车, 被老大戏称“情侣车”, 囧…
微微教我们设计中的“色”, 糖糖带领大家探讨文学中的情,熊熊大侃NBA,小杰杰分享的军事知识, 老大分享的正体字简体字,舒雯讲了F1商业模式和感冒, 啊舟分享的心理学都让我收获良多。 哦,还有平辉现身说法讲了结婚手续神马神马。。

厝边团队是一个优秀、有爱的集体,很遗憾由于个人原因不能和各位一起走到最后。我相信厝边在各位的努力之下一定会有很好的前景,你们有朝气、有热情、更踏实、更努力… 从各位身上我能看到太多太多自己不具备的优秀的特质,更重要的是你们有一个有理想、敢追求的老大。

期待大家接下来的精彩表现。

写于异年同日:

  1. 2010:  几个新兴领域的维权方式(8)
  2. 2010:  《然后,就没有然后了》全集(9)