很久沒有更新部落格了。原因在於工作發生了變動，去新公司的第乙個任務就是從無到有的開發一套億級交易量的系統，因而開啟了一段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)中的崗位才有討論意義。
上述三點都是一些主觀判斷，甚至有些時候帶有一些運氣的成分。
對於工作的一些思考
感覺自從領導讓我管專案以來,一直沒有讓領導很滿意的地方是自己在專案上花的心思太少.很簡單的一些例子就證明了,比如自己雖然是中途接手的專案,然後並沒有仔細檢視招標檔案,沒有針對招標檔案的要求 去核對乙方的一些功能是否完成.其次,對於乙方,我還在心裡上和行動上 做到完成把控住,我不僅要去分析我領導的想法...
工作氛圍的一些思考
這周出差去我們上游晶元廠家k公司出差，要推動和解決的問題都有了一些著落。與以前公司做硬體的同事 目前他在k公司做pm 吃了個飯聊了一下，感受到一些不同的企業文化，在此記錄一下。首先說說相同點 老闆都是浙大畢業，大小事情都是老闆乙個人說了算 他們公司分工比較明確，工程師年輕人居多，都還比較負責，只要找...
關於SpringIOC的一些思考
ioc是 依賴倒置原則 的乙個特例，說其是特例，就是說其具有 依賴倒置原則 的性質。依賴倒置原則強調的兩點是 上層模組和下次模組都依賴於抽象，二者之間通過這種抽象的東西聯絡在一起 具體可以依賴於抽象，而抽象不能依賴於具體。我認為spring提倡的 基於介面程式設計 就是為了遵循 依賴倒置原則 其中所...