在軟件開發的過程中，經常聽到一個詞叫“代碼複用”，就是根據具體業務場景，把一些比較公用的東西寫出來，封裝固定方法或者類文件，然後多處調用，這麼做的好處就是大大提高了開發效率，節省了勞動成本，減少了工作量，“代碼複用”是軟件思想中最普遍的一個思想了，但是在現實中並不是所有人能夠對“代碼複用”思想良好運用，最後是“代碼複用”變成了“代碼複製”！近期一名碼農網友分享了他身邊的一個故事。
據這名碼農網友說，他算是一名應屆生，不過現在也算是對公司的各項業務都熟悉了，近期他發現，他寫的代碼總被同事抄！leader分配給任務後，他先提交了，同事就是連註釋都不改，直接把他的拿來就套他的代碼。週報也是這樣，他不提交她（他同事）也不提交，他提交了她（他同事）複製過去只改幾個字就提交。他對此非常生氣，於是就遲遲不提交，leader問他他就說還有點bug沒改好。另外這名碼農進一步解釋他負責移動端，她（他同事）負責pc端，框架是leader搭的，代碼結構都一樣，往裡面填代碼就行了，特別簡單的，他填好了推上去，同事立刻把他的拉下來改成她自己的。這令這名碼農網友非常生氣，針對這樣的情況，讓我們看看其他網友們都是怎麼看待的吧！
網友一：告訴你leader說pc移動你都能搞定，全讓你來幹
上世是朵花：這麼說倒是不合適，可以讓leader考慮一下，規劃一下中間層代碼，可以供pc端與移動端複用，而不是“複製”，這麼說就顯得格局更高一點了。
阿里巴巴員工：其實很簡單，用幾種設計模式寫出來，搞得越複雜越好，埋個很深的按端區分的邏輯。還能鍛鍊自己
上世是朵花：但是要把握好度，別讓leader認為代碼不友好，可讀性不高等情況。
網友三：我們組有2個人抄一個老同事的代碼，老同事寫了一個拆分集合，多線程調用的方法。然後週會的時候，經理問那2個人為什麼拆分4個集合呀，2個人懵逼了，就說覺得4組好，把我們樂的
上世是朵花：看來這種“代碼複製”的情況還存在的真不少，不只是個例，作為技術管理者，要讓代碼複用 去替代代碼複製才能讓團隊工作更高效。
網友四：正常的軟件公司不會讓一套代碼在多個不同的項目裡面重複使用。
上世是朵花：沒錯，這種方法工作效率低些，大家都在重複勞動，顯然不划算。
網友五 ：你下次和她協商唄，一人做一部分，然後互相抄
上世是朵花：原來是一個人幹兩個人的活，現在變成兩個人幹一個人的活，這出發點沒什麼不好，但是不一定能行的通，他同事願意麼？另外這麼做也不是什麼好辦法，本來可以複用，卻選擇複製，後期還需要投入兩個人來維護兩份代碼，顯然是比較愚昧的做法。
網友六：“她”是重點
上世是朵花：這名網友把焦點放在這兒，呵呵，我想樓主並沒有想這樣表達吧！
網友七：抄代碼怎麼了，代碼不就是用來copy的嘛
上世是朵花：對，抄代碼沒什麼，抄代碼是允許的，比如工作中的事情，從網上搬過來一段代碼，修改一下能用也是允許的，但是，同一個公司存在大量的冗餘代碼顯然是不科學的，無形中增加了勞動力和代碼的維護量。
網友八：移動pc代碼又不能完全複用，這種要搞死他分分鐘的事情
上世是朵花：如果只是簡單複製別人代碼，不去做深入瞭解，後期維護的話，顯然也是成本很高的，就會覺得當初還不如自己寫呢。
從這名網友分享的情況，可以看出他們公司在代碼管理上存在這一定的問題，而這名程序員只是站在自己的角度看出自己代碼被抄，很不高興，而他卻沒看出這是一個技術管理方面的一個問題，這種重複勞動在軟件開發領域是最不應該出現的，作為技術管理者，有時也不要老想著人不夠用，應該多想想現在的開發流程是否正確，是否將每個人的價值充分發揮出來了，如果老是讓一些人重複的搬運代碼，他們就不是程序員，而是搬運工，這樣的話，他們會遲早厭煩現有的工作，會感覺很枯燥，他們不能發揮出自己的價值，對整個的技術團隊成長也是非常不利的，更談不上團隊的高效了，因此建議技術管理者，要多與一線程序員們溝通溝通，深入瞭解一下當前的開發狀況，並作出顛覆性的規劃，這樣不但能提高團隊的開發效率，讓團隊成員的價值充分得到利用，同時也大大增加了公司的整體技術實力。
以上所有圖片均來之互聯網
大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步瞭解我，那就關注我吧！
閱讀更多 上世是朵花 的文章
