什麼要偷偷呢？bug存在是難免的，修改以後做版本迭代就好了，導致改bug還要偷摸說明單位制定規則的人可能就不瞭解技術。

如果是公司程式碼管理不嚴格，自己發現自己程式碼中出現了bug，並沒有被其他人發現， 就可以及時對齊修改，但是還要測試充分後再進行提交，以免新的bug出現

一般情況下，我們是無法偷偷修改bug的。比如我們現在使用Perforce和Github程式碼版本管理系統，並且設定了程式碼review機制，沒有透過別人approve的程式碼是無法提交的，程式碼任何改動都被記錄下來，所以沒有人可以隨隨便便改程式碼，更無從說偷偷改bug

了。

作為一個程式設計師，我們要有嚴謹的思維，並且端正的態度，遵守公司規定的程式碼提交規範，以確保程式碼高質量。

一個程式猿的日常

日常工作中，除了要完成功能需求外，絕大部分時間都是在解決bug，在除錯程式。題主所謂的偷偷改bug,存在一種情況。但這也不能用偷偷兩字來形容。在網際網路公司，除了程式猿的存在，還有一些測試小哥哥小姐姐們的存在，我們做好了的功能模組都是要給他們去測試的。正因為他們的存在，使得我們的程式被使用者所接受。而且我們的bug都是提交在bug管理系統的，比如禪道。這樣便於跟蹤。

是人都會犯錯，有一種情況就是測試過程中，被發現的bug都被提交到bug管理平臺，並指派給對應相關的人。但是也存在一部分bug是測試沒有發現的。反而這部分bug是程式猿自己發現的。面對這樣的bug，我們程式猿是有職業操守的。程式是我們自己寫的，就相當於自己的小孩一樣愛護。所以都會發現了bug都會自覺去改過來。這不存在說偷偷的改bug。

在研發團隊中，程式猿都是善於分享的一夥人，雖然說是悶騷型，但是一說到技術，都會聊的很帶勁。現在大部分公司都會每週，或者每月都會開技術分享會。正是因為程式猿們骨子裡有這份分享。所以偷偷的改bug是不會存在的。即使是測試沒有發現的bug,我們把bug改過來了，也會出於分享精神，也會告知測試的。

總結：

我從沒有偷偷的改過bug。我也覺得沒有必要這樣。反而我覺得研發團隊都是一群樂意分享的一群人。熱衷於分享技術，分享經驗。及時有些bug，測試沒有發現，而程式猿發現了bug,會自覺的改掉。然後還會跟測試們交流，主動會跟測試說，自己剛剛改了一個什麼bug,要測試再幫我們去檢測下。這個才是我們真正的程式猿。

我出現這種情況還是在一個專案全部是自己寫的，或者大部分是自己寫的時候。

一種是自己在使用過中有發現有問題，然後在別人發現前己經改好。

另一種就別人發現，但是我據理力爭，找了使用方法不當或者環境不同等理由搪塞過去，然後馬上去改好。

所以最終就被定性為 偷偷改bug。

不過如果是在協同開發的情況下，一般都會上git，所以基本上每次操作都會被記錄下來，這樣的修改都會被發現，也就不能稱為偷偷的。

所以還是要認真細緻點，養成良好的編碼習慣， 至少在push時儘量三思！

這樣不好，如果是自己安排進度，則說明不是偷偷改。

如果是他人安排，則你偷偷改可能造成一個時間安排有衝突，二個責任無法劃分等管理問題。

程式設計師專注於程式程式碼的編寫，在軟體版本確定併發布後，需要進入測試階段。在測試前，不建議輕易去改掉已知的bug，以免引入其他更多的的bugs。建議將這個bug告知測試組，列入bug list，安排統一時間去解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是外行找到的，各軟體企業、組織包括我們，對找到BUG和修復BUG都會給予表揚或者獎勵，而不管BUG是誰寫出來的，只會對底級的、故意的製造BUG者提出批評或懲罰，但在我們公司還沒出現過，所以就不存在偷偷改，而是光明正大改。

