您會怎麼做？您認為我的語言不專業嗎？

是。

您的評論跨越了從糾正（通常依賴於具體和具體的評論）到侮辱（“這是太可怕了，如果我們堅持下去，我們就注定了”）。

有多少經驗都沒關係。代碼是否完整無用無所謂。誠實不是無禮的藉口。這是停止團隊進步和動力的最快方法之一。無論您個人的經驗或生產力如何，如果您在工作場所的態度會阻礙您的同事，都會對您的公司造成整體傷害。

這特別麻煩（原因以及管理層）可能是這樣嚴厲地回應了），因為從長遠來看，它實際上傷害了您的團隊。您應該知道，如果您的目標是提高團隊所生成代碼的真實質量，那麼這將嚴重損害您的目標。之所以這樣，是因為當您因舉止重要而無用而獲得聲譽時，人們不會向您求助（當您嘗試提供幫助時，他們通常也不會聽您的話）。結果，隨著時間的流逝，您的任何經驗都會浪費掉，因為人們會停止聽您的話。

保持禮貌。提供幫助和更正，而不是批評。我個人認為，在這種情況下（向相關人員和團隊道歉）是非常合理的。

編輯以添加當然，這裡也進行了有益的評論當然很好，但是請記住，感知與現實同等重要。在許多情況下，只需使用一個選擇不當的單詞即可撤消代碼審查本身所做的任何實際好處。一個非常有用的代碼審查，其結尾（我理解這不完全是所發生的事情），“總的來說，這是垃圾”仍然會給編碼器留下一個非常不好的印象，並且很有可能它們會停止聽你說的其他話。在整個過程中的每一步都要保持整個過程的專業性。

以這種方式嘲笑他人的代碼是信息技術專業知識的最低點，並且超越了嘲弄您的觀點。

1. 這是公開完成的，這就是為什麼您（實際上）被拉到一旁的原因。
2. 它破壞了團隊。
3. 它滋生了怨恨。
4. 編碼器，就像藝術家們批判非常親自。
5. 這句話令人非常沮喪。該編碼器的生產力將受到打擊。
6. 這會使其他人不太願意冒險，以免他們被嘲笑。
ol>

我必須用最強烈的話說這是壞事。此行為沒有任何藉口。不要重複。

我有我自己的感受，我們當中的很多人都同意。與那些態度不好的人相比，我可以管理那些編寫了不良代碼的人，壓力減輕很多。我總是可以幫助您改善代碼，但是一個人的態度是我無法控制的，我不會與態度不好的人打交道。

對於被此類語言冒犯的人來說，很難解釋自己對未被此類語言冒犯的人的反應。通常有效的經驗法則是：如果關鍵性聲明解決的是超出一個特定事件的一般性，那麼這是令人反感的（因此不專業）。

換句話說，更專業的表達是堅持您的詳細審核，該審核特定於所審核的特定代碼。您可能會解釋，此錯誤代碼將提高代碼質量得分，這意味著我們也需要研究質量指標。人們已經做好準備，可以從一個嚴重的事故中吸取教訓。

但是，當您更改為全局上下文時，您的一條評論（是的，只有一句話！）現在是在批評員工自己或整個公司，並且更具威脅性。

您會在關係文學中發現全局批評和針對特定實例的抱怨之間的區別。 約翰·高特曼（John Gottman）的解釋（請參閱“批評”）是一個受歡迎的例子。

您選擇的單詞固然重要，但上下文更重要。說“垃圾進，垃圾出”是完全可以的（在我所知道的大多數軟件商店中），因為這具有特定的含義，並且您使用該短語來描述為什麼特定的設計不合適。走吧。

直接，誠實和直截了當。

否則的話：苛刻，刻薄，不外交。

要學習的艱辛我們程序員是人類不是機器。他們對赤裸裸的真理不感興趣。人類是社會動物，需要良好的外交才能進行溝通。

甚至有人甚至認為，溝通的真正目的不是傳遞信息，而是增進友誼。我不會走那麼遠，尤其是在專業環境中，但這是您永遠不會忘記的事情：即使在什麼都沒說您的情況下，“直接，誠實和直率”實際上也會使人們對您不滿意。 ，這可能會妨礙您以後的工作關係。理想情況下，您總是希望在讚美之間夾一層批評。

什麼才是發表評論的合適語言，這完全取決於您的公司文化，但是簡單地將某人的代碼稱為“垃圾”（括號內表明您實際上使用了一個不太禮貌的詞）肯定不是很有建設性的。它不會幫助任何人改進。

