Ruddy Lee 分享空間

Emergent Design 演化設計

我寫程式的習慣 My Habit of coding.

leave a comment »

年輕的工程師問我如何開始建構程式? 真是好問題。基本上我不覺得有什麼標準作業程序(SOP)存在,也一向不覺得自己寫得好什麼程式。但幾杯威士忌下肚後還是答應今天一大早寫給他。

.

我寫程式的習慣

  1. 先啟動 PPT 把草稿建立起來。(目錄是重點,紀錄)

  • 選定Keyword、建目錄。
  • 相關資料收集、分析。
  • 概念模式成型。
  1. 啟動IDE建立程式雛型

  • 選擇程式pattern。
  • 修正撰寫程式的模式。(微軟VS的Template 太一般的雜亂)
  • 決定解決問題的主戰場。
  • 加入版本控管。
  1. 問題陳列

    (不宜太早做的步驟,因為還看得不夠深入)

  • 找出真正的客戶? 真正的問題? 決定該放入多少比重在看板牆上。
  • 風險: 評估出恰當的架構。
  • 設計運作流程(可控制與不可控制的部分)
  1. 開始嘗試建立解決方案…

  • 奢侈一下,告訴自己今天建的是 prototype。(可以不怕改)

.

解題從抽象化開始

沒有太多東西可以教你的,但我習慣從抽象化開始,因此就選擇由PowerPoint開始。PPT其實是抽象化最好的工具。選擇在PPT裡頭進行草稿的思考,通常是預做未來包裝上的簡介手冊,但有時候一不小心就會把Prototype也畫完了^_^。接著把所有的資料都塞到這個固定的目錄裡去當做文件,可以省掉未來要寫文件時沒東西參考的煩惱(就在目錄裡命一個叫"文件"的目錄),反正有相關資料就塞進去,可以拿來做應付外界詢問用。只要有人要求做訓練或交接,隨時可以用它來做簡報。有趣的是;自從我養成取一個目錄叫"文件"之後,它就從來沒有空白過,這也是一種成就感、一種習慣。現在只要我回頭尋找程式的時候,一定會先去"文件"看看它。

.

取Keyword 是我寫程式之前最快樂的事

為專案命名! 想到甚麼就取什麼名字,反正高興就好,可以拿來講故事的話,就更有樂趣了。它往往會成為日後回憶的關鍵字,很有趣的,不妨試試看。回想一下微軟 Longhorn = WPF 的由來,它是 Michael Wallent 取的名字,典故是他來自德州,長角牛Longhorn具有德州的代表意義。如果可以的話,再拍個幾張照片來陪襯就更有味道了,更能有利記憶。記得有一回我取了一個codename = 劍潭(Jiantan),專案合作的對象有不少老外,茶餘飯後老來問Jiantan到底是甚麼意思!? 哈哈! 其時背後隱藏的是鄭成功把配劍扔進有妖怪的湖裡,而引來"劍潭"取名的由來。但老實說;大部分的人從頭到尾都搞不清楚,純粹是程式員的自得其樂而已。

.

由PPT做起手勢好處多多,有時候做完PPT之後,coding就省下來了,因為分析完畢之後;就找到不用寫程式也能解決的方案了,那還寫甚麼程式呢! (上回因為需要重複改幾十個檔案名稱,就決定來寫一個好用的改檔名的工具,想說日後一定還派得上用場,但做完PPT檔之後,回過頭來就找到已經寫得很棒的工具程式了。真是前人種樹,後人乘涼)。

.

還記得由"抽象"到"明確"的解題法則嗎?

你很少會有一眼就望穿問題的時候(一見鍾情還是存在的,只是不多見),所以跟在畫廊看畫一樣,不要急著讚嘆,先後退個幾步,試圖看清楚輪廓再動手。通常我都是在這個時候找靈感的。找不到就請出Google來幫忙。相信自己不是第一個需要寫這支程式的人。所以先看看前人都是怎麼做的,有沒有物件可以拿來繼承的。(我定期會把一些程式丟到 Codeproject 網站上面,只是想像有人會用到它。如果你在那裏找到了合用的資料,記得要感恩,順便給下一次禱告增添一些內容)。搞清楚些再開始! IDE是我們寫程式的主要工具,但它太過於明確了,不利客觀思考,多抽象一回兒;等你迫不急待要真正寫一點東西的時候,再來動手寫。不要急,急只會出錯!

.

用看板來取代 To-Do List

用看板來取代 To-Do List,一下子就能讓你想到如何加速開發作業的方法了,它有視覺化的神奇魔力,能讓人看到那些事是浪費,是可以改善的地方。可以客觀的看到,你現在正在那裡做掙扎,該怎麼下決定才對? 因為它把流程都攤在桌上了,只要記得反省一下,改正一下,這就做到敏捷了,好棒! 現在的數位化工具太多、太強了,尤其是看板牆的App,手機、平板App到處都能用,隨時可以進行瀏覽、修改,做為搭乘捷運時的低頭滑手機族,正好可以拿來充分運用時間!

.

先做問題陳列會比較好嗎?

你可能會覺得,是不是應該先做問題陳列呢! 但經驗跟我講;思考的時間太少了,就列不出太多東西來,急著做等於白做。這跟精實軟體開發原則的盡量延持決策(Decide as late as possible)或許有些相關吧。急著想清楚反而適得其反,不如先用漏斗理論客觀的在外圍觀察一下,再從最大的風險處切入做架構設計。(請記得設計模式是針對問題而生的,若沒能肯定遭遇到何種問題,就無需決定採用何種設計模式。像現在一窩蜂的;所有寫ASP.net 的 Web 程式的工程師,無論寫甚麼程式,一律採用 MVC的模式,真是違背了設計模式的基本精神。難怪設計模式的書賣得好,因為確實是需要的。)

.

不寫了,再寫下去就過中午了,有機會再聊。寫程式,弄清楚問題才是主角。怎麼寫則是其次的事。要知道;問題只有一、二個,但解決之道則絕對不是只有一種方法的。對於寫程式的語言、工具或環境不熟,不用擔心,K一下很快就可以上手了,但放心好了,很快你就又會忘掉的,不用急著成為熟手,有需要時自然會的。(我習慣睡前靠在床頭滑iPad,睡前走一趟看板流程,雖然個人看板上都是些瑣事,但滑一滑總能讓人安心,好睡)。

Written by ruddyllee

2015 年 01 月 31 日 於 12:09:40

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: