你介意別人修改你的代碼嗎?

         自己的代碼被別人改動這事,應該不少人遇到過,作爲當事人之一,你介意嗎?

         我也遇到過,甚至在改動前基於修改人本身的一些情況,我會變得謹慎起來,甚至有些牴觸。理由很簡單:一個能力比你差得人要改你的代碼,你不緊張下。即使他的修改能實現需求,等到你看到修改的代碼可能是這樣的:

          邏輯有些混亂,可以簡化下,爲什麼要搞這麼複雜,不是有現成的SDK可以用嗎?

          很多無用的語句,無效的引用依然留在源代碼中,即使編輯器中已經有黃色標記警告也無動於衷;

           調試輸出的語句直接用print而不用日誌組件,事後又沒有刪除、註釋掉;

            註釋和代碼不對應,複製粘貼惹的禍;

            命名不規範,拼音英文混合,自己搞的縮寫;

            文件目錄劃分混亂;

            單個文件代碼過多,很多不相干的功能塞在一個類中;

            修改了已有接口的內部邏輯,卻不知道這個接口還有其他地方在調用。導致他自己的功能沒問題了。已有的功能出問題了。算是挖了坑;

            這些基本都遇到過,當然還有其他很多因修改引起的問題。遇到了這些,你還能淡定嗎?

            如果你已經不再參與這些項目,不用寫這些代碼,自然無所謂。

           當你還要參與項目開發,還是主要負責人呢?估計你會發飆、抓狂。開始也許還有耐心提出些建議,慢慢的同樣的錯誤一而再,再而三的犯,都不願意再交代任務讓其完成。或者在他提交了代碼後,還要看下實際運行效果,看下代碼。生怕挖了什麼坑。因爲一旦出了問題,領導首先需要的是能快速解決問題的人。而這時也就是你來頂上。所以有時候我寧願任務往後壓下,自己來做,也不願意別人接手。不是覺得自己多牛,也不是覺得自己有多好的精力,想圖表現。而是很多時候,別人做的時候你要仔細和他交代,中途還要協助下,最後收不了場了,還得自己去救場。後期再開發,本應該是由原來的開發者做,爲了趕時間,領導覺得你能力強,效率高,讓你來接着開發。有些開發員屬於過路,開發一段時間就走了。還有就是一直做開發,維護項目的,一般也是個小負責人。代碼沒有控制好,最後苦逼的就是他了,他是最後兜底的人。

           這就涉及到我改別人的代碼了。同樣我也不願意改人家的代碼,原因也簡單:要改他的代碼,就先要看他的代碼,理解他的思維邏輯,處理過程。對於那些註釋少,甚至沒有或者乾脆還是牛頭不對馬嘴,代碼命名還是拼音加縮寫的。就很難看明白了。再遇到使用的組件過時,架構不合理。你還有改下去的動力嗎。寧願另起爐竈都比這快。只有不得以的情況下,纔去使用,修改前任的代碼。

           在這種情況下,修改前我會把接口名字故意改動下,IDE一般就會有錯誤提示,哪些地方引用到該接口;或者新建一個方法,甚至一個文件,利用裝飾模式利用原接口做功能增強或調整,這樣既不改動原接口,也能實現自己的需求。

           有些可能還會引入新的組件,sdk來實現自己的需求。因爲每個人都有自己的技術棧,別人使用的東西對自己來說太陌生還得花時間去學習,或者不習慣用已有的組件,自己有更好的選擇。但這也會給整個項目代碼帶來另一問題,隨着時間的增長,參與人員的增加,都按自己的技術棧來完成自己任務,最後項目中就充斥着各種組件,甚至同類組件出現各版本。這對後期的項目維護是很大的危害。

           可能有人會說都是從新人過來的,都是從這樣的過程走過來的。問題是一些基本原則不應該忘記或完全不知。改別人的東西,可以先找原作者瞭解下情況;利用些技術手段規避修改帶來的問題;重要的是同樣的錯誤,不要一再犯。不要一上來就是一通猛改,自己的功能能跑通就可以。不管對原有的功能有沒有影響,會不會給別人挖坑。不能走自己的路挖坑給別人,讓別人填坑。這也不是什麼多高深技術問題、經驗問題,這首先就是做事的一個認知問題。不是所有的知識都是從教訓中獲取的。

       

     

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章