不知不覺工作已三年半，準確的說是三年零五個月。在這過程中，在技術和業務上的成長，多多少少都會有一些，但最大的收穫，還是長見識。聊聊幾點感受吧。
學會向上彙報
別隻顧埋頭做事，要做“對”的事情。
這是個人情社會，你的領導也只是普通人，他不太會有大把的精力去關注底下的人每天具體幹些什麼事情，這種情況下，如果你只知道一味地埋頭做事，即便做了很多，加班累成狗，但是領導壓根不知道，是沒有任何意義的，典型的吃力不討好。很多時候是需要你主動向上彙報的！定期地跟領導保持正向溝通，積極反饋工作中遇到的問題以及自己的想法，讓領導感知到你的付出，當然有產出是最好的了。
什麼是“對”的事情？要有全局觀，審時度勢。當前領導最關心最迫切的事情，就是對的事情。舉個栗子，隨着用戶量的快速增長，系統的壓力越來越大，原有最初的系統逐漸暴露問題，甚至因此頻繁出現線上故障。這個時候，如果領導發起了“系統壓測”的任務，那麼當務之急，壓測就是最重要的事情，工作的重心應該以此爲準。即便此時業務上也有很多新的需求，你也應該做取捨，否則即便你做了一大堆需求，此時的領導根本無暇顧及，他所關注的必然是壓測的進度，千萬不能撿了芝麻丟了西瓜。
打破侷限，解決問題纔是王道
在遇到緊急情況，如線上故障處理時，快速解決問題纔是關鍵。有的時候我們容易陷入程序員慣有的思維裏，遇到問題會習慣性地一上來就嘗試用代碼去解決，而忽略了一些非代碼的簡單處理方式，比如粘貼/複製、excel工具、sublime文本替換等。這裏列舉兩個工作中的小例子，深有感悟。
栗子1：故障處理
在一次故障處理過程中，需要對一批指定用戶做一個操作，這個操作可以通過curl請求來完成，當前已有的是已經導出的以userId逐行排列的userIds.txt文件和請求的url，分別長下面這樣子：
userIds.txt內容：
userId1
userId2
userId3
...
userIdn
url內容：
https://www.yangbing.club/${userId}/doing
當時的第一反應就是準備寫個shell腳本或者Java的Job來搞這個事，本身邏輯簡單，一層循環就能搞定，僞代碼大致如下：
userIds <- userIds.txt
for userId in userIds:
actualUrl = url.replace("${userId}", userId)
curl -H 'Cooike: xxx' actualUrl
但偏偏shell又不太熟，還得調試，想想就頭大。此時組裏新來的清華實習生給出了簡單粗暴的方式，直接在userIds.txt文件上做文章，用sublime的文本替換功能，將文本中每一行，如第一行userId1的行首^替換爲請求url中${userId}之前的子串curl -H ‘Cooike: xxx’ https://www.yangbing.club/，將行尾$替換爲url中${userId}之後的子串**/doing**，這樣就得到如下的結果文件：
curl -H 'Cooike: xxx' https://www.yangbing.club/userId1/doing
curl -H 'Cooike: xxx' https://www.yangbing.club/userId2/doing
curl -H 'Cooike: xxx' https://www.yangbing.club/userId3/doing
...
curl -H 'Cooike: xxx' https://www.yangbing.club/userIdn/doing
然後一行命令就能搞定：
sh userIds.txt
如果處理速度慢了想要併發，又可以通過split命令將userIds.txt按記錄行數拆分成多個小文件，然後依次sh，利用操作系統的多進程併發處理。
回想這個事情的處理過程，我們的最終目的實際是爲不同的userId生成對應的url，然後curl請求執行。程序員的固有思維就是消除重複，儘可能複用！對於這種userId不同，有相同的url模板的典型case，很自然的想到用循環。而忽略了ctrl C/V這種“重複”的快捷方式。
栗子2：日常開發
產品有個導數據的需求，要將特定篩選條件下的用戶列表導出爲Excel文件。這本身並不難，一個常規的Job就能搞定了。
同事A的方案也很常規，算是比較自然的思路，大概構想了一下代碼流程，類似這樣：組織篩選代碼邏輯，將符合條件的用戶列表篩出來，然後將列表轉換爲行數組，並構建標題數組，再通過Excel三方庫或公司已有的工具類，將數據寫入Excel文件。在這過程中，除了篩選條件的代碼邏輯外，轉爲Excel工具需要的數據格式並生成Excel文件，看起來是最耗時的工作。
這看起來好像沒啥問題，但筆者並沒有採用上述方案。我們來看下這個需求，首先它是個一次性的，數據導出之後就完事了，也沒有後續迭代；其次，Excel文件只是產品所需要結果的一種文件格式，我們只要能確保最終給到產品的是Excel就行，至於我們是通過代碼生成Excel的方式，還是借用Office Excel強大功能將其他格式的文件轉換爲Excel的方式，產品並不關心。而我們又知道，Office Excel可以輕鬆支持將特定分隔符（如逗號、tab鍵）的文本文件導入爲Excel，因而方案自然就變爲：
先篩選出符合條件的用戶列表，然後通過log.info將每個用戶記錄User的各字段以逗號","分割打印一行，這樣我們就得到了第一版數據——日誌文件，大概長這樣：
......// 啓動日誌
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] job start
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506672,"userName1","address1",2
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506673,"userName2","address2",3
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506674,"userName3","address3",2
......
2019-11-25 23:00:45 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506694,"userName100","address100",1
2019-11-25 23:00:45 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] has processed 100 users
2019-11-25 23:00:45 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506694,"userName101","address101",1
......
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] job end
......// job退出日誌
這時候，強大的文本編輯工具sublime就登場了。可以看到，日誌中除了含有user info的行尾是我們需要的數據，其餘都是無用信息，冗餘數據處理分爲如下幾步：
- job起始和結束我們通常會打印job start和job end，那麼這兩行分別之前和之後的內容可以直接刪除
- 像has processed xxx users這種打印job進度的信息，可以通過正則**.*has processed [\d]+ users\n**替換爲空串，這個地方需要注意一個細節，就是正則中要包含"\n"符號，否則替換後會留下空行，比較尷尬。
- 前面兩步處理完後，就剩下數據行了，然後用正則**.*[org.sherlockyb.blogdemos.ExportUserJob] user info:**把無用的前綴替換爲空串即可。
- 剩下的數據行其實就是標準的CSV格式文件了，改下後綴，然後打開文件，將內容複製到Excel文件即可。或者在打印日誌時我們用"\t"分割，這樣在得到剩下的數據行時，可以直接複製到新建的Excel文件也是可以的
可以看到，這個方案的核心在於，通過Office Excel已有的強大功能，代替了通過寫代碼生成Excel的方式，從某種意義上說，這也是複用，只不過複用的不是現有代碼，而是現有的軟件功能，而這些強大的軟件功能，同樣也是別人寫代碼實現的，間接地複用了"已有代碼"。
同事A後來聽我跟他講完我的實現方案，表示“秀了我一臉”，真實。。。。
用“好工具”，“用好”工具
好的工具能讓我們極大地提升做事效率。
以前我對於日常開發工具的認知就是，夠用就行，不用太深究，專注代碼和技術。直到後來，當我見識到周圍的朋友如何熟練地通過各種工具快速達到目的的時候，感覺真的被秀了一臉。
好的工具有哪些呢？筆者有個推薦清單：
- IntelliJ idea，真的比eclipse好用太多，用過的才知道。可配置各種常用快捷鍵，如項目切換、代碼視圖回退、代碼跳轉等
- Sublime，強大的文本編輯工具，日常的文本處理用它就行
- Excel，再普通不過了，基本用過pc的人都瞭解過一些基本用法，但又有多少人用過篩選、列隱藏、多列排序、指定分隔符導入文本數據等功能呢？多研究多使用，你會發現不一樣的天空。
- Alfred，mac下強大的搜索工具，真的很強大。在一個小小的命令框內，它可以快速定位本地文件，使用計算器、詞典，等等。比如通過
idea 項目名，你可以快速打開指定的idea項目，這比你每次點擊File -> Open -> 選擇項目目錄 -> ok，可是要快的多！ - open-falcon，小米開源的監控平臺，雖然使用上不太友好，但東西還是挺全的，需要的監控指標和功能基本都有
除了上面列的，還有很多日常可用的工具，基本只要你能想到的，都會有。在挖掘新的可用工具的同時，對於已經經常在使用的工具，可以深究，也許你會發現很多好用的feature，用好它，讓你事半功倍。
積極主動，要有owner精神
積極主動反映的是良好的工作態度，團隊需要積極的氛圍，領導更需要積極的人才。
owner精神，則需要較強的責任心，對所參與的業務以及團隊負責的業務負責，開發時積極推動項目進度，協調各方優先級，確保項目如期高質量上線；遇到線上故障時，積極響應，確保在最短的時間內解除故障。
溝通很重要，對上和對下
沒有什麼事情是溝通解決不了的，如果有，就多次溝通。
對上溝通，能讓領導對你有所知，有所期望，可能還會有額外的指導，能及時暴露風險，儘早解決；對下溝通，能讓你帶的小夥伴感受到溫暖，知道你時刻在關注着他，這是正向反饋。另外，你也能及時瞭解他當前的狀況，如有困惑，幫助他解決，讓他少走彎路；如有新的想法，拿出來討論，或許會給你帶來新的啓發。
愛鑽研，有技術追求
我在面試的時候，經常會看這一點。對於愛鑽研，有技術追求的候選人，他首先一定是自驅力不錯的，因爲技術鑽研這個事兒純粹是出於個人意願，能堅持下來，不容易。其次，他對於技術是有好奇心的，好奇心會驅使他去研究這裏面的細節，搞清楚原理，不會浮於表面。
反對過度設計與優化
技術架構一定是依託於業務的。
公司發展的不同階段，業務量級的不同，所需要的技術架構是不一樣的。初創期，業務規模小，產品迭代速度快，此時需要的是快速支持，快速開發，比如很多統計數據的場景就直接實時計算了，後端服務可能就是一個單體應用，這些都是可以接受的；隨着業務發展，業務形態多樣化，用戶量快速增長，導致系統壓力、複雜度倍增，此時就需要考慮微服務拆分、分佈式、性能優化、Redis緩存、分庫拆表等技術方案了。
技術架構除了要考慮能否支持業務發展，技術先進性外，也要考慮成本，這裏面既有數據庫、服務節點等資源成本，也有開發成本，更多時候是取一種折中方案，收益最大化。
成也經驗，敗也經驗
過去的經驗能讓我們在處理新的問題時有參考依據，儘量少走彎路，通常這是沒問題的。但有一個誤區是，過分相信此前的經驗，認爲那絕對是對的。工作中就遇到過這類case，關於thrift新增字段，是否需要設置爲optional的，同事A很自信地認爲用默認的required就行，因爲之前這麼幹過沒問題。但很快實驗表明，新增required字段，會導致新老版本不兼容，call端會報異常。
經驗有對有錯，我們需要有質疑心態，不能盡信之。
同步更新到原文