作者 | Oto Brglez

譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

在軟件開發中，總會遇到一些不同的難題。在本文中，我將介紹一些關鍵的主題，由于這些領域的“投資”很難短時間內在ROA/KPI/OKR儀表板上看出成效，遠遠比不上那些“客戶非常喜歡”的閃亮新功能，因此常常被忽視、遺忘或排除在外。

復雜性

第一個搖搖欲墜的“支柱”就是復雜性。在做技術規劃時，我們常常會忽略復雜性引發的各種問題。雖然只是添加了一個小小的庫，然而其背后引入的依賴性卻無法預知。很多人會因為患得患失而不斷添加各種微服務，然而這會引發一系列的后續工作：部署、版本控制、發展，乃至逐步淘汰。不僅如此，這也會加劇組織的復雜性：隨著產品、團隊和公司的發展，組織成員、文檔、利益相關者等的數量也會增加，導致組織的靈活性降低。

在考慮復雜性時，你還應該想到另一個可怕的問題：每個工程師每天都在構建功能，但這些構建工作都是正確的嗎？就目前來看，這些構建工作都是正確的？那么，再過兩年、三年、五年乃至十年，還正確嗎？該問題的回答越復雜，你就越應該感到害怕。我們應該通過良好的需求定義、明確的目標和持續的“簡化”來對抗復雜性。

在談論和思考復雜性時，應該采用記錄時間的方式：記錄下為了支持某些功能而浪費的小時數，記錄下為了讓 X 進入生產環境而不得不在 Y 上浪費的小時數。還有為了尋找與 Z 相關的信息而花費的時間?？偟膩碚f，我們不僅要知道需要什么，還要知道為什么需要。

技術負債

這就引出了我們的第二個“支柱”，技術負債不僅會破壞士氣，影響計劃和截止日期，而且在極少數情況下還會導致整個組織瓦解。每個項目，每個組織都有技術負債，就是因為他們不愿意談論這個話題，而且即便談論也是因為延誤項目而受到指責或以此為借口。

當然，你可以打一個補丁，然后再打另一個補丁，不斷累加。你可以調整界面，以便進度條在屏幕上多停留幾秒鐘；也可以將負載均衡器的超時時間延長至幾分鐘，讓服務“消化”有效負載；甚至可以用另一個服務打包整個服務。

這些不恰當的解決方案確實可以爭取一些時間，而且很多產品，尤其是年輕的產品，都采取了這樣的措施。然而，你必須做到心中有數，這些都是技術負債，最終仍然不得不償還。不償還這些債務，就會威脅到團隊和組織。技術負債是一種風險，尤其是當你身處管理職位時，必須時刻關注技術負債。

你需要記錄并公開討論技術負債，向其他工程師解釋為什么某些實現采取了蹩腳的做法。此外，還需要與管理層溝通，向他們澄清技術負債引發的各種問題：收入損失、系統停機、開發周期延長、錯誤和 bug 頻發等等。

資源

這個“支柱”比較顯而易見，且不同的組織有不同的稱呼：資產、人員、基礎設施、構建產品所必需的元素等等。我們經常討論將來的計劃，比如我們需要招聘 50 名工程師、20 名數據科學家，我們需要擴大云預算、購買新的 SaaS 服務等。

然而，我們應該多花些時間思考如何留住現有的人員、利用現有的服務，并以更有效的方式利用我們的資源。

從風險的角度來看，培養團隊內現有的專家比招募新成員的風險更小，尤其是在當前。嘗試新技術意味著，你的技術棧中將出現一條你不知道如何馴服的“猛龍”。

我建議多花些時間認為思考如何利用當前的資源，以及如何提升他們的價值和性能。

實驗

我很喜歡這個“支柱”。實驗有一種特殊的力量。然而，很多組織都會忘記實驗，或者更直白的說，他們會嚴格限制實驗和創新，他們希望“一切照舊”，甚至還有人說“被迫如此”。

我希望鼓勵每個人勇于嘗試以前從未接觸過的框架和技術，同時也希望每個人都能積極地想辦法解決符合組織愿景和挑戰的難題。

作為一名工程師，你應該積極地向管理層提出有關公司如何創新和提高競爭力的問題。作為管理層，你應該多投入一些時間和資源開展相關的活動，思考如何將一些不成熟的想法變成出色的解決方案。

總結

當然，對于各個組織、項目或產品來說，關鍵性的支柱肯定不止這四個。常見的還有優先級、預算、銷售等等，但是我認為這些支柱能夠讓組織保持良好的發展，而且還能幫助組織保持領先地位。

參考鏈接：

https://www.linkedin.com/pulse/four-dusty-pillars-software-engineering-oto-brglez/