1. 程式人生 > >程式設計師修煉之道-注重實效

程式設計師修煉之道-注重實效

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

責任

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

軟體的熵

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

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

石頭湯與煮青蛙

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

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

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

使用者的參與

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

知識資產

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

交流

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

小結

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

 

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

 

&n