时间过得很快，距离加入厝边已经两年有余。期间也确实有过几次离开的念头，唯独这次告别的决定来得太突然、太莫名，以至自己都不能对选择离开厝边的理由说出个所以然。
回想之前几次打算离开厝边，大都源于身边人对自己工作的不认可，这些我都能找到理由说服自己留下来。而这一次不同以往。
感觉自己是一个不善于描述现状的人—— 曾经多次试图分析处境，事后看来都与当时实际情况有所偏差。 所以现在感觉视野不足以看清当前所处环境时，会倾向于用时间来换取视野。
离职前的工作交接主要分两个方面：
一是自己主要负责的JS部分——考虑到短期内较难找到接手的人选，目前在做的是文档化现有代码；
第二部分是服务器管理工作的交接——之前是因为团队中没有专门设立运维的角色，而自己有着网站架设经历以及网络工程专业的背景，所以服务器环境搭建和管理一直由我负责。考虑到厝边网功能扩展伴随的业务逻辑复杂化，后端对服务器功能组件定制需求也会增加，故将服务器管理工作交接给PHPer 平辉，这一决定也事先获得老大的认可。
至于离职时间节点的选择，可以说这不是仅基于个人利益最大化的考量而做出的选择。
一方面，年前开始的活动也开发已接近尾声，而新的项目还在筹划阶段。承前启后之时，工作量较轻，减少新项目对交接工作的参杂；
厝边技术团队近一年多来一直稳定在“前前后后”【两个前端两个后端】的四人团队规格，每个人的分工也相对明确，按理说是一个低巴士因子的项目。得益于团队成员对项目整体把握和开发框架、流程的熟悉，而小团队背景也已将大家历练成能够独当一面的多面手。在我病假一周的时间里，除了一些增强效果的实现，活动页的开发整体进度几乎未受影响，熊熊和平辉的表现尤其让我印象深刻。这种情况下离开厝边，也许团队会暂时面临一些困难，但相信这也只是让团队能够走得更好的一次历练；
最初选用Mootools 作为项目基础类库，考虑的是模块可扩展性问题。《Pro JavaScript with MooTools》一书对Mootools 的Class 和Type 概念做了重点介绍，其中Class 的代码组织方式让我印象深刻。 合理利用MT的类继承机制（Extends 和Implements） 可以实现代码高复用， 让我们开发的模块符合开闭原则， 从而后期扩展模块功能时不直接修改前期开发的、可能已在使用的模块。
比如厝边弹窗组件， 最初的需求只是取代iWebSNS 系统本身的弹窗（zDialog、浏览器原生弹窗混搭 :P），只要开发警告弹窗（alert）和确认弹窗（confirm）两种。而到了后期， 尤其是活动页、专题页出来以后， 对弹窗组件的定制性要求越来越高， 产生了登录弹窗、定时关闭弹窗等新的需求， 不同的样式、按钮数、按钮功能的组合可能导致开发工作和代码量难以控制。而通过MT的类 继承机制，我们只是对LightFace 根据具体功能需求进行相应的扩展就能满足需求， 避免了重复开发的工作。更保证了全站UI 和操作的一致性。
厝边讲堂是大家分享知识的例行周会，分享的内容可以是自己感兴趣的或擅长的领域。 由于所有人都参与， 大部分听讲的并不具备你专业的知识， 所以分享内容不能太深入本专业， 以确保所有人都能从中有所收获。还记得自己第一次分享主题数《自行车》那以后除了乔乔和老大，全体技术男都改骑车上班， 二逼杰居然入手和我同款 连颜色都一样的自行车， 被老大戏称“情侣车”， 囧…
微微教我们设计中的“色”， 糖糖带领大家探讨文学中的情，熊熊大侃NBA，小杰杰分享的军事知识， 老大分享的正体字简体字，舒雯讲了F1商业模式和感冒， 啊舟分享的心理学都让我收获良多。 哦，还有平辉现身说法讲了结婚手续神马神马。。
厝边团队是一个优秀、有爱的集体，很遗憾由于个人原因不能和各位一起走到最后。我相信厝边在各位的努力之下一定会有很好的前景，你们有朝气、有热情、更踏实、更努力… 从各位身上我能看到太多太多自己不具备的优秀的特质，更重要的是你们有一个有理想、敢追求的老大。
期待大家接下来的精彩表现。
