淺談技術價值
最近事情不多，便想着整理下過去一段時間的想法和思考。自己大概算了下工作時間差不多也有 9 年時間，斷斷續續的思考技術在整個網際網路業務環節中的價值。
有人可能會想技術能有什麼價值？不就搬磚碼代碼嗎嘛，還想翻天了不成。是的，不少數會認為主要就是實作産品需求，并保證線上運作的代碼不出問題就已經謝天謝地了。至于想改變世界，大哥快醒醒，别做夢了，快點搬磚，給後面的人少挖點坑就闊以了.....
說了這麼多，其實，我不太同意上面的觀點。套用星爺說的一句話：【做人如果沒夢想，跟鹹魚有什麼差別】
基于此，今天我主要從保障服務穩定、提能增效、賦能業務三個角度來談談技術價值
服務穩定性
線上服務的穩定性直接決定了産品的業務資料。試想一下，淘寶在雙十一零點的時候，登入如果挂了，阿裡會損失多少 GMV 和使用者體驗。
那我們該怎麼樣提高服務品質和穩定性呢？先大概的從架構層面講一下，我們一般采取限流、降級、逾時、重試、備援等政策，來保障穩定性，具體詳細的操作後面會專門寫一篇文章讨論下【如何提高服務的穩定性】
提能增效
網際網路行業唯快不破，如果你們的産品比競争對手早上線，就能有更大機會超過對手，搶先一步占領市場佔有率。那怎麼樣提高團隊的研發效率呢？
- 首先，我們應該從整體出發來提高研發效率，其中階段包括開發、測試、運維。如果隻衡量開發環節效率，就會出現開發人員日均代碼行很多，甚至每天超過 1K 行以上。但是這個會使需求提前上線嗎？不一定，如果該需求産生的 bug 很多，沒有做單元測試和內建測試，更沒有進行聯調，我們就會花費更多時間都在修複 bug 和回歸測試上。整體來看，這個需求的實作效率其實不高，隻是将前面該做的事情挪到後面來做，同時這麼做的話，會極大的增加風險，到測試和運維階段才會發現。
- 其次，應該量化從接收到需求發起階到線上運作為結束，裡面每個耗時的階段都标記下。如果是聯調階段耗時比較長，我們就需要考慮搭建日常穩定的聯調環境。如果回歸測試的時間較多，我們要考慮建立 API 自動化測試來減少回歸時間等等
- 最後，可以采用測試前置和線上疊代周期減少來采用量化的思維展現出來，就像古話說的好：if you can't messure it ,you can't improve it