1樓：florent
TDD是你必須嘗試的方法。如果實在不適應，也應該盡可能的增加測試的覆蓋範圍，這樣雖然不能完全避免bug，至少可以讓你debug的時候大大的縮小需要考慮的範圍。
2樓：
初級程式設計師的一點心得: 出bug不是最可怕的，最可怕的是出了bug但不知道錯在哪，為了防止跑飛，我寧可在每個迴圈和判斷之後加乙個斷言。
3樓：鍾子期
我認為大部分的bug 應該叫失誤，而不是叫bug ,因為很多都是之前沒有架構好，想明白而產生的，對外叫bug ，對內應該叫失誤。
4樓：siegfried415
我寫過乙個編譯器，為了保證沒有錯誤，我花了3個月的時間，又寫了幾千個測試用例，跑一遍需要乙個小時，不過從此之後，即使做任何改動，都不怕系統出問題了。
5樓：alexsunmiu
多多assert，每個函式在正式幹活前把所有的假設全部assert一遍，免得函式寫到一半時去想什麼萬一XX條件沒滿足怎麼辦這種操心的事兒~
golang木有assert，不開心！
6樓：無名
正確的設計加上充分的測試。
正確的設計保證系統的擴充套件性
充分的測試保證系統的邊界得到正確處理
二者缺一不可，是人就會犯錯，再精巧的設計也避免不了bug。所以需要充分的測試
如果設計一開始就沒考慮清楚，經不起推敲，那麼你寫再多的自動化測試作用也無濟於事。
7樓：
Tony Hoare的圖靈獎感言中有一句充滿了大智慧型的話，講的是設計乙個系統(或軟體)的兩種方式：「一種是盡量簡單，這樣顯然不會有什麼問題；另外一種是，盡量複雜，這樣沒什麼顯然的問題。」
8樓：shuhari
我的經驗是，在很多專案裡，最大的bug來自於產品經理/客戶/老闆。
這個bug就是：他們自己也說不清程式應該是什麼樣子的，但是等你寫出來以後，他們能挑出你成千上萬個bug。
然而你又能怎麼樣（攤手）
9樓：馮東
「慢慢寫，多測試」在實質上是對的，但是不等於在 real time 的工作方式。多測試也不應該是像 TDD 那樣對測試的瘋狂崇拜。實際上，版本管理軟體是程式設計師的時間機器，能用好這個時間機器就能做到在虛擬時間裡的「慢慢寫，多測試」。
關於單元測試
作為程式設計師，你闖過哪些大禍？
搬磚一工兵 誤把總和環境的作業手冊在產品環境執行，刪掉了queue，還好現場的高手手動恢復了。教訓，作業人員必須通讀手冊，有疑問要向老手特別確認。老手的命令不一定是老手深思熟慮過的。老手也應認識到新人不會知道黯默的規則，從新人的角度看手冊中的危險，煩，總比錯好。與同行互勉。 Mr.曹 晚上加班走的晚...
高階程式設計師和普通程式設計師有哪些區別？
大繁至簡 普通或者經驗缺乏的程式設計師相對於高階程式設計師最主要的區別在於 理解和分析需求時，不能充分調研各種可能性，缺少預判和主導能力。執行開發時，選型不明，不按照業界通行最小代價來實現。功能驗收測試時，缺少充分的自查自糾能力，容易給同伴增加額外的工作量。乙個判定原則 好的程式設計師，一定是讓別人...
作為程式設計師，2023年你有哪些正在做的個人專案？
Ray odt 我18年10月開始寫的離線光線追蹤渲染器基於RTGU peter的one weekend 三卷本小冊子然後部分pbrt 接下去準備寫完全pbr的其實就是基本移植pbrt 然後單獨的幾個小型測試工程 PPM SPPM 這種拉出來單獨試試 git wenxiwu777 圖形學太有意思了一...