「把版面排得漂漂亮亮，連結規劃得合理，是做網頁最難的事！」
如果在貓兒還沒進網路公司前，問貓兒做網頁最難的是什麼，貓兒一定這樣回答。當兵在金門，退伍後又剛好遇到 921，為了一掃長期以來鬱卒的心情，貓兒自個兒跑去英國玩了十幾天，還去劍橋找臭鳥頭。回家以後，編了一些網頁，放在朋友的主機上。貓兒自認照片和文章應該算吸引人，但是第一次做網頁，怎麼安排版面、規劃連結，真是傷透腦筋。貓兒只用了 Photoshop 5 和 Macromedia Dreamweaver 2這兩個工具，就把網頁建立起來，覺得最困難的部份，當然也就是視覺上與超連結這類浮面的問題囉！（如果各位對貓兒的第一個網站有興趣，歡迎到這裏來：
http://aquaphoto.twbbs.org/~klavier
要先抱歉的是這個網站年久失修，很多連結和功能都爛掉了）
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
「網頁之間參數的傳遞，是網頁程式設計最難的事！」
貓兒在搞懂網頁程式設計的基本原理後，是這樣子認為。網頁程式的參數，有從表單進來的，有從網址列進來的，也可以自己定義（後來才知道還有其他三四種傳遞方式），這些參數，可以用在資料庫查詢之用，也可以傳給下一個網頁。但問題是網頁程式的生命週期很短，連上線、執行程式、呈現結果、斷線，這些參數的生命並不具有連續性，而是間歇性的，要把它們的值維持到下次程式又活起來的時候，的確需要不同於傳統程式設計的技巧。貓兒剛接觸這樣的東西，一下子就被搞迷糊了，經常把參數搞丟，造成資料庫查詢失敗，或開啟網頁失敗。參數的傳遞，變成貓兒最大的困擾。
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
「設計一系列的流程，是網頁程式設計最難的事！」
懂得網頁程式怎麼寫後，貓兒開始維護公司的網站。當貓兒可以解決基本問題，企劃部門就開始丟下工作來，其實只是一些簡單的會員註冊、產品上線的流程。網頁流程除了要考慮正向，還要考慮逆向造成的後果，因為你無法阻止使用者回上一頁，如果考慮不週嚴，就有可能發生資料重覆輸入，或一些「不可逆」流程的錯誤。而參數的傳遞也不是只有一個頁面，而是得在好幾個頁面間穿梭，規劃上又比單一網頁複雜得多。
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
「系統整合，才是最困難的事！」
貓兒在開發過幾個小活動，完成線上付款系統、購物車、會員流程等等後，接下來的重頭戲，就是移機了：把網站主機從甲地移到乙地，並且公司自行接管網管事宜。此時要考慮的因素，就不只是網頁程式了，資料庫如何轉移、網路如何規劃、流量分配器的設定、信件伺服器的架設、以及定期維護備份的工作等等，都得詳加規劃。
移穖這件事，全公司都像打仗一樣，因為有太多的事，大家都不熟悉、沒碰過。為了日後程式維護方便，貓兒還毅然決然把微軟 Site Server 從系統上剔除。但是很奇怪的在本地測試是沒問題，移機之後，流量開始進來，大概每十分鐘就會當站一次。貓兒當時已住在公司好幾天了，看到這樣的情況，全身都軟了，真的不知問題發生在哪，因為有太多的環節都有可能會影響到。
後來仔細地觀察龐大的 log 檔（一天四五十 MB），終於找到癥結所在，程式和系統的錯誤加起來，大大小小總共一百多項。貓兒又在公司拼了三天三夜，把重大的錯誤一一修正，總算，系統可以穩定地運行。雖然還是有錯誤發生，但那已是網頁的架構太複雜、連結太深、新舊版本參差不一造成的結果，已經很難去追蹤了。
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
「規劃『規劃網站架構』的架構，才是最困難的事！」
這句話看起來有點吊詭。在移機之後，貓兒深深體會到，網站的程式如果沒有好好的管理，開發時間久了，就很容易失控。連程式設計者本身，可能都會忘記自己寫過哪些程式、擺在哪個目錄下、網頁裏的超連結是怎麼設計。就像當時公司的網站，使用者常常會走入死胡同、在網站上迷路，甚至從藏在深處的超連結開啟一個半年前就打算關閉的功能。
公司的網站已經亂到無法管，改版就成了大家的共識。規劃新版網站的架構是很複雜的一件事，貓兒就想：「何不設計一個程式，專門用來規劃網站的架構，給予網站規劃者最大的彈性，並且重覆利用已開發好的功能與網頁程式？」這就是貓兒「網站架構器」的肇端，而規劃「規劃網站架構」的架構，也就成為貓兒日夜思考的問題。
首先貓兒要找到一個商業網站架構的通例。通常此類網站的最上方，都有一些「大選項」，像是「賣場」、「會員專區」、「商品常識」等，或者用作產品類別區隔，比如「書籍」、「禮物」、「電子產品」等。點選其中一個大項後，會有「小選項」，比如說賣場下面可能會分「特價」、「限量」、「競標」等等。每個小選項點進去後，可能是一個列表，也有可能就是這個階層的終點，或者是一系列流程的開始，所以在小選項之下，應該還要可以彈性掛上頁面。在網站架構上，貓兒就確立了這種三層式的樹狀結構－－大選項、小選項、小選項所屬的頁面們，有必要的話還可以往上延伸。
除了主要架構外，商業網站都會設計一些功能方塊，放在網頁的左右側。這些功能，可以是搜尋引擎、會員登入、銷售排行、最新討論話題、投票機等等。它們有可能每一頁都出現（比如搜尋引擎、會員登入），有可能只出現在首頁（比如投票機），也有可能因為出現在不同的產品類型頁面上，而有不同的列表（比如銷售排行）。如果真的要一頁頁去編排這些功能，不煩死才怪！而且同樣一段程式碼，可能會出現在好幾個頁面上，如果哪一天規格要修改，豈不是要一一去修正？於是貓兒設計了一種外掛的方式，程式設計師設計出所有的功能方塊，至於哪個「小選項」該掛哪些功能，交給網站規劃者去選擇，如此就解決了上述可能發生的麻煩。
再來就是網頁程式膨脹無法控制的問題。貓兒的解決方式是每一支網頁程式都必須「註冊」，並且產生一個序號給它，當別支程式需要導向到這一頁時，參照的是序號而不是檔名。雖然這樣比較麻煩一點，但是相對的可以得到更多的維護資訊，比如說貓兒可以輕易地查到哪些程式是用在哪個小選項下的、哪個檔案已經一個月沒更新了等等。
當然還有很多細部的規劃，足足可以寫一本幾十頁的規格書了。這是貓兒的第一套「系統」，它是用很粗魯的方法寫出來的，作業環境單純到只有資料庫和網頁程式，極少有外掛的元件，而且完全沒使用別的套裝軟體。公司網站的改版就是這套系統初試啼聲，它穩穩地跑了好幾個月，使用的系統資源只有前套系統的一半，更重要的是：以後企劃部門要新增單元、調整頁面、修改架構，只要不是太複雜的，自己從網站架構器動手就好，貓兒根本不必出面！
直到這個時候，貓兒才覺得自己長大了。這套架構器，其實並不是貓兒閉門造車就能開發得出來。閱讀過上千支爛程式，修正過幾百隻程式與系統的 bug，每日不停地接受企劃、客服、產品部門的需求，和別家廠商洽談時得到的鎖碎靈感，還有如雪片般飛來的使用者抱怨信，沈積了八個月，才終於蹦出創作的火花！
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
「找到會賺錢的商業模式，才是最困難的！」
現在，貓兒得追尋這樣的答案，只不過，全世界的人也都還在找。
