當個準時下班的工程師

做了近五年的專案性質的軟體工程師，就來談談如何有效率的開發系統吧!

面對常常是有時程壓力的專案，通常人的反應是因為時間緊迫，所以不管三七二十一，什麼規劃、可維護性、可讀性都免了，只要能結案就好。

因此工程師也不會在意程式的品質，都做不完了，還管什麼品質，deadline可是一翻兩瞪眼的事。但是，這樣做真的是好的嗎？是比較快的嗎？事實不然，因為我們不習於先思考怎麼開始，若貿然動工開始急急忙忙地寫程式，動不動就會卡住，甚至沒想到關鍵的部分而前功盡棄。

說穿了，大多數的小型專案都不會有詳細的規格，因此什麼英明的軟體工程方法，面對現實，還是得低頭，所以我必須有效率地進行開發，以達到準時下班的偉大目標(笑)。

關於這件事，我是這麼做的：

1. 【目的】：
   先看過規格全貌，知道這個軟體/系統最重要的目的是做到什麼事(抽象的)；有時候為了商業考量就接進來的案子，系統要做什麼搞不好PM都不知道，
2. 【觀察】：
   觀察功能面的流程、全貌，思考程式應該如何「流動」(flow)。
3. 【理解藍圖】：
   如果碰到不易理解的部分，就在紙上圖解、畫出概念，不一定要畫什麼偉大的UML Diagram，這是你寫程式的藍圖，是給自己看的。
4. 【預置兵力】：
   預先設定想各項功能應該怎麼做、用什麼技術、用什麼樣的元件搭配來完成該功能。
5. 【討論釐清】：
   跟開規格的人(可能是PM,SA或甲方)討論，釐清自己理解的是否正確，同時也可以藉此討論技術上的問題點，看看能否換一種方式達到相同的功能。
6. 【關鍵串接】：
   脫離單一功能之後，就會面臨整合性的問題，包括資料的存取、能取得的資料是否足夠、Input/Output的東西、功能之間的聯絡...
7. 【程式小小寫】：
   不要貪心想要一次寫好一整篇的程式再來Run，貪多嚼不爛!! 分小段小段寫(通常是一個function/method)，每個小段只要做好它該做的事和測試，這樣未來就不會難以找到問題，而且整合的時候會順暢很多。
8. 【卡關就別勉強】：
   如果某個地方一直寫不出來，不要硬撐，除了拜Google之外，也可以請教較有經驗的工程師，看看有沒有方式解決；若暫時無解，要先寫其他比較好寫的功能，千千萬萬不要苦守寒窯十八年，就算等到你的薛平貴回來，家裡也什麼都沒了(其他功能都還沒寫!)... XD
9. 【不要執著於UI】：
   老師有講:MVC(Model-View-Controller)的概念才好維護，就算不用這個概念，也要知道UI版面這檔事，輪不到工程師置喙，但是仍需要懂CSS概念才能活用；有時候長官、客戶的主觀美感，會讓你引以為傲、含莘茹苦做的版面控制，瞬間翻盤!! 然後該你寫的程式有的都還沒寫完....倒楣的絕對是你。

以上雖不是什麼偉大的軟體工程理論，但絕對是數年來的血淚爆肝、無數魔掌下的生存之道，講求的就是用最敏捷的方式開發，在個人可控制的範圍之內，降低後續維護的麻煩。

沒什麼章法學問，說穿了就是「謀定而後動」；若您有更好的方式或想法，也歡迎跟我一起討論，大家一起立志當個準時下班的工程師吧!! ;)