盤點程序員那些奇葩的代碼調試方式,第2種覺得挺累!

在電視劇中經常看到牛逼的程序員,快速的敲著鍵盤,一屏一屏的寫著代碼,最後一個回車,運行通過,堪稱完美,可是在現實中,這酷酷的樣子真的很難見到,可以說沒有,那麼接下來我說一下現實中的程序員是什麼樣子的吧。

盤點程序員那些奇葩的代碼調試方式,第2種覺得挺累!

圖片來之互聯網

製造假數據

程序員在調試程序的時候,為了模擬一些場景,一些特殊情況,常會自己在測試系統的數據庫裡製造一些假數據,有的數據以自己的名字命名,有的以各種各樣雷人的話命名,有的直接寫著“測試”的字樣,各種命名手法,可是這些測試系統畢竟不是隻有一個人在用,有很多人同時在用,有的同學剛建的數據,起名起的太隨意了,比如一條數據記錄“aaaaaaaaaaa”什麼的,這時,另外一個程序員看到了,說,這是什麼鬼呀,然後就隨手把這條數據幹掉了,而這個創造數據的程序員運行了程序之後發現自己的數據消失了,於是就開始懷疑自己的程序是不是哪裡出現了問題,檢查啊檢查,最後才瞭解了真相,呵呵,所以有的程序員把自己的數據命名為“不要刪!”,“不要動!”,“這是炸彈,動了會沒命”等各種各樣的奇葩詞彙,呵呵!

盤點程序員那些奇葩的代碼調試方式,第2種覺得挺累!

圖片來之互聯網

排除法

其實作為現在的程序員,絕大多數對IDE的使用工具都是相當熟練的,IDE不單單是提供了自動生成代碼,語法檢查等有用的功能,它還有很多的功能可能大家都不常用到,debug功能是IDE的一個插件,有一部分程序員可能也知道這個功能,但是可能由於使用不熟練什麼的就沒使用他們。當他們自己寫代碼的時候,當遇到代碼運行錯誤的時候會採取下面這種奇葩的做法,我在這裡就暫且把這種做法叫“排除法”吧!

就是他們發現運行代碼出錯的時候,首先分析可能是那個地方出錯了,然後就把這個地方的代碼暫時刪掉,再次運行,如果運行仍舊報錯,還會繼續擴大排除範圍,知道運行不報錯了,他們就根據最後刪除的代碼來確定錯誤的根源,最後還得一點點的恢復代碼,這種操作方式想想都感覺累,大家說是麼?

盤點程序員那些奇葩的代碼調試方式,第2種覺得挺累!

圖片來之互聯網

二分法

還有一種更奇葩的調試方式,與上面說的排除法類似,但風格上略有差異,估計這種程序員深受二分排序思想的影響,創造出下面的這種所謂的“二分調試法”,這個方法的操作方式如下,當運行整個文件報錯的時候,他們會上去對整個文件的代碼先刪除一半,然後繼續運行,如果仍然報錯,就會對剩下的一般中再刪除一半,就以這樣的方式定位錯誤代碼所在,最後還是需要一點點恢復代碼,如果能使用debug插件調試來代替這種奇怪的調試方法,我想調試的效率起碼提高好幾倍吧!

盤點程序員那些奇葩的代碼調試方式,第2種覺得挺累!

圖片來之互聯網

彈窗調試法

下面這種調試方式往往是一些前端開發工程師在調試一些複雜的邏輯是喜歡用alert彈窗進行調試,而不是通過控制檯打印日誌的方式去調試,我想他們用alert彈窗的方式可能是看著比較直觀吧,一個大大的窗口擺在自己的眼前看著比較真實,難道是這種原因麼?

盤點程序員那些奇葩的代碼調試方式,第2種覺得挺累!

圖片來之互聯網

這種調試方式最大的一個弊端就是,當調試一些複雜的代碼時,比如多層循環,你要是想追蹤js變量的軌跡,可能彈窗上百次,上千次,最後會把你一直點到手軟為止,點的你筋疲力盡,呵呵。

呵呵,程序員朋友們,你們平時也遇見過周圍人使用上面的奇葩方式進行代碼調試麼?還有哪些更奇葩的代碼調試方式,可以在評論區分享給大家哦!

大家好,我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華,互動交流,如果想進一步瞭解我,那就關注我吧!


分享到:


相關文章: