皖南阿蓮
作為一名愛面子的程序員，我倒是有很多次偷偷改 Bug 的經歷，特別是年輕的時候。
01. 測試環境，還沒有被測試人員發現，改了也就改了
代碼提測後，自己在測試環境上測了幾下，“哎喲，這裡好像寫的有問題，還好測試沒有發現...”，於是趕緊動手修改，編個理由更新一下測試環境，這個 Bug 就這麼神不知鬼不覺地修改掉了。
02. 測試環境 Bug 被發現，年輕的時候也要爭論一番
如果是測試人員提了一個 Bug，如果是我年輕的時候，第一反應通常是“不可能，絕對是你操作的原因”，或者“一定是錯誤數據的問題”，如果碰巧是平時就非常討厭的一個測試人員的話，總要找到各種理由證明不是自己的錯，比如一邊偷偷把 Bug 改掉，偷偷地更新測試環境，還要一邊說“是不是你瀏覽器緩存的問題啊，你再操作一遍啊”。
於是，“緩存的原因”、“你清一下瀏覽器緩存”、“有緩存，等我重啟下服務”，這也成為了程序員遇到 Bug 後的眾多回復之一，其實可能在這個過程中，我們已經偷偷把 Bug 修復好了。
03. 規範流程，光明正大地修改
當然，這種偷偷修改 Bug 的事情越來越少了，一方面是年齡大了，也知道這種所謂的“愛面子”是沒有意義的，另外也是因為現在的項目管理流程越來越規範了，在有些項目中，測試環境做了任何發佈都是有跡可循的，在一定程度上也杜絕了“偷偷”改 Bug 的行為。
04. 生產環境的任何 Bug 都，都不要偷偷修改
以上行為都是測試環境發生的行為，如果是生產環境產生 Bug 的話，千萬不能自己偷偷修復 Bug ，並裝作什麼事情都沒有發生過，這是非常危險的行為。
生產環境上發現 Bug，一定要及時和領導彙報，要迅速評估 Bug 對生產的影響程度，會不會產生錯誤數據，數據該如何修復；和測試人員溝通，評估是否測試用例未能覆蓋；Bug 要如何修復，什麼時候提測什麼時候上線，要快速評估並進行排期。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
剛上大學沒多久，就遇到件頭疼事。
富二代們剛來就帶著筆記本電腦，這讓咱們只能玩手機的屌絲輩們羨慕嫉妒恨。要命的事來了，晚上斷電不斷網，於是熄燈後筆記本仍然可以玩。
不巧的是，我們寢室也有個。常常熄燈後，非得把電池用乾淨才罷休。邊遊戲邊語音，還放著音樂，備受煎熬。雖經勸說有所好改，但過不了幾天又會復原。
為了迫切改變這個狀況，但又不想和新認識的同學扯，於是決定用技術方案解決。
可當時的家當只有一部諾基亞滑蓋手機，沒有裝備一切都是空談。唯一可行的，只有偷偷在他電腦裡設置個計劃任務，晚上自動關機。但那樣萬一發現了更不好，根本沒有技術含量。
無奈，只能把目光轉移到電腦之外，網絡上。如果不能上網，就算電腦能用，也不至於熬夜玩單機遊戲吧。
既然剛來時他的網線插口就能用，想必我這兒的也有信號。上一屆的肯定都開通過，總不至於走了以後還封掉。趁著有天寢室沒人，我把那筆記本的網線拖到我這邊一試，果然，信號！頓時來了精神，感覺有希望了！
也許你會說，總不可能把網線連到諾基亞上，然後用什麼惡搞軟件吧~ 當然不可能，那時的手機哪有這麼先進。
事實上，我們不用任何軟！件！，甚至可以不用硬！件！ —— 除了一根網線之外。
要說如何玩轉網線，還能從之前安裝機頂盒的那天說起。
曾有段時間，很多城市開始流行起數字電視。我們這也不例外，挨家挨戶的贈送機頂盒，還免費上門安裝。華數電視本來就和網通是一家，數字電視當然就是共享網通的寬帶了。由於之前已開通了網通，這次又要給機頂盒連網，我想至少得送個交換機才行吧。然而，安裝的師傅一進來，既沒掏出交換機、甚至連集線器也沒有，反而一剪刀把網線給割了！
當時就驚呆了，這究竟是搞哪門子鬼。儘管那時對網絡鏈路協議玩的挺嗨的，但物理層上的卻是一竅不通。那師傅不慌不忙的說，網線只要四個就夠了，還有些就是備用的。於是從之前的線裡，拆了四根給機頂盒。
這大出之前所料，居然沒用任何設備就把機頂盒接上了！於是，又開始異想天開了。。。
這分出來的兩股，在交換機來看是不是兩個獨立用戶？如果把他們接在一起，效果和一線插兩口相同嗎？能一樣短路局域網嗎？
懷著興奮的心情一測，果然可以！真把整個小區的網絡搞掛了！
在恢復之後很長段時間裡，一直撥不上號。在嗅探器裡發現好多鄰居們的也在不斷的撥號。顯然，剛剛那接通兩個4股線，把外部的STP包也轉發了，導致小區網絡被外部隔離了。
這一天，改變了之前的看法。原來只需一根網線，就可以來一次VLAN風暴！
為什麼一根網線插交換機的兩個口會產生風暴？因為交換機會把發往廣播地址的包，轉發到所有接口上。如果有兩個接口迴路了，一旦出現廣播包，就會彼此不斷循環發送，耗盡整個設備的帶寬。別小看交換機，它天生就是為發包設計的，風暴能把每個接口都佔滿，打出背板帶寬的流量。STP協議就是為了解決這個問題，進行迴路檢測。
儘管瞭解了這個新技能，但物理層的知識基本派不上用場，也就淡忘了 —— 直到發現寢室座位下有信號的那天。
根據回憶，寢室之間還打過局域網遊戲，顯然這不是獨立的網段，於是更加信心滿滿了！
立即找來一根網線，減掉一邊的水晶頭，刮掉外皮，然後把對應的四股兩兩粘上。果然，附近的寢室開始傳來 —— 不，先是寂靜了幾秒，接著陸續傳來的尖叫聲，吼聲。“卡了！”，“誰掉了？“，什麼情況？”，“靠，斷網了~~~”。。。
跑出走廊一看，整棟樓都暴動了！原來這寢室樓根本就沒劃VLAN，所有幾百號寢室都是連在一起的！！！
這時既興奮又擔心。興奮的是，以後有了電腦可以抓上千人的流量了。擔心的是，現在只想惡搞自己寢室，不想牽扯所有人。
不管怎樣，行動還是繼續。熄燈後本該休息，斷了所有的也沒什麼不好。
這時技術上已無大礙，就差實施了。如何從容而又隱蔽的操作呢？
為了不暴露沒電腦還插著根網線那麼荒唐，於是儘量沿著有遮擋的櫃子佈線，從衣櫃後一直拖到床鋪。剩下的水平部分就埋在床邊的縫隙裡，並用席子蓋著。
整個佈局不湊近仔細看，根本發現不了~
當晚熄燈後，夜貓子們又開始蠢蠢欲動了，我也迫不及待的開始試驗。和其他幾個同學一樣，假裝在玩手機，實際已開始悄悄的接線，頗有地下情報員的感覺。
當搭上最後一股時，流暢的遊戲聲立即出現了卡頓。畢竟整棟樓都在這個LAN裡，廣播包的數量是相當多的。
只聽得遊戲剩背景音樂，卻沒有音效了！
想著100Mbps的流量從手中捏著的網線穿過，彷彿看見密密麻麻的ARP、NetBIOS廣播在黑暗中閃過 —— 還有那少得可憐的、被擠掉的遊戲數據包。
下午的騷動又一次爆發了。儘管熄燈後少得多，但在夜晚的環境裡，顯然越發清晰。
被斷開的大多不甘心，還想繼續玩。這一次，不打算這麼暴力了，萬一觸發了迴路檢測，說不定整樓就被封了。
於是，改成搭上幾秒，斷開。再搭上、斷開。。。遊戲雖能運行，但不斷陷於卡頓之中。沒多久，傳來一陣陣溫馨的關機聲，紛紛洗洗睡了。
首戰告捷！終於睡了個好覺。
改良 v1
剛開始的幾天裡，效果非常理想，大家都乖乖的提前睡覺了。
不過沒多久他們就發現，網絡過會就會恢復的。原因很簡單，哥睡著前就把線放開了，於是他們又開始了瘋狂。
在迷迷糊糊睡夢中，要把網線重新搭上會困難的多。經常把不相干的也纏在了一起，結果就沒效果了。
於是，需要一次用戶體驗上的改進。
事實上，其中三股線都是事先粘好的，實際就控制一股而已。不如把那三股都提前隱藏起來，只留一股在身旁，這樣就不會搭錯了。
換了根網線重新制作。這次，直接把其中 3 股用膠布粘好，藏在衣櫃後面，只留一股拖上來。線路也細了不少。
這樣，就和電路開關一樣了。總共就兩根線，搭上或分開就行。
即使在睡夢中，也只需動動手指，就能輕鬆自如的控制整樓的網絡了！
改良 v2
不過這麼簡陋的設備，總會有操作失誤的時候。
在一個週末的半夜，被通宵的吵醒後，狠狠的搭上了網線，然後繼續睡。沒想到這一次太困，直接沉睡了過去。直到早上10點多，才被敲門聲驚醒。
原以為是隔壁同學，但敲門不斷，打開後發現進來一個揹著工具包的大叔。這時，才猛然意識到，搭著的網線忘了斷開了！！！整整斷了一晚，都查上門來了！
這時也來不及收拾了，心想這回終於要露陷了。不過那師傅一眼掃去，發現我們桌子上都是乾乾淨淨的，啥也沒有。唯獨敞著個筆記本，而且還沒關機。於是上前拔掉了網線，然後走了。
僥倖躲過了這一劫，迫切需要改進了。
如果能睡前開啟，睡著後自動關閉，那就十分理想了。再也不用睡夢中用意念去斷開了。
於是打算做一個有彈性的開關，必須按著才會開啟，鬆開就關閉。這樣睡著後身體放鬆就自動斷開了。
經過一番改進，把開關做得無比隱蔽：把兩根線塞到一個襪子裡，裡面塞了棉布等等有彈性的東西。正常情況線路是分開的，但輕輕往下壓就會搭住，放開後又恢復正常。
不過襪子捏手裡也怪怪的，於是就藏到腳後頭。至此，每當夜晚吵鬧時，只要腳趾頭稍稍踮一下，周圍的氣氛就立即變得格外安靜。
到此，總共花了兩塊錢打造的裝備，能讓腳趾來控制上千人的網絡狀態，簡直太有成就感了：）
沒多久，大家似乎發現了規律，只要聲音太響網就會卡，但無奈又找不到原因。於是都變得乖乖的安靜上網了。（每次回想起就特別搞笑）
當然，這裝置只投入使用了半年。第二個學期大家都裝了電腦，於是一起愉快的通宵上網了。
筑邦網
作為一個程序猿的我很高興回答本行業的問題。哈哈，偷偷的改bug?感覺程序猿又要被黑了。儘管現在很多公司有些會以bug數量來考核一個程序猿，但是我還是覺得沒有必要偷偷的改bug。至少以我的從業經歷來說，沒有偷偷改bug。
一個程序猿的日常
日常工作中，除了要完成功能需求外，絕大部分時間都是在解決bug，在調試程序。題主所謂的偷偷改bug,存在一種情況。但這也不能用偷偷兩字來形容。在互聯網公司，除了程序猿的存在，還有一些測試小哥哥小姐姐們的存在，我們做好了的功能模塊都是要給他們去測試的。正因為他們的存在，使得我們的程序被用戶所接受。而且我們的bug都是提交在bug管理系統的，比如禪道。這樣便於跟蹤。
是人都會犯錯，有一種情況就是測試過程中，被發現的bug都被提交到bug管理平臺，並指派給對應相關的人。但是也存在一部分bug是測試沒有發現的。反而這部分bug是程序猿自己發現的。面對這樣的bug，我們程序猿是有職業操守的。程序是我們自己寫的，就相當於自己的小孩一樣愛護。所以都會發現了bug都會自覺去改過來。這不存在說偷偷的改bug。
程序猿是一個善於分享乾貨，熱衷於技術分享的群體
在研發團隊中，程序猿都是善於分享的一夥人，雖然說是悶騷型，但是一說到技術，都會聊的很帶勁。現在大部分公司都會每週，或者每月都會開技術分享會。正是因為程序猿們骨子裡有這份分享。所以偷偷的改bug是不會存在的。即使是測試沒有發現的bug,我們把bug改過來了，也會出於分享精神，也會告知測試的。
總結：
我從沒有偷偷的改過bug。我也覺得沒有必要這樣。反而我覺得研發團隊都是一群樂意分享的一群人。熱衷於分享技術，分享經驗。及時有些bug，測試沒有發現，而程序猿發現了bug,會自覺的改掉。然後還會跟測試們交流，主動會跟測試說，自己剛剛改了一個什麼bug,要測試再幫我們去檢測下。這個才是我們真正的程序猿。
有沒有覺得贊同的程序猿同行們？一起交流討論下唄！
感謝您的閱讀胖子李愛互聯網
我們使用的更大型的程序，比如操作系統以及大型遊戲程序，它們註定了bug重重，而且許多bug甚至只有在大量用戶的使用過程中才有可能暴露出來，還有一些bug只有當你“惡意”的使用軟件的時候才會暴露出來，比如非法獲取系統權限。要求一個複雜的大型軟件，沒有任何bug，那基本上是強人所難，簡單說就是這超出了人類的能力，而我們製造的用來開發這些大型軟件的軟件本身就不是完美的。但我們當然希望儘可能完美，因此在軟件行業專門引入了軟件測試工程師。並且，希望儘可能減少bug的數量，完美做不到，但趨近於完美是有可能的。
交流不夠、誤解或者沒有進行有效交流
1.目的不明，不知道要實現什麼功能不需要實現什麼功能的情況下，就開始開發。
2.程序設計錯誤
和所有的人一樣，軟件開發人員也會出錯。
3.開發中途，需求變化
需求改變帶來的複雜性可能導致錯誤，還可能影響工程參與者的積極性。
針對以上，所以也會改bug.改完也會測試，合理後會經過告訴同事和領導一起來商討這個事情，在什麼情況下能達到最完美話，謝謝大家！
軟件開發工具
小琳看影視
程序員修改bug是非常正常的經歷，問題的玄機就在於偷字。
從事軟件開發十幾年，始終有一個認知只要是程序就存在漏洞，好的軟件漏洞和bug相對少一些，程序員就是喜歡通過不斷的修正問題或者框架來讓程序運行的更加流暢，軟件修正需要的是一個過程，所以程序需要不斷的升級，在現實生活中程序展示的形態多種多樣，有手機App的方式展示，有的各種基礎設備裡面，智能化的升級是自動悄悄的升級，被動的升級是出問題了打客服的電話，售後人員上門給升級檢查下，在現實中程序的更新方式多種多樣，當然每次升級解決的問題也會不盡相同，所以程序員大部分的時間不是在設計而是修正問題，有些問題是自身代碼造成的，也有一些是相鄰的模塊造成的，也有一些是特殊的場景做成的，這就是軟件開發的過程。
到底有沒有程序員在偷偷修改bug的行為或者程序員偷偷修改bug的理由是什麼？
程序員偷偷修改bug一般都是公司的行為。早期華為在技術還不是很成熟的情況下經常半夜盯著設備解決問題，因為在半夜的時候客戶不怎麼使用，這樣容易發現和解決問題，這種屬於典型的偷偷修改bug的公司行為，這種非常多的適用於創業的公司，很多企業由於早期的技術還不是非常的成熟，為了儘快的完成訂單就在拼命的趕訂單，難免會遇到一些問題，為了減少客戶的損失就在半夜或者客戶使用比較少的場景下拼命的修正和驗證問題，所以很多企業制勝靠的不是技術水準還是對客戶認真負責的態度，早期的華為就是這麼慢慢贏得客戶的，而程序員這種行為屬於公司直屬的。
有些屬於智能化的升級。特別是一些互聯網的設備，在遇到問題的時候也會啟動遠程升級的方式，這也算是偷偷修改bug的一種手段，但這種坐起來比較優雅，很多客戶可能都沒意識到問題就已經給解決了，所以很多企業出廠的時候就自帶上網絡，就是為了維護設備的方便，畢竟讓售後跑一趟現場或者讓客戶升級都不是非常好的體驗，如果通過遠程升級就給解決的問題，不但能夠及時的解決問題還能節省成本，也是很多企業比較願意做的事情。
個人行為的修改bug，一般是在平時開發過程中突然發現之前寫的代碼存在問題，就會立即同步在代碼分支上，並且會向自己的領導報備問題，這樣在下次程序升級的時候會自動給更新上去。其實程序員所謂的偷偷修改bug，更多的是自己在寫模塊代碼的時候自檢發現問題然後快速的修正解決，程序員幾乎每天都是發現問題解決問題，只不過這個過程更多是在思維意識裡面，其中很多不是放在小組或者企業的內部作為討論的重點，自己去設計修改程序這些行為都是在每個程序員自我意識中，這些都屬於偷偷修正的過程。
所以看這個偷偷是公司行為還是個人的行為了，大部分來講都是公司行為，因為企業還是想把事情做得更加完善，從企業的性質考量如果是事情都在企業內部解決的了，證明企業在規模上已經相當了，個人程序員偷偷修正自己的問題，也是偷偷提升自己內功的具體表現，希望能幫到你
大學生編程指南
沒有，除非搞壞事，自己留下BAG又良心發現[大笑]
修改疫情BUG的工作，是一件比程序員更困難、艱難的工作。
程序員重來不會為程序設置BAG，但使用程序的人使用中會遇到BAG，這樣就會導致使用者使用中遇到麻煩，反饋到程序員這裡來的就會及時修補，幾乎沒有完美的程序，有些重要的程序保證人們一段時間內不會碰到，但經過長時間的使用就會凸顯出來，舉個現實的例子：這次疫情防控措施好比一個程序，有一部分人想突破這個防控措施程序就要找漏洞，黃女士成功找到了這個BAG。經過修復這個BAG基本完美，結果就是一些人員、官員得到處理。對於BAG的危害也看出來了。而這個BAG的發現是防控措施的末端申報制度，就相對於人們使用程序發現BAG後上報，最終被程序員修復。
人生路上的BAG還得需要被人來上報呀。
哈哈外行人說內行話還請行家多多指教。
靜穩
沒有所謂的“偷偷改bug”，都是明目張膽地改bug，只不過會經歷一個階段。開始時幾乎沒有用大腦不停改bug，然後一邊思考一邊間歇性改bug，然後是腦子動了半天都改不出一個bug，最後的最後，因為一個bug苦思冥想了好久，可能幾個小時，可能十幾個小時，可能幾天，也可能半個月，甚至是改不好，一旦改好了，會像個神經病一樣，單手握拳，或者雙手握拳，從桌上或者從床上跳起，比看到自己喜歡的球隊進球還舒爽。
這就是所謂的bug和程序員之間的剪不斷理還亂，繞不過要死磕，好比一場相愛相殺的虐戀，整個過程是一種智慧的博弈和情感的拉鋸戰，可以用以下過程來概括：開始下定決心搞定她，然後慢慢動搖搞不定她，但是現實是一定要搞定她，再找找還有什麼方法能搞定她……總而言之，沒有改過bug的程序員，壓根就不是程序員。
火星課堂
如果是公司代碼管理不嚴格，自己發現自己代碼中出現了bug，並沒有被其他人發現， 就可以及時對齊修改，但是還要測試充分後再進行提交，以免新的bug出現
一般情況下，我們是無法偷偷修改bug的。比如我們現在使用Perforce和Github代碼版本管理系統，並且設置了代碼review機制，沒有通過別人approve的代碼是無法提交的，代碼任何改動都被記錄下來，所以沒有人可以隨隨便便改代碼，更無從說偷偷改bug
了。
作為一個程序員，我們要有嚴謹的思維，並且端正的態度，遵守公司規定的代碼提交規範，以確保代碼高質量。
三文魚愛芥末
我出現這種情況還是在一個項目全部是自己寫的，或者大部分是自己寫的時候。
一種是自己在使用過中有發現有問題，然後在別人發現前己經改好。
另一種就別人發現，但是我據理力爭，找了使用方法不當或者環境不同等理由搪塞過去，然後馬上去改好。
所以最終就被定性為 偷偷改bug。
不過如果是在協同開發的情況下，一般都會上git，所以基本上每次操作都會被記錄下來，這樣的修改都會被發現，也就不能稱為偷偷的。
所以還是要認真細緻點，養成良好的編碼習慣， 至少在push時儘量三思！
李老師tome
工作中有一部分跟程序相關，不只需要改BUG，還需要改“需求”，好操心，所以寧願，
思考2小時，出活5分鐘
要麼反過來，就成了，
出活5分鐘，bug兩小時，就相當尷尬了，就跟【OPPO手機的宣傳口號，充電5分鐘通話2小時】一樣的反結果
