如果您對此有所擔心，則應該閱讀代碼並提供建議（聽起來像是推動代碼審查的好時機！）。可能需要3000行。僅僅因為有3000行就可以確定它是對還是錯是任意的。

[根據更新進行編輯]

您說代碼的速度無關緊要。在這一點上，這聽起來像是醜陋的代碼。自從您已經給了他們建議（因為您不是他們的主管等）以來，最好的行動方案可能就是簡單地接受它並繼續前進。如果您需要處理他們的代碼，聽起來好像已經足夠細分，可以輕鬆地將其分解為多個功能，但是它按原樣可以工作，您可能不需要接觸它。

繼續老闆希望您從事什麼工作，並在適合他們的地方提出建議和改進。如果您嘗試修復所有錯誤，則會立即看到所有內容，而沒有充分的理由就會感到壓力。

我將重點放在可維護性問題上。

根據情況，一個只做一件事並且有據可查的1000行函數比20個行函數會延遲每個函數的可讀性和可維護性。決定十個調用函數實用程序的深層堆棧，隨著需求的變化，每個函數都會隨著時間的推移而移植特殊情況（我知道有些奇怪的說法）。

具有大功能的清單：

功能的長度通常與它的易懂程度相關，但這並不是一個硬性規定。

我曾經處理過遺留代碼，然後將整個網站處理在一個大約100,000行代碼的單個文件中。那就對了。該網站的所有內容都在一個文件，一個功能中完成。在某種程度上，添加或修改某些內容意味著您一直滾動到最底端，只需修改輸出緩衝區即可更改內容。就像有人說要更改句子一樣，我們執行正則表達式來搜索句子，然後將其替換為新句子。

我們最終到了使它變得where腫的地步，只有少數人是修改輸出緩衝區的“專家”。最終決定只扔文件，並以一種現代的方法重做整個站點。

我認為這將在這裡發生。保持3k功能，如果他繼續，只需扔掉代碼。那就是我要做的，而不是浪費時間試圖說服某人更好。它起作用了，這就是論據是什麼，那可能是正確的。如果沒有一個懂代碼的老闆或具有良好的軟技能，那麼您可能很難說服您的平等同事進行變革。

長方法絕對是一種代碼異味，但是它並不能最終表明有問題。實際上，我認為您不應該僅僅在長度上就將方法分開，這是任意的。例如，我看到了一些用於不同ETL（提取/轉換/加載）任務的長方法，其中長度實際上是由數據量決定的。

此時不要向老闆報告。找到可以改進該方法的明顯原因，然後以建設性的方式將其傳達給開發人員。

不用擔心。這不是你的問題（現在）。這是維護代碼的責任，而不是您的責任。不要碰它如果老闆要您觸摸它，無論是現在還是以後，請告訴他們為什麼不這樣做。

如果您的同事離開，您會買一本有關重構的書。這就是您告訴老闆此功能不可維護的地方。

我對此有何專業反應？

“太好了，謝謝！”

現在，如果您認為代碼不夠理想， 不管行數，您都可以在側面對其進行測試，以查看其是否滿足任何性能要求。這樣可以為您提供有意義的，可操作的信息。

如果您認為代碼遵循不良做法，則可以在代碼審查中提出。

您曾經說過，每個開發人員都應對自己的代碼負責，但是您希望向您的經理報告一位同事，因為他們沒有遵循您的標準。

如果有代碼可以按預期工作，在有問題的時候或為整個團隊設定編碼標準的時候，無需贅言。

請他編寫測試以證明其有效。檢查測試範圍。如果它小於100％，那就是個問題。

然後，至少，如果您有一天必須對其進行維護，您將能夠進行更改，而不必擔心搞砸某些東西而沒有意識到。

您在這裡有兩點：

• 在您當前的職位上，這不是您的問題，您說您的老闆要這個同事完成快速編寫代碼，所以他做到了，留下了3000行，並欠了很多技術債務，您可以向老闆提起這件事（他不懂編程，但是債務的概念是每個人都可以理解的知道）只是解釋說，在代碼正常工作時，如果出現問題或編寫該代碼的同事離開公司，需要花些時間來了解他的所作所為，他可能會理解，但即使他理解這一點，他也會說那不是問題，因為這不是問題，至少不是您的問題，這將我們帶到了下一個問題。

• 因此，同事離開公司，而現在是您的問題（您提到有3個開發人員，因此即使在這種情況下也可能不是您的問題），嗯，（我可以根據經驗談談）除非必要，請不要觸摸它，與您的b再次麻煩，記住他的第一次談話，但是在老闆批准或s＃！t發動狂熱之前，不要開始重構該代碼，因為如果您開始重構該代碼，這可能很容易，但是很有可能

