讀codelife有感

春節在家閒暇無事的時候看看書，翻到之前讀的codelife，決定記錄一下看後的心得（俗稱讀後感）

1. 技術是爲業務服務的，要深入理解這一點。

程序員的迷茫不只僅是面對技術繁雜的無力感，更重要的是由於長期埋沒於軟件世界的浩大分工體系中，沒法看清從業務到軟件架構的價值鏈條，沒法清楚定位本身在分工體系的位置，處理很差自身與技術，業務的關係所致。

這句話我深有體會，寫代碼寫的多了，不免會煩躁，以爲本身寫的代碼沒有創造出價值，沒有成就感。這是因爲咱們僅僅處於一個生產鏈條的一環，咱們只關注自身，並無把握整個生產鏈條，從而不能知道咱們這一環在整個鏈條中佔有一個什麼樣的位置，咱們就像一隻沒有頭的鳥，一隻在扇動翅膀，殊不知道飛向何處。
試想一下，若是我是公司的老闆。個人目的很簡單，就是盈利，爲了達到盈利，我須要開發軟件，實現業務。真正實現盈利的是業務，只要軟件能很好的實現業務，呈如今客戶面前，就能實現盈利，就這麼簡單。
因此，接下來，進入到軟件開發，固然軟件開發是一個系統的工程。我須要產品經理理解業務，整理出需求，設計出原型；把原型交給ui來設計出好看的界面；再把先後臺開發叫到一塊兒開會討論開發具體事宜。咱們每每須要思考，爲何要有這些功能，這些功能爲何要這麼去設計，確定是有其道理的。

要深入理解業務，要明白，本身的每一行代碼，都是在實現業務，優化用戶體驗。

2. 想要工做出業績，必須認清系統背後的業務價值

leader問我對接下來的團隊有什麼計劃？我當時說了一堆什麼改進代碼質量，天天晨會，任務透明化，創建迭代機制等等，而後被各類批駁一通。

這一點我也有體會。去年在九度網絡擔任前端開發經理，公司的軟件已經上線，處於空檔期，老闆叫我寫架構文檔，接下來的計劃等等。我當時也是說了很對泛泛而談的東西，什麼code review，小組會議，代碼規範什麼的，結果老闆也是不滿意。當時有一個技術難題，把公司的業務模塊化，經過後臺實現業務的組裝，這個問題我當時想了好久沒有拿出好的解決方法，這一點上老闆很是失望。其實什麼代碼規範的東西，老闆根本不關心，他只關心業務能不能知足，功能能不能實現，由於這纔是賺錢的根本。

業務固然要理解，可是也不必深刻研究，那是老闆的事，除非你要本身創業。做爲一個技術人員，技術纔是第一位的，你理解了公司的業務，也要學會用最合適的技術去實現這些業務，甚至用多種技術去實現這些業務，技術學到了是你本身的，而業務若是你不能用來創業賺錢，再深刻也沒有用。試想一下，你換了一家公司呢？新的公司有新的業務，你以前公司的業務不是沒用了嘛。

3. 分工緻使軟件開發效率的提高，同時也會致使人與人之間的矛盾從而增長軟件開發成本

好比開發人員負責開發週期負責完成軟件研發，測試人員負責對開發人員交付的 成果進行測試等，因而就造成了分工。一旦分工造成，每個分工組織都會有本身的 價值追求，架構師關注的頂層的價值即軟件系統可否支撐業務增加被分工的形式打 碎到各個組織中。分工是有其價值的，他使得複雜昂貴的任務能夠被簡單、並行、 可替換的流水線方式解決。但長此以往，價值碎片化的問題就出現了，好比測試人 員只關注找出更多問題，開發人員只關注快速開發更多的系統，運維人員只關注保障系統穩定。

這彷佛是一個矛盾體，人與人之間的協做，是很是講究人員素質的。而且人與人之間的矛盾是沒法避免的，怎麼讓一個團隊發揮出最高效的狀態，是一個管理上的難題。

4. 做爲team leader 須要自己的思考以外，還須要外交能力

• 識別業務痛點，向上管理與老闆對焦
• 與下屬進行業務梳理，共同完成業務開發
• 與其餘部門進行協做，如測試部門，運維部門

向上管理是拔赤老師比較強調的內容，若是你的老闆不是前端，向上管理特別有 必要，你須要消除「語言差」、作必要的前端核心概念「科普」。
通常業務 / 產品老闆的關注點是:流量、轉化、跳失、體量、用戶體驗、規模化、 模式 / 產品創新等，要了解清楚現階段老闆的關注點是什麼，從本身團隊的維度思考 試圖給出到達路徑，這是很是重要的規劃線索。
向上管理不是有事沒事找老闆嘮嗑，而是注意溝通的有效與質量，提問題最好帶 着初步的解決方案，業務 / 產品老闆的時間有限，又存在「語言差」，相對複雜的內容 務必準備 PPT。

特別是理解業務，進行向上管理。有時候領導的想法沒有準確的傳達到本身這邊，或者本身意識到一些問題，這時候要主動找到領導，說出本身的想法，領導瞭解了你的想法後，若是合理會採納，不合理也不要緊，至少領導更加了解你了，也會更加信任你。