Bug，程式設計師心中永遠的痛。Bug，意味著錯誤、加班、不確定性、交付風險、改別人寫的程式碼等等……隨便找有過一兩個專案經驗的開發者，問問他關於debug 的回憶，氣氛都不太融洽。

為了對抗 bug，佔據智力金字塔頂端的人們也發明了各種各樣的工具和手段，上至高大上的方法論，下至接地氣的生產工具。從越來越先進的 IDE到複雜的程式碼審查制度，從單元測試到整合聯調，再配上beta版、試用、公測等等...目標很明確，結果很慘淡。

關於為什麼會產生 bug ，荷蘭計算機科學家 Edsger W. Dijkstra 有過一句經典名言：

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

換而言之，存在即合理。

所以，有生之年如何才能寫出沒有 bug 的程式碼呢？

答案是：不寫程式碼。

這句正確的廢話儘管聽起來悲觀，但也隱含了一個方法論：儘可能少寫程式碼。在解釋這個方法論的時候，我們先分析一下程式維護的特點，為什麼bug的產生無法避免 ？軟體工程經典鉅著《人月神話》用“前進兩步，後退一步”一語道破了程式維護的一個基本問題：缺陷修復總會以固定（20%-50%）的機率引入新的bug，整個過程是前進兩步，後退一步。

“我們為您修復了一個bug，並帶來更多的bug”

軟體系統開發是減少混亂度（減少熵）的過程，它本身是處於亞穩態的，相反軟體維護是提高混亂度（增加熵）的過程。而要解決bug的問題，程式碼開發僅是其中一環，實際還涉及了前期需求調研、軟體設計和開發完之後的整合測試、交付運維等環節。

需求分析、軟體設計麻省理工學院發現軟體釋出生命期中有一個有趣的迴圈：新版本修復了上一個版本被發現的bug以後，程式會正常執行一段時間，接著，錯誤率又會重新攀升、bug又會集中出現。因為當用戶的使用達到了新的熟練水平，他們開始運用新的功能，這種高強度的考驗查出了新功能中很多不易察覺的問題。

矛盾來了，一方面對軟體開發者來說，使用者能真正把軟體用起來是讓他們非常有成就感的一件事，但是隨著使用者對軟體功能的深度探索，新的bug接踵而至，太難了...

軟體的建設與應用本身就是一項需要深度改變使用者習慣的工作，回到上面“儘可能少寫程式碼”的方法論，無程式碼開發的一項重要價值就是透過“所見即所得”的視覺化構建方式，在前期需求調研、軟體設計階段就把實際使用軟體的業務人員拉上一起參與軟體的共建共創，保證軟體的使用者在一開始就熟知軟體的各項功能，並全程參與除錯，避免上述“熟練使用之後才發現bug”的情況。

軟體實現傳統開發方式裡，前端工程師根據需求文件及高保真圖花大量時間寫程式碼，開發頁面樣式，後端工程師根據業務流程圖和後端邏輯重複造輪子，程式碼質量堪憂。為什麼缺陷不能徹底被修復？看上去很微小的錯誤實際上可能是系統級別的問題，修復區域性問題的工作量很清晰，但是更大範圍的修復工作常常會被忽略，當軟體結構很複雜、文件寫得很爛的時候debug更痛苦。找bug和找東西在這方面有異曲同工之妙，所謂“燈下黑”，你找的時候它死活不出現，你不找的時候它又不請自來。

整合測試

理論上，每次修復一個新bug後，必須重新執行先前所有的測試用例，確保系統不會以更隱蔽的方式被破壞。在快速迭代開發的過程中，新版本的連續釋出讓迴歸測試進行得更加頻繁，成本非常高，維護成本通常是開發成本的40%-80%。

交付運維軟體維護的週期比較長，出現人員更替、工作交接也是很常見的現象，這導致維護人員通常不是編寫程式碼的開發人員，而是一些初級程式設計師或者新手，本身技術人員的水平參差不齊，程式設計師有多討厭讀別人寫的程式碼也無需多說了...而無程式碼開發的方式可以拖拽介面、修改配置、即時響應驗收需求，做到“邊驗收邊修改”，視覺化的應用配置方式可以讓工作無縫交接、非常方便。

不止1024，希望大家善待身邊的每一位程式猿，希望碼農們不要再談bug色變，可以從繁瑣的CRUD中解放出來，做一些更有價值的工作。當然也希望大家看到無程式碼不是洪水猛獸，不單純是為了脫離程式碼，在提高軟體產能、降低缺陷率、提高可靠度和提升使用者使用體驗方面，我們還是有一些真功夫在身上的。NO CODE NO BUG

NO CODE NEW WORLD