if 語句是任何軟體工程師用來解決日常問題的基本工具之一。從第一天開始，它就是軟體工程的一部分，就在學生寫下第一個“hello world”之後。它無處不在，它的破壞力也是如此。
盡管工程師們系統地對這一現實視而不見，但讓我們看看我們如何改變思維方式來克服這個問題，并赢得與臭名昭著的 if 語句的戰鬥。
2013 年，我對一個有 20 年曆史的軟體進行逆向工程，他的原始建立者沒有留下任何文檔。幾周後，我了解了算法的工作原理——它背後的美——以及它的邊緣情況。這些邊緣情況由 if 語句（或它們的邪惡化身）映射，最終在代碼中形成一片森林。
如果您想知道，是的，它的原始建立者使用模式來适當地組織代碼并使其可讀，但事實是，模式隻是為了可讀性而隐藏 if 語句，但它們并沒有擺脫它們。是以，最後，它們都在周圍——就像蚊子整夜咬你一樣。
就在那一刻，我用以下方式挑戰自己。
如果每個算法可以使用有限數量的 if 語句，我将如何編寫解決方案？
經過一番反複，我發現 if 語句讓工程師懶于編碼，此外，為他們提供了一種簡單的方法來避免思考如何雄辯地解決問題——它創造了一種“啊，那裡是一個邊緣情況，讓我們寫一個 if 語句”。
考慮到這一點，現在我們可以談談我一開始承諾要分享的心态：
考慮一個問題，使邊緣情況成為常态的一部分，而不是例外。
讓我們用這種新的思維方式來解決一個實際的問題，看看它是如何工作的，在這種情況下——隻是為了加強我之前關于工程師在這個問題上系統性地盲目的觀點——讓我們使用算法工程師在大學第一年學習一種稱為“單連結清單”的特定資料類型：
盡管它是一段被廣泛使用的代碼，并且在世界各地的大學中都以這種方式教授，但該代碼已經很糟糕了——如果你到目前為止已經注意了，你可能知道為什麼……
是的，最後的 if 語句 。
我們不需要深入分析代碼，簡單來說就是處理一個特定的場景，當條目需要被删除，但是，删除的方式取決于它是第一個條目還是在中間（邊緣 案子）。
如果我們使用新的思維方式——以邊緣情況成為常态的一部分而不是例外的方式來思考問題——我們可以用這種新的方式重寫這段古老的代碼：
看看 if 語句是如何消失的，但更重要的是，邊緣情況現在是規範的一部分，而不是例外，而且——作為一個重要的副作用——代碼變得更加直接和雄辯。
盡管這是我們掌握主要思想的一個基本示例，但概念要複雜得多；它是關于看到邊緣案例模式并本能地知道如何将它們轉化為規範。一開始很難，但通過練習變得更容易管理。
現在繼續打開您昨天正在處理的代碼，并嘗試使用這種新思維方式删除您的第一個 if 語句！
學習更多技能
請點選下方公衆号