「程式設計」不等於「軟體開發」

本文轉錄自IThome，作者為資深軟體人王建興。

作者以自身長久以來的經驗，指出「程式設計」與「軟體開發」的knowhow是可以被分離的，甚至可以說「軟體開發」的甚及層面更廣，包含了團隊的整合、測試與除錯、時程的安排...等等。

而這也是橘子蘋果一直以來想強調的特質：一個優秀的人才，絕非在數理或外語上保有優越而已。

在開發程式的過程中，提出構想、實作規劃、解決問題、發表、以及團隊溝通的技巧都是現今人才所不可或缺的！

對於「軟體開發」，很多人都會把它跟「程式設計」看做同一件事，但是實際上兩者是有區別的，還需要有完善的專案規畫、人力部署、品質測試與確保，程式寫完了，並不意味著軟體就開發完成。

在我從事軟體開發行業以來，有一個體會，是有些人對於這個行業有個誤解，包括我自己也曾經如此。究竟是什麼誤解呢？也就是以為寫程式就是開發軟體的全部或絕大多數。

不只我曾經這麼認為，我也相信有不少人也和我一樣有過類似的誤解，以為只要找了一些知道如何寫程式、或是很擅長寫程式的人，就可以順利地，把軟體開發出來。即使軟體開發的環節需要其他的角色，也不過只是配套，真正的主角還是撰寫程式，其他環節其實並不重要，搞定程式撰寫，就大概可以搞定整個軟體的開發了。

不過，在過去的經驗裡，也有過整個團隊都是程式設計高手，在開發軟體時卻屢遭失敗的經驗。這樣的情況給我一些反思，也就是程式設計其實並不等同於軟體開發，程式設計只是軟體開發的一個階段，是重要的階段，但重要程度不像大多數人所想像的那樣，支配著整個軟體開發的結果。在今天，相信還是不少人認為，只要找到了一群很會寫程式的傢伙，把他們湊在一塊，開發軟體就能無往不利，事實上卻不一定如此。

 

程式設計與軟體開發的區別

程式設計像是個人的作戰技巧，而軟體開發像是團隊行軍作戰，需要的不只是個人的戰技，諸如整體的戰略、陣勢、分工、武器……等等，也都相當的重要。軟體開發只講程式設計，就像兩軍交戰，我軍空有個人戰技，卻不談如何設定戰略、也不談該如何擺陣一樣。

在多年前我還是菜鳥時參加了一個專案，那時聽到了前輩和客戶的一句話，讓我心裡很震憾。我記得，他大概是這麼說的：「我現在已經不太懂得如何寫程式，但是我懂得怎麼做軟體，這個專案在我的協助下，會順利完成的」。這句話完全顛覆了我那時對軟體開發的看法。

我那時仍舊以為，能夠把程式寫好，軟體就能做得好。因為，不懂得如何寫程式，怎麼把軟體做好呢？然而，之後的一些經驗，讓我慢慢體會到這句話的意思。

開發軟體本身就是一個獨立的學問，和程式設計可以是分離的。程式設計是開發軟體中幾乎不可或缺的一環，但是並不是全部、也不是唯一。

這就好比測試工作也是一個專門的領域，也是開發軟體中無法省略的環節，但不會有人認為測試等同於開發軟體一樣。

之所以會有程式設計等同於開發軟體的想法，可能是源自於程式設計是產出實際程式碼的直接手段，因此，才會有類似的迷思產生。

據我觀察，不少人都有這樣的迷思，而這樣的迷思，會使得我們在開發軟體時，太側重在程式設計部份，而忽略了其他在軟體開發中，也必須關注的重要的事情。

就像前段中所說的，軟體開發是一個獨立的學問，它探討的是相關的觀念和方法，使得人們可以更好的開發出軟體。

如果拿打棒球來比喻，球員的打擊技巧像是程式設計，總要把球打出去，才可以發動真正的攻勢，但是，若是要得分，要有選球的觀念、跑壘的觀念，球員間需要合作才能在一個個的壘包間向前推進，而教練也會有各種的戰術運用，像是打帶跑、盜壘、牲打、等等……，綜合搭配起來，才能在一局局的球賽中嘗試得分。

