The Basic Tools - 基本工具

千呼萬喚 終於等到Pragmatic Programmer 20週年紀念版 如果沒聽過這本書 你大概也聽過程序員修煉之道︰從小工到專家這本暢銷了20年的書 終於等到了再版

在再版裡面 刪掉了比較過時的內容和範例 收集了20年來收到的feedback 在讓這本書的內容也可以適用於2020年的程序員 但在我細細品嚐後發現 其實很多人生的哲學並不是只適用於程序員 各行各業看了都可以有所收穫

因為每個篇章的篇幅都不長 所以筆記也用條列式紀錄

本篇的圖片以及程式碼來自於原書內容

第三章: 基本工具

好的工具會放大你的才能 工具越好 工作起來就越有效率 必須要向工匠一樣 不停地充實你的工具集合

純文字的威力

作為務實的工程師 我們的基礎原料不是木頭或鐵 而是知識

我們收集需求作為知識 然後在設計/實現/測試/文檔中表達這些知識

我們相信 保存知識的最佳格式是純文字

也許有人會說 二進位省空間啊 但大多數二進位格式的問題是 理解資料所需的相關資訊和資料本身是分開的 我們人為的使資料脫離其意義 如果沒有應用邏輯去解析他的話 就毫無意義

什麼是純文字

就像購物清單那麼簡單

• Milk
• Lettuce
• Coffee

而以下文字不是有用的純文字

lj;uijn bfjxrrctvh jkni’pio6p7gu;vh bjxrdi5rgvhj

這種也不是

Field19=467abe

我們希望純文字是對人類來說可以理解的

用純文字保存知識

文字的威力

純文字不代表文字沒有結構 HTML/JSON/YAML都是純文字 網路上大多數的基本協定也是如此 比如HTTP/SMTP/IMAP等等

為什麼這些協定都選擇純文字呢 有三個原因

1.不會過時

2.可以利用現有工具

3.更容易測試

不會過時

人類可讀形式的資料和所有其他形式的資料比起來 更有生命力 只要資料還在 你就有機會使用它 即使當初建立資料的應用程式已經失效很久了

比如說下列的資料

<SOCIAL-SECURITY-NO>123-45-6789</SOCIAL-SECURITY-NO>
<SOCIAL-SECURITY-NO>567-89-0123</SOCIAL-SECURITY-NO>
<SOCIAL-SECURITY-NO>901-23-4567</SOCIAL-SECURITY-NO>

一看就知道是什麼 即使當初讀取這個資料的應用已經過時了或不見了 可以很容易的再寫個新的讀取它

相較於這個

AC27123456789B11P
XY43567890123QTYL
6T2190123456788AM

沒人知道是什麼玩意

別忘記 所有的軟體總有一天會變成老舊過時軟體 但資料卻會一直在

利用現有工具

事實上 從版本控制工具到IDE再到command line 計算機的所有工具都可以對純文字進行操作

更容易測試

如果你的測試資料是使用純文字建立 那麼添加更新或修改資料就變得很簡單 不需要建立任何特殊的工具就可辦到

SHELL

對於操作文字檔案的程式設計師來說 工作台就等於是命令shell 你可以在shell提示中組合所有的工具來做到幾乎任何事

講到這就不能不推薦所有讀者去看阮神的《Bash 腳本教程》教學

屬於自己的shell

看完阮神的教學後 別忘了把你的terminal客製化 比如

1.設定顏色主題

2.設定提示符號: 比如目前目錄 版本控制狀態 時間 等等

3.命令自動補完

4.別名: 比如你常搞混是先upgrade還是先update 就直接設一個別名

alias apt-up=’sudo apt-get update && sudo apt-get upgrade’

或是你怕你rm會不小心刪到重要的東西 以下的別名會讓你每次在刪除前都出現確認提示

alias rm =’rm -iv’

功能強大的編輯器

花時間去熟練你平常所使用的IDE 讓你想做什麼跟程式做了什麼的gap縮到最小

給自己一個挑戰: 放棄使用滑鼠/觸控板 一個星期 把所有必須要鍵盤達成的指令的快捷鍵寫下來 前幾天工作效率會受影響 但一陣子後你就會發現編輯得更快 更有效率

版本控制

請在你的專案中使用版本控制

進步不是由變化構成 而是在於堅持 無法記取過去經驗的人註定要重蹈覆轍覆轍
                                                     – George Santayana, Life of Reason

除錯

沒有人能寫出完美的軟體 所以除錯會佔用你一天的大部分時間 讓我們來看看除錯中涉及的一些問題 以及尋找難以捉摸的bug的一些通用策略

除錯的心理學

不要把debug想成是一個負面的詞 或是待解決的難題

除錯只是在解決問題

如果你在過程中發現了是別人的錯誤 你可以花時間精力把責任推到罪魁禍首身上 這可能是你們工作場合文化的一部分 但在技術領域中 你希望集中精力在解決問題 而不是責備別人

這個bug是你的錯還是別人的錯並不重要 它依然是你必須要解決的問題

除錯的心態

Don’t Panic

你可能有時限壓力 或是老闆正在看著你 但你必須後退一步 確實的思考是什麼導致了你認為是bug的狀況

試著去找出發生問題的根本原因 而不僅僅是問題的表面現象

除錯策略

一但你認為你知道發生了什麼事的時候 就是該找出程式認為發生什麼事的時候

複製錯誤

開始修復bug的第一步是讓這個bug可以被reproduce 畢竟如果不能複製這個bug 你怎麼知道你已經修好了呢?

最好可以在你開始修之前先寫好測試(當然這個測試必須fail) 有幾個好處

1.你現在在debug 就代表當初你的測試並沒有考慮到這個情況 把他補上

2.把有bug的情況獨立出來 有利於以後的開發 你知道下次遇到同樣情況你要考慮這個bug

向他人解釋

有一個簡單且有用的除錯方法 就是假裝有一個人在聽你講話 你把這段程式在做什麼講到他懂 常常你講著講著就找到問題了

反思

找到bug之後 請思考 你能做些什麼讓你下次修復這個bug更加容易 也許你可以寫一個測試用hook 或者撰寫一個log檔案分析器

工程日誌

工程日誌用來記錄每天所做的事情 所學的東西 想法草圖 基本上和工作有關的任何事情 都可以寫在工程日誌

工程日誌有幾個好處

1.讓你之後寫review 或是紀錄你的專案時 你可以知道你每天做了什麼

2.給你個地方紀錄也許跟工作無關的想法 讓你可以繼續專注在你正在做的事情 不會說忙完就忘了

3.就像你跟別人(其實就是未來的自己)對話一樣 把事情寫下來 當你在讀一次你寫下的東西時 你可能有種旁觀者清的感覺

記得是用手寫 不是網路上的檔案或是文件

試著寫寫看工程日誌一個月 看看有什麼好處