作為一名開發(fā)者，它把我惹毛了?。?/h1>
論讓開發(fā)者不開心的二三事。
作者 | Nicklas Millard 譯者 | 香檳超新星 責(zé)編 | 屠敏
出品 | CSDN（ID：CSDNnews） 老實(shí)說(shuō)，想要惹毛一名開發(fā)者很容易。有時(shí)候，一件不起眼的小事情也可能會(huì)觸發(fā)程序員敏感的神經(jīng)。個(gè)性越鮮明的開發(fā)者，越容易炸毛。在我看來(lái)，開發(fā)者、程序員和工程師人群的整體氛圍堪稱“有毒”。
直至今日，還有很多人在大張旗鼓地討論，什么樣的人算是初級(jí)開發(fā)人員，什么樣的程序員又能被稱為大神。同時(shí)，當(dāng)一些工程師被稱為“碼農(nóng)”時(shí)，也會(huì)非常生氣。
除了以上，開發(fā)者群體中還有很多雷區(qū)，接下來(lái)，我將盤點(diǎn)其中的一部分，順序不分先后。不過，因?yàn)榻?jīng)驗(yàn)、技能和理念的不同，開發(fā)者們炸毛的程度也會(huì)有所不同。
If-else 與多態(tài)
還記得，我曾經(jīng)發(fā)布過一篇《停止使用 If-else》（https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4）文章，那個(gè)時(shí)候的我，還不知道自己捅了多大的一個(gè)“馬蜂窩”。
不到幾天的時(shí)間，這篇文章瀏覽量就 10 萬(wàn)+（這在國(guó)外內(nèi)容 Medium 平臺(tái)上算是爆款文章了），同時(shí)在 Reddit 上還有一個(gè)關(guān)于這篇文章的討論區(qū)，里面充斥著很多反駁的評(píng)論。顯然，按照傳統(tǒng)分支編寫那種不良代碼的做法至今仍有大批開發(fā)者，使用 if-else 就是如此。
讓非技術(shù)人員來(lái)評(píng)估編程任務(wù)
剛接觸編程時(shí)，我的第一個(gè)項(xiàng)目竟然是由一個(gè)政治學(xué)碩士出身的同事進(jìn)行評(píng)估的。當(dāng)時(shí)我們必須在項(xiàng)目期間從零開始完成整套的解決方案，包括部署三個(gè)云環(huán)境、創(chuàng)建數(shù)據(jù)庫(kù)模型、編寫業(yè)務(wù)邏輯，編寫后端和前端。
他當(dāng)時(shí)在評(píng)估之后，給出的預(yù)估計(jì)時(shí)間是 34–36 小時(shí)，以及需要一名開發(fā)人員的支持。萬(wàn)萬(wàn)沒有想到的是，他在評(píng)估結(jié)束之后，直接把這些時(shí)間表就發(fā)給了客戶，甚至都沒有問過作為開發(fā)者的我們切合實(shí)際的開發(fā)者周期究竟是多長(zhǎng)時(shí)間。
正如不懂技術(shù)的產(chǎn)品經(jīng)理提出了一個(gè)天馬行空的想法讓技術(shù)來(lái)實(shí)現(xiàn)，像這樣的破事兒毫無(wú)疑問會(huì)惹毛開發(fā)人員。
“按照我的經(jīng)驗(yàn)，XX種技術(shù)行之有效”
很多文章常常試圖挑戰(zhàn)別人做事的方式。就我自己而言，我經(jīng)常會(huì)收到這種評(píng)論，“我已有 20 年的工作經(jīng)驗(yàn)了，并且我總是以相同的方式來(lái)完成 X 任務(wù)，而且這樣行之有效”之類的。
通過這種言論，我們能知道過去 20 年來(lái)，他/她的代碼風(fēng)格一直沒有改變，而且閱讀那篇文章的目的就是因?yàn)橄ＭC明他們古老腐朽知識(shí)仍然適用——但令他們失望的是，他們的知識(shí)已經(jīng)并不適用了。
閱讀其他人的代碼
有時(shí)候我們真是討厭死其他開發(fā)者的代碼了。尤其是當(dāng)我們不確定它的實(shí)際功能時(shí)，我們就喜歡瘋狂吐槽這段代碼有多么愚蠢（以掩蓋我們看不懂這段代碼的事實(shí)）。
在沒有注釋的情況下，當(dāng)接手別人的代碼時(shí)，任何一個(gè)細(xì)節(jié)都可能激發(fā)開發(fā)者的厭惡情緒。包括一些大括號(hào)之類的小事，不論是放在同一行，單獨(dú)成行，或K＆R風(fēng)格，都無(wú)法讓所有人都滿意。如果去 Google 一下關(guān)于大括號(hào)的爭(zhēng)論，它的問題會(huì)讓你越看越傻眼。
此外，Tabs 鍵和空格也會(huì)讓開發(fā)者很無(wú)語(yǔ)。
代碼審查和 pull request
在開發(fā)者群體中，code review 和 pull request 是備受爭(zhēng)議的兩個(gè)關(guān)鍵點(diǎn)。
code review 就像是公開邀請(qǐng)“羞辱”他人的編程能力。或者，至少有些人就是這樣看待 pull request 的。當(dāng)你花了很多時(shí)間準(zhǔn)備好將功能合并到主版本中時(shí)，你的代碼卻被沒有參與項(xiàng)目的其他人破壞了，還有比這更讓人惱火的事嗎？
從本質(zhì)上講，code review 和 pull request 是一個(gè)開放的舞臺(tái)，允許別人對(duì)你所編寫的代碼自由評(píng)論。
代碼注釋，真的有幫助？
對(duì)于代碼注釋，不同的開發(fā)者有不同的看法。有人認(rèn)為，代碼注釋在代碼審查期間會(huì)吸引開發(fā)者很多注意力，在他們看來(lái)，“如果還需要注釋，只能說(shuō)明你的代碼不夠清晰?！?/span>
不過，多年的事實(shí)證明，認(rèn)真的給代碼寫注釋對(duì)后來(lái)閱讀代碼的人會(huì)有很大的幫助。甚至未來(lái)有一天，你自己也會(huì)慶幸當(dāng)初寫了注釋。
原文地址：https://levelup.gitconnected.com/how-to-piss-off-a-developer-eea2069633fc
作者簡(jiǎn)介：Nicklas Millard，F(xiàn)inTech行業(yè)C#后端開發(fā)工程師，曾在四巨頭大廠擔(dān)任高級(jí)技術(shù)顧問。
高級(jí)程序員必知的 7 種軟件架構(gòu)模式！
（干貨）吐血總結(jié)：技術(shù)大佬都是怎么學(xué)習(xí)的？
面試官：如何發(fā)現(xiàn) Redis 熱點(diǎn) Key ，解決方案有哪些？
論讓開發(fā)者不開心的二三事。
老實(shí)說(shuō)，想要惹毛一名開發(fā)者很容易。有時(shí)候，一件不起眼的小事情也可能會(huì)觸發(fā)程序員敏感的神經(jīng)。個(gè)性越鮮明的開發(fā)者，越容易炸毛。在我看來(lái)，開發(fā)者、程序員和工程師人群的整體氛圍堪稱“有毒”。
直至今日，還有很多人在大張旗鼓地討論，什么樣的人算是初級(jí)開發(fā)人員，什么樣的程序員又能被稱為大神。同時(shí)，當(dāng)一些工程師被稱為“碼農(nóng)”時(shí)，也會(huì)非常生氣。
除了以上，開發(fā)者群體中還有很多雷區(qū)，接下來(lái)，我將盤點(diǎn)其中的一部分，順序不分先后。不過，因?yàn)榻?jīng)驗(yàn)、技能和理念的不同，開發(fā)者們炸毛的程度也會(huì)有所不同。
If-else 與多態(tài)
還記得，我曾經(jīng)發(fā)布過一篇《停止使用 If-else》（https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4）文章，那個(gè)時(shí)候的我，還不知道自己捅了多大的一個(gè)“馬蜂窩”。
不到幾天的時(shí)間，這篇文章瀏覽量就 10 萬(wàn)+（這在國(guó)外內(nèi)容 Medium 平臺(tái)上算是爆款文章了），同時(shí)在 Reddit 上還有一個(gè)關(guān)于這篇文章的討論區(qū)，里面充斥著很多反駁的評(píng)論。顯然，按照傳統(tǒng)分支編寫那種不良代碼的做法至今仍有大批開發(fā)者，使用 if-else 就是如此。
讓非技術(shù)人員來(lái)評(píng)估編程任務(wù)
剛接觸編程時(shí)，我的第一個(gè)項(xiàng)目竟然是由一個(gè)政治學(xué)碩士出身的同事進(jìn)行評(píng)估的。當(dāng)時(shí)我們必須在項(xiàng)目期間從零開始完成整套的解決方案，包括部署三個(gè)云環(huán)境、創(chuàng)建數(shù)據(jù)庫(kù)模型、編寫業(yè)務(wù)邏輯，編寫后端和前端。
他當(dāng)時(shí)在評(píng)估之后，給出的預(yù)估計(jì)時(shí)間是 34–36 小時(shí)，以及需要一名開發(fā)人員的支持。萬(wàn)萬(wàn)沒有想到的是，他在評(píng)估結(jié)束之后，直接把這些時(shí)間表就發(fā)給了客戶，甚至都沒有問過作為開發(fā)者的我們切合實(shí)際的開發(fā)者周期究竟是多長(zhǎng)時(shí)間。
正如不懂技術(shù)的產(chǎn)品經(jīng)理提出了一個(gè)天馬行空的想法讓技術(shù)來(lái)實(shí)現(xiàn)，像這樣的破事兒毫無(wú)疑問會(huì)惹毛開發(fā)人員。
“按照我的經(jīng)驗(yàn)，XX種技術(shù)行之有效”
很多文章常常試圖挑戰(zhàn)別人做事的方式。就我自己而言，我經(jīng)常會(huì)收到這種評(píng)論，“我已有 20 年的工作經(jīng)驗(yàn)了，并且我總是以相同的方式來(lái)完成 X 任務(wù)，而且這樣行之有效”之類的。
通過這種言論，我們能知道過去 20 年來(lái)，他/她的代碼風(fēng)格一直沒有改變，而且閱讀那篇文章的目的就是因?yàn)橄ＭC明他們古老腐朽知識(shí)仍然適用——但令他們失望的是，他們的知識(shí)已經(jīng)并不適用了。
閱讀其他人的代碼
有時(shí)候我們真是討厭死其他開發(fā)者的代碼了。尤其是當(dāng)我們不確定它的實(shí)際功能時(shí)，我們就喜歡瘋狂吐槽這段代碼有多么愚蠢（以掩蓋我們看不懂這段代碼的事實(shí)）。
在沒有注釋的情況下，當(dāng)接手別人的代碼時(shí)，任何一個(gè)細(xì)節(jié)都可能激發(fā)開發(fā)者的厭惡情緒。包括一些大括號(hào)之類的小事，不論是放在同一行，單獨(dú)成行，或K＆R風(fēng)格，都無(wú)法讓所有人都滿意。如果去 Google 一下關(guān)于大括號(hào)的爭(zhēng)論，它的問題會(huì)讓你越看越傻眼。
此外，Tabs 鍵和空格也會(huì)讓開發(fā)者很無(wú)語(yǔ)。
代碼審查和 pull request
在開發(fā)者群體中，code review 和 pull request 是備受爭(zhēng)議的兩個(gè)關(guān)鍵點(diǎn)。
code review 就像是公開邀請(qǐng)“羞辱”他人的編程能力。或者，至少有些人就是這樣看待 pull request 的。當(dāng)你花了很多時(shí)間準(zhǔn)備好將功能合并到主版本中時(shí)，你的代碼卻被沒有參與項(xiàng)目的其他人破壞了，還有比這更讓人惱火的事嗎？
從本質(zhì)上講，code review 和 pull request 是一個(gè)開放的舞臺(tái)，允許別人對(duì)你所編寫的代碼自由評(píng)論。
代碼注釋，真的有幫助？
對(duì)于代碼注釋，不同的開發(fā)者有不同的看法。有人認(rèn)為，代碼注釋在代碼審查期間會(huì)吸引開發(fā)者很多注意力，在他們看來(lái)，“如果還需要注釋，只能說(shuō)明你的代碼不夠清晰?！?/span>
不過，多年的事實(shí)證明，認(rèn)真的給代碼寫注釋對(duì)后來(lái)閱讀代碼的人會(huì)有很大的幫助。甚至未來(lái)有一天，你自己也會(huì)慶幸當(dāng)初寫了注釋。
原文地址：https://levelup.gitconnected.com/how-to-piss-off-a-developer-eea2069633fc
作者簡(jiǎn)介：Nicklas Millard，F(xiàn)inTech行業(yè)C#后端開發(fā)工程師，曾在四巨頭大廠擔(dān)任高級(jí)技術(shù)顧問。
高級(jí)程序員必知的 7 種軟件架構(gòu)模式！
（干貨）吐血總結(jié)：技術(shù)大佬都是怎么學(xué)習(xí)的？
面試官：如何發(fā)現(xiàn) Redis 熱點(diǎn) Key ，解決方案有哪些？