大家好，我是辣條，
為什么程式員會有代碼能跑就不要動的觀點？
今天就和大家說說這個有趣的話題，
針對這個問題某乎上有個小哥講了一個小故事，先分享給大家：
新來的程式員小哥覺得代碼不規范，記憶體釋放的模塊很混亂，這可能有隱藏的風險，接下來，他做了整合，把記憶體釋放進行了模塊化，專門整好了，代碼變的更優質了，對吧？到這里算是好的，
然后過幾天，就出事了，生產出現重大故障，系統記憶體泄漏，系統崩了，影響客戶使用，客戶投訴，扣錢，然后整個專案組開始大排查，排查到最后，就是這個記憶體釋放的優化，有個位置漏了，沒改到，但是其他位置全改掉了，然后這個沒改到的位置，記憶體長期不釋放，好了，記憶體爆了，記憶體泄露，系統崩潰，就是這個優化，導致了重大故障，
然后全公司通報批評，要求專案組整改，并且出檢討，現在能理解了嗎，代碼能跑，就別改，
辣條對這個倒是沒有太大感覺，也沒有很多作業這塊的經驗，不過之前暑假實習，有位前輩和我聊過這個話題，他大致是這么看的：
很多中小型公司和一部分大公司對于代碼質量、開發效率等基礎設施建設沒有什么追求，這些公司的商業模式側重在業務邏輯方面，由于各種原因（比如壟斷等），用戶對于產品質量沒有什么話語權，不得不容忍系統和應用的缺陷，這使得此類公司的技術團隊從KPI的角度沒有足夠的動力去改良代碼和系統的質量，除非這種改良可以直接帶來商業利益，
具體來說，比如一個提供打車或者外賣服務的平臺，它的商業收益主要來自于線下的用戶行為，改善代碼質量只有在用戶數量增長需要擴容服務、提高性能的時候才有正的商業收益，除此之外，改善代碼質量幾乎沒有可見的商業收益，這給中層管理者帶來很大的挑戰，因為他們需要去證明投入工程資源的產出，如果這種產出無法直接或間接地通過銷售增長、用戶增長等指標反映出來的話，中層管理者就不會愿意讓自己管理的開發者去改善代碼質量，
長此以往，代碼庫中會逐漸累積各種技術債和潛在的缺陷，隨著時間的推移，重構代碼的代價會越來越大，風險也越來越高，這種情況下從風險收益比來看，盡量不要改動能夠運行的代碼是一種區域最優的策略，
只有當代碼質量嚴重影響了系統的穩定性以后，中層甚至高層管理者才會有動力去投入資源做大范圍的重構和改良，而這種時候通常伴隨著技術團隊人員流動，很容易出現全部推翻重寫的局面，
辣條個人認為倒也不是絕對的，這取決于你個人對整個專案的熟悉和理解程度，
可以動的情況如下：
- 你是專案的主要代碼貢獻者之一，你對每個模塊做什么都有充分的理解，知道修改帶來的影響，
- 專案成敗責任在你，你需要判斷某個模塊如果不修改的風險，以及事故發生時會造成什么損失，
- 雖然之前的代碼很亂但能跑起來，但專案還沒上線，為了日后系統的穩健，你決定大動干戈，重構一下，
不要動的情況：
- 你往一個巨大的專案里面添加了小功能，為小功能而且修改已經存在很久的部分，風險是很大的，除非你有充分的理由，
- 專案bug很多，改了一個bug會有n個新bug出現，
- 專案已經上線，如果需要大改動，需要測驗，
個人建議：
- 如果你的代碼能跑，但你不知道它為啥能跑，你還是不要提交這種代碼了，搞懂了再提交，
- 寫單元測驗，以后修改了跑一次全部測驗，也知道修改帶來了什么影響，
元芳，你是怎么看的呢？歡迎在評論中留言，
行業資料：添加即可領取PPT模板、簡歷模板、行業經典書籍PDF，
面試題庫：歷年經典，熱乎的大廠面試真題，持續更新中，添加獲取，
學習資料：含Python、爬蟲、資料分析、演算法等學習視頻和檔案，添加獲取
交流加群：大佬指點迷津，你的問題往往有人遇到過，技識訓助交流，
👇🏻 獲取可通過搜索下方 👇🏻
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/328162.html
標籤：其他