一些事情需要考慮，即使這是一家老闆不多的小公司不了解軟件開發的工作原理：

• 如其他答案所述，雖然您的老闆不了解開發，但他了解業務（我希望如此），因此最好的方法是使他了解為什麼需要進行代碼審查，單元測試和其他實踐的目的是告訴他，這是投資，更少的bug，更少的生產停機時間等。
• 我不知道您團隊中的高層是誰是擁有3000條線的那條線，您可能很難說服老闆他在做什麼不是最好的方法。如果您是經驗不足的人，這也適用。
• 您可能想與您的同事交談，並嘗試了解他為什麼這樣做，他提到已優化，這可能意味著代碼可以如您所說的那樣工作，而且速度很快（您可能不會考慮與速度相關的問題，但是對於企業而言，有時候這是一筆不小的數目），但是他知道這有技術上的欠債，並且他計劃解決此問題，他只是按照您老闆的命令來完成。

我認為受到公車打例子可能是最好的。

我去找你的老闆，說：“如果員工被公車打，我擔心代碼的可維護性否則以其他方式無法使用，將需要我##週才能解決。如果在其他人不在家的情況下該項目需要維護，我可以在##週內無法從事其他項目嗎？”

讓您的老闆對哪個項目“已完成”或“可維護”更重要做出最終決定？

就我們所知，老闆可能是，客戶將不得不向我們支付兩倍的費用，因為如果他們想要完成修改，他們將不得不為此付出代價。

意味著對老闆來說最重要的是客戶要付的錢。

預防問題比等待問題發生並解決問題要便宜。你的老闆喜歡便宜。

詢問老闆是否希望長時間使用您的代碼，並且如果客戶付費，是否有可能更改。

如果兩者都獲得肯定，則表明您希望您的同行審查新編寫的代碼。它們不會花費很長時間，而且額外的時間將花費十倍，因為錯誤可以更便宜地更早地檢測到它們。在代碼中發現的錯誤比在客戶端發現的錯誤要容易得多，而該錯誤通常來自客戶端，但通常沒有幫助的錯誤報告。向他保證，您不會要求進行過多的代碼審查，也許每兩週一次。如果他詢問您是否不確定代碼的質量，請向他保證根本不是這種情況。但是6眼比2眼具有更大的視野，並且代碼審查是一種標準的行業慣例，因為它的好處遠遠超過了最低成本。

如果他同意的話，當您的朋友在您的代碼中發現錯誤時，請務必將其提及給老闆。提到如果代碼投入生產，您將需要花費更多時間調試問題。否則會失去客戶的信心。提及即使您從事不同的項目，這個團隊的工作水平也會提高產品的質量。 >如果他不願意接受自願去審查他的密碼的人，那麼您就沒有機會讓他讓您審查您朋友的密碼。

根據您的描述，您需要攀登一座山，並且需要一個團隊向上拖動。

我認為我不會特別談論1k線方法，我首先介紹與您的老闆按1：1進行最佳實踐。詢問他團隊是否遵循任何編碼準則或最佳實踐。假設答案是否定的，請針對所使用的任何編程語言收集一些鏈接，以獲取有關最佳實踐的文章。我嘗試與大公司的編碼指南保持聯繫...每個人都會聽說過的公司，例如google，Microsoft等，並從他們的編碼指南入手。實施最佳做法有何幫助……有什麼好處，等等。請不要帶來您的信息，您就是使者。您帶來了一些令人高興的方法，這些方法可以提高效率，節省資金，減少缺陷，而且清單還在繼續……

我認為您的老闆會對此方法做出更好的反應。然後，一旦（讓他）迷上了他，就可以進行團隊討論，讓我們開始關注它們。 （我還將介紹一些程序最佳實踐，例如代碼審查等，而不僅僅是編碼準則。）然後，如果您能在目前為止買到它們，則可以開始應用這些準則並審查新代碼（將舊代碼視為

“嘿，我發現了這種大方法，根據最佳實踐ABC，我們應該將其分解為只擔負單一責任的小方法，以此類推。”並從那裡走。

老實說，我懷疑您在這方面是否會走得很遠，但這就是我的處理方式。

如果老闆對編程一無所知，那麼我就不會告訴他。聽起來，您的同事將為他自己做到這一點，特別是因為他在吹牛。

代碼需要工作，這是老闆所關心的。當然，如果是大型項目，則大小和速度是重要的因素，但如果是小型或中型項目，工作就足夠了。

請您的同事向您展示代碼的運行情況或代碼本身，以便您進行檢查。

