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

• 2019 年 10 月 3 日
• 筆記

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

責任

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

軟件的熵

熵是一個物理學的概念，指的是某個系統中 “無序” 的總量，當軟件中的無序增長時，我們稱之為 “軟件腐爛”。至於什麼情況會導致軟件腐爛，作者舉了一個 “破窗戶” 的例子，也就是我們常聽說的 “破窗理論”。簡單來說，一扇破窗戶，長時間不修理，會給人們帶來一種廢棄感。於是又破了一扇窗戶，人們開始亂扔垃圾，亂塗亂畫，最終房屋的結構遭到嚴重破壞，且超出了業主的修理程度，從而廢棄感變成了現實。破窗理論啟發了警察部門對一些輕微的案件也嚴加處理，防止大案件的發生。

在軟件開發中，低劣的設計、糟糕的代碼和低質的文檔等，都是 “破窗戶”，應該看見一個修一個，不能讓這種無序的狀態越來越嚴重，導致軟件腐爛。當然我們可能沒有時間、精力去清理所有的 “破窗戶”，我們可以加一些 TODO，或者集中整理成文檔，拉一個專項專門處理。所以說，沒有不好的程序員，只有不好的設計、代碼和文檔。

石頭湯與煮青蛙

我們開發過程中，需要其他團隊配合的時候，往往容易出現其他團隊對我們所做的事情的漠視、拖延。這時候比較好的做法是，我們需要先把自己的想法進行落地，設計並開發出一個初版，有一些成就積極與大家分享。當其他人看到這個東西正在走向成功的時候，別人就會願意幫助我們，最終共同協作完成項目，當然成果也要與大家共享。為了說明這個問題，作者講了一個故事，有三個飢餓的士兵，路過一個村莊，由於多年的戰亂，村民的食物也很匱乏。於是，士兵們便煮了一鍋水，裏面放了幾塊石頭。士兵告訴驚訝的村民說這是 “石頭湯”，如果放一點胡蘿蔔會更鮮美，一個村民就跑開去拿胡蘿蔔。士兵又說放點馬鈴薯會更好，另一個村民回去拿馬鈴薯。接下來不斷有人拿東西，食物變得越來越多，湯越來越豐盛，最終士兵和村民一起享用了一頓美餐。這就是 “石頭湯” 的案例。當然，工作中也會碰到有些團隊就是不配合，就像有些村民就是不願意把自己私藏的東西拿出來。這也沒辦法，或許別人有更重要的事情去做。至少這個案例給了我們一個解決這類問題的新視角。

從村民的角度來，這個案例也告誡我們視野不要太狹窄，要關注到別人做的事情，如果是一件值得去做的事情就要積極主動地參與進去，留心大圖景。不要固執地只負責自己那一塊的內容，不要做溫水裡的青蛙。所以，石頭湯和煮青蛙看似兩個獨立的案例，卻有一定的聯繫。

用戶的參與

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

知識資產

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

交流

雖然程序員生活中不善言談，但在工作中往往需要大量的溝通，小到接口協議，大到架構設計。交流一方面是為了推進自己的工作，另一方面是為了輸出自己的觀點，建立自己的影響力。同時交流的過程需要注意一些細節，比如：了解聽眾，選擇溝通的時機，選擇溝通的風格，溝通前注意自己的思路、文檔是否清晰，交流中要傾聽別人意見、讓聽眾參與，溝通後及時總結、回復他人。

小結

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

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