複製貼上比依賴更好

banq發表於2018-12-24

人們過於害怕程式碼重複，過於憧憬可複用可重用的美好，導致對程式碼重複發起了一場神聖的戰爭。如今人們提出了不同的意見，在Twitter上引起了一場爭論：

“我呼籲結束針對程式碼重複的神聖戰爭。我們讓年輕的開發人員和工程師相信這是有史以來最糟糕的事情，當時間告訴我們所有人時，絕大多數情況下，複製比依賴更可取。”

“特別是當我們透過抽象僅僅相似但不相同的程式碼來建立大量複雜性時。”

“我通常的過程是：1。編寫程式碼。2.複製貼上程式碼，修改新用途。3.再次複製貼上程式碼，修改新用途。4.當他們全部工作時，如果所有三種用途都可以合理地合併。......很多時候，由於使用不同，答案是“不”。”

“如果它們不能幹淨地合併，那麼合併它們可能不是正確的做法 - 用例太不同了。試圖合併它們是方形圓孔。”

“保留3份程式碼並不意味著它們不可重用，這意味著它們無法高效且乾淨地合併。”

“不重複程式碼是一個重要的學習課程。但是，一旦你學會了它，下一步就是學會平衡增加的複雜性與必要的重複。”

“如果遵循SOLID，DRY原則，則會很好。不要重複（單一）責任。”

“KISS勝過DRY。”

“依賴性是已知的。重複的程式碼很快就變成了未知的未知數。我更願意與前者打交道。”

“我認為這在很大程度上取決於你的複製程式碼塊有多大。小塊這很好，但對於大型例程，它增加了你複製bug的機會。一旦我進入了一個或多個程式碼螢幕，我通常會嘗試儘可能多地使用它”

“如果考慮微服務而不是類，則更為真實：服務透過“主要依賴”實現簡單性並透過“明智的責任”實現價值（在這種服務中複製程式碼是愚蠢的。）”

“對於只有少數開發人員的小專案，這是事實。在更大的專案上（假設> 10個開發者）我寧願儘可能避免程式碼重複。”

“一個新的CRUD API，在我的工作中只涉及50-100個SQL表，重約77,000 SLOC，因此列印2000-2500頁，4-5密集教科書。這種幾何爆炸在實踐中發生的唯一方式是複製/貼上，它會妨礙對理解的任何信心。”

“如果您複製的程式碼不是您自己的程式碼：請不要忘記檢查並尊重版權 ”

“rule-of-three：在有三個工作（獨立編碼）的案例之前，永遠不要建立“抽象層”。它也不是抽象，而是提取共性。”

“實用/有意識的程式碼重複和無意識的程式碼重複之間存在巨大差異。瞭解抽象和外部依賴的實際成本需要經驗！”

“概括通常是錯誤的。”

“藝術家透過複製大師來學習。”

“重複通常會在系統內發出巨大的問題。SOLID不是銀彈，它總是取決於實現者。”

“耦合/依賴對於維護者來說往往比在程式碼中改變一些地方要糟糕得多。”

“開源曾經是治癒良方，然後一些白痴開始分叉”

我的意見是：可複用是一個響尾蛇或美女蛇，很美好，但是導致過度設計，有界的上下文原則大於可複用！

你呢？

相關文章