邁向大師之路
the pragmatic programmer

你擁有改變的能量

你的工作環境糟糕嗎？你的工作無聊嗎？請試著改變它，但也不要試到天荒地老。

如果你擁有的技術看起來已落後，請從自己的時間擠出時間來學習看起來有趣的新東西。您是在為自己投資，所以趁下班時間做這件事是合理的。

想要遠端工作嗎？你有問過可行性嗎？如果得到的答案是不行，那就找一個說可以的人。

您的團隊必須能夠信任和依賴您，您也需要放心地依賴他們每個人。

責任感代表您積極認同的東西，因為您作的承諾是要確保某件事要被正確完成，但您不要一定能直接控制該件事的所有細節。除了盡自己最大的努力之外，您還必須分析形式，找出自己無法控制的風險，您有權利不為做不到、風險太大或道德含義太含糊的情況承擔責任。

當您接受承擔結果的責任時，別人就會認為您要為結果負責。所以當您犯了錯或判斷錯誤時，誠實承認它，並嘗試提供解決問題的選擇。

在您打算去見任何人，並告訴他們為什麼有些事情做不到，為什麼有些事情會延後，為什麼有些事情會失敗之前，請先暫停一下，先把自己的想法告訴黃色小鴨或你的貓看看，你的藉口聽起來是合理還是愚蠢的？

請在腦袋中演練對話，猜測別人可能會怎麼回應？他們會不會問您：「您試過這個嗎？」「你沒有考慮過嗎？」您將如何回應？在您去告訴他們壞消息之前還能試試別的嗎？

有時候，您根本就知道他們會說什麼，所以就不用去麻煩他們了。

不要找藉口，請提供解決問題的選擇，而且不要說做不到；說明一下做什麼才能挽救這種情況。

也許你需要額外的資源來完成這項任務，又或者您需要的是花更多時間和使用者相處？或者您需要的就是您自己：學習技術閱讀書籍或進修課程會有幫助嗎？不要害怕去要求或承認您需要幫助。

在大聲說出那些藉口之前，試著把藉口毀掉掉。

破窗效應

啟動疲勞

請不要看並快速的回答，您頭頂的天花板有多少盞燈？房間裡有幾個出口？有多少人？有沒有什麼被亂放，看起來不屬於這裡？

這是一項關於態勢感知（situational awarenss）的練習，養成仔細觀察周圍的習慣，然後對您的專案做同樣的事情。

我的註解：

負責任包括專案執行中必須監控進度不要在炸了以後才尋求協助，然後去引導別人調整並且維持專案品質和進程。

足夠好的軟體就是最好的軟體

您可以訓練自己撰寫足夠好的軟體，對於使用者、未來的維護者、對於您自己的內心平靜來說足夠好的軟體。您會發現您更有效率，您的使用者也更滿意。您的程式實際上越早完成越好。

足夠好不是隨便，我們只是主張給使用者一個機會，讓他們參與到這個過程中來，決定什麼時候您的產品能夠滿足他們的需求

通常是您為別人寫軟體，所以你會記得要找出他們想要什麼。但是你可曾問過他們想要多好的軟體嗎？雖然有些情況我們沒得選，例如你開發的可能是心臟起搏器，那對於好的定義將更加嚴格。

但是如果你正在開發一個全新產品，您將面臨不同的限制，我們可能有交付計畫，可能有現金流限制，如果因為想做優化就忽略使用者的需求，是一種不專業的表現。承諾不可能實現的完成時間，和為了滿足最後期限而偷工減料，兩者不專業的程度是相同的。

批判性思考

您需要確保自己知識資產中的知識是準確的，不受供應商或媒體炒作的影響。小心那些堅持他們的教條是唯一答案的狂熱者，就算它可能適用於你，也可能不適用於你的專案。

永遠不要低估商業主義的力量。不要因為一個網路搜尋引擎列出的熱門搜尋就決定它是最佳匹配；內容提供者可以付費來獲得更高收入。書店推薦的書並不代表它是好書，甚至不代表它很受歡迎；可能是有人花錢把它放在那裡的。

