在不瞭解業務上下文情況下請容忍軟體瑕疵Bug - jackhodkinson

banq發表於2021-02-09

牢記業務上下文的技術決策建議，業務上下文是唯一的衡量軟體質量的關鍵指標。
如果有事情不對勁，軟體工程師會感到不安。學生或初級工程師由於不熟悉程式設計概念而感到不安。漸漸地，我們對更高層次的抽象感到不安：我們不再會像當初因缺乏理解而煩惱，而是知道系統確實屬於有害反模式時，會更加不安。
不安情緒是我們即將面臨問題的可靠指標。
普通或優秀的工程師都會感到這種不安，優秀的工程師會傾聽自己的直覺，但會用自己的意識來思考是否應該執行某些操作。優秀的工程師會在不安和行動之間建立空間。優秀的工程師可以容忍缺陷。
在做出所有工程決策時，應瞭解其周圍的業務環境。為什麼要編寫這段程式碼？這必須為您做出的決定提供依據。
 
假設您正在開發一個對某些資料進行操作的系統。您是否應該將某些資料保留在資料庫，有序日誌或屬性檔案中？是否需要永久保留它，還是可以在開始時重新計算？甚至接受重啟後資料將丟失的資訊？在真空環境中，你不可能就這些解決方案中的任何一個提出有效的論據。
根據上下文，所有這些解決方案（以及更多解決方案）都是合理的。它們都有權衡：初始實施工作，執行成本，維護，監視。但是我經常看到工程師選擇過於複雜，過於昂貴的選項，因為愚蠢的簡單解決方案使他們感到不安。
當您有很多可用的解決問題的方法，而簡單的方法使您感到不安時，您應該退後一步，考慮一下原因。通常，是否有一個合理的原因解釋為什麼簡單的解決方案不起作用？如果沒有的話，您就可以省去實施複雜解決方案的麻煩，而您的隊友則可以維護它。
到目前為止，我僅討論了編寫新軟體所涉及的權衡。但是主要的罪過是拒絕現有程式碼中的缺陷。
技術債務有其合理存在的原因。
您有多少次聽到一個隊友說他們正在重構：卻造成失控並完全停止了其主要目標的進展？這些重構中有多少最終在完成之前就被放棄了？導致同一事物的兩個並行模型的頻率如何，使程式碼庫更加混亂？（重構還不如不重構，不折騰，折騰前先搞清原因再入坑，不要等入坑以後才知道原因）
 
容忍瑕疵還有其他優點。舊程式碼的原始作者可能做出了完美的權衡，但您無法從自己的位置或角度看到這一點（每個人的視角不同）。您的不安是沒有根據的，更類似於初級工程師或學生的不安。始終考慮直覺是錯誤的可能性。重寫初級工程師的程式碼使人沮喪。如果大三學生做了不正確的事情，請不要自己重寫。
如果您要完成任何事情，您必須能夠容忍缺陷。我們做過的任何事都不完美。嘗試這樣做是愚蠢的事,放手吧。

壞習慣不能隨便改，減肥不能隨便減：切斯特頓柵欄和二階思維的教訓
 

相關文章