我的工作经历 --Boxnearby

logo：

地址：

南京集庆门大街苏宁慧谷 B8-605

工作时间：

从一开始的想去就去到最后的巴不得天天在公司

工作职位：

2016.5~2016.9.20：IOS 工程师

2016.9.20~至今：乾智嘉项目经理

2016.11.10~至今：Bxxx 架构师兼乾智嘉项目经理（涉及到项目私密，所以暂用 Bxxx 代替）

工作经历：

怎么说呢，很感谢这份工作对我的培养，这是我最想说的话，至于工作经历分为三部分来说吧：

1.IOS 工程师

那个时候，我刚刚参加完阿里天池的一个比赛，记得名次好像是 150/5000 的样子，至于原因，可能当时心里只是想着通过这个项目上手大蟒蛇吧，然后写完几个爬虫，一个爬迅雷会员的，一个爬某知名博主的文章总结为 PDF 版本，然后就觉得想自己写 app，然后就浑浑噩噩的买了一个二手的 MacBook，25 块钱的淘宝 IOS 教程，学了一个月，那时候我还是在用 Object-C，深知学习一门语言，目的才是最好的驱动，于是我就写了自己博客的浏览器，现在回头想想，其实就是调用了个 UIWeb。

上面说的都是前提，也就是在 2016.4 月初的时候，我一个 2 战考研失利的朋友选择走上工作岗位，也就是这边的乾智嘉，巧的是，这家公司刚刚接了一个海外的项目，更加巧的是，这家公司没有 IOS 开发人员，而最巧的是，公司当时的负责人对新人不排斥，所以也被我这烂的掉渣的 IOS 初学者混进公司了。

以上，我以为我很幸运，我万万没想到，这份工作对于我这种 IOS 半吊子是一个巨大的考验，具体原因是：

1.整个 IOS 开发组就我一个人

2.没有师傅带我

3.这个项目不仅有我根本就没接触过的网络请求，还有蓝牙模块，跟这边的硬件设备交互

4.开发周期只有三个月

5.语言要求 swift

当时知道这些消息的时候，我有点不知所措，到现在看来，压力有的时候不见得不是一件好事，正是因为这些压力，我才走到现在。

项目刚刚布置下来的时候，简直就是在考验我的想象能力，因为所谓的要求，就是没有要求，简单的说了一下有几个界面，然后剩下的就是我自由发挥。当时的我简直懵了，还好，后来，甲方的人似乎察觉到不能任由我自由发挥，就让这边的美工做了几个效果图，通过了他们的确认后，然后才算正式的开工了，那时候因为作为兼职这边工资不是很理想，所以身兼数职，同时也在创思特和小状元任职以及攻读我的硕士学位，万幸的是这几份工作之间并没有时间上的冲突。

第一个 app 的名字是 Bxxx，我在写这个简历的时候还没有上线，不过等到 HR 看见这个简历的时候应该是上线了，具体过程就不多赘述了，主要难点是与后台人员的对接与蓝牙模块的编写，写后台的是我那个二战未果的盆友，后台能力也是半吊子，所以对接总是会出现很多的问题，现在想来倒也庆幸，至少让我知道了这些问题的解决方式。而蓝牙模块的对接简直就是纸老虎，因为之前没有涉及过与硬件对接，所以我觉得应该很难，事实证明，有一个高效的伙伴，这些问题只是坐下来调试几次的问题，在这里感谢在我心目中是一位大神的长辈，杨总，一位近 45 的互联网长辈，他对我的指导很关键。

这个项目进行到 8 月中旬的时候，甲方派人从美国那边过来了，因为我手头上的工作基本都完成了，所以有时间跟甲方负责人对接了，这个时候，我之前培养的交流能力体现出作用了，我把甲方的人哄的很开心，当然这些开心都是建立在我项目完美完成的基础上。通过那时候的交流，我才知道我们项目后面的靠山是前荣耀掌门人刘江峰。甲方负责人（jenny）是一个 40+ 的一位很有气质的华裔 Lady，正是那时候的交流以及后续的一些任务的主动承担，也导致了后来的这整个项目由我负责，当然提升能力的同时也承担了很多的压力。

