新人一優化，系統就會炸！
阿粉最近在刷知乎的時候發現了一個很有意思的問題，那就是：為什么程序員會有代碼能跑就不要動的觀點?
說實話這句話在阿粉的工作中經常會聽到，不僅僅是對于一些長期沒人維護的代碼，對于日常維護的系統哪怕是之前實現的代碼，大家更是敬而遠之，能不動一行代碼絕不加個空格，更有甚者哪怕是復制一下之前的代碼改改，也不考慮復用之前的代碼，畢竟復制粘貼大法實在好用。
那么為什么程序員會有這種想法呢?
不得不說知乎的答主都說人才，同意一句：新人一優化，系統就會炸!
容易改出問題
首先當我們對系統不熟悉的時候，最容易改出問題，你是不是也遇到過明明就改了一行人畜無害的代碼，結果服務就掛了，然而還找不到任何原因，最后只能回滾!這種情況往往是因為對系統的設計不了解的人，不知道哪里有坑，看著只是改了一行很簡單的代碼，結果導致了服務宕機。
經驗告訴我們再修改任何代碼的時候我們都需要搞清楚這段代碼的真實意圖和邏輯，不管是誰如果面對的是一段自己不熟悉的代碼的時候千萬不能隨便動，因為很有可能會改出問題，動手之前一定要搞清楚代碼的具體邏輯。
特別是新人!特別是新人!!特別是新人!!!
這里的新人指的是剛剛接觸項目的人，跟工作年限關系不是特別大，新人雖然說因為沒有經驗偶爾會改出問題，但是并不代表有經驗的人就不會改出問題，特別是有一些有多年工作經驗的人，在面對新的環境和編程風格的時候，往往還是習慣自己的那一套，上來就大刀闊斧的改東西，結果導致各種問題發生。
這其實也是為什么有些公司愿意招聘一些畢業生，因為畢業生就好比一張白紙，可以慢慢培養，當然也可以理解成容易洗腦，哈哈哈。
成本問題
動不動代碼取也決于我們對這段代碼的投入是一次性的還是長久的，如果是一次性的那能不動就不動，因為不值得為了一次性的功能花費時間和精力去改動原有的東西，更不要隨便就重構(雖然我知道很多程序員動不動就喜歡說重構)。
但是在工作中很多時候我們都會接手別人的項目，接手的項目肯定是后續我們需要維護和迭代的，這種項目未來會有很多需求和迭代，我們要動，而且要精雕細琢好好的動，弄清楚系統中的每個細節，在適當的時候該重寫就重寫，該重構就重構，因為我們的目的是讓服務長久的運行下去，如果長期不動舊的代碼，只往里面添加，那么系統只會變動臃腫，最后想維護都維護不起來。這個時候我們就需要通過一些設計思想和設計模式來改造我們的系統，使其變得更加活力。所以就要動了，也該動了。
真的改不動
其實阿粉覺得還有一種可能，那就是真的改不動啊~網上經常有段子，說一個程序員看到一段代碼，不由自主的罵了一句：這代碼寫的就跟狗屎一樣，然后看一下提交記錄，打臉了，原來是自己幾個星球前寫的。說真的，這種情況經常會發生，很多代碼只有在面臨當時的業務需求的時候才知道為什么要這樣寫，時間一長根本記不起來當時為啥這么寫，更不用說再重構了，要想重構也需要花費很多的時間去重新理解當時的業務邏輯，但是在業務推動的社會，老板哪有那個時間給你重構!
知乎網友的一個回答也很有意思，截圖給大家看看。
是不是有一種蝴蝶效應的感覺，軟件開發有的時候真的就跟蝴蝶效應一個樣，不然也不會經常出現往往自己就改了很簡單的一行代碼，結果就崩了。
總結
總結一下該動舊代碼的時候就要動。
技術是為了業務服務的，當我們的技術或者系統在不滿足業務發展的時候就需要動，即使項目能正常運行，我們也需要進行適當的重構，作為一個合格的工程師，在設計系統的時候，我們要把眼光放到未來一年，提前做好設計和布局，這樣就不會被業務追著跑，導致系統臃腫從而最后改不動!
