程式設計師的資訊系統

我不確定其他人對於程式設計師的定義為何,很多時候我覺得設計程式的目的在於取代重複性高的工作,我也經常以這種概念去說服客戶導入資訊系統;但是開始寫程式一陣子之後,發現寫程式本身也是一種重複性極高的工作,經常有複製、貼上、調整這樣的動作產生,為何我們不為自己設計資訊系統,或者請人幫我們設計?

其實很早就有人思索這個問題了,只是完整的解決方案大多所費不貲或難以掌控,對於預算不高卻隨時得應付客戶需求的小公司而言,少有機會接觸這方面資訊;在開放原始碼的世界裡,我還沒發現一個能夠完整解決我問題的方案,但是我所需要的功能其實透過一些現成的工具可以分別滿足部份需求,雖然仍有缺憾,卻已經強過什麼都沒有的窘境。備份: rsync

其實透過 Linux 環境的壓縮與網路傳輸指令,我已經能夠組合出本地端與遠端主機的備份方案,只是 rsync 提供了更多功能,像是差異備份、安全連線傳輸與錯誤控制等,讓這方面的工作簡化許多。

版本控制: subversion

很久以前就知道 CVS 的存在,但是它一堆專有名詞加上維護不易讓我遲遲無法享有它帶來的好處;但幸運的是 subversion 出現了,除了讓我克服心理障礙外,還提供了比 CVS 方便的功能,像是將路徑的變化也納入版本控制範圍等。而且還有 TortoiseSVN 這個超方便的用戶端工具。

專案管理: trac

其實我還沒真的去管理 trac 的系統,只是在一些專案中透過它與開發者互動,感覺它的介面設計相當友善,而且完整的與 subversion 結合。

=== 以下只適用於 PHP ===

API 文件產生器: phpDocumentor

其實這個工具對我自己寫的程式幫助不大,因為我的註解不多…而且很少照著它的格式…,只是用它來產生其他函式庫的文件相當方便,省去許多需要直接打開程式碼找答案的步驟。

程式碼整理工具: PHP_Beautifier

過去我並沒有遵循標準來寫程式的習慣,但是後來發現自己連自己的程式都看不懂時,我才開始逼著自己去熟悉一些標準,即使那些大多是不成文的標準;對於過去沒有照著標準走的程式碼,或是一些其他人提供的部份,透過 PHP_Beautifier 可以統一他們的風格,我因此省了很多揣測的功夫。

程式碼產生器: *

目前這個部份都還在實驗當中,因為有太多的選擇存在,並沒有任何一個具有權威性的解決方案;不過我想 CakePHP 在台灣已經有不少朋友採用, symfony 有許多開發者支持,PRADO在技術層次獲得最多迴響,以及幾乎是PHP代名詞的Zend也有相對應的方案剛在醞釀當中,這幾個應該都值得持續關注。

其實有些理想的狀態是,透過 UML制定流程與行為後,讓程式去產生所需的程式碼、API文件甚至是使用者操作手冊,這種東西用想的應該可以做到,但是離實際產品出現應該有很長的一段路得走(據說 IBM 那些貴死人的方案中已經離這個目標很近了)。有生之年不知道會不會看到 AI成熟到可以自動發掘需求然後轉化為程式…然後程式設計師只負責鬼扯…(其實現在就常常在鬼扯了…)。

總之,別將自己寶貴的生命花費在可以輕易被取代的工作上,用些現成的工具把工作早點完成,多花些時間在自己和家人身上;只是同時也得權衡輕重,別讓方便成了隨便,資訊系統的效益還是在使用者身上。

希望透過這篇文章拋磚引玉,讓各位前輩們可以秀些傳家寶給我們後進學習。 :)

(打到一半隔壁突然傳來了一句刺耳的評論: "你真的很喜歡瞎掰ㄟ"……無言…)

本篇發表於 程式設計。將永久鏈結加入書籤。

程式設計師的資訊系統 有 3 則回應

  1. tokimeki 說道:

    話說這個介面標準也不會是一直固定的,所以每隔一段時間(例如:3~5年),就會有所改變。
    如果我們一直在這上面工作,不說習慣的問題,累積下來的資訊就很可觀,你要不要拋棄這些資訊?
    我個人的選擇是拋棄它,這是從商業循環的角度看的,不破不立…

  2. 疑問… 說道:

    請問…

    關於java的問題

    是真的多做練習就好了嗎?

    還是要有天份呢?

  3. kiang 說道:

    程式語言跟一般語言一樣,熟練度很重要;說是天份,不如說是有沒有用心、創新吧。