这一年与下一年-2016年度总结正式版

这一年

每当总结过去一年的时候,总感觉时间匆匆,一转眼又是一夏,一转眼又过一秋,时间流逝不止,我们只能以成长搪塞逐渐衰老的年华。

我是6月20日来到贝聊的,处于程序员小白水平的我,当时只能勤奋的追赶,努力的做些小项目练手,同时也疯狂的补齐残缺的编程知识。半年以后到今天,积累起来,完成的项目大大小小,林林总总,也有一二。如网络日志feature、班级列表刷新、老师端班级语音播报、家长端老师端发现改版及再改版、老师端和家长端好习惯首页和详情页、弹窗基础框架、优惠券详情页和帖子详情红包页、一系列小的工具拓展、大图浏览、客服、专属客服、客服评价等等。我是一个不喜欢拖累大家的人,不愿意大家因为我的原因出现拖延,因此这些项目大部分如时的交付,而且作为初学者,写代码时如履薄冰战战兢兢的,千般思虑,万般测试,因此上线后的bug并不多见,整体还算优良。

其实回想起这段日子,我能分明的感受到自己对编程的认识是一个层次一个层次的成长,每做一个大的feature项目,基本就会遇到一个大的问题,然后就向前进一步。

记得我正式做的第一个独立feature是语音播报,迅速的写完UI,连通API后,随便测试一下就上线了,当时心里极其地没底,强烈地感觉代码能跑起来是随机的,我思考了很久也没找到让我心安地路径,但这个问题却一致残留在脑海,直到做了几个大的项目后,我才找到答案,那就是充分地自测和正确的开发流程,但是能做到这些也是在我解决其他同样让人苦恼的事之后了。

之后便接到了发现改版的feature,这个feature对我而言,是较新较重的,时间又非常紧迫,要5天后交货,我压力山大,当时我连怎么写请求,怎么发请求,怎么写model,怎么合理分离vc的职责等都还不懂,收到设计后,便立即动起手来实现UI,想着不懂的边写边学,疯狂5天后,不懂的真的都依葫芦画瓢地大概懂了,但是却不出意料的没有跟上进度,但谁曾料第五天上午突然接到消息说项目取消了,劫后余生我仰天长笑,不过做项目中有一朵巨大的乌云让我很烦恼,即如何处理UI更新与数据更新的耦合逻辑,我翻看了其他员工的部分代码,数据的流动杂乱不堪,UI更新随意罗列,就像在悬崖边飙车,刀锋上跳舞,看的我心惊肉跳。在苦思无解之际,有一天突然听到子豪极其推崇react的单向数据流,我灵机一动,突然意识到每一个VC的数据都可以看成这个VC的状态,而UI只是状态的表现,更新UI应该在更新状态之后,而状态更新应该集中处理,几番思考后,我确定这是个不错的想法。

于是很快,发现改版又启动了,世事变幻真是让人来不及定睛一看,这次我推翻了以前的逻辑架构,开始试验局部单向数据流动的想法,把dataSource更名为stateSource(现在想想正确的叫法应该为stateStore),把stateSource中所有model名都更改为state(现在想想应该所有的model类都应该更名为state),每一个state的状态都有一个对应的修改方法,在修改后利用stateSource持有的vc直接更新UI,而如果某一状态需要更新,直接调用相应状态的更新方法即可。这样,整个数据流动和UI更新就极其的清晰。现在想想这其实就是MVVM的思想,只不过我这里没有UI和数据的自动绑定。但在应用中,发现页面的状态并不多,局部单向数据流的优势发挥的并不明显,所以在后面的业务开发中,我并没有刻意把model名改为state,只是劫取了核心思想。

