昨天的 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.