分類彙整：程式設計

怎麼開始的？

在實際使用 CakePHP 前，我已經是個以設計 PHP 應用為主的工程師，也是開始體會到，程式設計其實還有蠻多煩瑣的工作必須完成，不是每天都可以接觸新玩意兒。

一個使用者在操作過程發現，好像應該加一個欄位進去，需求進到工作清單，在資料表開了對應的欄位，接著就是在表單新增一個欄位，確認資料可以塞進資料庫後，就開始著手修改畫面，簡單測試後就請使用者試試。然後使用者會發現，這個欄位並不只是要顯示而已，應該加入一些判斷，讓他更好做事，這種工作就這樣成了無限迴圈，使用的人越多，發生的頻率越高。 繼續閱讀 →

我不確定其他人對於程式設計師的定義為何，很多時候我覺得設計程式的目的在於取代重複性高的工作，我也經常以這種概念去說服客戶導入資訊系統；但是開始寫程式一陣子之後，發現寫程式本身也是一種重複性極高的工作，經常有複製、貼上、調整這樣的動作產生，為何我們不為自己設計資訊系統，或者請人幫我們設計？ 其實很早就有人思索這個問題了，只是完整的解決方案大多所費不貲或難以掌控，對於預算不高卻隨時得應付客戶需求的小公司而言，少有機會接觸這方面資訊；在開放原始碼的世界裡，我還沒發現一個能夠完整解決我問題的方案，但是我所需要的功能其實透過一些現成的工具可以分別滿足部份需求，雖然仍有缺憾，卻已經強過什麼都沒有的窘境。備份： rsync 其實透過 Linux 環境的壓縮與網路傳輸指令，我已經能夠組合出本地端與遠端主機的備份方案，只是 rsync 提供了更多功能，像是差異備份、安全連線傳輸與錯誤控制等，讓這方面的工作簡化許多。 版本控制： subversion 很久以前就知道 CVS 的存在，但是它一堆專有名詞加上維護不易讓我遲遲無法享有它帶來的好處；但幸運的是 subversion 出現了，除了讓我克服心理障礙外，還提供了比 CVS 方便的功能，像是將路徑的變化也納入版本控制範圍等。而且還有 TortoiseSVN 這個超方便的用戶端工具。 專案管理： trac 其實我還沒真的去管理 trac 的系統，只是在一些專案中透過它與開發者互動，感覺它的介面設計相當友善，而且完整的與 subversion 結合。 === 以下只適用於 PHP === API 文件產生器： phpDocumentor 其實這個工具對我自己寫的程式幫助不大，因為我的註解不多…而且很少照著它的格式…，只是用它來產生其他函式庫的文件相當方便，省去許多需要直接打開程式碼找答案的步驟。 程式碼整理工具： PHP_Beautifier 過去我並沒有遵循標準來寫程式的習慣，但是後來發現自己連自己的程式都看不懂時，我才開始逼著自己去熟悉一些標準，即使那些大多是不成文的標準；對於過去沒有照著標準走的程式碼，或是一些其他人提供的部份，透過 PHP_Beautifier 可以統一他們的風格，我因此省了很多揣測的功夫。 程式碼產生器： … 繼續閱讀 →

如果對於程式設計有些概念，應該曉得傳值與傳址的概念；以往許多人都會鼓勵盡量使用傳址方式設計程式，因為使用的記憶體少、執行速度也較快，但是我偶然遇到一個問題。 一個客戶緊急求救，因為過去的程式調整並沒有留下太多文件，因此我接手後加入一些現成的模組讓客戶使用；不過最近有個網友提醒新的模組有問題，會洩漏個人資料，因此客戶要我檢查。 這個問題的原因是舊有系統的部份欄位被挪作他用，而我套用現成的模組時並不清楚細節，因此新的模組會把那些被設定為不該顯示的欄位抓過來使用，造成資料的混淆與外洩。 問題來了，我找到有問題的程式碼將它停用，可是狀況依舊；我一度以為是自己沒有找對位置，所以試著翻遍所有程式碼，後來才突然理解，新加入的模組使用了傳址方式引用函數、物件，程式在執行時會先看看記憶體有沒有載入過該函數、物件，如果有就會直接拿來用，而沒有檢查實際檔案中的資料有無更新，造成我無論作什麼調整都無法即時看到效果。 解決這個問題的方法也許是重新啟動網頁伺服器，但是這個時間點（中午）執行這個動作可能會干擾到其他使用者，因此我選擇暫時將有問題的功能整個抽離，等晚點再將它還原，並且重新啟動網頁伺服器。 經過這次的事件，對於傳址方式的好與壞多了些概念。

