關於設計思維的落實 — 自問自答

Q1.為什麼程式設計師不太重視設計(Design)?
A1.

  • 傳統 “Top/Down” 分析->設計->實做 的迫害,使得程式設計師根本就不相信設計圖與程式碼是一體兩面;設計圖是空談、設計圖是文件、設計圖是造假(嚴重了!)
  • 太麻煩,無法看到立即可執行的產出(應用程式)。人們往往要 “眼見為憑”,尤其是 PM、老闆。
  • 不知該如何表達,用 UML?覺得好像是要去學另外一種語言,粉累… @$~
  • 傳統的包袱、本位主義,認為程式設計師就是該用原始程式碼來溝通。

Q2.是否應該把想法表達出來在設計圖上?
A2.

  • 當然,用嘴巴講不清楚、用程式碼除了 “同類” 的看得懂(要看懂別人寫的也要花很多時間滴~),PM/SA/SD,怎麼看得懂?
  • 用圖來溝通最簡單了,只要不要畫得太過抽象畫,大約解釋一下為什麼這麼畫,應該可以讓團隊成員很快就看懂你的 “塗鴉”。
  • 往事用圖來回味是最輕鬆愉快的了~,若是用程式碼,嘿嘿,光自己三個月前寫的,自己都已經看不懂了,更何況別人?

Q3.那麼,該如何將腦海裡的想法表達出來?
A3.心中先有個標的:

  1. 你要表達什麼(What)?
  2. 你要表達給誰看(Who)?
  3. 為什麼(Why)是這樣表達?
  4. 你該如何(How)表達?

例如,Client/Server,畫兩個圈圈,一個圈圈代表 “UI Form”;另一個圈圈代表 “Database”。”UI Form” 圈圈畫一個箭頭指向 “Database”。如此從圖就可以看到,兩個元件(Component)的相依性(Dependency)關係:”UI Form” 圈圈元件相依於 “Database” 圈圈元件。

同樣,你有幾個 “Class”、”Class” 之間又是怎樣的呼叫來、呼叫去的,如何表達?
就把每個 Class 畫一個圈圈,然後再用箭頭連起來;若是要呼叫的 Class 是在另外一個系統上,那麼,被呼叫的 Class 就是小圈圈 — 被框在該系統大圈圈內囉~

用什麼工具來畫圖比較理想?
用 VISIO? WORD? 乾脆直接一點,畫在紙上,應該夠簡單了吧?

擔心語法表達的問題?
唉呀,先把圖畫出來吧,就像小朋友那樣…
我想到什麼,我就畫出來,你看不懂?我來說給你聽,或是我再來把圖修正一下吧。慢慢的,你就能看得懂我想表達什麼囉~

UML 的問題?
慢慢的,一點點的學習、一點點的修正,一點點的嘗試,慢慢會搞通的啦(搞不懂 UML 也無所謂,自家人都看得懂,又不外包的話,”Who Care?”)。

將想法用簡單的設計、簡單的方式來表達在圖上。
一個人開發的話,可以慢慢反思自己的設計… ; 團隊開發的話,成員之間可以分享彼此的想法、集思廣益。
不需要花超過一天,有初步的共識後,就直接寫程式來落實印證,然後再回饋(feedback)結果回來,做一些修正、加一點功能。如此循環 “簡單設計” 、“馬上落實”

這樣不是很好嗎?

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *