英文原文：Code fast or code slow? Who are you?

　　一般而言，有兩種類型的開發者。一種編碼速度快，喜歡一大段一大段的組合代碼，然后看它是否能順利運行，這是編程中的“快槍手”，還有一種在朝著目標前進的時候比較淡定，他們會確保他們所寫的一切代碼都是精心設計的，可維護和可擴展的。因為這個原因，使得他們在速度上顯得比別人慢，所以是“慢悠悠”。

　　兩者之間的區別是，前者完成的效率更高，但代碼的錯誤率更大（除非他們特別幸運），而后者代碼的錯誤率就少多了，并且易于擴展和維護。親你是哪一種呢？

　　愚蠢的“快槍手”？

　　大多數開發人員可能不敢承認自己是那種以良好的體系結構為代價的“快槍手”。為什么呢？因為這樣可能會產生更高的錯誤率。但是回過頭來想想，哪個系統沒有代碼錯誤？

　　拿我自己舉個例子。

　　我如果接了個單子要寫程序什么的，會有來自客戶方面的壓力，因為我必須及時交付。而客戶對于軟件的要求大多是通過電子郵件，電話告知的，或者在某些情況下，客戶會直接寫在票務系統里發過來。我的責任就是，確保程序的功能可以準確反映這些要求。而大家都知道，有時候客戶想要什么卻并不說出來，而這一點也是我必須考慮進去的。

　　在開發團隊中，有寫的快的成員也有寫的慢的，有代碼錯誤率高的也是錯誤率低的。而我我大部分時間在做的是，怎樣將這些人員有效分類。

　　繼續講那個例子。那么我該如何確保客戶的要求能實現呢？答案是，我得看到實現要求功能的代碼在哪里。所以，我就有兩個選擇了。第一個選擇是把單子交給能快速交付的“快槍手”，這樣我便可以及時看到運行結果（無論代碼是否有bug也不管后期是否易于維護）。另一個是讓“慢悠悠”來做，有可能直到最后一分鐘他都交付不了，但是拿出來的解決方案必是精品。

　　第一種情況下，我能很快拿到成果，而且如果客戶不滿意，還有時間去修改，但是我可能不得不面對不支持擴展和不可維護等等方面的缺陷。而在第二種情況下，因為沒有多余的時間，所以將不能按客戶要求進行修改，但是代碼簡潔優雅，如果未來有需要的話還可以進一步擴展。

　　在這里要著重講一下，可擴展和不可擴展以及可維護和不可維護的區別。例如，我們已經按客戶要求搞定了所需的軟件，但是它的代碼是不可擴展的，那么如果用戶喜歡并且想進一步擴展的話，那你就只能叫苦連天了。但是如果是可擴展可維護的，那么用戶想在某個方面擴展的話，那就是小菜一碟了。

　　所以，如果用戶沒有要擴展某個方面的想法，那么我會選擇“快槍手”。反之就需要“慢悠悠”了。但是如果你想保證100%選擇正確，那就只能讓事后諸葛亮出馬了。

　　因為這是一個主觀判斷。

　　不可協同工作

　　上面我講的例子如果能團隊中實行，肯定可以提高整個團隊的工作效率。在分配過程中，我認識到，“快槍手”有快速編碼快速交付的特點，而“慢悠悠”有完成的代碼簡潔明朗易于維護的特征。

　　隨著社會的發展，CI / CD已經變得適用于多種環境。并且現在推陳出新也是越來越便宜。即使代碼不可擴展，人們也負擔得起更新迭代，甚至哪怕就是再次重新架構也可以承受。這樣一來，我們就需要“快槍手”按照要求盡可能的快速開發，而在需要架構或者重構的時候，再青睞“慢悠悠”來大顯身手了。

　　但是如果“快槍手”的代碼寫得太快以至于“慢悠悠”完全跟不上，那時候就悲劇了，因為你得到的只會是一個千瘡百孔，滿是bug的系統。

　　誰都不希望得到這樣的結果。

　　預見機制

　　為了解決上述問題，我們可以使用預見機制，用于衡量開發人員的bug在代碼運行時會導致什么問題。這樣既可有效控制“快槍手”的錯誤率，也能確保“慢悠悠”的代碼火車不再晚點。

　　有沒有覺得，“快槍手”好像文獻資料或者是驗證器？而“慢悠悠”則更加適合放在設計和架構功能方面，以便于這些方面今后有需要的話，容易維護和擴展。

　　也許我們可以叫“快槍手”為功能團隊，而“慢悠悠”則更趨向于是一種工程團隊。

　　最后，問問你自己，“快槍手”和“慢悠悠”，親你是哪一種呢？

it知識庫：你是編程中的“快槍手”還是“慢悠悠”？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。