如果您是開發人員,不知疲倦地推出新的更改,卻被過去工作中的錯誤拖了回來,那麼這篇文章對您來說非常重要。
在過去的十年裡,在軟體開發中,我犯過並且看到其他人反覆犯過的關鍵錯誤之一是專注於做更多的工作,而不是確保完成的工作(無論多小)是穩健的並且將繼續正常工作。這些重複出現的錯誤會嚴重影響生產力和積極性。
從我自己的錯誤中,我學到了寶貴的教訓。在這裡,我想分享一些策略,它們不僅可以幫助您交付強大的軟體,還可以讓您擺脫過去工作的束縛。
我們將討論對我最有效的 5 個策略:
恕我直言,工程師有兩種:為今天而奮鬥的工程師和為遙遠的未來而設計的工程師。這兩種方法本身都不可持續。
您的程式碼應該能夠應對您的業務即將經歷的成長。然而,針對未來挑戰的過度設計可能會導致不必要的複雜性。有一個專門的術語 -自行車脫落
這是我的實用經驗法則:規劃目前規模的 10 倍,或考慮您的業務在未來 2-3 年內預計會成長多少。確保您的計劃與您的業務目標保持一致。
例如,如果您是一家設計預訂模組的計程車公司,現在您的公司每天處理 10,000 次乘車,並預計在 2 年內達到每天 100,000 次乘車,請以此作為基準。當您只進行 10,000 次騎行時,設計一個每天可進行 1000 萬次騎行的系統可能會導致解決方案過於複雜和昂貴。
「幾天甚至幾週的除錯可以節省你編寫測試的幾個小時」——明智的人。
在不測試所有邊緣情況的情況下發布程式碼就像噴霧和祈禱策略。確保程式碼按預期工作的最簡單方法是新增單元測試。這聽起來似乎是顯而易見的,但徹底測試的重要性怎麼強調也不為過。
單元測試不僅充當針對明顯錯誤的第一道防線,而且還可以作為程式碼的保險,防止可能違反業務需求的意外更改。因此,減少每個衝刺分配給您的臨時錯誤 😉
懶人(像我)的一個技巧:在寫程式之前:
編寫涵蓋您能想到的每個極端情況的測試。
假裝你正試圖破壞別人的系統。
在所有測試中編寫斷言 False 並執行它們。
當然,所有測試都會失敗。
現在,只需努力讓每個測試通過即可。這種方法總體上花費的時間較少,每次都會產生健壯的程式碼!
我的一位經理曾經給了我最有影響力的建議:“採取行動,不要做出反應。”當我不斷在不同的 Slack 頻道上因問題、客戶投訴和付款失敗而被標記時,我提出了這個建議。我只是對每個請求做出反應,不知道接下來會發生什麼。
從那時起,我開始對我建造的每個功能提出三個問題:
我怎麼知道它正在工作?
我怎麼知道它失敗了?
我怎麼知道它成功了?
然後,我透過將指標傳送到我們的 APM 工具(例如 Datadog 或 NewRelic)來回答各個層級(功能、螢幕、應用程式)的這些問題。
設定完畢後,我配置了警報,以便在出現任何問題時通知我。
透過這樣做,我在錯誤升級為重大問題之前就意識到了它們,從而防止了反應性措施、糟糕的客戶體驗以及我自己對接下來可能發生的事情的不確定性。
每次建造一些東西時,就開始回答這三個基本問題,以確保您始終採取行動而不是做出反應。
就像糟糕的工作會讓你在各種 Slack 頻道上進行修復一樣,出色的工作會讓你在你所從事的領域中被貼上上下文標籤。
這可能會在你最意想不到的時候耗盡你的精力,或者更糟的是,它可能會讓你成為執行相同任務的首選人選,因為你了解完整的情況。
請保留這個秘密技巧:
記錄一切。包括您在建立功能時所做的上下文、架構和特定於業務的決策。當有人詢問某個區域的上下文(功能、螢幕、應用程式)時,只需向他們發送更新文件的連結即可。這每次都會為您節省幾個小時。
此外,完整的文件使新團隊成員的入職變得更加容易,並確保您的工作隨著時間的推移仍然可以存取和理解。
軟體工程通常強調個人貢獻者路徑。然而,單獨實現最終目標是不可能的——你只能與你的團隊一起實現它(反之亦然)。
理解並採用流程卓越的思維方式可以幫助您充分利用團隊的集體生產力。
對於這樣的措詞表示抱歉😄
簡而言之,確保審查、部署和任何涉及程式碼的協作活動不會有很長的等待時間,這可以大大提高您的工作效率!
辨識團隊中長時間等待或阻塞時間的最佳方法是衡量 DORA 指標。您可以使用像Middleware這樣的開源工具,它提供開箱即用的DORA 指標。
{% 嵌入 https://github.com/middlewarehq/middleware %}
PS:我也是Middleware的共同創辦人,我們的使命是讓工程師的工程變得順暢。如果您喜歡我們所建造的內容,請考慮給我們一顆星星!
透過採用這些建議,您可以大幅減少重新審視和修復過去工作所花費的時間。這不僅可以提高您的工作效率,還可以確保您始終專注於創新和提供新功能。
保持高效,而不是忙碌!祝一切順利😊
原文出處:https://dev.to/middleware/write-less-fix-never-the-art-of-highly-reliable-code-5a0i