代碼出了什麼問題？他們如何改善呢？開發人員應該做些什麼？那是您應該包含的唯一信息。如果它太糟糕而無法超出評論的範圍，則應將開發人員擱置一邊並親自討論。

作為團隊負責人和經驗豐富的人，您有責任提供幫助您的團隊會進步。那是你的工作。相信他們在代碼審查註釋中並不能帶來任何好處。

您會怎麼做？為什麼您認為我的語言不專業？

所以……這是交易：

• 您是團隊的負責人；這意味著您應該建立團隊，而不是擊敗他們。

• 代碼是開發人員的工作；在同齡人面前以書面形式以垃圾方式稱呼垃圾是沉重的打擊。好吧，現在停止閱讀。下一部分...您可能會做些什麼？

  • 保留詳細的建議，這些建議很好

  • 在“總體”部分，說該文件未遵循以下詳細說明的最佳做法

  • 進行分組討論，與男生1-1或與男生進行培訓團隊來學習最佳做法。換句話說，將這個錯誤轉化為機會

  只有我的兩位，喲。

這非常取決於公司文化。但是，需要考慮一些常規事項。調用代碼垃圾可能被認為是不專業的，主要有兩個原因：

1. 它確實（本身）沒有提供關於什麼是壞的或如何改善情況的見解，它只是給出了代碼（低）值，雖然通常您只是想看一下它的優缺點，而不是一般認為它是不好的
2. 它可能對同事（即編寫該代碼的人）感到冒犯
> ol>

對於1），可以通過提供有關您認為不好的方面以及如何解決它的具體細節來緩解。通常，有一些原因說明事情原樣，而不是有人只想寫垃圾。該代碼可能非常適合編寫該代碼時打算完成的工作，但是上下文發生了變化。

對於2），如果您引用的代碼是某個特定人員最近提交的，該人可能會感到生氣。特別是如果他有理由客觀地寫一些不好的事情（例如時間限制），而您卻沒有考慮到這一點。通常，對您來說，垃圾是對其他人的完美選擇，稱其為垃圾只會將情緒帶入原本可以進行充分的客觀討論的地方。另一方面，如果您接管了一個舊的大型代碼庫，而當前團隊中尚無人認為“他的代碼”，那麼稱呼那堆可能是費解的代碼垃圾就很不切實際（仍然無法解決1個問題）但是，您最好對其進行備份）。另一個問題是如何交付任何包含詞義的行。越是情緒化的（和指責的）越糟，就越輕鬆，也許諷刺地針對自己，就越容易被接受。

因此，如果不確定，請不要將任何內容稱為垃圾內容。如果您想測試一下水域，請開始使用這種無價語言來編寫沒人會喜歡的代碼（或您自己的代碼），並為自己提供一些自己不喜歡的細節。

人們是否僅根據您使用的詞語做出冒犯的反應並認為您（非）專業取決於公司文化。但是，一般來說，人們會根據您的使用方式來判斷您。如果您只是在不爭論自己的觀點的情況下就將東西稱為垃圾，而沒有接受其他開發人員就代碼的原樣進行討論的理由，那麼人們會認為您是不合理和有判斷力的。因此不專業。尤其是如果您明確或隱式地指責您的同事認為您的錯誤代碼。這是正確的，無論您是否使用專有名詞，即說“這段代碼很糟糕”，而沒有任何進一步的評論，也是不專業的，但是，如果您使用的詞在情感上投入的越多（呈現給他們的情感就越多），那麼情況就越糟。 -工人，但是作為一種增加印像或減輕挫敗感的方法，完全可以。我在這樣的環境中工作，即語氣非常直接，好玩且句子經常充滿粗話。但是，通常，任何這樣的術語都是針對某些技術問題，某些框架的行為無法預測甚至是自己的代碼（“看看我在那裡做的垃圾，我寫的東西真是令人難以置信！”）。另一方面，我很少看到團隊如此專業地工作-互相尊重，總是尋找解決問題的方法，而不是如何分配責任。

TLDR ：使用專有名詞來描述代碼本身不一定非專業。但是，在某些文化背景下，任何使用專有名詞都被認為是不專業/令人反感的。在使用它們之前，您必須先弄清楚在您的環境中是否存在這種情況，而不是首先這樣做是不專業的。如果（他人）的代碼絕對有價值，是否使用了粗話，而沒有（a）提供細節，並且（b）在不將批評與他人分開的情況下以及c）在不知道他人可以將對其代碼的批評與對自己的批評分開的情況下，這也不是專業的。在您目前的公司中，人們顯然不習慣任何罵人/罵人的行為，並認為這是不良行為-因此請不要這樣做。

