最佳的版控系統方案應該是不存在的，正解是根據專案狀況選擇最適合的就是最佳的。 最早的版控是檔案取出與存回，可以透過FTP或SMB的方式進行。但實際這不能叫做版控，只能鎖定檔案避免另一個人蓋台，但阻止不了自己蓋台的悲劇。 真正進入版控開始是集中式版控，經典代表CVS與SVN，集中式的缺點，當沒有網路可連線到伺服器，就無法作業，因此有了分散式版控，經典代表就是GIT，有關版控演化說明可以參考這篇。 GIT作為主流分散版控代表，每個客戶端都可以當作是伺服器的備份，這種去中心化的分散運算作法，就是一種區塊鏈，跟邊緣運算又有那麼一點相似。 但話說回來，通常會用到版控，往往是有多個人在寫CODE，大家都各自分工，必定要同步，因此就有GitLab的出現，提供一個管理平台讓團隊可以交換。 最適方案是什麼？相信GitLab會滿足大部分專案需求。

今天來說說為什麼要用版本控制系統，最大的原因是因為版控可以將檔案存放多個歷史版本，避免辛苦心血因為一個不小心蓋台造成付之一炬。 至於有哪些版控系統呢？依據年代先後簡單列表如下： CVSSVNGIT 微軟的就先不列了，更多比較可以從參考這篇。

Bug修正成本請參考這篇，系統測試就是一種最簡單檢視有無Bug的方式，但是還有其他方法，參考如下： 單元測試Code review(早期的一種白箱測試方法)pair programming白箱測試(原始碼與弱點掃瞄)黑箱測試(駭客攻擊等滲透測試)

簡單聊聊，系統軟體專案中，越早發現的Bug，其修正成本就會越低，如果系統上線了，相對花費修正時間與費用成本就會愈來愈高，甚至可能包含修正資料庫的錯誤資料修正，請參考下圖： 早期發現、早期治療，治癒機率就高，軟體工程也是這樣，有一些手段與方法可以避免日後付出高額修正Bug的代價。 後話：系統需求變更成本也是這樣，越是後續修改，其時間與費用成本也越高。

首先簡單的說明一下甚麼是MVC? 模型（Model）：處理資料庫。視圖（View）：使用者看到的。控制器（Controller）：控制流程與處理View、Model之間的溝通。 那為什麼要用MVC進行開發呢?因為傳統的開發方式，例如.NET中的WinForm或WebForm，算是一種義大利麵的寫法，雖然有稍微把design與code分開了，但是還是「拉奏會」，跟義大利麵一樣。 以下有幾篇文章，推薦可以看看喔： 什麼是義大利麵型的程式開發?寫爛 CODE 是學程式必經之路 義大利麵做得太大的時候，系統會變得難以維護，一個程式原始碼檔案應該盡量維持在500行內較妥，行數太多的時候，人生會覺得非常的苦。 基於以上說明，所以MVC就這樣誕生了。為了便於維護而誕生，試想，當使用者說要改一個字的顏色，基於MVC就知道要去View裡面找，維護就會變得簡單。 但是也不能甚麼專案都要MVC，畢竟小專案要搞成這樣，反而會得到反效果，系統要夠大，才能把MVC的優勢發揮出來。

資訊的領域非常廣，很少有IT人可以把所有資訊領域都精通，因此從上游、中游到下游的一貫合作就顯得非常重要，以一個系統開發簡單的例子，來說明資訊產業鏈。 假設現在要開發一個上下班打卡系統，用的是NFC感應卡，那會是一個甚麼情況：上游：設計卡鐘實體，並提供軟體開發套件（Software Development Kit, SDK）。中游：因為取得SDK所以有辦法開發應用程式，例如自動抓取刷卡資料與更新人員等等。下游：進行系統維運，故障問題排除等。 不可能樣樣都自己來，因此也就有了系統整合(SI：System Integration)商的角色出現。