不知不覺工做已三年半,準確的說是三年零五個月。在這過程當中,在技術和業務上的成長,多多少少都會有一些,但最大的收穫,仍是長見識。聊聊幾點感覺吧。java
別隻顧埋頭作事,要作「對」的事情。程序員
這是我的情社會,你的領導也只是普通人,他不太會有大把的精力去關注底下的人天天具體幹些什麼事情,這種狀況下,若是你只知道一味地埋頭作事,即使作了不少,加班累成狗,可是領導壓根不知道,是沒有任何意義的,典型的吃力不討好。不少時候是須要你主動向上彙報的!按期地跟領導保持正向溝通,積極反饋工做中遇到的問題以及本身的想法,讓領導感知到你的付出,固然有產出是最好的了。面試
什麼是「對」的事情?要有全局觀,審時度勢。當前領導最關心最迫切的事情,就是對的事情。舉個栗子,隨着用戶量的快速增加,系統的壓力愈來愈大,原有最初的系統逐漸暴露問題,甚至所以頻繁出現線上故障。這個時候,若是領導發起了「系統壓測」的任務,那麼當務之急,壓測就是最重要的事情,工做的重心應該以此爲準。即使此時業務上也有不少新的需求,你也應該作取捨,不然即使你作了一大堆需求,此時的領導根本無暇顧及,他所關注的必然是壓測的進度,千萬不能撿了芝麻丟了西瓜。shell
在遇到緊急狀況,如線上故障處理時,快速解決問題纔是關鍵。有的時候咱們容易陷入程序員慣有的思惟裏,遇到問題會習慣性地一上來就嘗試用代碼去解決,而忽略了一些非代碼的簡單處理方式,好比粘貼/複製、excel工具、sublime文本替換等。這裏列舉兩個工做中的小例子,深有感悟。數據庫
在一次故障處理過程當中,須要對一批指定用戶作一個操做,這個操做能夠經過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
這種「重複」的快捷方式。
產品有個導數據的需求,要將特定篩選條件下的用戶列表導出爲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的行尾是咱們須要的數據,其他都是無用信息,冗餘數據處理分爲以下幾步:
同事A後來聽我跟他講完個人實現方案,表示「秀了我一臉」,真實。。。。
好的工具能讓咱們極大地提高作事效率。
之前我對於平常開發工具的認知就是,夠用就行,不用太深究,專一代碼和技術。直到後來,當我見識到周圍的朋友如何熟練地經過各類工具快速達到目的的時候,感受真的被秀了一臉。
好的工具備哪些呢?筆者有個推薦清單:
idea 項目名
,你能夠快速打開指定的idea項目,這比你每次點擊File -> Open -> 選擇項目目錄 -> ok,但是要快的多!除了上面列的,還有不少平常可用的工具,基本只要你能想到的,都會有。在挖掘新的可用工具的同時,對於已經常常在使用的工具,能夠深究,也許你會發現不少好用的feature,用好它,讓你事半功倍。
積極主動反映的是良好的工做態度,團隊須要積極的氛圍,領導更須要積極的人才。
owner精神,則須要較強的責任心,對所參與的業務以及團隊負責的業務負責,開發時積極推進項目進度,協調各方優先級,確保項目如期高質量上線;遇到線上故障時,積極響應,確保在最短的時間內解除故障。
沒有什麼事情是溝通解決不了的,若是有,就屢次溝通。
對上溝通,能讓領導對你有所知,有所指望,可能還會有額外的指導,能及時暴露風險,儘早解決;對下溝通,能讓你帶的小夥伴感覺到溫暖,知道你時刻在關注着他,這是正向反饋。另外,你也能及時瞭解他當前的情況,若有困惑,幫助他解決,讓他少走彎路;若有新的想法,拿出來討論,或許會給你帶來新的啓發。
我在面試的時候,常常會看這一點。對於愛鑽研,有技術追求的候選人,他首先必定是自驅力不錯的,由於技術鑽研這個事兒純粹是出於我的意願,能堅持下來,不容易。其次,他對於技術是有好奇心的,好奇心會驅使他去研究這裏面的細節,搞清楚原理,不會浮於表面。
技術架構必定是依託於業務的。
公司發展的不一樣階段,業務量級的不一樣,所須要的技術架構是不同的。初創期,業務規模小,產品迭代速度快,此時須要的是快速支持,快速開發,好比不少統計數據的場景就直接實時計算了,後端服務可能就是一個單體應用,這些都是能夠接受的;隨着業務發展,業務形態多樣化,用戶量快速增加,致使系統壓力、複雜度倍增,此時就須要考慮微服務拆分、分佈式、性能優化、Redis緩存、分庫拆表等技術方案了。
技術架構除了要考慮可否支持業務發展,技術先進性外,也要考慮成本,這裏面既有數據庫、服務節點等資源成本,也有開發成本,更多時候是取一種折中方案,收益最大化。
過去的經驗能讓咱們在處理新的問題時有參考依據,儘可能少走彎路,一般這是沒問題的。但有一個誤區是,過度相信此前的經驗,認爲那絕對是對的。工做中就遇到過這類case,關於thrift新增字段,是否須要設置爲optional的,同事A很自信地認爲用默認的required就行,由於以前這麼幹過沒問題。但很快實驗代表,新增required字段,會致使新老版本不兼容,call端會報異常。
經驗有對有錯,咱們須要有質疑心態,不能盡信之。
同步到原文