除了“ 3000 LOC”外，OP中還有另外三個短語引起了我的注意：

• 我應該將此信息告知上司，他對編程一無所知
• 我在這裡最大的擔憂是，我的同事可能會在某個時候終止與公司的關係，而我將不得不照顧他正在從事的那部分項目。
• 代碼審查在這裡不存在。

有人離開是業務風險，也許是非程序員容易理解的風險，並且可以減輕風險通過代碼審查。

您可能會告訴老闆，程序員（至少）應該理解彼此的工作-它的工作方式和實現方式-如果其中之一落在總線下。您可以添加這是正常的/專業的。

然後在代碼審查期間問您的同事，“這是如何工作的？”

您說您擔心的是...

我怎麼會讀到3000行的方法？

...所以代碼審查應該說明這一點-即他們如何解釋，如何閱讀

您可能想要堅持“您應該使用子例程”，但是如果同事懷有敵意進行更改（附加到現有實現中），那麼堅持就沒有意義了。只需確保您了解它即可，因此可以根據需要更改它（例如，如果繼承它）。

代碼審查還有其他好處...

• 錯誤檢測（但是您在代碼檢查期間發現了一個錯誤）
• 知識轉移（您可能會通過閱讀彼此的代碼並進行討論來互相學習）
• 模塊之間更好的集成（另請參見康威定律）

我嘗試使用靜態分析器執行此操作。來自計算機的反饋不會錯，因此您不必親自面對同事。您只需要在代碼規則上達成共識或採用一套基本的現有規則即可。

我在這裡感覺到兩個主要缺陷：

• 您提供解決該問題的方法嗎？僅告訴“此代碼太可怕了”不會工作。可能是一種觀點，它不會給公司帶來價值；老闆和企業需要解決方案。

• 您有審查程序嗎？無論團隊規模如何，都應該對代碼進行同行審查：實際上，提供有關如何重構代碼的詳細信息要比任何可能的抱怨要好，並且還可以解決上述問題。

我從您的編輯中得到了答案：第二個是“否”，所以也許要向老闆指出正確的事情是談論過程，而不是指出他無法正確評估的單個“代碼失敗”，除非他相信您會很開心。

如果您告訴老闆：

聽，我有一個想法可以使我們的工作更有效率：我們可以編寫更好的代碼，更好地適應改變業務，減少錯誤並擁有可維護的代碼庫，對於新來者來說也更容易掌握

，也許他會更仔細地聽。您在提供解決方案，而不是指出問題。

該函數試圖做什麼？這項任務有多複雜？他們的目標是什麼優化類別（速度，準確性，可用性）？沒有這些信息，將很難做出判斷。您可以隨時查看代碼。如果存在效率低下的情況，請指出它們，例如“代碼很好！快捷[省時/性能提升/無論如何]，您始終可以執行X以避免[瓶頸]'

您可能會因為技術原因而使您的同事相信編譯器可以為他們內聯，因此此源代碼級的“優化”無濟於事。

希望您誇大了他們說的話這可能是整個3000行方法最可能優化的，否則您的同事可能對性能優化一無所知，只是鎖定了他們閱讀過一次的內容。認為自己知道某事但真的不理解的人有時最難以說服。我曾在堆棧溢出註釋中進行過多次交流，人們拒絕相信它們是錯誤的，但是無法給出有意義的連貫技術解釋。

作為asm優化專家（SO金牌是[x86]，[assembly]，[performance]，[sse]標籤等），我可以告訴您，即使您的同事花了多年的時間進行性能分析和調整，該功能也是“最優化的”幾乎是不可能的（在某些特定的硬件上（具有某些特定的操作系統和編譯器版本））。較大的函數將始終有空間進行較小的調整（或進行較大更改的新思路），這些調整可能使其更快或更小（機器代碼）以相同的速度運行（也許對超線程更友好，可以用更少的指令來完成相同的工作） 。

我認為C＃編譯器+ JIT並不糟糕，它無法為您內聯方法調用，尤其是當它們只有一個調用站點時。我不了解C＃（主要是C和C ++），但是它具有類似 static inline 的非成員函數之類的功能嗎，編譯器可以內嵌 來發出基準單獨定義，即使該函數很大，也將這樣做嗎？還是GNU C __ attribute __（（always_inline））之類的東西？您的同事可以使用這些工具來感覺他們正在獲得他們認為重要的優化，而不會使源頭變得一團糟。

但更重要的是，僅當簡單基準版本（您以起點為基準，並針對優化版本進行基準測試）比您想要的速度慢時，“優化”才值得在可讀性上權衡強>。如果您沒有比較的起點，就無法判斷您是否實際上在優化任何東西，從而判斷可讀性或機器代碼大小/指令緩存佔用空間與加速之間的權衡。

