軟體開發不等同寫程式

[Anthony Tsai]

要回答這個問題，首先必須瞭“軟體的本質”是什麼？在“數位式競爭”一書中說到：『軟體』說穿了，就是以數位形式呈現的知識。不過，我喜歡把它改寫成：
『軟體』就是以數位形式存 的“活知識” 。說它是“活知識”，是因為：軟體只要 “在目標的硬體環境上跑起來” ，就能 “發揮其作用”。

如果，您能認同這樣的看法，那麼 “軟體開發” 就是：將某一知識 (以下簡稱為對象知識)，由原來的形式(不是數位化的) 轉換成數位形式的過程。簡
而言之，此一過程就是：由一個擁有對象知識的人，將原本非數位化(高抽象程度) 的知識，傳遞給另一個人。再由這個人使用某種技能(分析、設計…等)，
將其接收到的知識內容轉換成另一種形式(低抽象程度) ，再傳遞給另一個人，再由其繼續降低對象知識的抽象程度，此一程序反覆進行，直到對象知識成為數
位化的形式為止的過程。

然而，對象知識的廣度 (該知識為一個人所具有或一群人所共有)與深度 (抽象程度的高低) 在不同的軟體間有顯著的差異。也有可能在軟體開發之初，對
象知識尚未完全成形，甚至根本不存在。以上這些種種因素都會使得，此一轉換過程會更為艱難與漫長。其間所牽涉到的轉換技 與人員，也更為多樣(角
色眾多)與多變(人員與角色的轉變)。此一因素又會反過來使得這個轉換過程難上加難。

因此，“如何確保對象知識”在這樣艱難又漫長的傳遞與轉換過程中 “不失真”，就成為軟體開發工作最大的挑戰。為應因這樣的挑戰，就有了種種的軟體工程
知識的發展。而其中最重要的基本要件之一就是：用書面的方式描述目標知識的不同抽象程度。

以“書面方式描述 (傳遞與轉換)”有以下的好處：
 可以將目標知識定型 (協助防止目標知識的變幻)
 可以有效地檢驗目標知識(檢驗是軟體工程的另一基石)
 可以進行非同步地溝通 (非同步溝通可以讓傳遞者與接收者有效運地用時間，縮短整個轉換過程所需的總時程)

以“不同抽象程度來呈現”目標知識，有助於不同人員(stakeholder)的思考與有效溝通。

以上簡短地說明了“軟體開發”的本質，接下來我們再來看看“寫程式”是怎麼回事。

“寫程式”是由英文“coding”意譯而來，其直譯為“編碼”。其本質則是：將某段“已適合”轉換成程式的文件，按照某種程式語言的語法，正確地轉換
成該語言的“程式原始碼”。“已適 ”的意思，是該文件的內容的抽象程度已低到，一位合格的程式設計師已不須要繁複的思考過程，即可將它轉換成程
式碼。譬如：某一蒐尋邏輯的演算法或某一商業規則的決策表…等，簡 言之，它就是該程式的設計說明。這個轉換過程是否被正確地完成，首先要經過程式
語言地編譯器檢查其語法，其次要經由單元測試去檢驗其語意。在這個過程中程式設計師的溝通對象有二 ，其一為“軟體設計師”，他們之間使用的溝通工具
(語言) 就是設計說明。另一溝通對象為“編譯器”，他們之間的溝通語言就是程式語言本身。再說的明白點，在這個過程中程式設計師是不應該有自己的想
法，它只要忠實地按照程式語言的語法， 設計說明的內容正確地轉換成程式語言就可以了。

到這裡各位看官，應該可以理解到：軟體開發“真的不等於”寫程式。

最後，再補充說明一點，我不是反對 Agile Method。我要說的只是：對不會以不同的抽象程度描述對象知識的軟體人或開發組織而言，
Agile Method不是終點，而是一個起點。對已有能力以不同的抽象程度描述對象知識的軟體人或開發組織而言，將Agile Method應用在
某些特定類型的對象知識(軟體)上，不失為一個輕快的好方法，不過要慎選其應用的對象。