Q：越來越多Web 2.0網站走向應用平台，你認為打造這類平台的關鍵為何？
A：簡單來看，應用平台就是API，任何Ajax或 Web 2.0類型的網站，都是在應用平台上運用了API來創造出視覺介面的互動效果。例如Yahoo Mail，透過簡單的Request呼叫，來讀取後續的信件。打造這類網站，如何規畫解決問題的方式，會決定了網站未來的擴充性（Scalability），而非效能決定網站的發展。
Q：如何規畫網站架構，才會具有擴充性？
A：將一個網站應用，分成幾十個獨立小程式，前端透過 API提供服務，後端是應用程式引擎，這樣做自然會有擴充性。因為應用的每一個部分，都有不同等級的使用方式，需要有不同的擴充程度（scaling level），需要不同的機制來處理。以開發Yahoo Mail而言，是要開發一個地址服務程式丶一個讀信服務丶一個送信服務，而送信程式完全和讀信程式無關。以Yahoo的規模而言，需要讓這些工作完全分離，才有擴充性。
Q：這種規畫網站的方式，什麽是最重要的關鍵？
A：關鍵是你必須建立分離丶模組化的獨立端點，而不是全部放在同一個大籃子裡。大多數現今MVC架構（MVC framework）的開發框架（Framework），使用所謂的前端控制器（Front Control），每一次浏覽器提出Request請求時，就會呼叫這個前端控制器，再由前端控制器來分辨，使用者想要執行哪一支程式。這樣做，一點意義都沒有。
在浏覽器層次，程式完全能知道使用者想要做什麽事情，例如使用者只是要讀信，程式就不用再把需求送到伺服器，讓伺服器判斷使用者要讀信還是送信。將這類決策工作拉出浏覽器，由伺服器處理，就會浪費大量伺服器資源，來處理那些對使用者沒有實際功用的工作。擴充性來自架構，很多開發框架，將所有事情綁在一起，限制了架構。選錯開發框架，你就沒有擴充性。
Q：你是說MVC模式不利於網站擴充性？
A：MVC模式比較適合用在網頁控制器（Page Control）的層次。基本上，每一個網頁控制器都是獨立模組，讀信和查地址是不同的網頁控制器，所以，讀信程式就不會干擾到查地址程式。所以，在每一個端點使用MVC模式來打造小型的網頁控制器，是不會有問題。但是，大多數采用MVC模式的框架，預設在網站中采用前端控制器，而非用網頁控制器的方式，這樣的MVC模式，只適合在小型或單一伺服器的網站。
Q：你會如何選擇開發框架呢？
A：一個框架都不要用。但是，我會從這些開發框架中，找出我需要的功能，拿出那個我需要的程式模組來用，或者參考其中的設計想法，而不是套用整個框架。我所看到的大多數框架，都沒有專注在打造有效能的擴充性和可模組性。
Q：難道開發者不需要框架或架構嗎？
A：網站的確需要有架構，每一個人都需要框架，框架是一種解決問題的方法。但是你並不需要通用型框架，用一個前端控制器，來解決所有問題，這樣通常沒辦法成功。每一個問題都不同，你需要引導框架，使用正確的設計模式，直接解決真正要處理的問題。只生產一款汽車，怎麽可能滿足全世界人的需求！
用框架開發雛形系統就好，但真正的產品就不要全部套用。從框架開始比較容易，但你要拆開全部的框架，移除Runtime檢查丶拿掉不需要的功能，只留下你會用到的程式模組。你不需要一個通用型框架，因為它無法提供未來的擴充性，但也不用重頭寫起，你需要的是介於兩者之間。
Q：網站需要規畫到多久以後的擴充需求？
A：我總是痛恨要幫未來考慮太多。當你無法預測未來，你就無法幫未來作決定。
網路變化太快，我通常只規畫半年內的事情。現在決定半年以後的事情，可能會做出錯誤決策，反而讓事情更糟。如果你沒有解決當下的問題，而是想像未來會發生的問題，我認為不值得，我寧可解決眼前看得到的問題，真正聚焦在當下需要的產品。
Q：那麽，有任何准則是架構人員可以遵循的嗎？
A：最主要的原則是，仔細考慮如何分配程式模組，盡可能將程式拆解成更小的元件，調校出適當的API，你應該規畫的是使用者端點的事情，例如浏覽器請求的類型是什麽？應用程式要如何回應？是否可以切割？是否可以把這些工作分配到完全分離的伺服器上執行？即使是在同一台伺服器上，你也能從使用者端點的角度來架構應用程式，有一天，當你的規模變大後，就可以很容易加入第二台伺服器，只要在前端伺服器不儲存任何資料，就能進行流量分擔。一般開發者最大的錯誤是，讓程式碼之間的交互關連（interrelation）太深，每個不同的元件都需要和其他外元件溝通，這樣做很難調校出很乾淨的API。開發者會無法抽離出效率慢的API放到輔助伺服器中，而讓主要伺服器只執行必要API。
Q：切割服務丶拆解程式的難度是什麽？
A：必須在開始之前，就要非常了解問題。當你寫完第一個版本的程式，才著手拆解問題，那幾乎是不可能，很難事後處理。這的確很難，因為問題會一直改變。但是，若你從簡單的架構開始，並且保持這個精神來區隔程式模組。每次當網站發生變化時，問題的變化也只會影響到一小部分，你就能夠非常清楚那個地方，能夠直接解決問題。就好像樂高游戲一樣，蓋好每一個小塊積木，哪邊還有不足，就只需要再補上一小塊就好，不用對整體改變太多。
Q：除了擴充性以外，如何提高網站效能呢？
A：要提高效能，得先知道每一支程式花了多少時間。我會問，使用者送出Request請求後，要多久才會收到第一個Byte的資料？很多開發人員不曉得這個時間（First Byte Latency）是多久，不曉得自己的程式碼用掉多少時間？可以透過Profile來追蹤效能，畫出視覺化的效能流程圖，來了解瓶頸在哪。
甚至要考慮到單一機器上的延遲，透過系統層級的追蹤程式，知道程式執行的每一個系統呼叫（System Call）耗費多久。還要考慮浏覽器中的延遲，從使用者實際感受的速度來改善網頁執行方式等。
每次你增加一個新功能，要能計算出新功能會增加多少毫秒，想一想這麽做值不值得。
Q：那麽，網站的安全性又需注意哪些原則？
A：基本精神很簡單，只要用資料防火牆的概念來設計網站。網路防火牆會嚴密監控每一個通訊埠，只讓沒有安全疑慮的封包通過，但網站開發者剛好相反，只擋掉自以為有危險的內容。開發者不能信賴任何從外部取得的資料，借用防火牆概念和手法，建立資料防火牆，就能提高網站安全性。
Q：好的架構師需要什麽樣的條件？
A：必須非常了解技術，了解每一個細節，例如設計資料儲存機制，要了解哪種資料可以儲存丶可以存多大的檔案，放多少資料丶每秒鐘可以放多快？如何復制資料？前端必須使用哪種資料格式等。架構師可以不用像 DBA，知道如何修復Oracle資料庫的錯誤，但是要能夠了解Oracle資料庫擁有的能耐。這種人很難找，必須要失敗過很多次，才會有足夠的經驗。
Q：台灣還有不少舊網站使用PHP 4，他們應該現在升級到PHP 5嗎？還是等待PHP 6？
A：盡快升級到PHP 5。只要作一些測試和修改，就能得到更好的效能和安全，為什麽不做？不需等待PHP 6，開源社群的運作方式，無法承諾推出時間。很多新功能已經放到PHP 5.3版中，趕快從4升到5最重要。