守備方也一樣，面對不同的打者，會有不同的守備陣形，而投手的配球策略也會做因應調整。當攻擊方擊出球時，不同位置的守備球員該怎麼移動、補位、甚至如何進行封殺、……等等，這些觀念也都會深深影響最後的結果，而不單單取決於投手的球速、變化球的種類或變化幅度。

想打好一場棒球賽，固然個別球員的球技扮演重要的角色，但是像是作戰策略的擬定、或是融入於比賽之中的各種觀念，默契搭配方式，其重要性也不亞於球技，甚至更在那之上。

棒球比賽的例子，我們可以拿來類比軟體開發的觀念及方法。若想好好地設計出軟體，光能設計程式還不夠，你得懂得如何開發軟體，而且不是懂得程式設計就懂得開發軟體，兩者可以說是獨立的領域。

因此，我們應該要把軟體開發當做是一個獨立的學問來看待，而不是把它和程式設計給混在一起，才能夠把軟體開發做的更好。

 

軟體開發的要件

在軟體開發裡，你要懂得開發軟體的流程、步驟、跟步調。軟體開發中有很多基本的觀念，就像棒球比賽中跑壘、選球那樣的基本，也那樣的重要，但還是很多人是在不了解或不貫徹這些基本觀念的情況下開發軟體。在這種情況下，即使很會撰寫程式，軟體開發的過程，也有可能發生諸般的問題及不順利。

就像有個基礎的小觀念就是，在開發時你應該畫分階段，不論究竟分為多少階段、也不管每個階段究竟有多長或多短，每一個階段都有一個明確的開始和結束。在每個階段裡都應該要有明確的需求、有個明確的目標，才能開始進行之後的開發動作。

但是，我們還是很常看到一些人開發軟體時沒有明確的階段畫分，把所有想做的事都混在一起，也沒有明確的需求就開始寫程式，也放任需求不時地改變、調整，沒有任何管控需求變更的程序或手段。這麼一來，就容易導致無法收斂的需求、或是持續變化的需求，影響到整個開發。

 

控管品質也是軟體開發的一環

又好比對軟體品質穩定的看法，事實上，在程式碼寫完之後，還需要一段測試及修改的時間，而這段時間通常不少於撰寫程式所花的時間，甚至倍數於撰寫程式所花的時間。

其實，這是一個很基本的觀念，但也總有人不知道、或是不相信這個觀念，最後錯估了軟體實際需要完成的時程，或是在時間截止時，只能交付品質不夠穩定的軟體。

再者，又像是軟體開發中的瑕疵（defect）或議題（issue），經提出後，都需要被透過某種方式來追蹤，並且促使其完成。每個需求不論描述方式多嚴謹或多簡略，都應該有一個明確的描述方式，以便在團隊成員間溝通確認。

採用不同的軟體開發方法論，都有不同的信仰、價值、和所衍生出來的觀念，而絕大多數的開發方法，也都有其共通的基礎觀念。不論如何，我們都應該學習這些觀念並且把它們落實在實務的開發生活中。

軟體開發，除了大體的精神之外，就是由這個精神之下再展開的諸般觀念。這些方法和觀念的重要性並不遜於程式設計的技巧，甚至影響的層面更深遠。

有些人偏重程式設計而忽略軟體開發，或是誤以為程式設計就是軟體開發，都有可能使得他們不多下功夫在軟體開發之上。

然而，軟體開發本身就是一個獨立的學問，它關心的是如何用更好的方式打造出品質好的軟體，和程式設計有相關，但不能畫上等號，或認為它們很接近。

很多時候，我們不見得需要複雜的方法，我們只需要把一些基礎的觀念落實，如此就能得到不錯的成效。

因為，跑壘的速度固然重要，但跑壘的策略和觀念也同樣不可忽視呀。