你曾經遇到過難以開始一件事情嗎？我不是在談論在冬季啓動一輛汽車，而是一些工作，可能是一個新項目或一篇博客。啓動新項目不容易。你還記得你曾經思考過，說過或聽過下面的一些事情嗎？
“我還在計劃這件事。”
“我需要做更多的調查。”
“我的想法還不夠完美。”
“我還不確定哪種方式最好。”
癥結
這些片斷有個共同點。最好的情況顯示爲猶豫不決，最壞的情況可能是分析癱瘓。這個情況（對某些點的思考和分析無法前進）並不少見。
作爲一名軟件開發人員，有兩種情況在這種狀態裏會經常出現:選擇做什麼和怎麼做。在同時扮演產品經理和開發人員的個人項目裏，我們必須兩種情況都處理。合同方往往不必處理“做什麼”，因爲產品經理或業務經理會做這個決定。怎麼做，通常要開發人員花大量時間在上面。
開始寫程序不久，我們意識到通常有更多方式來解決“怎麼做”這個問題。這意味着一名程序員要花一些時間來考慮不同的實現方式。這個思考過程肯定有價值-通常一些想法很快就會被排除而被其他簡單的想法代替。當一些明顯的選擇被排除後困難的部分就來了。從這個職位出發，我們想要一種方式來決定最好的選擇。
選擇的矛盾
Barry在他2005年的Ted演講中說到選擇的矛盾。他確認當自由選擇是一個好機會時，社會上的大量選擇“留給我們的不是更自由而是更無力，不是更快樂而是更不滿。”爲什麼選擇更多反而不是好事？
無力分析讓人壓力很大-自帶焦慮和自我懷疑。這些感情，儘管沒有有形輸出，但卻使用了有價值的認知資源。開車時使用手機被認爲很危險，因爲這會分散我們對路上危險的注意力。與此類似，當我們因爲擔心而精力分散時，對於我們手頭的問題，我們深入考慮或創造性思維的能力會降低。
第二個關鍵因素是選擇疲勞。我們做的決定越多，決定就變得越困難。衆所周知，成功人士包括Steve Jobs, Carrie Donovan和Mark Zuckerberg每天穿同樣的衣服。當這一點被質疑時，Zuckerberg迴應到：
“我真的想梳理我的生活來實現對任何事情做儘可能少的決定，除了如何最好地服務這個社區之外。”
反複分析後給出所有這些負面結果，我們怎麼做能避免選擇的矛盾呢？
快速決定
將一個實現決策過程分解成一些明智的選擇，我們怎麼做能防止做出無效的分析？一個點子是拋硬幣決定：
“當面臨兩種選擇時，只是拋硬幣來決定。這種辦法有用不是因爲它爲你解決了問題，而是因爲當硬幣在空中的短暫時刻，你突然明白了你想要的是什麼。”
—Kevin Purdy
然而這個引用傾向於做不太重要的決定，我認爲這個概念有效。有時候當我們花太長時間分析我們的決定時，我們的直覺會變得模糊。當決定不明顯時，拋硬幣能使一些模糊的東西變得明確。在某些情況下潛在的本能選擇沒有直接出現，拋硬幣吧，因爲這是一個結果同樣可行的好機會。另一個好處是減少了我們的思考時間。這樣做我們可以最大化我們獲取更多信息的時間。
“但是如果我做了錯誤的事情或者錯誤的決定怎麼辦？”
在軟件開發中，不像許多其他情況，在初始階段作出錯誤決定的成本是非常低的。當前版本控制系統的能力意味着對實際的影響是微不足道的。當我們做了錯誤的決定我們只是失去了時間。我們可以通過減少我們花費在分析一個決定上的時間來減少我們失去的時間。然而，那不意味着我提倡每次遇到選擇困難時就用不夠好的代碼直接衝進生產環境。做決定是第一步，不是最後一步。
然後完善
我們也可以利用這次機會來提高我們的代碼質量。看到實施可能帶來的重構、改善命名規範或者讓代碼更精煉的機會。
這個觀點和許多現有軟件實踐相似。在乾淨的代碼裏，Robert Martin描述了一個他叫做持續改善的過程，其中有人在對代碼質量改善之前先寫了粗略的代碼。通過他的測試驅動開發的三個規則，他加強了代碼，這有助於確保你不用去做一個大的決定，但是採取一些小的改進措施來引入測試過的產品代碼。
類似地，遵循Kent Beck的四大簡單設計原則，我們確保我們的代碼在再次代碼迭代之前以可能最簡單的方式通過測試。
不清楚是否這些原則的設計是爲了抵禦決策失誤，但是其中每一個用某種方式來避免決策失誤。
最終決定
思慮過多對我們的產出是不利的。爲了避免這一點，我們應該儘可能減少我們選擇的數量，減少我們做決定的時間，最終將一些東西列在紙上來加固它。
做一個小跳躍來嘗試第一個選擇產生的證據，在此基礎上，我們可以做出更好的決定。通過小迭代措施，我們確保我們的決定是成本低而又可變的。我們不是爲了避免難題而做一個無聊的決定，我們是爲了做一個更好的決定而做一個快速的決定。
好了，現在我們下定決心嘗試“快速的抉擇”而又不影響產品質量。同時在迭代過程中，快速的選擇停止來控制住質量。
【英文原文：https://8thlight.com/blog/nick-dyer/2016/11/17/dont-make-it-perfect.html】
{測試窩原創譯文，譯者：思雨}
https://www.testwo.com/article/852