我相信自己不是個以專業為主要訴求的工程師，許多狀況下我都是抱著先求有、再求好的心態；但是最近有件事情讓我很掙扎，一個很久以前完成的專案現在要擴充其他功能，當初設計時是很標準的想到就寫，因此程式碼亂、小問題一堆（雖然只有自己看得到，心裡還是毛毛的），現在回頭看還蠻想吐血的。 問題來了，我該全部改寫還是延續這個爛攤子？ 全部改寫其實不會花費太多功夫，因為舊有系統的功能並不會很多，而且透過一些現成的程式架構（ framework ）很快就能搞定，還多了一堆莫名其妙的功能；特別是想要透過這次機會實做幾個先進的程式架構，藉此提昇自己。只是這樣一來，系統的複雜度增加，未來問題發生時可能不好掌握關鍵；而且加了太多新功能可能造成使用者困擾，使用者困擾的時候就是工程師的惡夢了。另外有個折衷的想法，如果將程式架構當作物件庫來使用呢？這可能有些難度，因為對於程式架構的瞭解還沒有那麼深入，隨意的拆解開來可能需要花更多的時間去深入程式碼運作流程。平常沒想那麼多，遇到的時候才想要臨時抱佛腳；選擇這個方案可能因此耽誤了專案的時程，心中想著四個字…萬萬不可… 採用現有程式架構的好處：1. 功能一堆2. 程式碼精簡3. 架構容易理解4. 文件齊備5. 可以跟很多前輩請教6. 自我提昇7. 練英文… 壞處：1. 複雜度增加2. 架構龐大3. 既有功能需要全部改寫4. 自找麻煩…orz 延續爛攤子的好處：1. 自己跟客戶都很熟悉…orz2. … 壞處：1. 問題一堆2. 要打很多字（程式碼）3. 自己看不下去4. 以後接手的人也看不下去 比較了一下，感覺還是使用程式架構改寫比較好；只是要試著讓介面盡量跟過去一致，否則使用者可能會一堆問號，我的臉上也會有一堆線…

