My friends, my life, my style - James S.F. Hsieh

1/13/2010

什麼是好的軟體?



實務派的人說:
軟體是種高度特化的藝術品, 所以裡面怎麼做不重要, 只要整體的功能與效率符合需求並且執行的很好, 最好能夠用最低的成本來達到目標就是王道.
架構派的人說:
軟體是種有系統性的積木, 為了增加複用性與生產力, 降低擴充與維護的成本, 架構是軟體的靈魂.
產品派的人說:
軟體只要功能多成本低, 能快速生產能夠高度客製化, 在效能上有好的表現, 很少 BUG 就是好軟體.
使用者說:
軟體只要便宜 (最好不用錢), 好用, 快速就是好軟體.

軟體的特性還蠻複雜的, 它有著生產, 運作, 維護 時間長, 複製成本極低, 規格變動, 汰換率與人事變動成本高, 不易維護, 除錯與驗證等多種複雜特性. 要減少這些特性的缺點增加其優點是很明確的目標, 所以上面沒有一種人說錯, 軟體是在上述的多種衝突需求中找到一個最佳的平衡點就是好軟體. 但怎樣的平衡是正確的選擇就有很大的學問,

舉個例子: timing 就是市場的一切, 快速的做出產品可以爭取更多的機會來把握 timing, 然而好的架構會因為降低耦合增加彈性等多種考量而延長產品的開發時間, 有時候這些設計可能在當下會被視為 over design 而被捨棄或忽略, 某個層面這是對的. 如果這個產品賣得好而延長了程式與架構的生命週期, 接下來要面對的就是該產品的架構會因為未來的需求而受到考驗, 好的架構也可以降低維護的成本. 所以這個平衡的因子似乎因為生命週期而有不同的選擇, 儘管軟體的生命週期會因為市場的反應而難以評估, 有些軟體可能會沿用個 10 年, 有些則只會出一個版本.

再舉個例子: 架構的取捨有時候還得考量 programmer 的技術能力, 也許你會遇到一個窘境是你使用了一堆很棒的 design pattern 但你的同事卻一個也看不懂還是能存活下來. 你該用易懂直觀的架構還是稍微難懂但頗富彈性的架構呢?

再再舉個例子: 如果有個公司就是做 OEM 或是硬體驅動程式 BIOS 這類強烈需求導向的工作, 也許這個軟體一但 GM 就等於進了墳墓, reuse 對這類型的工作也許毫不重要, 也可能這些具有 reuse 特性的部分人家都已經做好了等著你用, 這樣的公司文化與工作特質下, 怎樣的選擇好呢?

什麼是好的軟體? 因為人, 因為時間, 因為佈署的方式, 因為舊有的包袱, 因為公司的文化與營運方式有著截然不同的答案. 連怎樣評估軟體是好是壞都是如此的複雜...