越长大对时间越不敏感，小时候等一小时都如坐针毡，现在一年就这么不知不觉过去了。
一、工作
2017 计划：
1.重构代码，模块划分、功能设计和实现分离
2.探索其他通信方式（socket（tcp）， grpc）
具体工作：
离线鉴权：设计；单独异步请求；错误码细化；
音频源：内置、file、外部输入、阵列
场景化识别：action_type, input_type参数，仅输入法有
语音语义：identifier策略改进；model指定后台模型；设置发包间隔；
长时（录音笔）SDK: 尝试socket；http+客户端vad+服务端vad
输入法：短时识别根据第一个音频包的能量选择性进行agc；识别丢字（服务端VAD参数）；IMEI手机标识符传入，统一标识符；
同声传译SDK： grpc+protobuf
远场：初版录音+多路处理+唤醒+识别；按照语义结构重置，阵列录音同增强算法封入金锁底层库；回调改为在UI线程，方便操控UI；
声纹：重构SDK接口，撰写文档
17年初统计的SDK合作方有22家之巨，从原来的各家一套，目前已大致收敛为7个主要功能的SDK，其中有关识别的主要有4个（输入法、语义主线、长时、阵列），以及同传、离线鉴权、声纹，较今年年初混乱状况已有较大的改善，未来是否可以考虑进一步收敛？
17年放眼望去，工作依旧比较细碎，全新开启完全掌控的项目也有两三个，自我提升吧算是有的，不过整体而言，由于所做之事较为零散且杂乱，不成篇幅，大多的工作都是在赶需求完成任务，根本没时间关心代码质量、性能之类的问题，并且由于部门没有测试，很大部分的时间要用在测试上，时间碎片化严重；项目多、项目切换频繁带来的问题就是代码不熟悉，代码质量不高，大多为one shot，没有可扩展性。
目前存在的问题以及解决方法思考：
1.项目数量多，维护成本高
对于合作可以划分为对内和对外
①对内有些需求较多且可以实验性尝试使用一些比较新的技术，如输入法、车联网。对这部分合作，需求较多且较细碎，需求共性不大。对这些合作，单独拉分支或者提供单独的SDK；
②对外合作方（包括搜索app，搜索翻译等）需求较为简单，多数主要是语音识别+语义理解，可以采用标准化android或者跨平台通用的SDK对外输出，这部分合作不轻易定制需求；对于合作方提出的新需求，需要产品经理权衡的确有利于SDK服务质量再排期加上，其余的拒绝；另外，对于之单独提供SDK的合作方（搜索app，畅游等）需push他们迁移到这种对外合作统一输出的SDK上来。
关于标准化：
①SDK标准化：根据需求分2-3套。一套通吃维护成本将会很高，认为不太现实。
②服务端可配置：请求参数、响应统一格式，通过设置参数选择对应的服务（比如参数控制60s识别或者长时识别），目前通用SDK应该采用的这个模式
2.代码质量不高&相互之间业务不熟悉
①互相业务不熟，因为SDK部分基本是单独负责开发完成导致。
建议：规律的技术分享，增加奖惩机制保证分享持续（奖：按月/季评选这段时间的最佳分享，给予一定物质奖励；惩：对于分享delay的的童鞋，给予适当处分，发红包之类？）
此外，领导可以定期抽查旁听，监督防止敷衍放水现象
i.开发负责人员主讲，讲解自己的业务相关的模块规划和逻辑， Q&A
ii.非负责开发人员阅读代码以后分享串讲, Q&A
iii.开会组织大家一同阅读项目核心代码，提问分析代码的结构、设计、写法等
②代码质量不高
i.对于比较核心的SDK（输入法车联网、对外合作主线、通用等），增加code review机制，提交到代码库之前需要同事review之后再提交（review保证代码的正确性，同时写上可能的修改建议）
对于review之后的代码出现bug，将影响提交人员和review人员的绩效
3.无文档&文档不规范
一些legacy code以及demo类型的新项目没有文档，或者不同人写的文档质量参差不齐，导致交接成本（开发间的交接，SDK分发给使用者）直线上升。
建议：凡对外输出的SDK强制需要写文档，可以开会讨论商量出一套SDK文档的低配标准（核心调用类的接口参数，错误码，版本更新日志等），文档应起码达到低配标准的要求
4.版本管理混乱&版本更新不及时
①很多输出的SDK仍旧是“项目名称_输出日期”的格式输出的，建议输出日期改为“major_version.minor_version.revision_version”（v1.0.0）这种格式输出，较日期而言更好记且更直观（https://en.wikipedia.org/wiki/Software_versioning）
②版本更新不及时：某次SDK更新分发给A合作方，B报了一个bug/需求，查了很久发现在上次更新已经修复，结果两边都白花了很大的力气。之前跟产品讨论过这个问题，我们希望的是每次SDK更新的时候通知给所有使用该SDK的合作方，通知其更新细节，采取与否由对方决定。产品表示由于无法确保更新的新版本的稳定性（没有回归测试），贸然发送给本已较为稳定运行的合作方存在一定风险。由于回归测试较为花时间，由开发完成基本没有可能，故这一点在没有测试人力的前提下暂时没有好的解决方法。
5.性能评测相关
之前评测的指标用的是CPU占用率，内存占用绝对值
i.不同内存大小的手机上对于应用能占用的最大内存的限制是不一样的，所以同一个SDK跑在2G内存的手机和4G内存的手机上占得内存应该也不同，用内存占用绝对值不是很科学。考虑替换为内存占用率或者其他指标。
ii.测试case：正常使用，压力测试时性能指标的平均值和峰值；
iii.test case如何能客观得反映出性能，有待进一步研究，或者找测试同学设计
6.关于SDK崩溃监控/错误数量监控/错误排查等
①有必要建立崩溃上报和出错上报的机制，有利于我们监控SDK的表现，这个可以跟统计做一起，日活，使用次数等
②用户遇到错误反馈，没有对应机型复现的时候很难查出用户不可用的原因。暂时的想法是SDK增加存运行调试日志的开关，打开时把调试日志存储在SD卡上，然后在用户允许的情况下上传至服务器，以方便定位一部分前述问题的原因。
总结：
工作以外花在学习上的时间严重不足，除了12月一个月开始准备跳槽，刷题，看专业书籍过得比较充实以外，其他时间学习提升感觉比较少，危机感还是要增强。
期间也是下决心了解下ML，打算通过Andrew的Machine Learning来学习的，但又被打算跳槽打断，待工作尘埃落定后需要花时间补回来
二、运动&旅游&身体
1.旅游目的地：南京、苏州、杭州、成都、青岛、哈尔滨、青海甘肃大环线、深圳、广州、雪乡雪谷
一年跑了十多个地方旅游，不仔细翻行程真的不敢相信自己这么能玩。。。
怪不得最近想跳槽才发觉自己真的没啥长进，原来时间都花在跑步和玩耍上了。
明年需要削减游玩的时间一些，务正业一下，毕竟青春也就那么几年，趁年轻多多打拼一下。
2.跑步：
全马：成都双遗、哈尔滨、北京、广州
半马：北京长跑节
越野：三夫香山10k，三夫香山20k，星际越野-大觉寺（凤凰岭20k）
跑量：
3月 139.8
4月 176.5
5月 110.4
6月 47.1
7月 91.8
8月 165.1
9月 131.6
10月 138
11月 205
12月 154
上半年还是很兢兢业业地做健身餐，规律健身，后来越来越发觉大块肌肉和跑步成绩不可得兼，加上楼下健身房倒闭，且健身没有跑步的快感，于是顺理成章抛弃健身房而取跑步，健身部分交给了keep，把重心转移到跑步事业上，然后感觉时间多出好多！上半年非比赛月跑量太少，下半年专心跑步，跑量平均每月上升50-100km，足够的跑量给今年创造了足够多的PB!（好像是一路PB下来的，嘤嘤嘤），目前350，自己都没有想到的成绩，给自己点个赞，希望新的一年继续有突破。
17年开始试水越野了，起初是香山10k，感觉比跑步有意思，但觉得长距离有危险，所以暂时没继续下去？直到秋季，心血来潮去香山野路寻秋色，去了两趟，然后就不安分地尝试着报了两个20k，这一尝试一发不可收拾，山路路况复杂，景色迷人，体验一下子把路跑甩出几条街，“一入越野深似海，从此路跑成浮云”，深以为然。奈何越野就是有一丢丢风险就是了，万一哪下不小心没踩实那不是废了。还有越野距离也越来越长，50k，100k，168k，n百k，这么一直追寻下去感觉身体也要吃不消，还是量力而行吧。
18年估计越野和路跑并行发展吧，越野计划尝试50k，路跑主要还是抱着旅游为目的。
身体参数：
体重：59.8~63.5kg，目前61.4kg
胸围：88~94cm，目前90.5cm
腰围：78~81cm，目前80cm
臀围：87~89cm，目前87cm
体脂率：11.2~15.8%，目前15.8%
下半年跑量多了不少，奈何没有力量训练，肌肉也掉不少，体脂率也是飙升，无奈鱼和熊掌不可兼得啊。
来年如果有条件办张健身卡，加强大腿和核心的训练，争取可以把体脂率降一些
三、其他
投资：
17年一个重要收货应该是发现了小明哥的公众号，干活满满，虽然很多都看不懂。。。。
弄懂了敢于承担风险才能获得更大的收益，但是承担风险也并非无脑把钱咋进去/跟着某个砖家。
开始了解金融市场，希望能早点入门，对金融秩序有一些自己的理解。新的一年需要花点时间学习一些基本的金融知识，可以的话拿一小笔钱试水一下股市。
感情：
依旧一片空白啊。究其原因：主要还是没有好的线下渠道交到朋友。线上人虽多，但都是颜控身材控，且素质参差不齐，并且多数人自我认同还不好。反正自己要不断变强就是了，强者才有更多的选择权！至于感情，还是随缘吧。
母亲今年似乎也有点妥协了，但是妈妈也表达了担忧：
老了怎么办，这几年是得认真考虑下这个问题。
大概就这样吧，希望大家都有个美好的2018年！
