你是程式設計中的“快槍手”還是“慢悠悠”？

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

兩者之間的區別是，前者完成的效率更高，但程式碼的錯誤率更大（除非他們特別幸運），而後者程式碼的錯誤率就少多了，並且易於擴充套件和維護。親你是哪一種呢？

愚蠢的“快槍手”？

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

拿我自己舉個例子。

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

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

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

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

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

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

因為這是一個主觀判斷。

不可協同工作

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

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

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

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

預見機制

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

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

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

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