開發者很可能在無意中給代碼增加了技術債務。以下是如何從代碼中消除技術債務。

譯自How Frontend Devs Can Take Technical Debt out of Code。

技術債務可以有多種形式。它可能表現為代碼中的bug，或者同一部門不同開發者的編碼實踐不統一。

技術債務是指任何由于首次沒有做對而需要額外工作或重新工作的東西。有時開發者編寫的代碼在一臺機器上運行良好，但是當部署到分布式環境時就會失敗 - 這也屬于技術債務，BOS Framework的創始人兼CEOShashank Purighalla表示，BOS Framework是一個云基礎架構和DevOps自動化平臺。

“從高層次來看，從業務層面來說，你可以談到有意的技術債務，幾乎每個程序員和每個開發團隊由于時間和預算局限都會承擔這種債務。” Purighalla說。“同時也存在許多非故意或意外的技術債務，人們簡單地不知道自己正在承擔這種債務 - 由于知識欠缺，對整個生態系統認知有限，或者局限在自己的視野中。”

Purighalla 在接受 The New Stack 的采訪時表示，前端和 Web 應用開發者可以幫助解決技術債務。但首先，他們需要知道技術債務的表現。

理解技術債務

開發者可以通過各種方式識別技術債務，首先是修復代碼中的bug這種最令人討厭的技術債務。但他說還有其他指標。

“高級開發人員通常可以查看代碼，并指出:‘我看到某些構造做得不好，或者某些實現可能不太優化。’” Purighalla說。“從識別系統中的bug，到未完成的代碼，到實現粗糙，以及從生態系統分析角度略微提升 - 缺少安全構造或某些協議沒有正確實現。”

過去三年網絡攻擊的增加證明了軟件技術債務的存在，他說。

“這是技術債務的后果，我稱之為無意的技術債務，因為大多數情況下，技術團隊在使用、引入它或者接手該項目時，甚至不知道存在所有這些問題。”他說。

全棧思考，前端行動

為了應對技術債務，Purighalla 建議開發者 - 甚至前端開發者 - 應把自己的工作視為一個更大系統的組成部分，而不要孤立看待。

“開發者要考慮他們編寫的代碼是作為一個更大系統的一部分，而不僅僅是那個具體的部分。”他說。“有這樣一個工程原則: '對藝術的過度追求完美會損害整體的完整性'。”

BOS Framework創始人兼CEO Shashank Purighalla

這意味著即使不是真正的全棧開發者，開發者也必須具有全棧開發者的思維方式。對前端來說，這具體是要了解網站或Web應用所依賴的底層數據，Purighalla解釋道。

“這個系統明顯是從前端開始的，終端用戶通過它與應用程序進行交互，然后它與某種編排層比如API進行交互，然后與后端基礎設施交互，最后與數據庫交互。”他說。“編排層和前端的實現必須非常小心。”

Purighalla說，前端開發者應對他們的應用所依賴的數據負責。例如，前端開發者應知道，他們最終從界面展示或獲取的大致有5種類型的數據:

• 機密數據;
• 高度機密數據;
• 限制性數據;
• 內部數據;
• 公開數據。

根據數據的獲取方式以及將數據放回數據庫的方式，或者相反，根據從數據庫獲取并在界面展示數據的方式，這5種類型的數據有不同的要求，他說。

“當我們談論前端Web應用程序時，界面類型也非常重要。”他說。“特別是在AI世界中，你不僅僅是在屏幕上展示數據。你正在談論一個高度交互的系統，它可能由自然語言處理驅動。所以數據的獲取方式非常重要。”

例如，前端開發者需要知道何時使用加密、驗證碼或注冊表單。

“理解開發者的決策如何直接影響組織及其領導也很重要。”他補充說。“這是開發者經常沒有意識到的。”

面向所有開發者的標準

要開始減少技術債務，開發團隊應采用每個開發者都要遵守的編碼標準，他補充說。

“最基本的，要考慮命名規范。” Purighalla說。“如何命名變量？公共變量、全局變量、私有變量。”

他還建議采用測試驅動開發。在測試驅動開發中，單元測試是在開發實際代碼之前創建的。

“最起碼，測試驅動開發是減少功能和用戶體驗缺陷的一個非常好的策略。”他說。“所以需求不僅被視為需要驗證的清單，而且被視為需要實現的結果的一部分。”

測試驅動開發形成一種思維轉變，從功能代碼完整性或代碼完整性的角度來思考代碼，他補充說。

他還表示，前端還必須考慮自己是否在開發某些內部目的的Web應用，或者面向公眾的SaaS應用。可能存在與HIPAA、SOC 2或其他法規相關的合規性問題，他補充說。這與數據和安全的考量結合起來應該指導開發者。

這決定了必須遵循的標準類型，以及必須以一定周期進行的代碼掃描、代碼覆蓋率和安全掃描等基本原則。”他說。“要么進行靜態代碼分析，要么在每個部署周期中完成。”

他補充說，優秀的實踐必須致力于確保代碼可讀性，并進行適當的內聯文檔注釋。這可以簡單到開發者添加注釋說明誰在開發，何時編寫，為何編寫，存在什么需求，目的是什么，他說。注釋還應指明項目中是否存在更深層次的設計文檔或順序圖等參考資料。

“缺少這些是我們出現大量網絡安全漏洞的原因，我不能過分強調這一點，”他說。“如果你可以選擇技術棧，有時候就很容易，對吧？如果你用前端采用解釋型語言而不是編譯型語言，比如 PHP，很容易就可以找到漏洞然后開始攻擊系統。即使只有一個小漏洞，也不需要很長時間。如果你使用基礎的編譯型技術，如果做得好，被攻擊的機率會大大降低。”

此外，他補充說，組織中的所有開發者都應遵循這些實踐的相同標準。

“開發者必須明白，自己是更大生態系統的一部分，要構建能融入總體框架的組件，”他說。“從商業視角理解一切，然后按照商業需求反向工作，這可能包括我不會專門編寫某些安全構造的要求。”