所谓按下葫芦又起瓢。在发现再改版中, 紧迫的工期导致接口定义迟滞,接口上线更是在末日之时,为不延误开发,客户端只能先只做UI,然后等后端接口定义完成后创建model、request,完成数据的填充,最后再等待接口上线连调。然后UI调试需要各种边界数据,等到后端给数据,那都要上线了,黄花菜都凉了,于是做假数据避无可避,但如何高效的做假数据呢?这又是一条漫长的修行之路。我一开始是在需要数据的地方直接写死,但如果忘了,假数据就是真数据了,这无形中给自己的头上悬挂了一把利剑,而这在我们组就真实的发生过。于是我又借鉴子豪的写法,在假数据周围包上宏判断,这是安全不少,但一个一个的假数据散落四处,根本无法统一管理,不统一等于没有管理。在研究了一段时间单元测试后,我发现OHHTTPStub很适合做同一的假数据,写一个JSON文件,然后截取网络请求,返回这个本地JSON文件的数据,再生产model,填充UI呈现,近乎完美的流程让我非常满意,于是我开始推荐给同事,但用着用着问题又来了,这些本地JSON文件很容易一疏漏就真的上线了,一方面使安装包更大,一方面如果OHHTTPStub的代码忘了删除,整个线上请求就都被Stub了,这就是事故了。而且随着代码时长的累积,我渐渐发现UI调试时,频繁的改动假数据JSON文件,编译,然后查看效果,很耗时,很累,很烦,如果能修改一下数据,刷新一下效果就在眼前多好。于是我开始研究反向代理,本地搭建server,然后窃取网络请求返回我想要的数据。但这需要我懂web的一些知识,门槛有点高,而且说实话也太复杂了些。就在我危难烦闷之际,Charles的MapLocal出现在我的面前,我看到那一刻惊呼道,这他妈就是我想要的吗?简单,好用,还有throttle。从那时开始,我一直用Charles的MapLocal做各种假数据,对我的UI进行各种边界条件的测试,因此感觉自己对程序又多了一些掌控和熟悉。

用Charles做假数据的方案确实让我窃窃回味了一段时间,事实上,假数据的有效突破让我另一个心腹大患有了化解的微光。那就是紊乱的开发流程。从开发第一个项目到现在,项目的开发流程都是先写UI,然后再写Model,request连接数据。这中间扭曲的逻辑,让写代码的我感觉到先被一点点的撕裂,然后再一针一针的努力的缝合之前的伤痕。app本质难道不是数据流动产生的一系列奇妙的反应吗?数据流动才是根本,根本如果不存在,何来UI?我想编程世界最开始的开发方式本就是先数据后UI的数据驱动式开发,然而随着项目工期的紧闭,先UI后数据的UI驱动式开发渐成主流。如果前后端能完全脱离,完全独立,数据驱动式开发其实是水到渠成的事,必然的选择。恰好Charles在场,Charles高效自由的假数据使得移动端只依赖于后端的接口定义,而事实上,接口的定义是服从于设计的,我们完全可以对照着设计,自定义接口,只需要有个胶水层,能将我们自定义的接口与服务器端的接口对接起来即可,感谢ibireme,其写的YYModel就具有这样的胶水功能,只要前端和后端定义的接口逻辑上有严格的一一对应的关系,利用YYModel就可以将二者无缝的粘合起来,再结合Charles的假数据机制,数据驱动式开发可以说轻而易举。在随后的好习惯开发中,我迫不及待地尝试了这种开发模式,虽然开发速度因为个人开发经验不足并未快多少,但逻辑上顺畅如行云流水。直到现在,我一直都采用这种更贴近人类思维的开发模式,而且现在后端的接口早早就定义好了,无需再自己定义接口,就更省心了。

经过激烈的七八九十月后,腥风血雨的日子总算平静了下来,但iOS较高的崩溃率和一波一波的bug,无情否定了曾经的所有努力,特别是在android快速高质的高冷姿态下,一个个bug像是一把一把冷箭,把我们伤的体无完肤。怎么提高自己的代码质量减少开发时的bug?有一次回家的路上我偶然看到一片文章关于怎样提高自己的代码质量,文中有几个观点对我非常大的启发,“代码是写给别人看的”,“写代码是讲究流程的”。原来如此,流程,确实应该有个正确的开发流程。我觉得大家平时开发都略显随意,而机器并不喜欢随意,所以才会有很多意外的bug。结合那篇博客的思想和数据驱动式的开发思想,从拿到需求到最终上线我比较推崇以下开发流程:

1
2
3
4
5
6
7
8
9
10
11
12
------>拿到需求
------>深入了解需求的细枝末节,跳转,各种边界条件,各种状态(减少bug的关键)
------>思考业务的实现细节,与技术负责人探讨架构和技术难点
------>实现与后端数据无关的技术难点
------>后端完成接口定义后,与后端对接口,了解接口的完备性和合理性
------>model、网络请求、view controller搭建数据框架
------>用Charles做假到逼真的数据
------>写UI(有真实数据做支撑)
------>用Charles模拟各种边界数据,充分测试UI
------>交付测试
------>一对一code review
------>按code review结果优化代码结构

