以HTML5實作應用軟體的優缺點

HTML5 這幾年飛快的竄紅，絕對是軟體產業的一大事件。相信不少人聽到HTML5時，可能連HTML先前的幾次版本都沒聽過。也開始讓許多原先小看HTML的軟體工程師吃盡苦頭。HTML5 會突然聲名大噪，主要的起因是手機的智慧化逐漸成熟，手機瀏覽器的能力逐漸強大，在手機平台眾多的情況下，已網頁為主的服務開始興起。但起初也只是簡單的網頁而已，當時的手機能力也無法做什麼強大的運算，更不用說透過瀏覽器來運算了。

但到了近幾年，手機越來越強大，瀏覽器的能力也跟著強大，對於 HTML5 及 CSS3 的支援越來越完整，讓 HTML5 開發應用軟體變成跨平台的很好選擇，不再必須開發原生軟體才能達到想要的效果。也越來越多像 PhoneGap 這類的開發套件，來協助開發者以開發網頁的方式來開發軟體。

HTML5的優點：

• 跨平台，有瀏覽器引擎就可以執行
• 天生對於畫面構成的便利性
• 客戶端安全，受到先天標準規範的保護
• 許多自動化的記憶體及快取管理已經由瀏覽器統一管理

HTML5的缺點

• 需依賴瀏覽器(或瀏覽器引擎)才可執行
• 沒有程式碼的保護，若需要認證保護的機制將需要重新考量
• 受到先天標準的限制，沒有其他的外掛支援，很難做到某些功能
• 記憶體管理的邏輯與一般軟體設計不同，也是一般軟體開發者所比較不熟悉的部分

如同Flash的缺點，由Flash換到HTML5，在軟體的角度來說，並無大差別。基本上Flash也是基於Script，然後使用原生程式來進行直譯運行。所以原本Flash應該有的缺點，HTML5也幾乎都有。比較好的大概就只有簡化了與主網頁的互動部分，HTML5不再需要以類似Flash以Plugin的方式與JavaScript互動。畫面繪圖也可以非常容易的與瀏覽器的整個頁面渲染混合，搭配出更多樣化的效果。

要能夠發揮 HTML5 的軟體開發，CSS3 的能力是決定性的關鍵。嚴格說起來，CSS3 其實應該不算在 HTML5 裡面，不過都是用來寫網頁，所以經常被包在 HTML5 裡一起談。要能把 HTML5 APP 寫好，必須了解速度的瓶頸是在 JavaScript 的直譯器上。而 CSS3 則是讓物件的顯示方式與轉換效果，甚至是狀態轉換條件，是預先載入。畫面上的物件表示與狀態轉換，不再需要以 JavaScript 介入描述動畫的變化，因此可以以原生軟體的效能來畫出動畫。效能自然比以 Script 來畫出的動畫更為流暢。

透過 HTML5 來開發雲端應用自然沒有問題，但是若用來開發離線使用的本機端軟體就會有所不同了。透過 JavaScript ，因為瀏覽器的限制，許多本機的資源是無法使用的，若要使用，就必須使用其他方式；例如 Plugin 或本地端的HTTP服務等。所以你的程式就必須在 JavaScript 與原生程式間互動。如何分配，讓原生部分盡量減少來降低不同平台的差異化也是一個挑戰。

HTML5 可以提供了 HTML 的易學特性，也提供了大型軟體開發的彈性，成為目前軟體開發不可或缺的角色。不論是以 CSS3 的方式來實作介面，或以 Plugin 等方式來與原生程式碼溝通等，都是與傳統軟體開發流程非常不同的方法。軟體工程師們，不論你會不會用到 HTML5 ，你都應該來了解現在的 HTML5 軟體開發方式，相信可以對你的軟體開發想法有不同的啟發。

軟體開發的管理盲點

應該很多人都會同意，最難處理的事就是跟人有關的事。主要是因為人會考慮的因素非常複雜，難以掌握。而這次我想探討的是盲點問題，特別是關於軟體開發過程的盲點。

盲點之所以為盲點，就是指看不到的地方。而軟體工程中的盲點，卻往往不是真的看不到，而是選擇不去看到，或是主觀的接受一種特定的思考而刻意排斥其他方法。如何能跳脫既有的主觀見解，從其他角度來看同樣的事件，便成為一個很重要的能力。

很久以前有人出了一個有趣的題目給我，剛好符合這個主題。有九個點，排成如下圖的樣子，相鄰距離都相等，每個點是正田字的交點。而題目是要求受試者以一筆畫出四條連續的直線，貫穿這九個點。也就是一筆可以有三次轉彎的機會，但只能是直線。

應該有不少人在被問到這樣的問題時，會花上一段時間，才能找到答案。因為這個題目中，有個看不到的陷阱，侷限了受試者的思考邏輯。當然，並不是所有人都會被這個陷阱影響到，因為這跟每個人過去的經驗以及思考方法有關。

