程序員修煉之道-注重實效

本篇文章是閱讀《程序員修煉之道——從小工到專家》第一章 「注重實效的哲學」 的筆記。有了一些開發經驗後再看這本書會比較有感觸，本書第一章講了一些對程序員最基本的要求，若是你正在進行職業規劃，那麼這本書有很好的參考意義。下面我結合本身的經歷聊聊第一章的內容。

責任

責任是作一切事情得前提，小到對本身的代碼，大到人生規劃，我想這也是做者把它做爲第一章第一段的緣由。責任是你主動承擔的東西，固然若是這件事超過了你的控制範圍，你有權不對它負責。不然的話你須要切實負起責任，即便過程當中犯了錯誤也應該坦誠認可，而不是找各類藉口。我以爲大部分程序員都會對本身的代碼有很強的的責任心，畢竟它就像孩子同樣，固然責任心太強每每會致使不肯認可一些錯誤。其實在職場中領導也比較喜歡那些可以主動認可錯誤的員工，誰也不能保證不犯錯誤，但對於犯了錯誤藏着掖着甚至亂甩鍋的員工，領導可能更不放心交付他更重要的任務。

軟件的熵

熵是一個物理學的概念，指的是某個系統中 「無序」 的總量，當軟件中的無序增加時，咱們稱之爲 「軟件腐爛」。至於什麼狀況會致使軟件腐爛，做者舉了一個 「破窗戶」 的例子，也就是咱們常據說的 「破窗理論」。簡單來講，

一扇破窗戶，長時間不修理，會給人們帶來一種廢棄感。因而又破了一扇窗戶，人們開始亂扔垃圾，亂塗亂畫，最終房屋的結構遭到嚴重破壞，且超出了業主的修理程度，從而廢棄感變成了現實。

破窗理論啓發了警察部門對一些輕微的案件也嚴加處理，防止大案件的發生。

在軟件開發中，低劣的設計、糟糕的代碼和低質的文檔等，都是 「破窗戶」，應該看見一個修一個，不能讓這種無序的狀態愈來愈嚴重，致使軟件腐爛。固然咱們可能沒有時間、精力去清理全部的 「破窗戶」，咱們能夠加一些 TODO，或者集中整理成文檔，拉一個專項專門處理。因此說，沒有很差的程序員，只有很差的設計、代碼和文檔。

石頭湯與煮青蛙

咱們開發過程當中，須要其餘團隊配合的時候，每每容易出現其餘團隊對咱們所作的事情的漠視、拖延。這時候比較好的作法是，咱們須要先把本身的想法進行落地，設計並開發出一個第一版，有一些成就積極與你們分享。當其餘人看到這個東西正在走向成功的時候，別人就會願意幫助咱們，最終共同協做完成項目，固然成果也要與你們共享。爲了說明這個問題，做者講了一個故事，

有三個飢餓的士兵，路過一個村莊，因爲多年的戰亂，村民的食物也很匱乏。因而，士兵們便煮了一鍋水，裏面放了幾塊石頭。士兵告訴驚訝的村民說這是 「石頭湯」，若是放一點胡蘿蔔會更鮮美，一個村民就跑開去拿胡蘿蔔。士兵又說放點土豆會更好，另外一個村民回去拿土豆。接下來不斷有人拿東西，食物變得愈來愈多，湯愈來愈豐盛，最終士兵和村民一塊兒享用了一頓美餐。

這就是 「石頭湯」 的案例。固然，工做中也會碰到有些團隊就是不配合，就像有些村民就是不肯意把本身私藏的東西拿出來。這也沒辦法，或許別人有更重要的事情去作。至少這個案例給了咱們一個解決這類問題的新視角。

從村民的角度來，這個案例也告誡咱們視野不要太狹窄，要關注到別人作的事情，若是是一件值得去作的事情就要積極主動地參與進去，留心大圖景。不要執拗地只負責本身那一塊的內容，不要作溫水裏的青蛙。因此，石頭湯和煮青蛙看似兩個獨立的案例，卻有必定的聯繫。

用戶的參與

完美的軟件須要用戶的參與，由於一般咱們是爲別人編寫軟件。除了軟件的功能需求，還要關注交付時間、軟件質量等需求，無視用戶的需求，一味地追求新特性、粉飾代碼並非有職業素養的作法。以我所從事的大數據工做爲例，其實咱們的用戶就是運營、產品，若是無視他們的數據需求，一味地增長一些酷炫的指標，可能對分析產品並無什麼幫助，顯然這樣作是不對的。一樣，爲了交付期限、功能需求而無視工程質量的作法也不可取。因此，咱們常常須要在知足用戶需求與完美的工程實踐之間權衡。

知識資產

咱們常常聽到說程序員是吃青春飯的，也就是說知識資產是有時效性的。隨着咱們的知識價值下降，咱們對公司或者客戶來講，咱們的價值也在下降。爲了阻止這樣的事情發生，咱們須要像對待金融資產同樣，對待咱們的知識資產。每一年學一門新編程語言、每一個季度讀一本書（按期投資本身）。多接觸瞭解其餘的技術棧，好比：作前端的瞭解後端技術，作大數據的瞭解算法（多元化的投資）。關注新技術，在新技術流行前就花時間研究，當它流行時咱們已經領先了大部分人（低買高賣）。要常常評估本身掌握的技術在市場上中的地位，若是已經涼了，須要果斷放棄把經歷放到新的方向（週期性地從新評估資產）。咱們常常拿老外來反駁程序員吃青春飯，看完這部份內容才發現，原來老外把知識資產當作了金融資產，因此才能保證本身的價值。

交流

雖然程序員生活中不善言談，但在工做中每每須要大量的溝通，小到接口協議，大到架構設計。交流一方面是爲了推動本身的工做，另外一方面是爲了輸出本身的觀點，創建本身的影響力。同時交流的過程須要注意一些細節，好比：瞭解聽衆，選擇溝通的時機，選擇溝通的風格，溝通前注意本身的思路、文檔是否清晰，交流中要傾聽別人意見、讓聽衆參與，溝通後及時總結、回覆他人。

小結

本篇內容各個小結看似比較獨立，但實際上是有必定的聯繫的。首先責任是後續因此內容的一個前提。其次，做爲程序員咱們要把本身的工做作好，「軟件的熵」 告訴咱們要立足於咱們本身的工做，要解決本身軟件裏的的「破窗戶」。當咱們把本身的事情作好，須要別人參與到咱們的軟件中，組成一個大的協做體的時候，須要咱們怎麼去協做，即是 「石頭湯與煮青蛙」 一節的內容。咱們開發軟件，最終要解決用戶的需求、爲用戶創造價值，因此這個過程要有 「用戶的參與」。雖然目前咱們開發出了讓用戶滿意的產品，但過程當中咱們用到的知識有時效性的，「知識資產」 這節告訴咱們若是讓本身有價值。最後提到的 「交流」 是爲了讓咱們上面全部的努力可以輸出，創建本身的影響力。

歡迎關注公衆號「渡碼」，我將分享更多優秀書籍的內容