关于定位
我来公司也有 4, 5 年了, 但是时常还会感觉惶恐, 不知道该做些什么. 之前一直做运维, 每天接工单, 做变更. 也做过一段时间运维开发, 做过一段时间(伪)SRE. 那么, 现在呢? 说是运维, 但是不住场, 也没有工单. 说是实施, 可能还沾点边, 但是也不完全. 更多的时候是在跟开发测试环境打交道, 搞搞 jenkins, 配置个端口映射什么的, 偶尔还会帮开发工程师定位下问题. 我给这些工作起了个名字, 叫"研发支持".
来年, 希望运维组能以"研发支持"的定位, 为团队创造更多价值.
关于加班
2019 年可能是团队最忙的一年, 有些人长期出差, 有些人长期加班, 总之很忙.
出差也许可以理解, 毕竟客户和我们不在一个城市. 但是, 加班却不能, 尤其是长期加班. 看见加班的同事, 我不禁要问个为什么. 是有紧急 bug 需要修复? 还是工作量太大, 工期太紧不加班做不完? 又或者是工作效率太低? 也许都有.
不管是什么原因, 加班并不是一件让人愉快的事情, 也不是什么好现象 -- 加班通常意味着项目进展不顺利. 同时, 加班还让公司付出了额外的经济成本, 个人也付出了额外的时间和精力.
2019 年的软件行业似乎已经走下神坛, 不再是一个能够赚取超额利润的暴利行业, 而是变成了一个普通行业.很多互联网公司都撑不下去了, 或是倒闭, 或是裁员. 即便是阿里也开始堂而皇之的向社会"输出人才".难道是因为行业利润率的下降, 导致我们只能像快递小哥一样, 通过延长劳动时间来让自己和公司生存下去吗? 也有可能, 但我不愿意相信.
昨天看了一个 左耳朵耗子(陈皓)的采访, 他说"技术一定会导致有人失业", 这话听上去有点残忍, 但却没错, 技术进步了, 劳动生产率高了, 不需要原来那么多人了, 当然会有人失业. 但是, 技术进步却是任何人都无法阻挡的! 跟不上就会被淘汰.
作为个人, 我们也许都该想想, 自己为什么忙? 忙的是不是有意义? 作为工程师, 有没有什么手段, 尤其是技术手段, 能让自己的工作稍微稍微轻松哪怕一点点, 去干点儿比加班更有意义的事情.
关于技术
平台建立初期我们就引入了 dubbo 作为 rpc 框架, 将原有的单体应用拆分为服务. 但是彼时团队的水平很差, 没几个人知道 RPC 是啥, zookeeper 是啥, 甚至连打包都搞不定. 但是现在呢, 都了解了? 是不是有人认为 dubbo 和 RPC 是一个东西? 如果 dubbo 接口, 和 http 接口同时存在, 它们是什么关系? dubbo 接口跟 service 层什么关系, 我似乎隐约看见有人把 service 层的方法作为 dubbo 接口给注册了? 这么做好吗?
后来, 我们还引入的前后端分离的开发模式, 有了单独的前端团队. 形式上我们确实有了两个团队, 但是实际上呢, 前后端真的分开了吗? 为什么有些前端页面的提示信息会出现在后端代码里? 这样好吗?
年中的时候我看过两本关于 DDD(领域驱动设计) 的书, 实现领域驱动开发, 领域驱动设计, 还了解一下 "简洁框架(The Clean Architecture)", 如果你也看过这些东西, 你大概就有答案了.
后端统一错误处理的事儿老早就提过, 但是后来我看见的却是统一的错误页面?! 其实我说的是 @ControllerAdvice, @ExceptionHandler. 有了统一的错误处理方式, 就可以在代码的任意位置抛出错误. 搭配上自定义的 Exception, 规范的错误码和错误信息, 代码才能写的干净, 接口格式才能统一. 否则指不定哪天改着改着就把响应体里的错误码或者错误信息改没了.
这几年我们一直忙着做项目, 忙着实现业务功能, 欠下了不少技术债, 常常在自己制造的泥潭里打滚儿.
成长 再出发
2019 Java 圈发生了很多事情, JavaEE 改名了; Kotlin 上位了; JDK 开始采用新的发布周期, 版本号也已经飙到 14 了; 像 quarkus 这样的超轻量, 云原生框架开始出现了. 也有很多值得我们反思的事情, 但是不管怎么样, 它已经过去了. 一个曾经出现在科幻小说的年份 2020 已经来了. 2020 我们有很多技术债要还, 也有很多新东西可以玩儿!
祝愿大家在新的一年里, 能少加几天班, 能多看几页书.