满月纪念篇

满月纪念（流水账）

                               --- 从简单的事情中寻找机会

今天是儿子满五个月纪念日，也是我新起点满月纪念日。儿子在老婆、丈母娘和岳父等各位大人的悉心照顾下，一天一个样，越来出 越招人喜欢了，精神倍儿 好，胖乎乎，肉墩墩，嗓子贼亮，非常感激你们在谦谦身上辛勤付 ；同时我在新的环境中也收获蛮多，在这里你们汇报一下（虽然知道你们不会到iteye 上， 也不会看到这些内容）。

 

报到第一天恰巧部门搬家，从理想到朔黄，不到一百米的距离，暗示我和大家同时面临新的环境。

入职的一张表格中写明了实习期将精力的阶段，以及每个阶段阶段的职责，虽然我知道很多公司这些内容都是糊弄新员工的，真正面对的职责可能千差万别，不过我还是将它拍到了手机里。暗示自己：我能够做到得远比这里要求的多得多。

入 职后，距离春节也就不远了，团队内新的研发任务也不是很多。刚好赶上12306 网站人气爆棚，组内也组织了专题讨论。我负责整理了需求，并参与了组内技术 方案的整理（具体的内容就不在这里掰扯了）。通过这个案例，我看到了解决方案公司和互联网公司做事的差异，也对部门的文化印象深刻。

团队文化：重视每个工程师的发言权

为了避免某些成员的被淹没在辩论之中，所有的人将自己方案写在纸上（15 分钟）。

所有的人被划分到3 个团队，每个团队的leader 带领成员进行讨论，并形成团队的方案。

每个小组选一个人进行方案讲解，讲解分自主讲解和观众提问两个环节，最终由评委会进行打分。

 

技术方案：重视技术环节

个人资深的解决方案从业背景，对企业解决方案的架构设计已经有一套方法论。在小组PK 时，我感觉自己对互联网行业架构需求（Features ）把握方案还不够深入，对架构的基础设施内容掌握也不够，不过也发现小组讨论会很快进入细节技术点的讨论，而忽略的方案的完整性。

能够正确认识自己的优势和不足，我对自己充满了信心。期待补充自己技术方面的不足，并在系统化思维和方案展示方面继续深造。

 

第一个任务：入门熟悉系统接口

从看文档开始，熟悉每个接口的调用形式；熟悉开放平台认证方式OAuth1 、OAuth2 ；

这 个过程中做了一个App 的Demo ，熟悉了Java 版本SDK 包，注意调用了一下接口，对OAuth 的调用流程印象更加深刻了。这个时候，我发现很难对接 口有更深一层次的认识了，因为这个Demo 应用没有业务逻辑的驱动，也不能受到大众的欢迎（这个也不是我开发它的主要目的）。我对导师提出：想做一款接口 测试的App ，对接口进行回归测试。既然这个Demo 已经可以调用每个接口，自动化回归一下也是举手之劳。因此也就有了我的第二个任务。

 

通过对OAuth1 的理解，发现国内大多数OAuth1 的文档都是转自我们的开发平台（毕竟我们做得比较早），但一个细节跟国外网站的解释有点出入，见下图

 

参考：

http://hueniverse.com/oauth/guide/workflow/

http://zh.wikipedia.org/wiki/OAuth

 

第二个任务：回环测试

系统接口的回环测试，这也是自动化部署中一个重要的环节。熟悉了Node.js ，从JavaScript 开始，运行一下Helloworld 程序，开始看回环测试工程源码。也学习到Node 的不少用法，尤其是对js 函数的运用（函数也可以作为参数传递，因为所有的东西都对象）。认真看了Node.js 官方文档中的几个包Http\Event\ Globals ，掌握这几个包后再看工程源码中感觉非常轻松，在现有工程基础上（复用他人的代码是一种好习惯）完成了一个回环测试的例子。

同时也发现，当前的工程虽然很好地满足了回环测试本身的工作，但基于Node 的Callback 机制导致单元测试中逐层（N 层）callback ，对于需要在一个点上等待多个结果的事情并没有考虑，而且为了等待上一个操作的结果，有时需要为操作设置延迟执行时间（setTimeOut ，并不是超时时间；而且Node 明确表明对时间不提供精确的保证），会影响到整个测试工程的时间周期，怎么解决呢？朴灵在InfoQ 上一篇文章给出的答案，决定引入EventProxy 包。

后来一个机会，线上回环测试偶尔会包错误，但又不是经常出现，不好分析问题在哪里。经讨论，在线上回环测试中输出的更详细的日志，在一次测试时终于捕获了异常，并最终定位了问题（随后很快解决）。这算是一个意外的收获吧，也是我参与解决的第一个线上问题。

参考：

http://nodejs.org/docs/latest/api/index.html

http://www.infoq.com/cn/articles/tyq-nodejs-event

 

 

第三个任务：开发接口服务

开始接触到业务层代码，也有机会恶补一下 Java web 开发方面的基础知识（ Spring 、 Jersey 、 Java 注解），刚开始看源代码也不得其径，遇到看不明白的就 Baidu/Google 一下，磕磕绊绊看了一些；终于利用周末一个上午在中关村图书大厦看了《 Java-web 21 天》，对 Spring 、 Hibernate 有了比较系统的了解，结合对 Jersey 的理解，才逐渐对能够看懂工程的源码，这方面还需要继续加强。

然后进入计数器服务，逐渐接触到我熟悉的后台服务 Redis/Cache/Storage ，这部分代码的阅读较快，不过学习到不少内容，同时看到自己的差距。

 

顺带一点项目管理的东西吧，不管在哪里做开发都绕不过项目管理的基本要素（时间 - 成本 - 进度）。这个接口需求发生了比较大的变更，为了不影响正常的上线安排，明天可能需要加班做一些工作了。教训：任何情况下，不要把自己仅仅当做任务的执行者，既然由你来做，你就要了解任务的来龙去脉，清楚相关的干系人，做好优先级权衡，协调资源，做到提前沟通，从而顺利按期完成项目。

 

参考：

《 21 天学通 JavaWeb 开发》

http://www.ibm.com/developerworks/cn/web/wa-aj-tomcat/

每天跟儿子视频聊天感觉很好，他比我更渴望成长，长得更快，向儿子学习。

 

欢迎微博交流，个人微博地址：http://weibo.com/tuyu2wangzhiguo