自 2018 年初以來，我一直在團隊中擔任領導/老闆/首席開發人員的職位 - 你想怎麼稱呼它就怎麼稱呼它，但重點是我對其中一個模組以及所有工作的開發人員完全負責在上面。 這個職位讓我對開發過程有了新的視角，因為我參與了更多的專案並更積極參與決策。 最近，由於這兩件事，我突然意識到理解的程度對程式碼和應用程式的影響有多大。
我想說的一點是，程式碼（以及最終產品）的品質與設計和編寫程式碼的人對自己所做的事情的了解程度密切相關。
你現在可能會想，「謝謝，隊長。 當然，如果能夠大致了解您所寫的內容，那就太好了。 否則，你不如僱一群猴子去敲任意鍵，然後就這樣了。” 你是絕對正確的。 因此，我理所當然地認為你認識到對你正在做的事情有一個總體的了解是必要的。 這堪稱零層次的理解，我們就不詳細分析了。 我們將詳細了解您到底需要了解什麼以及它如何影響您每天所做的決定。 如果我提前知道這些事情，就會節省我很多浪費的時間和有問題的程式碼。
儘管你不會在下面看到一行程式碼，但我仍然相信這裡所說的一切對於編寫高品質、富有表現力的程式碼非常重要。
第一層理解：為什麼它不起作用？
開發人員通常在職業生涯的早期就達到了這個水平，有時甚至沒有其他人的任何幫助——至少根據我的經驗。 想像一下，您收到了一份錯誤報告：應用程式中的某些功能無法運行，需要修復。 你將如何進行？
標準方案如下圖所示：
- 找到導致問題的程式碼片段（如何做到這一點是一個單獨的主題，我在關於遺留程式碼的書中介紹了它）
- 對此片段進行更改
- 確保錯誤已修復且未發生回歸錯誤
現在讓我們專注於第二點——對程式碼進行更改。 此過程有兩種方法。 首先是深入研究當前程式碼中到底發生了什麼，識別錯誤並修復它。 第二：憑感覺移動 - 添加，比如說，+1 到條件語句或循環，看看該函數是否在所需的場景中工作，然後嘗試其他方法，依此類推。
第一種方法是正確的。 正如Steve McConnell 在他的《Code Complete》一書中解釋的那樣（順便說一句，我強烈推薦這本書），每次我們更改程式碼中的某些內容時，我們都應該能夠自信地預測它將如何影響應用程式。 我是憑記憶引用的，但如果錯誤修復沒有按您預期的方式工作，您應該非常警惕，並且應該質疑您的整個行動計劃。
總結一下前面所說的，為了在不降低程式碼品質的情況下進行良好的錯誤修復，您需要了解程式碼的整個結構和特定問題的根源。
第二層次的理解：為什麼它有效？
這一層次的理解比前一層次要直觀得多。 我當時還是個開發新手，在老闆的幫助下學會了它，隨後又反覆向新人解釋了事情的本質。
這次，假設您同時收到兩個錯誤回報：第一個是關於場景 A 的，第二個是關於場景 B 的。在這兩個場景中，都發生了錯誤。 因此，您首先要解決第一個錯誤。 使用我們為 XNUMX 級理解而開發的原則，您可以深入挖掘與問題相關的程式碼，找出為什麼它會導致應用程式按照場景 A 中的方式運行，並進行合理的調整以產生您想要的結果。 。 一切都很順利。
然後您轉到場景 B。您重複該場景試圖引發錯誤，但—令人驚訝！ - 現在一切都按其應有的方式進行。 為了證實您的猜測，您撤銷了在處理錯誤 A 時所做的更改，錯誤 B 又回來了。 您的錯誤修復解決了這兩個問題。 幸運的！
你根本沒有指望這一點。 您已經想出了一種方法來修復場景 A 中的錯誤，但不知道為什麼它對場景 B 有效。在這個階段，很容易認為這兩項任務都已成功完成。 這是非常合乎邏輯的：重點是消除錯誤，不是嗎？ 但工作還沒有完成：你仍然需要弄清楚為什麼你的行為糾正了場景 B 中的錯誤。為什麼？ 因為它可能遵循錯誤的原則，然後你就需要尋找其他出路。 以下是此類案例的幾個範例：
- 由於該解決方案不是針對錯誤 B 量身定制的，因此考慮到所有因素，您可能會在不知不覺中破壞功能 C。
- 也可能潛伏著第三個錯誤，與相同的功能相關，而您的錯誤修復依賴它來保證場景 B 中系統的正確運作。 現在一切看起來都很好，但是有一天，第三個錯誤將會被注意到並修復。 那麼在場景 B 中，錯誤會再次出現，如果只是出現就好了。
所有這些都會給程式碼帶來混亂，有一天會落在你的頭上 - 很可能是在最不合時宜的時刻。 你必須鼓起你的意志力，強迫自己花時間去理解為什麼一切似乎都有效，但這是值得的。
第三層次的理解：為什麼它有效？
我最近的見解正是與這個水平有關，如果我早點想到這個想法，它可能會給我帶來最大的好處。
為了說得更清楚，讓我們看一個例子：你的模組需要相容函數X，你對函數X不是特別熟悉，但是有人告訴你要相容它，你需要使用F框架。與X 整合的模組與他完全相容。
你的程式碼從F框架誕生的第一天起就完全沒有接觸過它，所以實現它不會那麼容易。 這將對模組的某些部分產生嚴重後果。 然而，你全心投入開發：你花了幾週的時間編寫程式碼、測試、推出試點版本、獲取回饋、修復回歸錯誤、發現不可預見的複雜情況、未滿足最初商定的最後期限、編寫更多程式碼、測試、獲取回饋溝通、修正回歸錯誤——這一切都是為了實現 F 框架。
在某些時候，你突然意識到 - 或者可能從某人那裡聽到 - 也許框架 F 根本不會為你提供與功能 X 的兼容性。也許所有的時間和精力都投入到了完全錯誤的事情上。
在我負責的一個專案中，也發生過類似的事情。 為什麼會發生這種情況？ 因為我對函數 X 是什麼以及它與框架 F 的關係知之甚少。我應該做什麼？ 要求分配開發任務的人清楚地解釋預期的行動過程如何導致期望的結果，而不是簡單地重複對其他模組所做的事情或相信他們的話，這就是功能 X 需要做的事情。
這個專案的經驗告訴我，在我們清楚了解為什麼要求我們做某些事情之前，不要開始開發過程。 直接拒絕。 當你接到任務時，第一個反應就是立即接受，以免浪費時間。 但「凍結計畫直到我們了解所有細節」的政策可以將浪費的時間減少幾個數量級。
即使他們試圖向你施加壓力，強迫你開始工作，儘管你不明白這樣做的理由，也要抵制。 首先，弄清楚為什麼要給你這樣的任務，並確定這是否是實現目標的正確方法。 我必須以艱難的方式學習這一切 - 我希望我的例子能讓那些讀到這篇文章的人生活得更輕鬆。
第四層理解：？？？
程式設計總是有更多東西需要學習，我相信我只是觸及了理解主題的表面。 在多年的程式碼工作中，您還發現了哪些其他層次的理解？ 您做出的哪些決定對程式碼和應用程式的品質產生了積極影響？ 哪些決定最終被證明是錯誤的並給你上了寶貴的一課？ 在評論中分享您的經驗。
來源： www.habr.com