[譯]好程序員的五聲「吶喊」

一般編程狀況下，會致使軟件項目變壞的一些列反應

原文：The five shouts of good programmers

 

      在任何一天，在這個世界上都有軟件項目正在失敗，這很常見。常見到當軟件產品按照預期發佈時人們都會感到吃驚。這不是什麼新鮮事，基於被普遍引用的Standish Group的Chaso報告，這種事情已經已經發生了幾十年了。可是如今，在不少狀況下，人們試圖盡最大努力去避免這種悲劇，可是常常公司的政治老是會比實用主義更具優先級。只要不要太晚，這都是能夠經過簡單的延遲來避免。

      在這種狀況下，程序員做爲戰場的一線戰鬥人員，會比其餘人都更早的看到這些問題。可是，程序員都會缺少以一種簡單的方式解決此類問題的技能，這也就意味着不少狀況下他們都只是在一個已經註定命運的項目上埋頭苦幹。

      經過一次又一次的觀察到這種狀況，我意識到程序員們須要一個高效的回退機制，這也就是爲何我寫這個文章的緣由。這些「吶喊」都只是隱喻層面的。也僅僅是當如下談及的問題場景出現的時候，你能夠告訴本身的一些話，使得你有力量將一些很差的狀況往好的方面發展。

 

1.不要作重複的工做（Don’t repeat yourself!）

      假想一下你處於這樣一種狀況，你須要去寫一些特定功能的代碼，可是同時相似的代碼已經存在。很顯然，最好的方案是修改已經存在的代碼，讓這些代碼對新的場景可以兼容。同時，這須要你將老的和新的測試場景都進行測試，以確保沒有引入任何迴歸Bug。項目管理人員爲了時間考慮，會建議你簡單的將代碼拷貝一份，而後進行修改，此時只須要測試新的應用場景。在這種狀況下，你須要使用此條規則。「Don’t Repeat Yourself!」。

      其中一個主要緣由是，重複的代碼是Bug的主要來源地之一。當有兩個函數或模塊，都實現幾乎相同的任務，在某一時刻業務發生了改變，此時頗有可能程序員只會記得更新其中的一個，而忘記了另外一個，這就產生了Bug。同時這也下降了代碼的可理解度。若是當新人碰到這兩個幾乎相同功能的代碼時，會好奇究竟選擇使用哪一個，甚至更糟的是，會兩個都用上。寫相同功能的代碼多是中捷徑，可是最終仍是會爲此付出代價的。

 

2.不要作無心義的工做（No monkey business！）

      第二個場景涉及到重複性的工做。程序員常常可能想要將重複工做自動化，可是管理者常常不會爲此投入相應的資源，相反還會以「只須要幾分鐘」爲藉口進行爭論。這些人常常不會意識到，重複性的工做很容易出錯，而且花費的時間會增加。5分鐘的工做可能會變成10分鐘，10分鐘的變成15分鐘，等等等等。很快，就會看到程序員瘋狂敲擊鍵盤，看上去很忙的樣子，但實際上並無完成什麼有意思的工做，很像一隻敲鍵盤的猴子。

      此時，程序員就可能須要使用「No monkey business！」了。程序員的職責就是編程，若是讓他們作一些欠考慮的，無心思的重複工做就是浪費他們的能力，最終會致使負面情緒的增加。除此以外，將一項任務自動化會讓程序員以一種批判的眼光去看着這件事，可能會在這個過程中發現一個漏洞，而這個漏洞但是是以前被忽略的。

 

3.安全優先（Safety first！）

          在公司層面，不少活動中更傾向於規避風險。好比在廣告中，可能由於一句錯誤的臺詞致使公關危機；在財務中，一個錯誤的財務計劃可能會致使公司破產；在市場調查中，一件新產品須要被公衆所接受。然而，在談及技術上的規避風險是，公司一般會有很大的慾望去冒風險。一般表如今經過減小或免去測試來節約成本。儘管相似測試驅動開發這樣的工程實踐會帶來一些好處，可是我依舊聽到不少關於說服程序員不要寫自動測試用例來減小時間的爭論。一些人會說，真正的程序員是瞭解他們在作什麼，因此他們不須要測試；另一些人會說，測試的結果最終不告知用戶，所以它不是產品的一部分，這就意味着測試時能夠在程序員的私人時間內完成。

      事實是，忽視安全在實際中太廣泛了。人們不會意識到他們是在一個不安全的環境中（譯：我的以爲是開發流程中的不安全性）工做。可是，你能夠經過在一個項目的過後分析的典型結論中來證實這個事實。他們一般會將失敗歸結於糟糕的需求或者糟糕的預估，可是永遠不會歸結到不安全的環境上。他們永遠不會說「咱們失敗是由於咱們的開發環境出的問題，它沒有預防一些錯誤的發生」。這就是爲何咱們須要使用「Safety first！」

 

