相較于全書眾多的干貨筆記，這篇文章是個別思想經驗的總結，希望和大家交流，
武俠影視劇中，江湖各路豪杰可以多年苦苦追尋一本武林秘籍，希望能夠得到高人指點，從而功力突飛猛進，對于程式員來說，《程式員修煉之道》就是頂尖高手的智慧結晶，它的第一版風靡了二十年，更難能可貴的是，二十年后原作者又與時俱進重寫了第二版，我們把這本書認真讀了一下，相較于全書眾多的干貨，這篇文章只是個別思想經驗的總結，希望和大家交流，如果能激發大家對原書的興趣，自然更好，
能適應使用者的就是好的設計，對代碼而言，就是要順應變化，因此要信奉ETC原則（Easier To Change，更容易變更）——就該如此，
據我們所知，無論是什么設計原則，都是ETC的一個特例，
為什么解耦很好？因為通過隔離關注焦點，可讓每一部分都容易變更——此謂ETC，
為什么單一職責原則很有用？因為一個需求變化僅體現為某個單一模塊上的一個對應變化——此謂ETC，
為什么命名很重要？因為好的命名可以使代碼更容易閱讀，而你需要通過閱讀來變更代碼——此謂ETC！
我們常講要對線上變更有敬畏之心，ETC原則是一個很重要的意識，因此我們在作業中要思考怎么樣設計代碼才能更方便、更高效、更不容易出錯地變更，當我們針對一個任務有多個實作方案時，可以考慮把是否符合ETC原則加入到選擇指標中，
比如說代碼依賴某些值，這些值后面可能會變動（可能是因為業務邏輯變了，或政府出了個新政策或用戶的需求變了等等），那可以把這些值放在外部，作為配置項，
我們認為，想可靠地開發軟體，或讓開發專案更容易理解和維護，唯一的方法是遵循下面這條被稱為 DRY 的原則：
在一個系統中，每一處知識都必須單一、明確、權威地表達，
DRY原則大家也很熟悉，但是如果認為DRY只是說不要復制粘貼原始碼，那還遠遠不夠，DRY指的是你對知識和意圖的復制，哪怕用兩種不同的形式在不同的地方，它們表達的東西可能是一回事，
當我們要改變一個業務邏輯時，是否在不同的地方以不同的形式進行了變更？包括代碼、檔案、資料庫Schema、資料結構、注釋等等，如果我們的這個邏輯（或知識）在那么多地方重復表達，那么可以想到的是，用不了多久這些地方的資訊就會不同步；如果你想確保它們同步，那每次變更就要花更多的時間和精力，
每個專案都有自己的詞匯表：對團隊有特殊意義的術語，“Order”對于開發在線商店的團隊來說是一回事，而對于記錄宗教團體的世系的應用程式來說，意味著完全不同的另一件事，重要的是，團隊中的每個人都知道這些詞的意思，并始終如一地使用它們，
一種方法是鼓勵大量的交流，如果每個人都參與結對編程，并且頻繁地交換結對，那么術語就會滲透性地傳播開來，
另一種方法是使用專案術語表，列出對團隊有特殊意義的術語，這是一個非正式的檔案，可以在 wiki 上創建并維護，也可以將索引卡片掛在墻上，
過一段時間，專案術語將會有自己的生命，隨著每個人都熟悉了這些詞匯，就能夠把這些術語用作簡稱，準確而簡潔地表達許多意思，（這正是模式語言所指，）
維護一個概念串列，可以保證團隊交流的準確性，避免你說的是A，我理解成B的情況，一個專案中有不同的角色，業務方、產品、前端、后端、演算法、資料，對于一起開會時經常提起的概念，大家的理解并不一定一致，舉個簡單的例子，比如業務方有個二分類的需求，要從一些商戶中找到其中不合規的商戶，模型預測結果如下圖所示，但是一個人以為的準確率是(a + d) / (a + b + c + d)，另一個人以為的是d / (b + d)，如果沒有在專案之初明確下來大家關注指標的具體含義，那可能出現各說各的的情形，技術按照一個計算邏輯承諾并達成了準確率指標，業務方按照另一個邏輯計算后發現準確率遠遠沒達到，這會給團隊合作帶來障礙，
維護一個專案概念串列還有一個好處，就是在制定串列的同時會推敲這個概念的說法是否合適，舉一個場景，政府規定購買某些藥必須有48小時內陰性的核酸檢測結果，要用模型識別訂單是否需要攔截，有人把”識別通過“說成”識別成功“，把”識別攔截“說成是”識別失敗“，這樣就很容易把失敗率和模型的識別錯誤率當作是一回事（因為”失敗“和”錯誤“這兩個詞太相似了），其實這是兩個完全無關的指標，如果短時間內有10個訂單全部攔截了，而且用戶確實不符合防疫規定，真實的識別錯誤率是0，但是用失敗稱呼攔截很容易以為模型識別全錯了，
概念是“思維的細胞”，維護一個概念串列不僅有利于專案成員內部的合作，也有利于給上級或其他人匯報時聽眾能更容易準確理解你的意思，因為專案成員有更多的背景知識，用詞不準確不一定會引起歧義，大家都能理解，但是非專案成員不一定都能準確理解，
新手開發人員經常犯的錯誤是，把這種對需求的宣告照單全收，然后實作對應方案，
根據我們的經驗，最初對需求的宣告，往往并非絕對化的要求，客戶可能沒有意識到這一點，但一定希望你能一起去探索，
下面給出一個簡單的例子，你在一家出版紙質書和電子書的公司作業，你接到一個新的需求：所有 50 美元以上的訂單都應該免運費，停一秒鐘，把自己帶入這個場景，首先想到的是什么？你有大把機會發現問題：
3、50 美元必須全是用來買紙質書嗎？還是允許在同一訂單中有部分電子書？
這就是我們所做的，當某些事情看起來很簡單的時候，我們卻會去尋找那些邊緣情況，并就其不勝其煩地問人，
很可能客戶已經想到了其中的一些問題，并假定實作將以某種方式作業，問這類問題只是把資訊明確下來，但有些問題可能客戶之前并沒有考慮到，這就是事情變得有趣之處，也能讓好的開發人員從此處事老練，
上面的例子是通過幫助業務方理解他的需求，從而讓問題變復雜了，那是因為問題本身就復雜，業務方最初沒想清楚，你如果按照最簡單的假定去做，可能會出現資損、客訴等各種問題，
有些場景下，幫助業務方理解他想要什么會讓問題變得簡單，比如在某些合規審核場景下，業務方需要你從某種證照圖片中提取法人姓名，你在OCR識別之后準備訓練一個NER模型用來識別姓名，需要的注意點很多，比如這是全國的商戶，少數民族的姓名通常的NER模型識別不出來或錯誤率高（針對性訓練的話又需要標注資料了），但仔細想一下，業務方想要的真的是這個姓名嗎？詢問之后發現，業務方想要的是圖片中的姓名是否和已知的姓名一致，問題突然變簡單了！你只需要判斷真實姓名是否存在于OCR識別的字串中即可，通過準確理解業務方的目的，你更快更好地完成了任務，
每個人都覺得，地球上只有自己一個好司機，全世界都在闖紅燈、實線變道、不打燈就轉彎、開車發短信，總之都不符合我們的標準，所以我們需要防御性駕駛，在麻煩發生之前就做好準備，預料到意料之外的事情，永遠不要把自己置于無法自拔的境地，
與編程類比，上述理論也明顯成立，我們不斷地與他人的代碼互動，代碼可能不符合我們的高標準，或需要處理可能有效也可能無效的輸入，所以我們被教導要防御式編程——有任何疑問，都要去驗證我們得到的一切資訊；使用斷言來檢測錯誤資料，不信任任何可能來自潛在攻擊者或有惡意者的資料；做一致性檢查，對資料庫的列設定約束——做完這些，我們通常就會自我感覺良好，
務實的程式員則更進一步，他們連自己也不相信，既然沒人能寫出完美的代碼，那么也包括自己在內，務實的程式員會為自己的錯誤建立防御機制，我們將在契約式設計中描述第一個防御措施：客戶和供應商必須就權利和責任達成共識，
當我們和他人的代碼互動，比如呼叫他人的介面時，最好要考慮到正常情況之外的一些corner case，它們可能非常罕見，但是最好不要在出現時導致故障的發生，
我剛開始作業時，看到團隊的一大堆代碼，真的是頭皮發麻，遇到過代碼上一次變更是10年前(非阿里)，結果團隊待得最久的成員才待了7年，也沒啥檔案，沒人知道咋弄，只能硬看，這就是檔案的重要性，
記得有一次，我發現某個地方有問題，理解上應該是如果errorMsg非空，那就列印errorMsg，結果代碼是如果errorMsg為空，那就列印errorMsg，但是問了團隊同事，他說，也不一定，都不知道寫代碼的人想干嘛，建議別動，我本來想改掉，聽他這么說，心想還是算了，和我這個需求無關，到時候改出問題了咋辦，做一些我認為正確但是有風險，做好了也收益不大的事情，還是需要勇氣的，而當時在試用期的我，并沒有這份勇氣，這真是個非常現實的問題，屎山也許就是這么來的，
本書提了一些方案，比如少用繼承，多用interface，使用配置等等，同時也提到說，不要因為懶，就放棄做決策，把分歧都做成配置，也不要做的太過，把所有東西都做成配置，會導致修改和維護起來非常難和低效，
有些程式員喜歡一整天都待在電腦前，不說一句話，但線上或線下的開會、溝通、分享等也是不可或缺的，這本書強調了溝通的重要性，一個是做的事情本身，一個是傳達和表達出來，兩個都很重要，如果心里有抗拒，那就把中文/英文當作另一門編程語言，去掌握和用好它，
讀這本書的時候，我們組一位同學做了一個很有意思的實驗，組會時大家也一起進行了討論，這里分享給大家，請看下面這段話：
“不要把問題歸咎于別人或其他什么事情上，也不要尋找借口，不要把所有問題都歸咎于供應商、編程語言、管理或是同事，這些因素都可能是問題的一部分，它們的確會對解決方案造成影響，但不是給你的借口，”
假設是你的主管對你說如上這番話，你覺得這是在pua你嗎，還是確實講的很有道理不是pua你？大家心里也許有一個答案了，
把這個問題發到脈脈上，讓大家投票，近500人參與投票，統計下來有60%的人認為這是PUA，
我們可以把這個問題再擴展一下， 如果你老板和你在平時輕松的狀態下和你講這番話，和打績效的時候講這番話，同樣的話你的感受是否會不一樣？如果是不在同公司的好友講的呢？如果是你敬重的前輩呢？
而如果，這番話來自本書《The Pragmatic Programmer 程式員修煉之道》呢？
1. 本身不是話術的問題，而是誰說出來的問題，場景問題；
2. 你對他是否“信任”很重要， 如果信任就不覺得是PUA，不信任就覺得是PUA；
3. 是否有利益關系，比如外部大佬跟你沒有利益關系，
如果要總結的話，就是我們心里知道說話人的動機到底是不是真的為我好，在這個前提下，對同一番話的解讀也會不同，
其實這些思考和討論都不局限于這本書本身了，感覺包含了對于生活和人生的思考，這也許是組隊讀書的好處之一，
最后，這本書只讀一遍是不夠的，需要反復閱讀并在實踐中增進理解，
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/The-Way-of-Programmer-Cultivation_Towards-the-Ultimate-Realm-of-Pragmatism.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/550081.html
標籤：其他
上一篇：自動化橫行的今天，手工測驗員如何殺出一條血路？
下一篇：顏值即正義,獻禮就業季,打造多顏色多字體雙飛翼布局技術簡歷模版(Resume)
