Giovanni Asproni

現代應用程式很少從零開始#

現代應用程式極少從頭建構。它們是使用現有的工具——元件（components）、函式庫（libraries）和框架（frameworks）——組裝而成的，理由充分：

• 應用程式的規模和複雜度持續增長，但開發時間卻越來越短。讓開發者專注在商業領域程式碼而非基礎設施程式碼上，是更好的資源運用
• 廣泛使用的元件和框架，bug 通常比自行開發的少
• 網路上有大量高品質的免費軟體，降低了開發成本
• 軟體的生產和維護是勞力密集的工作，因此買（buy）可能比建（build）更划算

選擇工具時的注意事項#

然而，為你的應用程式選擇正確的工具組合可能相當棘手。做選擇時，請注意以下幾點：

架構不匹配（Architectural Mismatch）#

不同工具可能對其上下文有不同的假設——包括周圍的基礎設施、控制模型、資料模型、通訊協定等。這可能導致應用程式與工具之間的架構不匹配，進而產生 hack 和變通方案，使程式碼變得不必要地複雜。

生命週期差異#

不同工具有不同的生命週期。升級其中一個可能變得極其困難且耗時，因為新功能、設計變更甚至 bug 修復可能與其他工具產生不相容。工具越多，問題越嚴重。

設定複雜度#

有些工具需要大量設定，通常透過一個或多個 XML 檔案。應用程式可能最終看起來像是全部用 XML 寫的，外加一些用程式語言寫的零散程式碼。設定複雜度會使應用程式難以維護和擴展。

供應商鎖定（Vendor Lock-in）#

當程式碼嚴重依賴特定供應商的產品時，會在多個面向受到限制：可維護性、效能、可擴展性、價格等。

免費軟體的隱藏成本#

如果你計劃使用免費軟體，可能會發現它並非完全免費。你可能需要購買商業支援。此外，**授權條款（licensing terms）**也很重要。例如，在某些公司中，使用 GNU 授權的軟體是不被接受的，因為其病毒式特性意味著使用它開發的軟體必須連同原始碼一起散佈。

緩解策略#

作者的個人策略是從小處開始——只使用絕對必要的工具。初始重點是消除低層級基礎設施程式設計的需求（及其問題），例如使用中介軟體（middleware）取代原始的 socket 程式設計，有需要時再逐步增加。

此外，作者傾向透過**介面（interfaces）和分層（layering）**將外部工具與商業領域物件隔離，這樣在需要更換工具時可以將痛苦降到最低。這種方法的正面副作用是，最終使用的外部工具通常比原先預期的少。