昨天的 bug#
昨天在文章中分享了项目里遇到的一个 bug—— 修改了 Apollo 远程配置但是项目中读取不到修改后的值。今天让公司的封装这个框架的同事帮忙研究了一下，结论是项目中有一个给 SpringBoot 配置文件 application.yml 加密的 jar 包中存在一个缓存池，从配置中心获取的值会先缓存在这里。所以导致了多次修改就取不到值的问题。
我们在大公司到底能学到什么？#
我目前所在的公司是一家上市企业。
公司内部部门众多，做事流程之复杂让人难以接受。我第一次入职这种企业，企业内部每个部门都有所属于自己的办事规则。
在公司内部我接触最多的是各部门之前如何协调工作，如何让兄弟部门协助自己快速的解决问题（就像我昨天遇到的 bug）。他们最常用的方式就是 —— 邮件。
我们用企业微信沟通。但是私聊往往解决不了实际问题。有效且简单的方式就是邮件，但是需要抄送给自己部门和协助部门领导。因为这样同事才会有办事的动力。
工作效率方面因人而异。公司内部没有具体的明确的每天需要提交多少代码量的统计，针对一个具体模块的研发也没有非常严苛的时间限制。会定一个 “预生产” 的日期，我理解就是生产环境之前的最后验证。这样的规则看似非常的宽松，会让人产生懈怠感。但是，实际上我发现并不是这样，当然会有少部分的员工摸鱼，大部分的同事看起来还是非常的尽职尽责。尽量的快速完成任务。
我在这儿待的这一年搞懂了一个产品的业务，接触了三个公司其他的产品，也正在慢慢变熟悉这些产品的业务流程，还学会使用公司内部研发的监控平台和数据抽象工具。这些都是内部研究院自己基于开源项目做了适配公司业务之后二次研发的。还有一些，就是办公室技术，比如如何回复电子邮件，如何处理私聊甩锅信息或者如何协调预约一次会议。以上我所描述的百分之九十五，我感觉对我下一份公司几乎毫无用处。
我花费了大量的时间来学习掌握其他地方根本用不到或者压根就不会存在的内部工具，这些工具会帮助我在当前这个公司完成一些工作，但是并不会对下一份工作有所帮助。换句话说，这种特定知识是不可转移的。
今天正好看到了一篇文章也说到了这个，最后借用文章最后一句：
So, selfishly, I tend to think this way: if 90% of what I’m doing today won’t help me in the next job, then I should either reduce that 90% (for example, by focusing on general-purpose ideas, systems, abstractions, technologies), just not care as much about that 90% (as I used to), or find a job where I’m willing to sacrifice that 90% of my time because I think the cause is really important or the money is so good.