blog 文章

2021年12月21日 星期二

[books] 程序员修炼之道: 通向务实的最高境界 (第2版)

程序员修炼之道:通向务实的最高境界(第2版)

THOMAS, DAVID; HUNT, ANDREW (作者) 
  • 书  号:978-7-121-38435-6
  • 出版日期:2020-03-26
  • 页  数:344
  • 开  本:16(185*235)
  • 出版状态:上市销售
  • 原书名: The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)
  • 原书号:9780135957059
  • 维护人:张春雨


纸质版 ¥89.00

第1章 務實的哲學
第2章 務實的方法
第3章 基礎工具
第4章 務實的偏執
第5章 寧彎不折
第6章 並發
第7章 當你編碼時
第8章 項目啟動之前
第9章 務實的項目

The Pragmatic Programmer: From Journeyman to Master 本文以 tpp 簡稱。

這本台灣有出第 2 版的繁體中文版, 由於之前看過簡體中文第一版的翻譯, 不知所云, 我很擔心台灣的版本也會有翻譯不佳的問題, 在沒親自翻過一次之前, 不敢購買。

後來看到簡體中文也出了第二版, 而且有電子版本, 平常電腦專業書籍可能不太適合看電子版本, 不過這本書的內容算是很適合用電子書看, 我看了一下譯者, 是雲風, 比較有信心, 他也是程式開發人員, 之前也看過其文章, 文句通順, 下載了試看的版本, 還不錯, 可以看的很流暢, 在綜合考量之下, 最後我買了簡體中文的電子版本, 花了 45.34 rmb, 過沒幾天降到 36.3 rmb, 垂心肝中 ...

台灣的書籍現在要面對中國簡體版本的競爭, 處地更是不利。

英文版本是用 markdown 寫的, 簡體中文譯本也是, 不知道繁體中文譯本是不是也是用 markdown 製作的。

簡體中文術語有些會看不習慣, 不過台灣人應該在慢慢適應中, 討論區的文字可以看到這些中國術語的出現。

另外比起簡體中文第1版的翻譯, 第2版拿掉了英文術語, 這是我覺得很可惜的一部份, 例如: 軟體腐爛 (software rot), 熵 (entropy), 少了這些術語的對照, 覺得有點失落。

這本書是一位強者朋友推薦的, 2011 年我因為翻譯問題沒有購買簡體中文版, 20200907 才購入, 來看看這本書是不是真的寫的那麼好。

雲風的翻譯果然不錯, 行雲流水般的看完第一章, 沒有詰屈聱牙之感, 讀來順暢。

fig 3 2021/12/12 拿到, 350nt,
購於讀冊二手書
看完簡體中文電子版本之後, 過了很久, 我收到了二手繁體中文版本, 350nt 算是不錯的價錢。

這本書我是歸類於你懂的話才能看懂裡頭的描述, 但很吊詭的是, 如果你已經懂了, 何必看這本書呢? 那不該看這本書嗎? 也不是這麼說, 總之身為程式員的你, 應該可以體會我想表達的想法 (如果你看過了的話)。

這是本很容易引起程式員共鳴的書籍, 程式員一定會對裡頭相關的描述點頭稱道, 沒錯, 就是這樣, 也針對軟體開發提出相關的建議, 讓我們開發出來的軟體品質向上提昇。

第1章 - 務實的哲學

和一般很常聽到的技術債不同, 本書用了「熵」來比喻軟體的混亂, 自然現象通常會傾向於「無序」, 請看影片氣體分子的例子即可理解, 程式碼也是一樣, 如果不特別做什麼事情, 你的程式碼是不是也會傾向於「無序」呢? 否則就不會有本書, 或是其他軟體工程的書籍在討論這個問題了。

書中提到「熵」, 如果不知道「熵」是什麼, 可能看不懂書中的描述, 請參考以下影片「熵」的說明:



看這本書沒多久前, 我剛好看了這影片, 知道了「熵」是什麼, 再看到書中描述, 會心一笑。

使用「破窗理論」來形容軟體, 真的貼切。是的, 我看到這邊的 code 就寫成這鳥樣, 自然也不會特別要求自己的 code 要好好的處理, 沒人想撿碎玻璃; 反之, 如果這包 code 的架構良好, 我一定會小心翼翼自己加入的程式碼, 不要搞砸前人設計精良的部份。

第2章 - 務實的方法

這章在說明怎麼樣設計軟體可以用來抵抗未知性的變化, 坦白說, 我覺得很難, 當然還是有一些方法可以讓這樣的混亂降低, 但以我自己的經驗, 通常在現實專案中, 有時程壓力、有上級壓力、有豬頭的決策、有公司的考量、有資金的壓力、有人員素質的問題 ... 很難有書上那樣的完美環境, 只能說做多少算多少。

我對於書中說的更換資料庫的例子有所感觸, 一般都是使用間接層來處理 (或是大家習慣的術語抽象化), 但你怎麼知道要怎麼設計這個抽象化呢? 要是你設計的抽象化這層根本無法順利接上另外一個資料庫 api, 那該怎麼辦? 白做了嗎?

也許有人會說資料庫操作就那些, 大同小異; 是的, 大同中有小異, 就這麼剛好中了這些小異, 我的意思不是說不做這些, 而是就算知道要這麼做, 在實際專案中, 可能還是會碰壁。

書中很多比喻都很傳神, 例如:「在黑暗中發光的程式碼」, 這是曳光彈的比喻, 在打靶時, 曳光彈的軌跡可以讓我們修正瞄準方向, 下次的擊發更容易打中目標, 發光的程式碼就類似曳光彈的效果, 但重點是, 怎麼寫出發光的程式碼。提示 20 在說明這件事情。

第3章 - 基礎工具

怎麼才算遊刃有餘的使用編輯器。這裡有一個挑戰列表, 你能完成多少?

  1. 當編輯文本時, 以字元、單詞、行、段落為單位移動光標及進行選擇。
  2. 當編輯程式碼時, 在各種語法單元 (配對的分隔符、函數、模組......) 之間移動。
  3. 做完修改後, 重新縮進程式碼。
  4. 用單個指令完成程式碼塊的註釋或取消註釋。
  5. Undo 並 Redo變更。
  6. 把編輯窗口切割成多個面板, 然後在它們之間跳轉。
  7. 跳轉到特定的行號。
  8. 對選出的多行進行排序。
  9. 搜索普通字元串, 或用正則表達式搜索, 然後重複上一次的搜索。
  10. 基于框選或某個模式匹配的結果, 臨時創建多個光標, 並行地在多個光標處編輯文本。
  11. 顯示當前項目的編譯錯誤。
  12. 跑一下當前項目的測試。
  13. 能不能不用滑鼠/觸控板完成上面所有的任務?
用 vim, 上述的要求大概可以做到八成; 如果用 emacs, 大概只能達到一成。我完全可以感受作者們說的這項好處, 但我懷疑多少人看了本書之後會照做, 畢竟比起編輯器, 其他事情更重要多了, 學習新的電腦技術、程式語言、新的 framework、學習版本控制 ... 在怎麼看來都比學習編輯器重要多了。

第4章 務實的偏執

第5章 寧彎不折
第6章 並發
第7章 當你編碼時
第8章 項目啟動之前
第9章 務實的項目
ref:

沒有留言:

張貼留言

使用 google 的 reCAPTCHA 驗證碼, 總算可以輕鬆留言了。

我實在受不了 spam 了, 又不想讓大家的眼睛花掉, 只好放棄匿名留言。這是沒辦法中的辦法了。留言的朋友需要有 google 帳號。