回头想想，Jenny 对我的信任产生应该是在我决定了第一块核心业务的提供商那个时候。因为我们这个系统主要是想通过智能快递打入美国那边的社区，把握住社区授权，所以，需要一家第三方服务商给我们提供可靠的快递服务。这是核心业务，本来这事跟我没有关系，但因为这个需求产生的时候正好是 Jenny 8 月中旬过来的时候，出于某些我也不知道的原因，jenny 他们高层开会的时候总会带上我，而在某次会议的时候，他们说了这个业务，并当场思考准备怎么办，结果是，需要把这个业务需求提交给甲方公司的架构师（David），于是当时立即就语音链接那边的架构师（一位资深的美国华为的 Leader，在 Bxxx 挂职），那边的架构师就问，跟我们这边谁对接，jenny 选择了我，因为当时就我，我们公司老板还有杨总，我答应下了。回去之后几乎一个晚上将海外那边提供这个业务的公司都测试了一遍，让后轻描淡写的写了一份报告发给 David，可能当时因为 David 那边业务也挺忙的，他就让我从中选一个出来，我选择了 Easypost 这家服务提供商，也就是现在我们系统使用的，当然过程总是曲折的，David 在得到我选择的时候，不知道出于什么原因拒绝了，而是选用了三家原服务商的并不是很稳定的服务（因为我们快递业务暂时只做 UPS，USPS，Fedex）。因为 jenny 要求我所有跟 David 的邮件交流都要 cc 她一份，所以我们两个的选择也被她知道了，最后 jenny 还是选择了我的结果，因为 Easypost 提供打印 label 的服务，也正是这边对接基本由我负责，也导致了 jenny 开始要求我负责这个项目整体。

而遇到难题是出现在整个项目第二块核心功能上。因为第二块核心功能涉及到付款，所以那边也显得极其重视，不过这时候矛盾就产生了，因为当时项目之前要求是圣诞节上线，但是 jenny 在圣诞节前三个星期突然说要提前两个星期做完，这下这边就懵了，描述一下业务就是一个星期做完 PayPal 付款对接，Easypost 付款对接，PayPal 与 Easypost 对接，公司正式后台就一个，就是我那个盆友，直接表示，他的能力还没有能做这些功能，另一个兼职后台没有多少时间。一个人的潜力有多大有时候得看逼得多狠，我被迫自己完成这些对接，兼职的后台做了 PayPal 的 Demo，然后我两次加班到晚上 10 点多，硬生生让我对接完成了，调试得到结果后，我感觉整个人都飘起来了。

2.乾智嘉项目经理

第二个 APP 原名叫网逑，后来改名为微妙。

今天是年初四，至此，这个项目，因为甲方资金问题，完成 80%，暂时搁浅。出于程序员出生的身份，我还是让项目组用边角的时间，完成了这个项目。

这个项目算是我在乾智嘉第一个从头开始全权负责的项目。甲方的负责人涂总是南京某街道某领导，一个很有思想的中年人，也找了几个合伙人，准备在互联网最后的余温未过的时候做点事。不巧的是，遇人不淑，一开始的时候，网逑这个项目交给了南京新街口某家小型互联网公司，当然，这也是涂总后来找我们公司收拾这个烂摊子的原因。

并不是指责现在某些小型的外包公司不负责任，而是某些人在没有掌握好现在未成熟的技术就滥用的行为，的确不是一种负责任的行为。当时，涂总把安装了那个外包公司做的网逑 APP 的手机交到我手上的时候，我简直不知道该怎么说。这是一个完完全全的 Hybrid App，整个 App 只有两个控件，一个 UIImage，用于初次加载加载引导页，一个 UIWeb，用于加载主体内容，响应速度以及用户体验简直到了令人发指的地步，任何一个操作都是少则 5s，多则数十秒的延迟。涂总当然不情愿了，当时涂总公司也来了一个技术，李工，是做硬件以及 WiFi 的互联网前辈，知识储备相当丰富，我们几次交流后，李总也是对我们公司稍许信任，于是与涂总一拍即合，让我们帮助他们收拾这个烂摊子。