五個為什麼

這對誰有好處？
時空背景是什麼？
何時何地可用？
再之後會發生什麼事？
為什麼會有這個問題？

溝通

我們花幾個小時開會，我們和使用者合作試圖瞭解他們的需求，昂。我們撰寫程式碼將我們的意圖傳達給機器，並為未來的開發人員記錄我們的想法。我們寫提案和備忘錄，要求和調整資源，報告我們的狀態，並建議新的方法。我們一天中大部分的時間都花在溝通交流上，所以我們需要把它做好。

把我們的母語當成另一種程式語言，像撰寫程式碼一樣撰寫自然語言，遵行DRY原則，ETC，自動化等等。

瞭解您的聽眾

只有成功傳達您想傳達的東西時才算是在溝通，光說話是不夠的。為此，你需要瞭解聽眾的需求、興趣和能力。我們都參加過這樣的會議，一個開發高手在市場副總裁眼前長篇大論一些神秘技術的優點。這不是溝通，只是在講話，而且這樣做很煩人。

與所有形式的溝通一樣，這裡的技巧是收集回饋。不要只是被動等待問題的出現：請主動詢問他們，看看肢體語言和面部表情。神經語言程式設計的前提之一是「您做溝通的意義就是得到的回應」，請在溝通的過程中，不斷提高對聽眾的瞭解。

知道您想說什麼

小說作者在開始寫作前會規劃他們的作品，但是寫技術文件的人卻通常樂天地坐在鍵盤前輸入：
1.介紹
接著腦中浮現什麼就輸入什麼。

請計畫好您想說什麼，列出一個大綱。然後問問自己，「這是否傳達了我想要向我的觀眾表達的東西，並對他們產生實效？」請重複地精煉它，直到它符合您的要求。

選擇合適的時間
請在對的時間，說對的內容。有時只需要一個簡單的問題，「現在是討論...的好時機嗎？」

選擇一個風格
請將你的產出調整成適合您的聽眾。有些人想要一個正式的「只說事實」簡報，另一些人喜歡在談正事之前進行一次前置長談。要思考聽眾在這方面的技能水準和經驗如何？他們是專家嗎？新手嗎？您需要牽著他們的手逐步漸進，或者適合廢話少說？如果您不知道答案，就去問。

但是請記住你的溝通任務只完成了一半，如果有人說他們只想要你用一段話描述某件事，而您覺得不花幾頁的時間無法說明，那就直接一告訴他們，這種回饋也是一種溝通。

使它看起來棒棒的
您的想法很重要，應該有一個漂亮的工具來將您的想法傳達給您的觀眾。

讓您的聽眾參與
製作文件的過程比最後製作出來的文件還要重要。如果可能的話，讓你的讀者參與文件的早期打稿。聽取他們的回饋。並理解他們的想法。

當一個聆聽者
透過提問以鼓勵人們交談，或者要求他們用自己的話重新詮釋目前的討論，把會議變成一場對話，會更有效地表達您的觀點。

回覆別人
請經常回覆郵件跟訊息，即使只是簡單地回覆一句「我過會打給你」。讓人們瞭解情況會讓他們對偶爾的失誤更加寬容，讓他們覺得您沒有忘記他們。

您說了什麼話，與您如何說這些話一樣重要。

文件

我們不需要為每個函式、資料結構、型別宣告等加上註解，這種沒人性的註解撰寫方法實際上增加了維護程式碼的難度：因為這樣您在做修改時就變成要維護兩種東西。所以請不要為非api撰寫它為什麼做某樣事，他的企圖和目標，因為程式碼本身已經說明如何完成，因此為它撰寫註解是多餘的。

在程式碼中的註解，記錄專案中那些在其他地方無法紀錄的部分，例如在工程上權衡得失、為什麽做了決策、放棄了哪些其他的選擇等等。

網路溝通

按下送出前再檢查一次。

檢查有沒有錯字或者拼寫錯誤。

保持格式簡單明瞭。

盡量少引用，沒有人喜歡引用原文一百行，最後只加上「我同意」三個字的郵件。