有bug很正常，一個專案就是一個團體，一個團體是由大家共同維護的。專案有bug不一定都是由他人發現的，自己發現自己改bug是對專案對團隊很負責任的表現。專案好了，團隊才會更好。不抱怨，就事論事，只為找到bug的解決方案！加油

沒有，除非搞壞事，自己留下BAG又良心發現[大笑]

修改疫情BUG的工作，是一件比程式設計師更困難、艱難的工作。

程式設計師重來不會為程式設定BAG，但使用程式的人使用中會遇到BAG，這樣就會導致使用者使用中遇到麻煩，反饋到程式設計師這裡來的就會及時修補，幾乎沒有完美的程式，有些重要的程式保證人們一段時間內不會碰到，但經過長時間的使用就會凸顯出來，舉個現實的例子：這次疫情防控措施好比一個程式，有一部分人想突破這個防控措施程式就要找漏洞，黃女士成功找到了這個BAG。經過修復這個BAG基本完美，結果就是一些人員、官員得到處理。對於BAG的危害也看出來了。而這個BAG的發現是防控措施的末端申報制度，就相對於人們使用程式發現BAG後上報，最終被程式設計師修復。

人生路上的BAG還得需要被人來上報呀。

哈哈外行人說內行話還請行家多多指教。

沒有偷偷改bug，基本上碰見了都是光明正大改的，每改一次bug，自己的靈魂就會得到昇華，耐心，體力方面就會得到鍛鍊，bug什麼的從來不怕，自己年輕敢於同bug做鬥爭，每碰見一次就學到一點東西，對於我這種需要成長的人來說是件很開心的事情。

工作中有一部分跟程式相關，不只需要改BUG，還需要改“需求”，好操心，所以寧願，

思考2小時，出活5分鐘

要麼反過來，就成了，

出活5分鐘，bug兩小時，就相當尷尬了，就跟【OPPO手機的宣傳口號，充電5分鐘通話2小時】一樣的反結果

謝邀，首先本人並不是一名程式設計師，但是題主給的這個問題，想想還是挺過癮的。個人認為，首先做為一名程式設計師，不會惡意去做這個東西，對自己和圈子裡的影響都不好，不會有人蠢到自絕後路吧。那麼這種情況大機率出現的就是對付無良老闆或者上司。。。。個別領導和老闆，真的是該受點教訓。

程式設計師修改bug是非常正常的經歷，問題的玄機就在於偷字。

從事軟體開發十幾年，始終有一個認知只要是程式就存在漏洞，好的軟體漏洞和bug相對少一些，程式設計師就是喜歡透過不斷的修正問題或者框架來讓程式執行的更加流暢，軟體修正需要的是一個過程，所以程式需要不斷的升級，在現實生活中程式展示的形態多種多樣，有手機App的方式展示，有的各種基礎裝置裡面，智慧化的升級是自動悄悄的升級，被動的升級是出問題了打客服的電話，售後人員上門給升級檢查下，在現實中程式的更新方式多種多樣，當然每次升級解決的問題也會不盡相同，所以程式設計師大部分的時間不是在設計而是修正問題，有些問題是自身程式碼造成的，也有一些是相鄰的模組造成的，也有一些是特殊的場景做成的，這就是軟體開發的過程。

程式設計師偷偷修改bug一般都是公司的行為。早期華為在技術還不是很成熟的情況下經常半夜盯著裝置解決問題，因為在半夜的時候客戶不怎麼使用，這樣容易發現和解決問題，這種屬於典型的偷偷修改bug的公司行為，這種非常多的適用於創業的公司，很多企業由於早期的技術還不是非常的成熟，為了儘快的完成訂單就在拼命的趕訂單，難免會遇到一些問題，為了減少客戶的損失就在半夜或者客戶使用比較少的場景下拼命的修正和驗證問題，所以很多企業制勝靠的不是技術水準還是對客戶認真負責的態度，早期的華為就是這麼慢慢贏得客戶的，而程式設計師這種行為屬於公司直屬的。

