共计 2683 个字符，预计需要花费 7 分钟才能阅读完成。
18 年还是让我觉得过得很快, 我想去年的我也是这么想的. 不同的是, 我觉得我今年经历了许多事, 这让我变得 … 或者说, 在那么几个瞬间, 我又老了一点.
看了下去年的年度总结, 感觉自己的视野还是放在了比较小的一块儿地方, 除了代码之外, 软技能也是必不可少的.
我还是想从工作谈起, 因为我现在专注在上面, 觉得挺快乐的.
工作
今年我离开了 ZStack, 那时的我其实明白自己想要什么——诸如想要什么样的生活、想做些什么事、还想知道些什么, 于是我来到了现在这家公司. 而我的愿望也的确被满足了.
而我的工作也不再仅仅是在编码上了, 我参与了很多事, 比如关注团队成长、开发规范的推进、大量的参与招聘等等 … 在此之中, 我也获得了成长, 在这里, 可以举几个例子.
开发规范
以开发规范为例, 当一些规范并未落地时, 会增加许多事后看来不必要的成本. 以我们熟知的自动化测试为例, 项目终于到了可以交给测试同学测试的阶段了, 然而测了半天有问题, 交由给你, 你改好了代码, 自己测了一遍, 测试同学测试后发现这个问题的确解决了, 之后几个问题也如愿解决. 但是最后一刻, 测试同学发现原本的功能遭到了破坏, 于是又是一遍你改代码手测交给测试同学的循环, 总算在客户生产环境上线了, 结果又发现了问题, 从交付同学 call 到 pm 或到测试, 测试再找到开发, 又是几轮测试下来. 如果问题多的话, 不知道会有多少人力成本浪费在里面, 而客户对这个公司的印象又会变得如何呢?
而我们的软件总是越来越庞大的, 我们发现我们要测的功能会越来越多, 测试同学的负担会越来越重 …..
如果这些手测能够交给机器来做, 是不是可以省下很多成本呢?——这就是自动化测试带来的价值.
把话题展开来, 今年类似开发规范推进的事, 我做了这些:
基于 GitLab 的 Continuous Integration ——尝试使用 GitLab-CI
Functional Spec (Or Proposal)
CodeReview
解放前端:API 文档 +SDK
CI
利用 GitLab 的 CI 让每个 commit 跑一遍自动化测试, 粗略算了一下, 目前所在的小组平均每周跑的测试有 5000 多个. 引入 CI 做这件事, 正是因为我信奉:
一个 bug 被发现的越早,fix 的成本越小
能通过机器来做的事, 就不要让人去做
Funstional Spec
编写这个文档的习惯来自于 ZStack.FS 是以 Feature 为基本单位, 用来约定 PM、测试、前端和后端如何在这个 Feature 中的工作一个 Spec. 里面必须写的内容有: 背景、原理介绍、接口设计、相关数据结构、测试用例. 并且保证在编码前这个文档足够完善, 在编码时完全依据此文档来编程.
而引入它的理由则是希望有个文档来约束各个角色在这个 Feature 中会产生意外的可能性, 比如测试一看说这个 API 的结果明显应该是这么期待的啊, 开发你怎么肥 4. 然后再测试阶段开始重构, 再测 … 天呐 …
不仅如此, 也是给后来的新人留下了有效的文档.
而在实践中, 发现这玩意儿还有约束 PM 意外能力. 哪天 PM 改需求了, 就和 PM 说: 看! 你当时不是这么说的. 然而没什么软用, 爸爸让你改你还是要改.
逛过 K8S 社区的人知道, 其实这个 FS 和里面的 Proposal 有点像.
CodeReview
CodeReview 配合 FS 是很棒的一件事, 因为这样 Review 的人能很快的得知上下文, 并参考里面的约定来 Review 代码.
而 CodeReview 带来的好处则是有效的 (或者说言传身教的?) 保证了项目代码的规范, 且避免一些低级明显的错误被提交上来.
当一个新人问我“为什么要这么改”的时候, 有时给我带来的思考收获甚至超过一天的编码.
解放前端
在实践中, 我认为 ZStack 对前端并不友好, 从外部来看, 它对于异步 API 支持轮询和 webhook, 轮询真的太挫了, 而 webhook 意味着前端要编写一些服务器逻辑. 而从内部来看, 它的 RestServer.java 抽象程度并不好, 二开则意味着紧耦合开发. 最后为了解决这个问题, 引入了 WebSocket.
再之就是给前端同学提供了文档, 因为我觉得来回问这个 API 那个 API 效率很低 … 后来发现, 我给前端 API 文档, 前端还是要照着写 Request 和 Response 的回复啊, 那为什么不用元编程提供一套 SDK 给他们直接用呢? 后来就这么做了. 这样前端同学就是可以专注他们自己的业务了, 而不是后端定义的数据结构上.
能通过机器来做的事, 就不要让人去做.
学习
再来谈点学习相关的事吧. 今年“极客时间”火了起来, 第一次接触它是在 17 年 11 月份, 那时感觉这 App 做的好粗糙, 且没有我想要的课程. 却不料后面课程越来越多, 且质量都还说的过去, 价格也算公道, 逐渐的便用上瘾.
最早使用“极客时间”的时候一度认为这不是程序员版的“得到”吗? 说起来, 今年 11 月份的时候我又重新拣回了“得到”, 因为今年引起我思考的问题实在是太多了, 或者说, 我想知道的东西越来越多了——而当我找到了我所认为正确的答案后, 我会带着这些问题一起记录到自己的博客里, 与你分享.
顺便翻了一下上面的年度总结:
然后是一如既往的英语打卡
今年的学习方式其实和以前几乎无异, 而我发现有很多地方是可以改进的. 在我看来, 学习是一件持续的事情, 并不是你今天看了一本书上了几节课就 get 了这个知识. 而是不断的消化这些知识——无论是“思考”还是“运用”也好. 这样你才能不断的迭代它们, 使它们变成你的一部分.
对于明年的学习计划, 没有很明确的目标, 但是希望能够聚焦在一定范围内:
学自己要用到的东西. 而不是停留在纸上谈兵
学自己想知道的东西. 而不是因为别人的推荐、别人说好去学
生活
从今年来看, 工作和生活得到了一定的平衡.
整个人也是明显的瘦下来了, 得益于坚持锻炼
对于运动这一块明年有两个小目标:
最大极限达到半马, 早日尝试跑全马. 目前我的极限是 15000 米
体脂到达 15 个点, 目前在 17~18 个点之间震荡
最后一些碎碎念
圣诞时, 公司颁了一个奖给我——5K 的红包. 奖励我对于“基础设施”的建设——上文提到的开发规范. 同时领导希望我能把这些好的习惯推进到别的产品线. 而现在我正在参与到更多很多环节, 尝试去改进、解决现有的问题. 明年, 我想我们还可以做得更好.
今年的我也终于意识到了“人言可畏”, 以前看三国时看到过孔明以流言害仲达, 故对其略懂一二. 而真轮到我时简直是头皮发麻——百口莫辩, 心塞无比.
然后便是遇见了很多人. 遇见了和我经历相仿的人, 这让我感到神奇, 能知道我为何而努力, 也能和我谈谈未来, 告诉我许多我不曾知道的事; 遇见了很多有趣、可爱的人, 也遇到了志同道合的人, 让我觉得不再寂寞 …
一切都在变得好起来.