您向錯誤的方向發送了該評論

當初讀您的帖子時，我認為這是對您的管理層的評論，而我最初的反應是“嗯，如果他們不喜歡事實，他們應該停止強迫您的團隊使用這種愚蠢的指標。”

這是否是實際情況（評論在鏈中沿上移 ）-可以了。可能有些 unprofessional ，但實際上，這是警告管理層他們正在使您的團隊陷入困境的最直接的方法。

但是，似乎這不是在哪裡評論發表了。與其代表團隊反對管理—刪除團隊同意的愚蠢指標導致寫入垃圾，您做相反的做法，而是將團隊置於“該死的，該死的，該死的”。

代碼質量的指標，我懷疑是由您的團隊創建的。他們可能已經感覺到它們是白痴，被迫跳過。

告訴他們他們正在編寫的代碼是“垃圾”；因為他們無法控制他們的系統-只是表示您沒有他們的支持，也不想打架。

不專業，問題出在哪裡源自，不是不是只是評論的措辭。您會以這種方式來欺騙您的團隊，這是一種感覺。他們的回應實際上是“為此怪罪我們，我們將非常清楚地表明這種情況是您的錯。”

您使用的語言可能給了他們更多與您抗爭的理由繼續-但這絕對不是您受到壓力的主要原因。

除了令人反感的語言外，您的評論還包含有關代碼實際錯誤之處的零內容，並包含與您的團隊目標相反的潛台詞。

因此，總體目標是提高代碼質量。為什麼不說“我們要提高代碼質量”呢？為什麼要將此代碼段作為 not 不能提高代碼質量的參數。

對於我（作為一個經驗不足的開發人員，對您而言），這聽起來像是一個習慣於舊方式並且不歡迎更改（即使其被稱為“代碼質量”）的人的評論。 / p>

我們必須像下面那樣引入垃圾

您可能已經收集到，稱其他人寫“垃圾”的東西不是獲得批准的好方法，您絕對不會提供任何有關為何“以下垃圾”可能出問題的信息，除了它會以錯誤的方式摩擦您。

具有15年經驗的 Leading 開發人員應該能夠提供比稱為“垃圾”的更多信息。

那麼我們就遇到了大麻煩。

為什麼？為什麼？為什麼？用您的經驗來查明問題，而不是簡單地指出問題所在。而且，如果您真的很擅長工作，請指向更好的解決方案，以便您的團隊知道前進的方向。

抱歉，但是您的評論（摘錄）確實是垃圾。根據其定義，可以將其扔到垃圾箱中。

關於更新1 ：如果您的完整評論很詳細並提供了所有上述信息。為什麼要在開發者之上侮辱開發者（並質疑您的團隊目標）？

如果提高代碼質量得分意味著我們必須像下面那樣引入垃圾，那麼我們就陷入了嚴重的麻煩。

在某些情況下，代碼可以稱為“垃圾”。例如內存分配或無法訪問的代碼。但是，我認為您不是用這種方式來表示它。

但是，我認為您在指代某些編程樣式時應使用適當的術語。我主要看到的是競爭條件，循環條件檢查會在不改變循環的情況下重新計算每個循環的數組，等等。我將專門評論錯誤之處，或者是否可以使用替代函數將其記下來。

大多數其他答案是在您對自動工具建議的代碼進行編輯之前，因此，讓我具體解決該部分。

您認為此代碼對於更嚴厲的批評是公平的，因為它來自工具而非人，但您沒有考慮：

• 一個或多個人決定讓此工具在評估代碼質量中起重要作用。
• 一個人決定複製/粘貼該工具的建議，而不是以一種更具可讀性的方式解決質量問題，要么是因為他們沒有想到可以做得更好，要么是他們不知道如何做來做得更好。

換句話說，循環中仍然存在人為的決定，而這些決定正陷入困境。我會更像您這樣表示反對：

在這種特殊情況下，我認為質量工具的建議不是很有幫助，這讓我感到沮喪，因為該工具經常會像這樣令人誤解。這不是很明顯，但是可以通過以下方式以更易理解的方式解決潛在問題：...

這可以清楚地表明您對質量工具而不是代碼作者的不滿，並提出了批評。通過提供解決問題的方法來建設性。