跳脫原有思考模式其實是非常困難的，但是如果能透過第三者的提醒就不一樣了。正所謂忠言逆耳，別人的提醒，若與自己的想法相左時，往往就不容易被採納。適度的在接收到某些負面資訊時，能夠多花一些時間，在拒絕之前，多深入了解，就可以排除很多自己原先看不到的缺點。每個人觀察一件事情的角度不同，會發現的或感到不妥的地方也不同。他人會提出不同的質疑或見解時，如果以找到這個不同意見發生的原因為出發點，就能更清楚判斷這個資訊是否有用。接下來我就列舉一些自己經驗裡看到的問題。希望對其他人能有一些幫助。

軟體工程

事情總是沒有絕對的對錯。市場上充斥著許多探討軟體工程流程的書籍以及研究，嚐試找到最好的軟體開發流程、軟體開發人員管理及訓練方法。然而，越多討論及研究的存在，往往表示一個問題非常有可能是沒有正確答案的。這些方法主要都是要解決軟體開發時的盲點以及可能發生的錯誤，而這與該團隊的人員素質及能力有關。極端一點，如果主導開發的人強到不會有設計盲點，初期設計的討論過程就是的沒有意義的。軟體開發人員，如果不會寫出 BUG ，就不會需要測試。如果人員的理解能力夠好，也不需要再規範什麼一致的coding style，程式整齊、拼字正確也就夠了。可是人員的能力素質往往很難正確的量化，以至於很難判斷對特定團隊，應該使用何種管理方式來達到最佳的效率。

驗證流程

然而一些人迷信於某些流程，而不能考慮自己參與的團隊與開發軟體的狀況，往往導致反效果。對於大部分小型軟體公司，如果在開始設計軟體時，就耗費過多的成本來在開發流程上，搞不好產品還沒生出來，公司就準備收起來了。小公司賭的是創意與工程師的才能，在現在這樣發展迅速的環境，產品比的是面市的速度，花過多的時間在測試，解問題，產品搞定時，類似功能的產品可能都已經搶了大部分的市占率了。很多時候反而應該是讓產品先出去，再提供修正。一來可以提早面市時間，二來可以試試消費者對於特定功能產品的接受度。也能夠由使用者的回饋來調整軟體開發的方向。

測試成本

另一個是成本問題，軟體開發時，開發者肯定是必須先做些初步的測試，以驗證自己是否完成。若公司設有測試人員，軟體開發者必須評估如何能夠利用測試人員的資源，來協助自己完成模組開發的驗證工作。若花上過多時間來保證自己開發的模組的正確性，反而是浪費成本的事情。自己驗證往往看不到真正的盲點，因為自己對問題的了解程度，引導自己開發出產品模組，若有問題，往往就是考慮不周全。而出現盲點時，很可能是對問題的了解程度不足，如此就更難自行測試出問題。研發人員的成本往往比測試人員高很多，若研發人員又不自知，花過多時間在證明自己沒有思考邏輯的漏洞，就是成本的浪費。

開發模組的相依性

軟體開發在切割後，很容易就會有相依性問題要解決。A模組可能依賴B模組，而開發A模組的人員往往可能等待B模組的開發人員提供成品來讓自己能夠驗證成果。而這個等待就很容易造成人力成本的浪費。當然，程式開發者應盡力避免這樣的等待，不應需要等待其他模組，提早進行下一步軟體的開發。但是，實務上，軟體開發者並不具備這樣的能力。就像很多軟體工程師在程式開發時，會有編寫邊編譯邊跑看看的習慣。因為他們沒有足夠的信心確定自己所寫的每段程式是否正確。主導設計溝通介面的人，最好能盡早發現這樣的相依性，請被依賴的一方能提早提供雛型，或僅有介面沒有實際功能的模組，以利依賴者進行開發。

專制才有效率

軟體開發有許多過程都有很多可有可無的設計，很多模稜兩可的邏輯。溝通與討論實際上可能只是浪費時間。A 說 X 方法好，B 說 Y 方法好，花了一堆時間討論與比較，從設計原理，到未來維護成本等。在很多時候這可能是浪費時間，因為這兩個方法的效益可能根本就差不多。主導開發者必須知道這樣的問題，提早決定某個方向，來避免過多不必要的時間浪費。開發的制度與流程也是如此，訂了就好，修改制度與流程必須評估其必要性與成本。軟體工程師對於制度與流程的改變是非常痛苦的。從員工的角度，若制度上你若有不滿，除非這樣的不滿是共識，否則你應該選擇接受，否則換個工作會比較快。

智慧是沒辦法訓練的

或許應該說訓練的成本過高，高到你不應該嘗試。邏輯是個說服的過程，有些人的邏輯，或行事風格很特別。這樣的人，你就別花時間嘗試改變他。而應該適應他的邏輯與行事風格，讓事情能夠平順的進行。笨是沒有藥醫的，個性好，但是笨，你也不需要花時間在改變他的愚蠢。工作是要成本的，你應該換掉這個人。如果你的老闆還願意糾正你，在你不爽之前，你應該想想這個老闆至少還願意花時間來訓練你。

以上分享是我看到的一些問題點，現在軟體開發產業變化非常迅速，台灣的軟體業也正在起飛。並非所有過往課程或書籍都能套在現在或台灣的環境。在看一個方法時，除了看他的優點，也應該看看他的缺點與適用的情境。人月神話是我還蠻建議的一本書。軟體開發仍然是商業，應回歸到成本管理上。