说是收拾烂摊子，实际上是完完全全的重做，也提了不少其它的要求。

我们项目组总共分为后台 1 人，Android 1 人，IOS 端 1 人，美工 1 人，因为只需要做 APP，所以没有专职的前台，只需要后台做一些简单的 JSP 管理员页面。因为公司刚刚起步，所以人员也比较紧缺，在确定了项目各个阶段的工程款项、起草了项目合同并签署后，我除了担任项目经理的职位以外也继续负责 IOS 这一块的开发。

任务分发使用 Teambition，版本管理及迭代使用的 git。java 端依赖管理要求 Maven，IOS 端要求 Cocoapods。

后台语言使用的 java 的 SpringMVC+Hibernate。数据库部分，基础数据使用的 Mysql，地理数据使用的 mongdb。IOS 端，使用的 OC+Swift 混编。

IDE 要求，java 是 Myeclipse，IOS 端要求 XCode，Android 端要求 ADT。

上面是这个项目的环境以及规定，在我们几个人的协作之下，3 个月完成了这个项目的 80% 的工作，期间辛苦倒不必说，的确是又收获了很多的经验，年前，张总跟我说，因为涂总那边的资金链出现了一些问题，导致现在项目暂时搁浅，失望是有的，项目组成员也认为，一个不完整的项目就这么搁浅就是对我们之前工作的侮辱，所以，我们还是坚持将它完成了。虽然可能在没有市场以及宣传的支撑下，这一类软件也只是鸡肋，但是，也算是一种交代吧。

3.Bxxx 架构师

想起来在进乾智嘉这个公司之前，我跟我那个考研两年未果的朋友还住在同一个屋檐下，那时候跟他讲，我说，我在毕业前唯一的要求就是能做到一家公司的项目经理。托他的福，进了乾智嘉，也万万没想到，努力得到的回报虽然不是即刻的，但绝对是值得的。

乾智嘉公司成立的契机是 3 月份，Bxxx 需要在中国找开发团队，于是，乾智嘉成立并与 Bxxx 达成长期合作。也就是那时候我朋友进入了公司，时隔一个月，我进入乾智嘉 Bxxx 项目组并担任 IOS 开发工程师，那时候，我并没有参与 Bxxx 后台开发，主要原因是因为是兼职身份，工资并不是很高，而且刚刚结婚，所以压力比较大，于是身兼数份工作，除了完成本职工作之外，也没有多余的时间完成其他的工作。

时间就这么来到 8 月中旬，我手头上其它工作都完成了，于是有时间投入到这边的 Bxxx 项目，于是开始着手了解这个项目，但也仅仅止于业务层的设计参与，并没有参与后台开发的工作。不过也就是在这个时候，慢慢的获得了甲方负责人，也就是 Bxxx 的 CEO 的信任。

我开始担任 Bxxx CloudService 架构师的契机是因为开发组几次出 release 的时候，效率极其低下以及漏洞很多，Jenny 开始对中国开发组这边慢慢的失望并透露出不愿意继续合作下去的想法，我觉得我的饭碗不保了，于是我着手开始负责这个项目并逐渐完成从项目经理向架构师的转变。

首先，谈谈我对架构师与项目经理区别的看法，项目经理偏于管理，对项目技术的理解不会很深刻，但是对于项目业务的了解以及任务的分配会比较得心应手，而架构师则偏于技术，可以解决项目中遇到的各个环节的难题以及效率上的攻坚。

其次，谈谈我是怎么完成这两者的转变的。

在做网逑这个项目的时候，我担任的是乾智嘉公司的项目经理的角色，网逑后台的那边，我更多的是负责业务的搭建以及项目各个时期任务的分配。而后台的任务分配下去，我就全权交给后台去负责了，顶多是在后台遇到技术难题的时候才会加以一些指导，更多的时候是导向，让他们去学习。

