靈感與文件

作者：
我自己以前很喜歡寫程式，現在不年輕了就較懶惰，所以大家猜的出來這故事發生在很久很久以前... 一顆1MB的RAM要一千塊美金，而且要排隊一個月才買得到的時代 。

我當初為了一家forwarder/broker（海陸運）公司寫一些應用程式。幫他們架網路，再完成了會計系統、出入口系統等業務的東西，終於要幫Sales的人們開發他們的系統。花了一些時間，把基本需求完成，然後很雞婆的幫他們作了一個小工具。結果，那個小工具成為Sales的人們最喜歡用的功能。

為什麼說雞婆呢？因為這沒有在他們本來的需求裡，而是在某幾次吃飯或咖啡場合聊他們做事的方法，我自己去作一些prototype開發出來的。其實那個功能需要跨幾個資料庫撈一些資料再整合，只是我們當初所使用的資料庫系統會鎖住資料庫，沒辦法邊看邊編輯資料。其實是為了安全的考量，資料庫鎖住是很合理的事。可是為了這限制，我一直沒有辦法完成我想要的功能。最後，在某一次的嘗試中，動態跑到作業系統裡把lock挪掉，做完工作，再把lock搬回，竟然就完成了所期待的工作。雖然有些危險，但是我非常有把握在這些功能的使用範圍內，應該是不會發生任何問題。

事實上，這工具他們之後用了很久，而且沒有發生任何意外。直到有一天我接到越洋電話...

時間已過幾年，我也搬來台灣。原來他們要upgrade系統，再重建構系統，所以希望我說明當初到底用了什麼撇步完成那功能。 坦白說，我連什麼功能都忘了，哪裡記得什麼妙法？

不知道各位有類似的經驗嗎？很多時候拼命coding，不是trial-and-error，就是靠著一些靈感完成工作。然後，沒記下來，過幾天就忘光光了。 明明知道要加註解，可是怎麼可以停下這麼順的『手感』，就繼續code下去了。更不用講到文件了...
在台灣的學歷：幼稚園中班肄業 （所受的教育都在國外）

留言

  1. 薛念林2009年3月12日 下午1:17

    我倒是想到另一件與文件無關的事。以前念高中的時候，是在丙組，後來班上很多的同學都成了醫生，懸壺濟世的幫助了很多人。我有時候在想，自己幫助了誰？一個軟體工程師幫助了誰？我想劉老師的經驗給了答案。其實一個好的工程做出好的功能可以幫助很多人，即便當初只是舉手之勞順道做做。

    在一個中型的軟體組織（約20人）有時很難去評斷每一個人的績效。主管常常會覺得為什麼系統開發的這麼慢？其實常常是被某一些雜事或技術絆住了，動彈不得。這時候如果有人跳出來寫一個小程式做自動化，整個組織的效率可以快上好幾倍。我覺得開發這類工具的人真的值得好好的犒賞一番。

    ps. 好像離題了...

    回覆刪除
  2. 黃為德2009年3月12日 下午6:09

    事實上，任何行業在我的觀念裡都可幫助許多人，軟體工程師的功能也不比一位醫生差，因為軟體可以說無所不在，甚至影響人類的文化與文明，試想Microsoft那些軟體工程師所創造出來的軟體系統，其影響何其巨大，其他組織亦然，只不過台灣的環境似乎無視軟體的影響力，因此無法讓軟體工程師盡量發揮罷了，薛教授也不必洩氣，實非不為也。

    如果說，主管會常常覺得開發緩慢，事實上並不足為怪，所以最近有一些新的軟體發展方法與技術問世，如Agile Method或MDA等等，或許多少可以解決這種問題。

    劉教授當時發展的工具，對他服務的公司看樣子有相當用處，只不過未依軟工流程發展，以致多年後不易更新，有點可惜，如果要用CMMI的標準來看，可能屬level 1，也許當時只想很快解決身邊的小事，以致於‧‧‧(非常抱歉有點批評)。

    回覆刪除
  3. 劉立頌2009年3月12日 晚上11:49

    謝謝黃教授的回應，我完全贊成兩位教授的看法，軟體工程師真可以以所做的為榮。感謝黃教授不吝指教，本人當初的行為的確是Level 1行為，這也是希望大家能分享看看如何把一些『靈感』正確的留下來。我一直都以programmer為榮，可是又知道SE的重要。假如是開發本來所規劃及設計好的東西，看來都可以乖乖的做一些SE規範中的行為，可是講到臨時加進來的東西，或者是自以為是的增加的東西，時常就沒有辦法乖乖的來做事。所以時間一過，『靈感』一起不見了，可是又沒有文件留下來，實在是矛盾…

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容