离职的两个月之后

三月下旬的离职，已经是两个月前的事了。在那之后我没有立刻开始寻求一份新工作，客观原因是考虑到我正处于疫情的中心地带——湖北；主观原因则是在调整自己的状态：想让自己完全从上一份工作状态里抽离出来——时隔两月，我总算可以比较客观、冷静地谈论起离职这件事了。

在前公司的状况

我的 leader 并非是技术出身，对因产品迭代而产生的技术问题往往视而不见，因此划定上线（提测）的日期往往非常紧迫，加班加点也只能堪堪完成功能上的开发，也就让员工不得不忽略代码质量的好坏与软件设计的正确与否。当然，由于我们组的外包人员非常多（占 80%），就算给他们更多的时间，他们也不一定有能力写出更好质量的代码或做出正确的设计，不过这并不是可以破罐子破摔的理由。

目前产品使用的 Web 框架是部门 VP 在五年前根据 Flask 定制的，把开发流程全部封装得严严实实：只需要继承一个 class 并将 URL 参数放在重写的 get、post 等方法的参数列表里，然后将 URL 加入某 YAML 文件里面，就可以开始编写业务逻辑了。你不用明白框架是如何将 class 注册为对应 URL 的视图函数，也不用明白如何从 URL 参数里取出和函数参数对应的名称的值并校验值的范围、类型，只需要写业务代码就行了，像极了流水线上的工人。

代码质量的低下以及框架本身偏向业务的定制加速了架构问题的产生：目前的系统甚至无法支撑十个用户的同时访问。原因在于框架一开始就没有考虑到并发，部署时也是使用的 FastCGI（单线程） + Nginx，Python 2.7 又无法使用 asyncio。同时，代码的规模越来越大、历史包袱愈堆愈多，而架构却无甚改进，导致目前的系统已经完全不能在本地运行起来了，这给调试带来了非常大的困难——只能把代码替换到服务器上运行（还不能打包替换，因为环境并不是你一个人在用），然后看日志。

离职的原因

离职的最主要原因是 leader 的管理理念与我个人的职业发展理念不符：他过分强调业务（KPI）的重要性，只在乎可量化的指标，例如：何时提测、功能是否完备；而对：架构的改进、代码的质量、用户的体验等非量化指标完全不在乎。

具体总结后的原因如下：

1. 公司不重视技术，招了很多很水的外包，导致产品的代码质量很差；
2. 领导对开发时间错误估计，以及人员良莠不齐导致加班很多（经历过两个多月的 996）；
3. 框架无改进、开发流程不规范，导致历史包袱愈堆愈多，开发、Debug、部署的负担也越来越重；
4. 只在乎 KPI，不在乎产品的具体实现和体验，如：某页面请求加载十几秒都不在乎。

这些原因既是我离职的原因，也是我认为目前产品的症结所在。我曾向 leader 指出这些弊端，并给出了解决方案，但 leader 想都没想就以当前项目太紧为由驳回了。看，领导根本不在乎这些，只要保证提测时产品本身是差不多可用的就行了，代码质量？那是什么，KPI 里有写吗？但我仍然相信，这些弊病迟早会拖垮这个产品，只是我没有必要等着这一天的来临罢了。

这样的管理理念磨灭了我钻研技术的热情，也违背了我做技术的初衷（从入职后的四五个月里 Github 的 contributiosn 基本为 0 可以看出），因此我选择离开。

两个月我做了什么

在下定决心辞职之前，我也想过在论坛发一个帖子，询问我这样的状态是否应该辞职，后来想明白了：为什么我的人生需要其它素不相识的人来决定，或者难道大部分人劝我忍一忍我就真的能安心干下去了吗？答案是否定的。想明白了这一点，我便直接裸辞了。

离职之后我在技术方面做了这些事：

1. 阅读了《Kubernetes in Action》这本书，学习了 K8S，并在我的项目 DIEM-API上实践了；
2. 在 Coursera 上完成了《Algorithm, Part I》课程的所有内容，完成了《Algorithm, Part II》课程的前两周内容；
3. 完成了 MIT 6.824《Distributed Systems》第一个 Lab MapReduce 的内容；
4. 重构了 Github 上的几个项目的代码，这段期间的 contributions 基本保持全绿。

这些内容对我的提升比我在公司八个月所获得的更多，因此我也并没有因为辞职而后悔。

总结 & 打算

离职就算不是一件光明正大的事，至少也并不需要讳莫如深：我对公司并没有什么怨念，同事之间也相处得很愉快，只是这些并不在本文的讨论范畴。毕竟离职的原因肯定不是因为公司对你太好了，而是因为公司有些毛病你无法忍受却又无力改变，因此只能选择离开。

毕业前因为想离家近，所以我选择了武汉；而接下来，我想的下一份工作能让我的价值得到比较好的展现。更进一步的讲，我想做一些更贴近用户的产品、一些用户真正需要的产品，能让用户的生活更加舒心，也可以满足我个人的成就感。