而 Bxxx 这边，我一开始只是做 IOS 开发的，直到上述的情况发生了，我开始向架构师的身份转变了。讲实话，做 IOS 的时候，因为是自己一个人做，遇到问题自己解决，写代码也很讲究，所以也不会存在什么太大的问题，而开始负责 Bxxx 这个项目的 CloudService 服务的时候才发现，我负责的时间太晚了。先说说我刚刚开始负责这个项目的时候，项目的情况：

因为我那个朋友也是刚刚加入互联网行业不久，没有人指导，所以很多东西不是很规范。项目整体的版本管理以及迭代管理不存在，直接后台前端协作是通过 U 盘拷贝。任务分发平台没有，release 管理平台没有，任何的持续集成环节没有，第三方依赖管理没有，测试环境不存在，release 出现 Bug 不谈，因为服务器部署在 AWS 上的缘故，并且没有第三方管理，项目后台达到 40M，单单上传时间长达半天，我刚刚接手的时候，直接就想放弃了，当然，我肯定是不会放弃这么好的锻炼机会的，至今，Bxxx 项目已经走上正轨，release 过程从开始到结束维持在 1 分钟以内，而且前提是在 test 环境测试通过下才会去发布项目，遵循基本火车模型进行发布 release，下面大概说说是怎么对 Bxxx 项目进行改造的：

1.首先是项目的管理方面：

a.代码管理以及版本迭代管理：直接使用 git 管理，简单粗暴，对项目组成员进行了一些简单的教学，大家都基本掌握了 git 的使用。其实，我也是知道的，项目一开始的时候，之前的 CloudService 负责人也是建议采用 Git 的，但是，并没有让大家了解到 git 的作用以及方便之处，所以慢慢的大家也就遗忘了这个极好的工具。

b.任务分发，采用 Teambition 管理平台：接到业务大体需求，我会先对整个实现进行大体分析，剖析到每个接口与每个界面，先写出需求文档，对应每个人的能力，有时候会具体到代码实现，发布到 Teambition 并规定 deadline，这样一来大家对自己的任务明确，并且有一个明确的驱动，大家效率也提高的很快。

2.其次也是整个项目最重要的部分，持续集成环境的搭建

Step 1 ：首先将项目集成 Maven，所有的依赖都采用 Maven 管理，这样一来，整个项目只剩下 5M 左右大小。

Step 2 ：搭建乾智嘉持续集成平台，采用 Jenkins 平台进行持续集成，编写各个环节脚本，搭建部署实例，由此，服务器直接从 git 拉取项目并使用服务器上的 Maven 环节编译项目，时间由此控制在 1min 以内。

Step 3 ：搭建测试环境：

a.环境部分：因为至此，项目还没有上线，仅仅一台服务器，所以在同一个服务器上搭建测试环境，直接就在同一个 Tomcat 下 8080 接口构建不同名字的另外一个项目，所有的第三方服务均采用 TestMode，PayPal 采用其沙盒模式。由此一来，发布 release 的时候，先使用 Jenkins 部署到测试环境，在测试环境测试通过后，直接改变项目的环境配置环境重新部署构建，脚本切换环境就可以发布 release 了，速度极快。

b.代码部分：测试环境采用 TestNG+selenium 搭建，单元测试使用 TestNG，每一次发布 release 之前测试环境的项目部署的时候，都会测试一遍，全部通过才会发布测试。页面测试使用 Selenium，所有测试用例均编写 TestNG 测试方法，保证每个操作都可以通过。

Step 4 ：搭建服务器奔溃日志管理系统

在每一个业务异常部分采用入库并邮件通知开发人员，特别是核心业务部分以及涉及到金钱交易部分，每一个环节都会采用错误入库管理。

如上，大概完成 Boxnearby 后台部分的改造，进一步的业务初步分离，缓存系统搭建这些小点就不多做赘述，这些改造部分大概花费了两个月，从 17 年第一个 release 版本发布以来，均未出现因为开发组导致 release 出现问题的情况，至此，也甚是欣慰。