淺談技術價值
最近事情不多，便想着整理下過去一段時間的想法和思考。自己大概算了下工作時間差不多也有 9 年時間，斷斷續續的思考技術在整個互聯網業務環節中的價值。
有人可能會想技術能有什麼價值？不就搬磚碼代碼嗎嘛，還想翻天了不成。是的，不少數會認爲主要就是實現產品需求，並保證線上運行的代碼不出問題就已經謝天謝地了。至於想改變世界，大哥快醒醒，別做夢了，快點搬磚，給後面的人少挖點坑就闊以了.....
說了這麼多，其實，我不太同意上面的觀點。套用星爺說的一句話：【做人如果沒夢想，跟鹹魚有什麼區別】
基於此，今天我主要從保障服務穩定、提能增效、賦能業務三個角度來談談技術價值
服務穩定性
線上服務的穩定性直接決定了產品的業務數據。試想一下，淘寶在雙十一零點的時候，登錄如果掛了，阿里會損失多少 GMV 和用戶體驗。
那我們該怎麼樣提高服務質量和穩定性呢？先大概的從架構層面講一下，我們一般採取限流、降級、超時、重試、冗餘等策略，來保障穩定性，具體詳細的操作後面會專門寫一篇文章討論下【如何提高服務的穩定性】
提能增效
互聯網行業唯快不破，如果你們的產品比競爭對手早上線，就能有更大機會超過對手，搶先一步佔領市場份額。那怎麼樣提高團隊的研發效率呢？
-
首先，我們應該從整體出發來提高研發效率，其中階段包括開發、測試、運維。如果只衡量開發環節效率，就會出現開發人員日均代碼行很多，甚至每天超過 1K 行以上。但是這個會使需求提前上線嗎？不一定，如果該需求產生的 bug 很多，沒有做單元測試和集成測試，更沒有進行聯調，我們就會花費更多時間都在修復 bug 和迴歸測試上。整體來看，這個需求的實現效率其實不高，只是將前面該做的事情挪到後面來做，同時這麼做的話，會極大的增加風險，到測試和運維階段纔會發現。
-
其次，應該量化從接收到需求發起階到線上運行爲結束，裏面每個耗時的階段都標記下。如果是聯調階段耗時比較長，我們就需要考慮搭建日常穩定的聯調環境。如果迴歸測試的時間較多，我們要考慮建立 API 自動化測試來減少迴歸時間等等
- 最後，可以採用測試前置和線上迭代週期減少來採用量化的思維體現出來，就像古話說的好：if you can't messure it ,you can't improve it
賦能業務
這塊其實是技術人員可以在老闆面前可以炫耀的資本，可以通過引入新的技術，新的算法模型，來提高用戶拉新促活或者 GMV 。
比如大家使用頭條的 App 來閱讀文章或者看抖音視頻，都會涉及到現在很火的推薦系統。那麼，某天技術人員引入某個深度排序模型，優化了召回和排序，結果使業務指標 CTR 或者 CVR 都提高了很多。這些一頓操作後，對應的技術同學感覺腰也直了不少，說話也不哆嗦了，對應的成就感也不一樣了。
最後，以上只是個人的淺薄之言，不期望每個人都認同，僅做參考，不喜勿噴~