如何惹毛一名開發者？

論讓開發者不開心的二三事。

作者 | nicklas millard

譯者 | 香檳超新星責編 | 屠敏

出品 | csdn（id：csdnnews）

老實說，想要惹毛一名開發者很容易。有時候，一件不起眼的小事情也可能會觸發程式設計師敏感的神經。個性越鮮明的開發者，越容易炸毛。在我看來，開發者、程式設計師和工程師人群的整體氛圍堪稱「有毒」。

直至今日，還有很多人在大張旗鼓地討論，什麼樣的人算是初級開發人員，什麼樣的程式設計師又能被稱為大神。同時，當一些工程師被稱為「碼農」時，也會非常生氣。

除了以上，開發者群體中還有很多雷區，接下來，我將盤點其中的一部分，順序不分先後。不過，因為經驗、技能和理念的不同，開發者們炸毛的程度也會有所不同。

if-else 與多型

還記得，我曾經發布過一篇《停止使用 if-else》（文章，那個時候的我，還不知道自己捅了多大的乙個「馬蜂窩」。

讓非技術人員來評估程式設計任務

剛接觸程式設計時，我的第乙個專案竟然是由乙個政治學碩士出身的同事進行評估的。當時我們必須在專案期間從零開始完成整套的解決方案，包括部署三個雲環境、建立資料庫模型、編寫業務邏輯，編寫後端和前端。

他當時在評估之後，給出的預估計時間是 34–36 小時，以及需要一名開發人員的支援。萬萬沒有想到的是，他在評估結束之後，直接把這些時間表就發給了客戶，甚至都沒有問過作為開發者的我們切合實際的開發者週期究竟是多長時間。

正如不懂技術的產品經理提出了乙個天馬行空的想法讓技術來實現，像這樣的破事兒毫無疑問會惹毛開發人員。

「按照我的經驗，xx種技術行之有效」

閱讀其他人的**

有時候我們真是討厭死其他開發者的**了。尤其是當我們不確定它的實際功能時，我們就喜歡瘋狂吐槽這段**有多麼愚蠢（以掩蓋我們看不懂這段**的事實）。

在沒有注釋的情況下，當接手別人的**時，任何乙個細節都可能激發開發者的厭惡情緒。包括一些大括號之類的小事，不論是放在同一行，單獨成行，或k＆r風格，都無法讓所有人都滿意。如果去 google 一下關於大括號的爭論，它的問題會讓你越看越傻眼。

此外，tabs 鍵和空格也會讓開發者很無語。

**審查和 pull request

在開發者群體中，code review 和 pull request 是備受爭議的兩個關鍵點。

code review 就像是公開邀請「羞辱」他人的程式設計能力。或者，至少有些人就是這樣看待 pull request 的。當你花了很多時間準備好將功能合併到主版本中時，你的**卻被沒有參與專案的其他人破壞了，還有比這更讓人惱火的事嗎？

**注釋，真的有幫助？

對於**注釋，不同的開發者有不同的看法。有人認為，**注釋在**審查期間會吸引開發者很多注意力，在他們看來，「如果還需要注釋，只能說明你的**不夠清晰。」

不過，多年的事實證明，認真的給**寫注釋對後來閱讀**的人會有很大的幫助。甚至未來有一天，你自己也會慶幸當初寫了注釋。

作者簡介：nicklas millard，fintech行業c#後端開發工程師，曾在四巨頭大廠擔任高階技術顧問。

☞在記憶體只有24kb的電腦上寫作業系統，是怎樣的體驗？