其實剛聽到有那種可以在 UML 圖形繪製完成後自動產生程式碼的工具時蠻訝異的，因為過去寫程式的方式呆到不可思議，連其中的 html 都是一個字一個字給它刻出來，頂多就是複製、貼上或者透過簡單的巨集處理；雖然到後面懶了些，極盡所能的用現成的函式庫，像是 PEAR、PECL或林林總總的 Framework (框架、架構、…），還是會發現有蠻多重複的工作，降低寫程式的熱情。（我指的是PHP）雖然聽到的那些工具都需要蠻多的"四個孩子"，其中一個還要超過"四千個孩子"，這我當然不可能碰啦，畢竟現在的產能沒有大到那種程度；於是乎就透過搜尋引擎挖了挖網路上得資訊，找到了一個免費的 argouml （ http://argouml.tigris.org/ ），它有PHP程式碼的產生器 auxiliary（ http://argouml.tigris.org/download/release0161.html ），也找到了一個可以設計資料庫存取物件樣板的 iCodeGenerator ( http://codegenerator.sourceforge.net/ )，但是可能還需要花些時間熟悉吧。 其實之前也在想，一個符合 CMMI 規範的 ISV 能夠有什麼樣的產能？畢竟在一個人寫程式的過程中，經常缺這個、缺那個的，而在台灣的客戶又經常趕著要，即使明白埋頭苦幹不利於長期發展，但是要跳脫那種壓力慢慢來確實也不太容易。 寫程式是一個蠻充實的工作，因為無論到那個階段都有著無窮無盡的挑戰；只是在台灣很難只做這件事情生活，三不五時就要修修電腦、送送文件。即使真的只做這件事情，台北是個很擁擠的生活環境，隨時可以聽到樓下經過一台拔除消音管的車子、因為辦公空間不足而容易因為眼前雜物分心，加上三不五時不看看新消息或透過通訊軟體跟朋友哈拉兩句好像怪怪的，所以如同之前一個阿斗仔講的，平均起來一天真正花在寫程式的時間可能不超過一個鐘頭（當然，那個阿斗仔的理由跟我不太一樣，人嘛…）。

每次要看別人的程式碼都很累，因為撰寫風格總是千變萬化，剛開始還興致勃勃的，但是一兩年後就真的懶了；基於這樣的心態，雖然知道許多程式架構( framework )好用，但過去還沒真的試著去用它來開發程式，還停留在大量的手工業階段… 程式設計這種事情的重複性蠻高的，特別是開發與資料庫有關的網頁程式，每次新增一個資料表就要花點時間做出相對應的增、刪、改、查，這個過程相當的無趣，特別是沒有像VB, JAVA那樣的IDE工具可用時。 剛開始看到Seagull包含了那麼多東西，所以一直想說如果要搞定它不就得看一堆文件，因此開發專案還是用自己的想法去做；但是寫到一半，天氣很熱、心情煩躁，特別是必須要做重複性高的工作時，於是又再次的下定決心去K英文文件。 昨天還有點不知所措的(其實是前天沒有睡好需要補眠)，今天就看懂了一些基本操作，而且發現真的是…方便，為什麼到現在才開始用這種東西…為過去莫名奇妙浪費的時間哀悼… 剛開始只要照著文件做一個簡單的模組就有個輪廓，接著就從現有的模組參考比較複雜的語法，把主要的物件與方法寫完後就可以執行，不用去考慮什麼呼叫、傳值與認證的問題，前端也使用樣板來產生畫面。 其實感覺跟PLOG蠻像的，只是Seagull多了些自動化與通用的函式庫(PEAR)，一個模組的基本樣貌與資料庫結構對應的物件都可以透過程式產生，參考一個比較完整的模組( user/classes/UserMgr.php )就可以把一些過去撰寫的程式移植到Seagull中，享受它的好處。 跟XOOPS比較的話，在XOOPS開發模組感覺像是爹不疼、娘不愛，可以使用的資源不多(也不熟悉)；Seagull給開發者的照顧就比較多了，除了整合了PEAR，也把一些可能想到的共用物件搞定，開發者可以專注於商業邏輯的核心。

以前的老師開暑修課程教JAVA，因為那個老師以前教COBOL教的很棒，所以我就跑去旁聽。今天講的是透過 JDBC 存取 SyBase SQL AnyWhere 資料庫的過程，因為對 SQL 的語法還算熟悉，所以沒多久就跟上進度了。 課程中使用了 Borland 的 Jbuilder，雖然過去在學 VB 時就見識過 IDE 的方便性，因為後來都是用土法煉鋼的方式寫程式(UltraEdit )，所以慢慢淡忘 IDE 這種東西；今天跟著老師的步驟操作，發現真是方便到了極點，有很多小細節都由 IDE的智慧功能補上，也經常會出現一堆必要的提示，讓寫程式的難度降低許多。不知道 Zend 的 IDE 工具有沒有那麼聰明，我想我該試著去找一套能夠簡化現在寫程式流程的IDE工具了！ Zend 的那個要不少錢，可能會試試 eclipse 吧。 額外一提，要搬到大房間了，結果前一個房客好像整年都沒有整理房間似的，害我清理半天還是覺得很髒；雖然不是我看過最糟的狀況，但是現在要找個乾淨的房間好像越來越不容易了…

因為XOOPS2.2有比較多方便的工具，所以…我又變心了，現在使用XOOPS2.2當作開發環境。下面是一些發現： 1.管理區的選單有現成的物件可以使用，只要引入 /include/cp_header.php 執行 xoops_cp_header()，接著就可以使用$xTheme->loadModuleAdminMenu(2, \’Category\’) 來產生/modules/module_name/xoops_version.php所指定的管理介面選單；第一個參數是選單項目的索引值，第二個參數則是這個頁面的名稱。在該物件的定義檔案為 /class/theme.php 2. 內建的表單物件很難搞，把 /class/xoopsformloader.php 引入後有一堆東西要看清楚怎麼用( /class/xoopsform/* )，做個簡單的表單就要變的這樣： $form = new XoopsThemeForm($title, \’guide_form\’, $url); $pgid_tray = new XoopsFormSelect(\’Parent Guide\’, \’pgid\’, $data[\'pgid\']); $pgid_tray->addOptionArray(glist($data[\'pgid\'])); $form->addElement($pgid_tray); if(!is_null($data)) { $tid_tray = new XoopsFormSelect(\’Parent Component\’, \’tid\’, $data[\'tid\']); $tid_tray->addOptionArray(tlist($data[\'type\'])); } … 繼續閱讀 →

恩…我是個善變的人… 後來想說，等到功能OK之後再回頭改就麻煩了，所以還是透過XOOPS核心物件進行設計；也同時想到，該以目前穩定版本(2.0.13)為基礎還是拿開發中的版本(2.1.X)，後來想想還是別太皮，因為開發中的版本意味著許多的異動，沒必要盲從。 雖然已經透過網路訂購書籍，但是可能要下個星期才會出現，所以昨天晚上跑去誠品把它翻完了；好像前面半本都跟要做的事情無關，不過後半部對於一些變數的說明可以省去一一測試的時間。也嘗試去官方網站看文件，但是少的可憐；有一個用phpDocumentor製做的文件，但是版本為2.0.6，所以我自己下載工具嘗試製作文件。 不知道是我從沒真的安裝完還是以前的設定真的很麻煩，最新版本的phpDocumentor我幾乎沒有進行安裝工作就開始運作，調整一下設定就可以產生文件，而且在WINDOWS環境下不管透過WEB介面或是那個陽春到不行的指令模式都能夠順利產生，工具的作者想必技術相當高超。不過要花蠻多時間等候就是了。 現在雖然使用了核心的物件，但是因為對物件導向設計的概念不熟，XOOPS2的整體設計也還需要時間深入，因此還是保留了過去的習慣；透過CBB的程式碼去看看有哪些物件可以使用，目前大概知道表單要如何操作了。 氣溫的關係吧，冷氣不打開就好像靜不下來；可是開了冷氣又感覺很浪費電(真是龜毛…)。想說要去圖書館，但是大的附近沒什麼餐飲設施，小的又很多怪咖，想想還是窩在家裡好了。到底要不要開冷氣咧……