程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第六章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章重點放在開始寫碼之前應該有的準備工作 - 收集需求,解決臭蟲,確認可行性,製訂規格 和 開發流程.

需求之坑 在於使用者很可能自己都不知道自己的需求為何的情況下,其實很多需求是在回饋的過程中,不斷地被挖掘出來的. 個人的經驗通常是,通過層層的關卡後,我做出來的東西,通常變的不會是終端使用者所想的功能,以至於後續會不斷上演砍掉重練的情況發生.

解決不可解的謎題 和之前提過的”靠巧合編碼”一樣,都是要求程式設計師要真正了解問題,把發生問題的原因解決,而不是掩飾表面或後續衍生的問題.

直到準備好 要求在寫碼之前要先規劃藍圖,房子不會邊蓋邊想要改幾層,但寫程式時常會被要求這要搞,但無腦之開寫的下場,辛運一點就是可運行但很難維護的程式碼,最衰的就是寫到一半才發現根本此路不通準備黑掉…

規範陷阱 相對於不規劃就編碼,它位於光譜的另外一端(凡事太過或是不及都不會是好事 XD),嚐試著一次完成所有的規格是件不可能的事,再加上客戶不斷增加或變化的需求,規格與實作往往會漸行漸遠. 做人腦筋不要太死板,規格也是一樣,且戰且走,邊做邊改,最後才不會拿到一本根本過時的兩千頁規格書.

圓圈與箭頭 要程式設計師對於各種開發方式採取開放的態度. 個人覺得這可以套用在各種地方,不排斥學習新知,好的學起來,不好的也了解壞在哪裡. 井底之蛙,以管窺天. 海納百川,有容乃大.

第七章 Before the Project

The Requirements Pit

• 將會變動的部份從需求中分離出來.
• 找出客戶為何需要此需求的原因,如此當你實作時才會更貼近其需求.
• 實際到使用者工作環境,觀察使用者會採取的行為操作.
• 利用工具紀錄新增的需求,好讓自己能夠知道目前到底增加了多少需求,以求通盤了解整體狀況.
• 從專案開始,就維護一份詞彙表,用來讓客戶,程式設計師以及其它人對照參考,確定彼此指的是同一個東西,而這份表格也能應用於使用者介面以及程式變數名稱上.
• 將文件放上內部網頁上,可供參與者觀看或編輯. 而非印出一份沒人會看也辦法即時更新的文件.

Solving Impossible Puzzles

• 跳脫既有的框架來思考問題.
• 遇到難題時,不要明知不可為而為之. 反之,列出所有可能的原因,然後一一去驗證,直到找到真正的問題來源為止.
• 靜下心來思考,哪些是真正的問題? 哪些只是衍生或是使人誤解的問題?

Not Until You’re Ready

• 準備好了再開始寫程式碼! 坐下來啥都沒想,邊寫邊想,那只能叫做敲鍵盤而已.
• 分辨你只是 想拖台錢 還是 真的覺得還沒準備好 的方法: 找出需求中你認為最困難的部份,開始寫一些 Prototype 的程式碼,若你發現你寫的很順,甚至開始覺得這樣下去只是浪費時間,那代表你已經準備好實作這個需求了.
• 正式編碼前先撰寫 Prototype ,就像大軍出動前會先派斥候去偵查敵方實力一樣.

The Specification Trap

• 不用想一次就補捉出系統的所有細節.
• 長篇大論讓人很好入睡.
• 取代先定規格再編碼的方式,讓 編碼 和 規格 同時進行. 這種開發流程鼓勵我們不斷從實作中得到回饋,然後將其轉換成最適合的規格. 編碼跟規格是同步在進化的,規格不在是一灘死水.
• 有經驗的程式設計師,在編碼時腦中應該會浮現最適合當前情況的設計抉擇.
• 在沒有考慮技術層面下,很容易定出沒有辦法實作出來的規格.

Circles and Arrows

• 對於各種開發流程,不要太過拘泥於形式.
• 客戶喜歡看到實際的產品,而非文件及圖表.
• 對各種開發流程採取開放的態度,學習並融合其優點,不斷改進自己的開發流程.