如果引用別的人的話或者郵件，一定要註明出處，在社交平台也是。

不要發怒，也不要表現得像挑釁者，除非您也想別人也這樣對你，並且纏著您。不想當著別人說的話，也別在網路上說。

發送前檢查收件者清單。

ETC ,Easy to Change
etc是一個價值觀，不是規則。

考慮到不確定未來會發生什麼形式的修改，你總是可以回到容易改變的道路上，試著讓你寫的東西變得可替換。這樣無論未來發生什麼，這段程式碼都不會成為絆腳石。

把這當做培養直覺的一種方式，在您的工程日誌中記錄這種情況：有哪些選擇，以及關於修改的一些猜測。在原始檔案中留下標記。然後當這些程式碼需要修改時，您將能回顧並給自己回饋。下次遇到類似的選擇岔路時，這可能會有幫助。

DRY,dont repeat youself

大多數人認為維護始於應用程式發佈之時，維護代表著修復bug和增強功能，我們認為這些人錯了因為程式設計師應該一直處於維護模式，因為我們對周遭事物的理解每天都都在變化，又或者環境改變了，不管出於什麼原因，維護都不是一個獨立的活動，而是整個開發過程中的一種常態活動。

當我們執行維護工作時，我們必須找到並修改事物中的表示形式，那些被嵌入到應用程式中的知識封裝。問題在於知識在規格中，我們開發的程式中是很容易發生重複，當這種情況發生就是維護的噩夢，所以一切在應用程式發佈之前就開始了。

在一個系統中，每一條知識都必須有一個單一的、明確的、權威的表述。

DRY是指知識以及意圖上的重複，它是在兩個不同的地方表達相同的東西，包含可能。使用兩種完全不同的表達方式。

這裡有一個嚴格的辨識方式，當你必須修改一處程式碼，卻還要修改文件或者資料庫結構，如果是這樣，你的程式碼就不符合DRY原則。

不是所有重複的程式碼都屬於知識複製

書中以兩個一模一樣的程式碼舉例，唯一差別在於一個是vaildate_age(value)一個是vaildate_quantity(value)，雖然程式碼相同，但是他們代表的知識是不同的，這兩個函式驗證兩個具有相同規則的獨立事物，這是一種巧合不是重複。

我的註解
單一責任原則同時要求一個程式應該只有一個被修改的理由，所以兩種驗證規則分開寫也可以符合單一職責的原則。

當一個模組代表一個資料結構時，您都必須將使用該結構的所有程式碼實作在該模組內部。在可能的狀況下，始終使用存取函式來讀寫物件的屬性，這樣的設計將使未來添加功能變得更容易。

模組提供的所有服務都應該透過統一的標記法提供，這種標記法不會洩漏服務是透過儲存還是透過計算實作的。

內部api的重複
請尋找允許以某種中立格式建立api的工具。這些工具通常會生成文件，會仿製api、功能測試和API的使用端，後者使用多種不同的語言。理想情況下，該工具將所有API儲存在一個中央儲存庫中，允許跨團隊共用。

外部API之間的重複
使用OpenAPI這類的東西撰寫正式規格，這種方法允許您將API規格匯入到本地API工具中，提升與該服務的整合度。

資料來源的重複
許多資料來源允許您修改它們的資料模式，這可用來消除它們與您的程式碼之間的許多重複。你可以從資料模式生成容器，而不是手動建立容納此儲存資料的程式碼，許多現有框架都能為你完成這項繁重的工作。

還有另一種選擇，而我們通常更喜歡這個選擇，與其撰寫程式碼來表示具有固定結構的外部資料（例如結構或者類別的實例），不如將其放入key/value資料結構中（map,hash,dictionary,甚至物件）。

這樣做是有風險的，你會丟失很多你正在處理資料的安全性資訊。因此，我們建議向這個解決方案添加另一個層面：一個簡單的表格驗證套件，他的功能至少能驗證你建立的資料結構（例如map）包含您需要的資料（同時驗證格式正確）。您的api文件工具有可能支援這個功能。