很久沒有更新博客了。原因在於工作發生了變動，去新公司的第一個任務就是從無到有的開發一套億級交易量的系統，因而開啓了一段996的生活。不得不說，996對於精力的消耗真的是太大了。之後將恢復更新。下一步在技術方面將會介紹一下這兩年來開發這套高併發系統的一些心得以及部分關鍵技術的實現原理。這一個系列主要介紹一些工作中的思考。
細細算來，我參加工作已經五年了。這個階段的工程師經常會進入一個瓶頸期。瓶頸期最常見的表現就是：工作本身已經無法讓自己繼續成長。而程序員恰恰是一個渴望成長，需要成長的職業。這種客觀情況與個人理想之間的矛盾讓讓人感覺無力。很多人也從此卡在了這個瓶頸期，再無進步。
一、工作的意義
互聯網行業的一個特點就是工作強度高，單元化程度高。長期的重複勞動很容易讓大家忽略一個問題，那就是：工作到底是什麼？
其實在職場上，所有的工作本質上是一樣的，那就是：資源交換。代碼能力是資源，懂業務是資源，甚至與上級或者其他部門的關係也是資源。而工作就是上述這些資源的交換和重新分配。一個聰明人所要做的，就是使用更少的資源去換取更多的資源。
上面的說法有些抽象，我用一個例子進行具體解釋。當產品向你提出業務需求時，你可能會有如下實現方案：(1)告訴他目前已經有實現好的功能，直接用；(2)生產系統支持靈活配置，無需發佈即可生效；(3)業務邏輯影響小，代碼稍微改一下就可以實現；(4)業務邏輯影響大，需要大改動；(5)這個需求做不了
很顯然，在收穫相同的收益(產品上線/KPI完成)的情況下，你所需要付出的資源按照從小到大排序依次是：(1)>(2)>(3)>(4)。而(5)則是0收益或者是負收益。因此，可以得出結論：在日常工作中，我們要做的就是努力達成(1)或者(2)，儘量避免(3)、(4)和(5)。
然而，在真實的工作中，很多程序員接到需求腦海裏第一個反應是：這個功能怎麼開發。而沒有嘗試去問自己，有沒有更好更快的方案。這種默認把自己限制在(3)和(4)中的潛意識，會大大束縛你的系統設計能力，進而影響到個人成長。
不是所有的需求都必須用開發代碼的方式去解決，多從系統設計層面去想問題
二、業務標準化和業務積累
程序員圈有一個很有意思的現象，那就是：雖然大部分人都是圍繞着業務做開發，但是共同語言不是業務，而是基礎技術方面(如語言/開源框架等)。產生這個現象的原因是：IT行業標準和積累的缺失。換句話說，一種業務沒有一種統一的實現標準，每個公司都有自己獨特的實現路徑。當程序員跳槽時，他所能帶走的只有基礎知識。而與公司盈利息息相關的業務能力則留下來了。
程序員的年齡危機也跟積累的缺乏有很大的關係。之所以機械/土木等領域的工程師較少遇到年齡危機，一個重要的原因則是這些行業都已經是極度標準化。由於大家都遵循同一個標準，因此工程師在跳槽時業務能力得以保留，其業務能力隨着工作年限的增加是一直在增長的。
目前在某些業務領域(例如廣告推薦/系統中間件/第三方支付等)，互聯網行業已經逐漸有標準化趨勢了。甚至在系統架構層面，阿里提出的“大中臺，小前端”也逐步得到行業內的認可(然而，在具體落體時還是同樣的問題：一個司令一把號-各吹各的調)。不過業務領域的標準化還是有一段相當長的路要走。
讓我們再把視線拉回到自己身上。在這樣一個容易清零的行業，我們應該怎麼實現最大化的業務積累呢？我有以下幾個建議作爲參考：
(1) 初始職業和出生點一定要選對。參加工作的前五年是業務能力提升最大的幾年。而公司和工作則是影響提升速度的最大兩個變量。一般來說：行業中樞公司優於分支公司，大公司優於小公司，核心部門優於邊緣部門。主力開發優於輔助功能開發。而是核心與否有一個最直接的標準，那就是公司靠哪個系統活着，哪個就是核心。
(2) 不要頻繁跳槽，尤其涉及到業務方向轉換時一定要慎重。跳槽是對個人業務能力的一次嚴重傷害。漲薪固然很好，但一定要注意業務方向是否能讓你得到連貫的提升；
(3) 培養自己的大局觀和方法論。 在工作中，要清楚的知道自己做的事情到底對整個系統，甚至整個行業有哪些影響。影響有多大。需要哪些部門配合你完成工作。而你的工作又是對誰負責。這些問題只有在符合(1)中的崗位纔有討論意義。
上述三點都是一些主觀判斷，甚至有些時候帶有一些運氣的成分。