油膩程式碼大叔與蝴蝶效應

作者：開濤

好久沒寫部落格了，好久沒看書了，好久沒拍到讓自己欣喜的照片了，好久沒……，突然間好害怕。手觸動鍵盤時，其實腦子是一片空白的，呆呆的坐著並沒什麼想法，難道是因為好久沒看書的原因嗎？

前些天突然覺得自己是不是得了老年痴呆，腦子總忘事，遇到佳純同學喊她姜楠，遇到周聰喊她“洋蔥”。

自己已是油膩大叔年紀了，大肚腩、大臉和雙下巴已經陪伴我多年。昨天晚上還瘋狂的吃了一頓火鍋，吃的時候幸福感是爆表，過後想想我應該很快就超越油膩大叔，變成肥肉大叔。這可能是小時候做過些壞事，上天對我的懲罰。

哎呀，寫著寫著饞蟲上來了，叫個小龍蝦外賣吃一吃，不過小龍蝦吃起來好麻煩，沒有吃火鍋爽，可以大口大口涮毛肚吃。

我想像《蝴蝶效應》的伊萬一樣回到過去改變自己。不過像我這種從小學習不好的，再怎麼改變也應該就這樣了。能改變什麼呢？

就像伊萬為了彌補錯誤，返回過去試圖消除痕跡，但總是事與願違，並沒有變好而是更糟糕。於是反反覆覆，他奔波於日益混亂的過去與現實之間，直到不可挽回的結局。伊萬試圖改變過去，希望能與他暗戀的凱蕾一起幸福生活的夢想，也成為了泡影。

既然這樣，“過去的已然成為過去，不要把精力用在追憶並後悔人生轉折點時作出的任何決定”。該吃吃該喝喝，做個沒心沒肺的人好像也挺好。

迴歸正題。

=======================

當我在設計開發一個系統時，一開始覺得自信滿滿，一切在控制當中。隨著時間流逝，出現了各種各樣的問題，專案交付時間一二三的被延期。心裡想自己到底做錯了什麼，為什麼呢？

當我在維護一個系統時，為什麼總是不穩定，修復一個BUG又出現另一個，出問題後不斷的重啟系統，總是被業務方投訴，為什麼它就不能老老實實的好好執行，讓我省點心。我們到底做錯了什麼？

先來看看我們開發一個系統需要做些什麼吧：

1. 首先產品會出PRD，大家一起評審，此時程式設計師需要去理解其中的邏輯：業務語言、流程、功能、異常；
2. 接著定義業務架構和系統架構，是分散式還是單體，業務和系統模組怎麼劃分，邊界如何界定，業務上下游依賴和邊界是什麼；
3. 接著開始進行專案搭建，用Java還是Go，用Git還是SVN，是基於Maven構建還是Gradle；
4. 接著進行一些技術選型，用SpringCloud還是Dubbo，要不要用Guava，用Slf4j還是直接Log4j；儲存選什麼；用不用快取；
5. 明確分工，構建各自的模組和系統，碼程式碼；
6. 進行模組整合或系統整合；
7. 測試、交付上線。

這是比較理想的一個開發方式，實際過程要複雜很多。我們會遇到需求不明確，需求錯誤，細節考慮不周全，技術上不可行等等很多問題。

在開發過程中還有一些非功能性需求要考慮：

1. 提升工程開發效率；
2. 魯棒性、可維護性、可擴充套件性；
3. 高併發、高可用、SLA；
4. 相容性；
5. A/B測試；
6. 可迴歸測試；
7. DevOps；
8. 管理複雜度；

還有我們解決問題的方式：

1. 當我們在解決一個類似問題時，有些人是通過抽象來解決；有些人覺得反正程式碼邏輯超簡單，複製程式碼來解決；
2. 有些不應該出生的程式碼出生了，維護一些亂七八糟的程式碼；
3. if/else巢狀超過三層；
4. 看框架原始碼又不能幫我提高寫程式碼的速度，浪費我時間；
5. 反正我能看懂，不寫註釋和文件了；
6. 複雜的解決方案沒有迭代優化；
7. 明天就上線，今天必須交付，然後就沒然後了；
8. 重啟來解決問題；
9. 不去學習解決問題的工具；
10. ……

可以看出開發一個系統從來不是一件簡單的事情，除了完成業務邏輯，還要考慮很多非功能性需求，其中一個沒有做好都會引起蝴蝶效應。使用者/資料量大會導致大的風暴，而使用者/資料量小可能就是下點小雨。

蝴蝶效應定義：

“蝴蝶效應是指在一個動力系統中，初始條件下微小的變化能帶動整個系統的長期的巨大的連鎖反應。”

我們看過的原始碼、看過的書並不是沒用的，每一個知識可能在未來的某一時刻被我用到，學習會使我的思路開放，而不是封閉。通過不斷微小的學習，觸發蝴蝶效應，得到巨大的收穫。

不過我好像已經走上了另一條不歸路，油膩程式碼大叔之路越走越踏實了！

不管怎麼學習也都是一個坑一個坑的挖，一個坑一個坑的埋。一開始就設計的很完美的系統是沒有的，系統是是不斷迭代出來了。另外推薦接著讀讀《億級流量》第一章 交易型系統設計的一些原則來看看一個高可用高併發系統需要填多少坑。