4.YAGNI!（You Ain't Gonna Need It!）

      相對於其餘的系統的工程來講，軟件開發時一個比較年輕的系統工程。天然，也從其餘的工程學裏借鑑了一些東西到軟件工程學中。其中一個就是試圖去預測將來的需求。

      假設你如今是一位市政工程師，你被要求去建設一座雙車道的大橋。在任什麼時候候，都值得去思考，這座橋須要四車道，由於這樣才能把基礎建的更牢靠，而且在將來想拓展成四車道也變得方便。按照這個邏輯，項目就有一個額外的，沒有人要求的需求了。它是基於設計者的假設而加入的，同時設計者認爲早作比晚作成本更低。

      第一個問題是，沒有任何跡象代表在需求出現前而去臆想需求會使得成本更低，尤爲是咱們使用現代的、迭代的實踐方法。第二個問題是，每當非被要求的功能性的需求被提起時，管理者一般決定不會解決。這就致使了一個這樣的企業文化：代碼的質量良莠不齊，有些會變「腐爛」直到徹底沒用。更糟的是，它會下降程序員的士氣，由於他們所工做的內容是以後從不會被用到的，所以會變得沮喪。

      若是是在這種狀況下，當沒必要要的需求浮現時，程序員此時須要說「YAGNI！」。

5.從如今開始！（Yes now!）

      這是爲最喜歡的一條。編程是一種持續冒險的活動。你可能須要去查看一些幾年前由你不認識的人寫的代碼。這些代碼可能運行在一些特定的場景下，你永遠不會知道你在此過程當中會遭遇什麼，多是一段很優雅的代碼，也有多是徹底沒法工做的代碼。這纔是編程的樂趣！

      假設你如今是名廚師，你到了一個一團糟的廚房裏。可能你有種立馬把裏面清理乾淨的衝動，而後才進行工做。做爲一名程序員，當你遇到一團糟的代碼時，你也會有那樣的衝動。可能代碼的清理工做並非項目的一部分，你這種好的想法也有可能被禮貌地推到一邊。「那是個好主意，可是咱們如今不用去作它。」。此時，你須要說「Yes Now！」。

      一個成功項目的最重要的文化氛圍就是，一旦出現了問題，立馬修復。若是沒有這種文化氛圍，那麼就會出現「破窗」理論。而後程序員就習慣工做在那樣設計很垃圾的代碼之上。這樣團隊士氣就會受到傷害。由於是我將代碼搞得很垃圾和代碼原本就很垃圾就變得很重要。「Yes Now！」幫助團隊集中焦點在對的事情上，而不去關注是誰讓事情變得糟糕。

 

      最後一條警告…

      這五聲「吶喊」是頗有用的工具，可是和任何工具同樣，濫用會拔苗助長。這些建議一般是用在當出現了一些壞的決策時，有些時候可能會致使一些衝突。衝突有時是個很好的提示，提示咱們須要在多個選項中選擇一個最好的方案。同時也意味着要當心使用這五聲「吶喊」。

      維持常態是拒絕改變的一種心理傾向。當開始使用這五條告誡時，決策的思路也開始改變，不少人最初都會去拒絕。出於這個緣由，最好的方案是溫和地使用這個五條告誡，同時在最關鍵的狀況下使用它們。當改變發生後，其餘人就會慢慢地注意到它帶來的好處，而後就能夠在更多的場景進行應用。

      改變很難。尤爲是要改變咱們使用了幾十年的習慣時。明智地使用者五條告誡，你會發現你的代碼和項目在逐漸地往好的方向改變。