編寫沒有簡單基準的可讀性差的“優化”版本通常是一個錯誤，除非您已經從經驗中了解到您知道簡單版本將如何編譯並且效率不高足夠。通常，作為單元測試的一部分，您將有一個簡單的版本，用於手動展開/矢量化版本。 （不過，這種手動內聯的情況可能有所不同。它不會使任何邏輯變得更加複雜或“奇怪地”實現。或者是嗎？塊之間是否存在手動優化？）

內聯通常對於小型函數而言，這樣做是值得的，但是從多個調用站點調用一大段代碼僅使用一次指令高速緩存。但是，它確實每次都會付出函數調用的開銷，因此僅對一個函數進行微基準測試就沒有程序的完整上下文，可能會使過度的內聯和展開看起來不錯。通常，我們可以將決定權留給現代的編譯器啟發式算法。它們通常都經過了很好的調整，特別是如果它們可以執行配置文件引導的優化來查找實際上很熱的循環。 （JIT編譯器在運行時運行，因此，如果願意使用它們，它們的確具有概要分析數據。通常從製作未完全優化的版本或首先進行解釋，然後使用概要分析數據推測性地內聯虛擬方法和類似的東西。）

有時優化不會損害可讀性，但在這種情況下，顯然可以。

在C ++中，我經常寫一些 static inline 輔助函數，這些函數將內聯成一個更大的函數，我正在使用SIMD內部函數優化廢話。當我查看由編譯器生成的asm時，機器代碼效率的下降空間為零，而源代碼的可讀性則具有良好的上升空間。這些幫助器功能的可執行文件中沒有獨立定義，因此它們甚至沒有膨脹可執行文件。

如果您想解決這個問題，請詢問您的同事是否查看了JIT編譯器的asm輸出以獲取其方法並對其進行了概要分析，發現這些大的條件塊使編譯器能夠以內聯無法實現的方式進行優化。

了解編譯器+硬件可以有效地工作並不總是一件壞事，如果您在不影響可讀性的情況下讓它告知您的編碼選擇。

很容易被吸引去優化不需要優化的東西。特別是如果您只是想優化一個函數在快速循環中被調用時的速度，而在非緊急情況下將其優化。如果不經常調用，則代碼緩存可能會很冷，因此緊湊會更好。 （更少的緩存代碼行可以從主內存中加載。）

這種參數僅在您可以從此3000行方法中排除任何常見的輔助函數時才有用。將每個塊放在單獨的函數中不會使機器代碼變小。但是，這可能會使要分配給哪個功能的決策邏輯更加本地化，​​從而導致該I-cache佔用的空間較小。而且從磁盤/ i-TLB佔用空間讀取/加載的4k頁面可能更少。

一些想法：

• 您的經理可能會提供解決衝突和調解的方法，但是他不能真正權衡技術優勢，因此他或她將需要依靠您的專業知識。如果取決於您的專業知識，那麼我認為您可以解決此問題。
• 您擔心不理會代碼的後果。如果後果是維護成本，那麼與您的同事下次下次必須更改功能時要努力工作相比，有什麼更好的方式讓您的同事學習該課程？經驗可以成為一名好老師。
• 降低成本的真正好處是可讀性，可測試性和簡單性。如果您的同事沒有理解這些好處，請他們分解這些好處將創建人為的代碼邊界。 向他們展示更好的方法將有所幫助。

換個角度看：領導力

我認為，而您的經理不是技術負責人，請他們解決這個問題將使您的同事學習的機會降到最低，並且可能會在您和他/她之間造成裂痕。

如果您不這樣做，讓技術負責人將其升級為，然後通過幫助您的團隊夥伴成長為更好的開發人員來成為該領導。

我們可以將所有這些歸納為兩種可能的方法：

保留原狀

讓他們按自己的方式做，當此代碼成為問題時，請幫助他們意識到為什麼問題並幫助他們找到一些可以拆分的關鍵代碼塊。他們會學習。說真的，沒關係。我已經在領導角色中做到了這一點。這只是代碼。以後可以更改。

顯示方式

向他們展示替代方案所有已實現的好處。通過將其分解為正確的層，在一個分支中重寫其代碼，使代碼清晰（良好的函數和變量名）並編寫非常好的單元測試。編寫測試，如果使用舊代碼，這是無法編寫的。在向您的同事展示此代碼時，提出您要假裝進行的任意需求更改，並逐步實施它們，以便他們了解實施 的容易程度，並確保其有效