數據人如何提升自己
程序員和金融是當前社會里唯二的高薪水崗位，努力一把，每月幾萬收入都不是什麼問題。很多人拿程序員和醫生、律師作比較，其實是不同的，醫生、律師的經驗可以複用，年紀越大，經驗越多，收入也就越高。但程序員和金融民工，很多時候，學習的技能更新換代很快，需要不斷的學習新知識，才能跟上時代的步伐。
|0x00 學習能力如何成長
1.工具使用的熟練度：爲什麼工具使用要放在第一個呢？我們知道，寫代碼其實只佔用了日常約一半的時間，還有一半的時間在Bug的修復和問題的查找上。如果你能夠熟練使用開發工具，別人找一個Bug或者修復一個問題需要1小時，你只需要5分鐘就可以了，那麼你的效率就是別人的12倍。天下武功，唯快不破，在程序開發中，效率決定了一切。
2.書籍與文檔的閱讀：程序的知識是一個系統性的框架，不是單獨看一篇文章就能明白，也不是刷一遍文檔就可以理解，既需要看原版文檔熟悉知識，也需要多看書籍理解背後的設計思路。當然，由於歷史原因，絕大多數的文檔和書籍都是英文的，需要下一定的苦功夫來閱讀，但時間長了以後，隨着閱讀速度的提升，你能力的提升也就比之前高了很多倍。
3.參加行業會議：不論是工具使用，還是文檔書籍學習，都能夠讓我們深入瞭解某一項技術，但是對於業務的全貌理解，還是不夠的。如果有可能，應該多參加一些行業會議或者技術大會，或者閱讀一些相關材料，像Spring等，能夠在單位時間內，集中討論一個問題。當你沿着一個問題由淺入深的瞭解下去之後，你會發現，對於技術，你得到的不僅僅是經驗的提升，更重要的是興趣的積累，讓你能夠更有動力去持續的研究下去。
4.多做項目、多看源碼：僅僅學習是不夠的的，還需要配合實踐的過程。在項目中我們可以嘗試一些新的技術，可以通過寫demo的方式快速的瞭解某一些項目的原理。寫一個demo可能需要1個小時，但它給你帶來的直觀印象，是很長時間內遺忘不了的。另外，看源碼也是一項非常重要的技能，至少能夠瞭解優秀程序員是如何思考和編寫代碼的。同時，對於底層運行的一些細節，也有很大的幫助。當然，看源碼是一項非常浪費時間的事情，但有一些必要的源碼，還是要抽時間去閱讀和理解的。
|0x01 技術能力如何成長
1.Coding能力的提升：前面提到了，學習能夠很快的推動你經驗的積累，但是轉化爲實際技術能力的提升，還需要大量項目的練習。雖然LeetCode能夠教會你如何寫一個算法，但是完整的實現一個項目，給你帶來的提升還是非常大的。很多技術新人在初次面對大規模併發、批量上線、海量Bug、CodeReview、秒殺場景等情況下，會出現很大的不適應心理，寫起代碼來畏手畏腳，其實都是不熟悉導致的正常現象。這種業務會推動你去解決各種非常實際的問題，也讓你去學習更多平時意識不到的技術，比如Java中多線程、反射等場景。如果系統性能要求非常苛刻，你還需要去學習JVM的底層原理，以優化那些看起來非常繁雜的代碼。可以說，Coding能力的提升，都是項目逼的，但這也是最快的提升路徑。多一次內存崩潰，你就對GC行爲多一份瞭解。在Coding的過程中，對於知識的深度，要求比較高。
2.架構能力的成長：說起架構，大家的直觀理解都是各種的流程圖、框架圖、結構圖等，看起來非常的簡潔明瞭，似乎每個人照着畫個類似的圖，也可以當架構師。但是，實際的困難永遠是隱藏在圖片後面的，你很難理解圖上的一個方框，爲什麼要用這種框架，以及爲什麼要放在這個位置。當程序員從初級走向中級的過程中，一個最大的變化，就是原先被動接受的需求，開始變爲主動的跨部門溝通，一個標準的項目，至少要跨三個團隊，怎樣設計好整個框架結構、怎樣定義數據的模型、怎樣對接各自的接口，都是一些細碎但是重要的事情。尤其是異地多活等項目，當參與人數上升到一個數量級時，每個人都需要看懂整個架構，才能明白自己應該做什麼。一個好的架構，需要根據實際業務的情況，來突出研發的重點，確保幾個最關鍵的問題如何解決。在數據開發中，如果不能夠設計好整個流程，最直接的影響，就是數據的準確性受到比較大的挑戰。在這個過程中，架構的學習，對於知識的廣度，要求比較高。
3.思考問題的深入：通常而言，技術人員思考問題有三個階段。第一個階段是“能用”，不論怎樣的需求、不論怎樣的編程語言，首先把demo跑起來最重要；第二個階段是“會查”，當項目的代碼數量開始不斷增長時，所面臨的耦合內聚等情況變多，以往寫過的代碼會出現隱患，系統之間的關聯會出現問題，代碼的Bug數量也就隨之提升，如何快速的思考問題產生的原因，如何準確查到問題，決定了你項目開發的週期；第三個階段是“要懂”，解決Bug，最重要的是避免寫出Bug，優秀的程序員，很多時候不需要畫出什麼架構圖，只需要拿出一小段代碼，舉一個簡單的Case，大家都可以明白。懂一個項目，理解程序語言的運行原理、理解開源框架的設計思路，能夠讓你在項目開始前就理解可能出現的問題，並在第一次寫的時候就避免這些坑。說來說去，原理性的東西，是每個人最難遺忘的東西，但掌握原理的過程，是沒有捷徑的，是需要通過1萬小時理論逐步積攢出來的。
|0x02 偏業務與偏基礎的選擇
每個程序員，在技術達到一定的階段之後，都會面臨一個方向的選擇，那就是偏業務方向，還是偏基礎技術方向。以數據爲例，一部分人需要承接日常建設數據倉庫、應對產品需求的任務，對SQL開發、數倉理念、產品模型的理解要求很高，這種情況就是偏業務方向；另一部分人需要搭建對應的Hadoop平臺，優化MR/SQL的運行，優化開源框架，或者是偏向機器學習、人工智能的算法研發，這種情況就是偏基礎技術方向。
1.偏業務的思考：偏業務的方向，比較建議針對某一領域，持續的投入精力，這樣對於自身業務的發展未來會有比較好的預判，能夠意識到數據產品背後的商業價值。同時，對於複雜業務邏輯的抽象，也是搭建數據倉庫的一個非常重要的前提，這其中需要用到很多方法論與建模知識。最後，在數據倉庫搭建的過程中，對未來業務的變化，也需要留下一定的改進空間，因爲重構永遠是偏業務同學最頭疼和最花費時間的事情。
2.偏技術的思考：業務通常是能夠實現的，但技術不一定，對於自己研發方向的基礎性技術，要有一定的預判性，防止業務發展受到基礎技術缺陷的拖累。此外，基礎技術需要多看、多學，對於業界的技術發展方向要有自己的認知和判斷。最後，就是多練了，對於自己領域的基礎技術，要有非常好的技術深度，才能應對可能出現的各類問題。
|0xFF 如何做一名合格的TL
工作五年以後，隨着技術的完善和成長路徑的清晰，很多技術人接下來就要面對TL的問題了。TL就是Team Leader，團隊管理者的意思。互聯網公司的技術管理通常有兩個方向：負責技術和負責團隊管理。傳統公司的TL更多的是負責任務拆解、項目進度預估及風險控制等方向，而互聯網公司由於項目的長期性，不僅需要對業務有一個清晰的認知，還需要對於對應的技術有長期的聯繫和了解，能夠幫助團隊在遇到瓶頸時跨越大山。
彼得格魯克說過：“組織的目的，是讓平凡的人做出不平凡的事情。”一個團隊發展的怎樣，很大程度上取決於TL的管理方式。馬雲說：“人才的離職有兩種情況，一種是錢沒給夠，一種是乾的不爽。”後一種，就是TL所面對的直接挑戰了。那麼如何做一名合格的TL？
1.團隊建設：團隊通常會存在兩種比較常見的問題，一個是業務配合不規範，一個是跨團隊協作混亂。業務配合是重中之重，如果每個人都採用自己的習慣來寫代碼，那麼其他人在維護的時候，通常都比較頭大，一旦人員離職，交接的成本也非常高。因此業務配合是首要解決的問題，主要就是在流程與制度上。例如，技術的開發要有規範，定期CodeReview以統一開發思想；開發、上線、運維，要有明確的負責人，避免出現問題無人負責；與需求方對接要有明確的PRD或者需求文檔，按照流程協作，避免後期出現了問題被Diss。其次，針對跨團隊協作的情況，由於需求變更快、責任劃分不清晰，會極大的損傷團隊的積極性，至少在團隊內部，TL要能夠幫助大家進行需求的統一管理和分派，避免成員收到外部過大的影響。
2.團隊管理：團隊管理通常有兩種風格，一種是集權式的風格，定義清晰的工作目標，並且把任務分解的非常細緻，團隊成員能夠按照計劃一步步推進，以過程爲導向；另一種是放權式管理，只定義一個大的目標，做關鍵性的決策，但並不深入每個細節，不管控團隊成員的具體行爲，以結果爲導向。兩種方式沒有對錯之分，當業務流程比較清晰，骨幹員工能夠很快的領悟業務並主動開發時，推薦放權式的管理。但如果團隊剛剛建立，流程與制度沒有完善，開發的流程也沒有跑通的時候，推薦集權式的風格，讓團隊儘快的有序起來。
3.團隊文化：團隊文化是一個非常軟性的指標，但對於結果卻有着比較大的影響。例如，在以KPI爲導向的公司裏，很多人爲了避免故障，就不會主動的重構代碼，就像一句笑談：“沒有上線，就沒有故障”。再例如，很多員工時間長了以後，積極性會下降，很難主動去承擔更多的責任。在不好的氛圍影響下，優秀員工會被排擠，團隊的向心力也很難聚集，離職率也就居高不下。因此，從TL的角度出發，發揮自身的人格魅力，儘可能的爲團隊樹立榜樣，很重要。這裏提出五個建議：坦誠、公開、透明；平等相處；團隊關係和諧；主動承擔責任；樂於分享。
4.溝通輔導：我們平時的工作中，溝通佔據了相當大一部分比例，以數據開發爲例，大約50%的時間都在各種溝通上。但在程序員羣體中，能夠主動溝通、或者是高效溝通的人，非常少，很多人非常不善於表達自我。作爲TL，最有效提升團隊溝通水平的方式，就是一對一溝通。建議找一個比較私密的環境，定期與團隊成員做一些溝通，用心傾聽並切實解決員工的問題，在一些比較迷茫的問題上給予自己的建議和引導。或者，定期舉行團隊溝通會議，不談工作的內容，只談生活和想法，也能夠很好的建立溝通氛圍。如果都學不會，那就團建吧。
熱門文章
【您的在看，我的莫大鼓勵】