其中第二条的边界条件分析和第九条的充分自测是减少bug的重中之重,前面是思考,后面是验证,而最终的一对一code review则是从别人的角度提高自己的代码质量,是自我提升和项目整体质量的重中之重。从我开始写代码到现在,或多或少基本遵循这个开发流程,写出的代码自己信得过,也获得了团队的肯定,也无形中考验了这个流程。

上述的局部单向数据流、Charles假数据、数据驱动式开发、开发流程等等是这半年我在编程认识上取得的进步,对别人来讲,可能都是显而易见的知识,但我是从零开始,每前进一步,都凝结了自己的思考和同事的无私帮助,并没有那么容易。自己的进步或多或少能带动整个团队的精神和气氛,我想这应该是我对团队和贝聊最大的进步。

最尴尬的莫过于整了两个重大的bug,但总体上在贝聊的这半年,我很满意,曾几何时,我还在广东省建筑设计研究院一所工作,不少个日以继夜,无数个通宵达旦,面对还算可观的成绩,扑面而来的却是无聊烦躁和对人生的迷惘,而如今同样的日以继夜,同样的通宵达旦,同样的还算硕果累累,心理感觉感到的是充实和安定。初次转行就能来到贝聊,不得不说感谢,事实上,贝聊是当时唯一一家愿意要我的公司,也是我面试过的公司中,唯一一个我想去的。曲折的过程和如今近乎完美的结局都出乎我的意料,或许是我多年沉淀的运气,或许是对方犀利的眼力,也或许是我不那么突出但还有一点点的才华,也或许仅仅是一个巧合。

放眼整个这一年,不能说成长,却发生了彻底的变化,2016年我从事业单位变到了私企,从建筑变到了IT,从对程序茫茫然变到了懂那么一点点的小程序员,从随波逐流变到了自己去选择道路。变化铸就了内心的强大,回忆期间坎坎坷坷的苦涩,现在都莞尔一笑。

下一年

记得贝聊面试我的时候,杨敏说特招我这个初学者,希望能以我旺盛的学习热情,去带动整个组的氛围。惭愧的是,这一年做的并不出色,我本身起点很低,一直在追赶,而在追赶别人的时候,你再努力,别人也只是在为你鼓掌。只有眼看着曾经比自己落后N个等级的人全面超越了自己,自己才会感受到落后的压力,进而产生动力。
所以下一年,我想

  • 在技术深度上,全面提高一个层次,看更多的开源库,研究一些有深度的课题,了解更多编程思想,了解更多程序方面的理念。
  • 在技术广度上,全面掌握React技术栈,伟大的想法都是相互借鉴的,我不可能狭隘于单一的iOS技术栈。

开始学编程到现在,我非常感念开源社区和那些无偿分享知识的博主,如果没有这些默默无闻的奉献,编程学习之路必然十分崎岖坎坷。我现在已经过了初学阶段,对编程也有一些自己的认识和看法,我觉得是时候去回馈编程这个温暖的大家庭了。

  • 大约每半年做一个有一定质量的开源库。
  • 大约每一个月写一篇有一定质量和观点的博客。
  • 对于团队, 我会想一些办法,在下一年切切实实的和大家一起成长。第三方开源库学习,专题研究,分享等。
  • 提高整个团队的代码质量。design review和merge request一对一的code review。

也想尝试做一下:

  • 基础工具小组,促进多语言学习、多平台学习和深度学习,而不是仅仅拘泥于一个小的平台上,也促进大家的产品思维。
  • 语言学习小组。我们虽然不是大公司,但真心希望能成立一个整体的技术学习小组,利用公司的已有资源整体提升公司的技术水平。这个很难,大公司都有自己的培训体系,但我们没有,属于真正的从零做起,紧迫性也不高,而且需要纯输出的付出,我想很难找到真正愿意一起行动的。

个人规划:

  • 8月份前处理结婚事宜。虽然已经领证,但还未结婚!
  • 去日本旅游一次,度度蜜月,看看外面的世界。
  • 开始自我管理。随着职责越来越重,自由就越来越少,自我管理也就更加重要。包括健康、时间、效率等。
  • 作为技术工,朋友圈一向狭窄。今年我想多认识一些人,多听听别人的想法。

往往计划就是用来计划的,林林总总我竟写了十几条,希望明年不只是勉强的笑谈,去掩饰内心的愧疚!

分享到 评论