小朱® 的技術隨手寫

只要程式開發久了，又有面對過不同層次的專案（例如產業不同，性質不同，應用方向不同或是不同的領域知識等），通常都會接觸或是使用很多的技術，而且技術的學習力又和自己本身的基礎能力有相當大的關係，它會左右你學習新技術的快慢，不過今天要談的倒不是學習力，而是決策力（Decision Making）。

當你的能力層次往上發展，且碰到很多新技術的時候，總是會有一些聲音跑出來：

• 這個技術好用嗎？
• 這個技術能夠用在現有的專案嗎？
• 這個技術是否可以做為新平台的基礎？
• 這個技術 Delivery 到公司內，要花多少時間才能夠有基本的開發能量？
• 這個技術是否可以幫助公司縮短開發時間或解決特定的問題？
• ...

其實不只是新技術的導入，更多的情境可能是選擇要怎麼開發專案，像是：

• 資料庫應該把屬性放在欄位，還是另開欄位？
• 要用 Windows 還是 Web Application？
• 是否要做分散式架構？
• 如果導入某些方法，是否可以增進彈性？
• 使用 ADO.NET Data Service 來做會比自己開 Web Service 要快嗎？
• ...

舉個簡單的例子，今天老闆要你開發一個線上商店架構，那你碰到的問題可能會有：

• 會員怎麼管理，要放哪些資料？
• 會員會不會有分等？等級間有沒有限制？限制的條件？
• 產品基本資料（含上下架等）是否會有不同性質（例如書本，3C產品或是衣服這些）。
• 庫存誰來管？怎麼管？有沒有稽核機制？
• 購物流程以及金流如何處理？
• 安全性要怎麼控管？
• 廣告以及促銷要怎麼處理？
• 銷售報表怎麼出？有沒有銷售分析能力？

以上這些都還只是大項而已，細部還有更多的決策要做，而且決策下去可能要變化的地方會很多，包含資料庫，工作流程，程式碼，畫面控制項甚至於 Policy 等都有可能。

只要專案的歷練一多的時候，這些問題可能會的變得重要，因為它可以左右你在設計時期，開發時期，甚至於是維護與擴充時期系統的各項指標與能力（例如可擴充性，可延展性，可維護性等），在這個時候，技術決策力（decision making of technology）就相當重要了，正確的決策會比事後再修修改改要來的有意義，也無須再花費修改的成本來做這些事，然而正確的決策說的好聽，要做到其實也真的不太容易，因為會有幾個因素來干擾你：

• 需求的變更。
• 新技術的誘惑。
• 領域知識的改變。
• 團隊的能力。
• 個人的喜好與經驗。

這幾個可能的因素其實有時候是每個人情況不同，需求的變更可以靠專案的控管來降低發生的機率，領域知識的改變也不是那麼頻繁（例如會計程序或是統計方法等，工作流程也不是像朝令夕改般那麼快速），團隊的能力比較容易影響到在採用特定技術上的決策，最主要的原因是你會用的東西別人未必會用，尤其以新技術為甚，例如 LINQ, ADO.NET Entity Framework, Silverlight, ASP.NET MVC 等。技術的進步總是非常快的，你無法把握所有人都可以跟上你的腳步（當然若團隊本身夠強的話就例外），這時團隊能力以及你想採用的技術間，就要有一定程度的磨合（像是辦幾場教育訓練課程把團隊程度拉上來；自己寫個介接的函式庫），若無法磨合的話可能就要放棄使用該技術。

新技術的誘惑可能會是阻礙你做技術決策的絆腳石之一，因為通常新技術（new technology）總是很容易吸引眾多技術人員的目光，然而現實是很殘酷的：向下相容性（backward compatibility），很多新的技術是無法向下相容的（例如 LINQ），若你身在新的軟體公司，且不必在乎向下相容的話，恭喜你，新技術可以當成是你的新坐騎，有如關羽得赤兔馬般，可以盡情釋放你的創意以及開發能量，或是幫你很快的解決問題。但若你身在一個有很多應用程式或是網站平台的公司，已經累積許多專案的情況下，那麼很抱歉，你可能無法很順利的導入新東西，因為你必須要顧及向下相容性，而且可能你的同事或團隊也未必對新技術有基本了解，此時可能就無法貿用新技術在專案上，那可能會讓你吃上無止盡的苦頭。

還有一種情況，就是本身很喜歡追新技術，學習新技術固然是好事，不過任何新技術的導入都要做過適當的技術評估（technology assessment），才可以決定可不可以導入，太過於追求新技術對架構設計並不是好現象，也不應該發生，架構所求的應該是廣度以及穩定，而不是求新求變，就像房子不可能一直改基礎或樑柱一樣，求新求變在 RD 上可能很好，但在架構設計上反而會變成相對較高的風險因子，不可不慎。

決策力的培養，通常以廣度為優先，因為有較寬廣的知識（像是可解決同一方法的不同技術，且不限於某一平台）在決策時可用的選擇就會變多，像是要做網路銀行，可以考慮 EJB 或是 .NET Enterprise Service；要做互連的應用時，端口的技術要用 MSMQ，IBM MQseries 或是 Java Message Service 等等。有了廣度後，再依不同的產業（領域知識）去做深入的評估訓練，像是要做 EC 平台時，選用的技術，資料庫，資料結構，設計方法，開發方法與部署方法等，每個不同的環節都有不同的決策方向，而且要練習多面向的思考，也就是要訓練自己的設計決策必須要符合多種開發特性（可延展性，強固性，物件導向等），這樣在架構發展上會容易具有較高的環境適應性以及彈性。