有些屬於智慧化的升級。特別是一些網際網路的裝置，在遇到問題的時候也會啟動遠端升級的方式，這也算是偷偷修改bug的一種手段，但這種坐起來比較優雅，很多客戶可能都沒意識到問題就已經給解決了，所以很多企業出廠的時候就自帶上網路，就是為了維護裝置的方便，畢竟讓售後跑一趟現場或者讓客戶升級都不是非常好的體驗，如果透過遠端升級就給解決的問題，不但能夠及時的解決問題還能節省成本，也是很多企業比較願意做的事情。

個人行為的修改bug，一般是在平時開發過程中突然發現之前寫的程式碼存在問題，就會立即同步在程式碼分支上，並且會向自己的領導報備問題，這樣在下次程序升級的時候會自動給更新上去。其實程式設計師所謂的偷偷修改bug，更多的是自己在寫模組程式碼的時候自檢發現問題然後快速的修正解決，程式設計師幾乎每天都是發現問題解決問題，只不過這個過程更多是在思維意識裡面，其中很多不是放在小組或者企業的內部作為討論的重點，自己去設計修改程式這些行為都是在每個程式設計師自我意識中，這些都屬於偷偷修正的過程。

作為一名愛面子的程式設計師，我倒是有很多次偷偷改 Bug 的經歷，特別是年輕的時候。

程式碼提測後，自己在測試環境上測了幾下，“哎喲，這裡好像寫的有問題，還好測試沒有發現...”，於是趕緊動手修改，編個理由更新一下測試環境，這個 Bug 就這麼神不知鬼不覺地修改掉了。

如果是測試人員提了一個 Bug，如果是我年輕的時候，第一反應通常是“不可能，絕對是你操作的原因”，或者“一定是錯誤資料的問題”，如果碰巧是平時就非常討厭的一個測試人員的話，總要找到各種理由證明不是自己的錯，比如一邊偷偷把 Bug 改掉，偷偷地更新測試環境，還要一邊說“是不是你瀏覽器快取的問題啊，你再操作一遍啊”。

於是，“快取的原因”、“你清一下瀏覽器快取”、“有快取，等我重啟下服務”，這也成為了程式設計師遇到 Bug 後的眾多回復之一，其實可能在這個過程中，我們已經偷偷把 Bug 修復好了。

當然，這種偷偷修改 Bug 的事情越來越少了，一方面是年齡大了，也知道這種所謂的“愛面子”是沒有意義的，另外也是因為現在的專案管理流程越來越規範了，在有些專案中，測試環境做了任何釋出都是有跡可循的，在一定程度上也杜絕了“偷偷”改 Bug 的行為。

以上行為都是測試環境發生的行為，如果是生產環境產生 Bug 的話，千萬不能自己偷偷修復 Bug ，並裝作什麼事情都沒有發生過，這是非常危險的行為。

生產環境上發現 Bug，一定要及時和領導彙報，要迅速評估 Bug 對生產的影響程度，會不會產生錯誤資料，資料該如何修復；和測試人員溝通，評估是否測試用例未能覆蓋；Bug 要如何修復，什麼時候提測什麼時候上線，要快速評估並進行排期。

首先要看是在什麼情況下修改：

1-如果是測試過程中，還沒提交中試，那麼自己改很正常。

2-如果是已經在中試或者已經部署了，自己還在改，沒有透過系統進行版本升級，就會造成實際生產版本與歸檔版本不一致，容易造成版本混亂和升級存在問題。

3-正常的流程是開發測試過程中，可以自己改，但是如果已經部署了，需要通知使用者進行升級，並在半夜進行割接版本升級且確保升級後系統正常執行，否則系統需要修復到前一個版本。

以上，供參考。