《程式員修煉之道——從小工到專家》 讀書筆記

軟體工程管理課程也進行了快兩個月了，讀書筆記也漸漸寫到第四篇了，還真的要感謝這門課以及教授這門課程的老師，讓我在這麼短的時間内閱讀了這麼多軟體工程相關書籍，從《人與神話》提到的溝通問題，《人件》裡注重的以人為本，《大教堂與集市》提到的開源與黑客，感覺自己對軟體工程這門學科有了更深的認識，有了更廣闊的了解，也培養起了我喜歡閱讀的興趣，會主動自己尋找相關書籍進行閱讀，并養成了一邊閱讀一邊記筆記的好習慣。

這次的書籍是《程式員修煉之道》，作為預備程式員，讀讀還是很有必要的，昨天是“1024程式員”節，感覺作為程式員還有節日挺有意思的，可能這就是一種職業自豪感吧。這本書是從程式設計出發，穿過專業化和技術問題，按照核心問題，即需求，來展開程式設計相關的思考。

這裡面針對程式員，反複提到一個形容詞，就是“注重實效”。根據書中所講，結合我的了解，我認為注重時效這個詞主要展現在責任上，對自己負責，對自己的代碼負責，對自己的代碼中的錯誤負責。“最大的弱點就是害怕暴露弱點”，我非常認同這句話，要坦然面對自己的錯誤其實并不是一件容易的事情，不僅要面對，還應該應對，比如提前預估風險，提前制定應急計劃，提供各種選擇而不是借口。

第一章還提到一個我最近思考比較多的概念，就是“知識資産”。知識資産包括很多，不僅是專業技術，更有用的我覺得是經驗。知識資産是需要經營的，途徑也有很多，無論是保持學習、參加活動、跟上潮流……總之，不要就此止步，要抓住學習的機會，利用碎片化的空閑時間，說不定哪天所學就起到作用了呢。但也不能像我最近一樣，雖然渴求知識，卻因為要學的知識太多而感到有些許焦慮，感覺時間不夠用。我想，隻能慢慢來，認真規劃，一個接一個的去執行，學到就是賺到。

書中中間幾個章節提到了程式設計相關的技術經驗方法，但由于我個人不是很喜歡寫代碼，是以看的也不是那麼感興趣，有幾點我覺得對我來說是可以學習并找機會實踐的。一是注重shell環境。因為平時都是GUI界面，“所見即所得”同時可以了解為“所見即全部所得”，shell環境可以通過建構指令序列，讓很多事情自動化，可以大大提高生産率。而我很少使用shell指令，是以不太熟悉它的好處，接下來的時間想認真學習一下這部分，感受一下它的高效。二是寫代碼要偏執。這裡的偏執其實是一個褒義詞，針對自己的錯誤進行防衛性編碼，減少出錯的機率并制定應急方案。要批判的思考所有的代碼，讓代碼變得有價值。三是黑闆概念。它解除了對象之間的耦合，提供一個類似論壇的平台，讓知識的生産者和消費者可以匿名、異步的交換資料。我覺得這有點像精益軟體工程裡的kanban，雖然不是一個東西，但其實都是将一個過程可視化，讓更多人參與去交換資訊，提高生産效率和品質。

在書後面一個章節提到了需求。在軟體産品規劃課程上，老師也講到了需求相關的内容，更偏向使用者體驗方面，但其實思考思路是大同小異的。需求很少浮于表面，要去深挖，要在使用者的角度去考慮需求，與使用者一同工作，像使用者一樣思考。使用者的需求要形成一個完整的故事，誰在做什麼事情的時候遇到了什麼問題，他是怎麼解決這個問題的，而我們又能提供什麼更好的解決方案。這是個典型的使用者故事模闆，思考清楚這個其實需求就有一個模糊的概念了。這個時候擁有形式化的模闆也很重要，這樣可以確定包括了用例中所需的所有資訊，減少考慮或記錄的遺漏點。

注重實效不僅存在于程式員層面，也存在于團隊層面。品質是一個團隊問題，團隊整體都不應該容忍破窗戶，大家都應該認識到品質對于軟體開發的重要性。而且團隊的每個成員都應該時刻主動去監視環境的變化，如果大家都安心的認為團隊中總會有人在處理或關注着某個問題而不去親自在意，這樣就容易導緻問題的遺忘，最後就如同溫水煮青蛙，問題總有一天會突然爆發。

以上就是我看完這本書後感觸最深的部分，其他内容其實也産生過同理心，但是由于篇幅原因就不再贅述，總之，這本書對我啟發最大的一點就是，要做一個注重實效的程式員，就是這樣。