油膩代碼大叔與蝴蝶效應
前些天突然覺得自己是不是得了老年癡呆，腦子總忘事，遇到佳純同學喊她姜楠，遇到周聰喊她“洋蔥”。
自己已是油膩大叔年紀了，大肚腩、大臉和雙下巴已經陪伴我多年。昨天晚上還瘋狂的吃了一頓火鍋，吃的時候幸福感是爆表，過后想想我應該很快就超越油膩大叔，變成肥肉大叔。這可能是小時候做過些壞事，上天對我的懲罰。
哎呀，寫著寫著饞蟲上來了，叫個小龍蝦外賣吃一吃，不過小龍蝦吃起來好麻煩，沒有吃火鍋爽，可以大口大口涮毛肚吃。
我想像《蝴蝶效應》的伊萬一樣回到過去改變自己。不過像我這種從小學習不好的，再怎么改變也應該就這樣了。能改變什么呢?
就像伊萬為了彌補錯誤，返回過去試圖消除痕跡，但總是事與愿違，并沒有變好而是更糟糕。于是反反復復，他奔波于日益混亂的過去與現實之間，直到不可挽回的結局。伊萬試圖改變過去，希望能與他暗戀的凱蕾一起幸福生活的夢想，也成為了泡影。
既然這樣，“過去的已然成為過去，不要把精力用在追憶并后悔人生轉折點時作出的任何決定”。該吃吃該喝喝，做個沒心沒肺的人好像也挺好。
回歸正題。
當我在設計開發一個系統時，一開始覺得自信滿滿，一切在控制當中。隨著時間流逝，出現了各種各樣的問題，項目交付時間一二三的被延期。心里想自己到底做錯了什么，為什么呢?
當我在維護一個系統時，為什么總是不穩定，修復一個BUG又出現另一個，出問題后不斷的重啟系統，總是被業務方投訴，為什么它就不能老老實實的好好運行，讓我省點心。我們到底做錯了什么?
先來看看我們開發一個系統需要做些什么吧：
- 首先產品會出PRD，大家一起評審，此時程序員需要去理解其中的邏輯：業務語言、流程、功能、異常;
- 接著定義業務架構和系統架構，是分布式還是單體，業務和系統模塊怎么劃分，邊界如何界定，業務上下游依賴和邊界是什么;
- 接著開始進行項目搭建，用Java還是Go，用Git還是SVN，是基于Maven構建還是Gradle;
- 接著進行一些技術選型，用SpringCloud還是Dubbo，要不要用Guava，用Slf4j還是直接Log4j;存儲選什么;用不用緩存;
- 明確分工，構建各自的模塊和系統，碼代碼;
- 進行模塊集成或系統集成;
- 測試、交付上線。
這是比較理想的一個開發方式，實際過程要復雜很多。我們會遇到需求不明確，需求錯誤，細節考慮不周全，技術上不可行等等很多問題。
在開發過程中還有一些非功能性需求要考慮：
- 提升工程開發效率;
- 魯棒性、可維護性、可擴展性;
- 高并發、高可用、SLA;
- 兼容性;
- A/B測試;
- 可回歸測試;
- DevOps;
- 管理復雜度;
還有我們解決問題的方式：
- 當我們在解決一個類似問題時，有些人是通過抽象來解決;有些人覺得反正代碼邏輯超簡單，復制代碼來解決;
- 有些不應該出生的代碼出生了，維護一些亂七八糟的代碼;
- if/else嵌套超過三層;
- 看框架源碼又不能幫我提高寫代碼的速度，浪費我時間;
- 反正我能看懂，不寫注釋和文檔了;
- 復雜的解決方案沒有迭代優化;
- 明天就上線，今天必須交付，然后就沒然后了;
- 重啟來解決問題;
- 不去學習解決問題的工具;
- ……
可以看出開發一個系統從來不是一件簡單的事情，除了完成業務邏輯，還要考慮很多非功能性需求，其中一個沒有做好都會引起蝴蝶效應。用戶/數據量大會導致大的風暴，而用戶/數據量小可能就是下點小雨。
蝴蝶效應定義：
“蝴蝶效應是指在一個動力系統中，初始條件下微小的變化能帶動整個系統的長期的巨大的連鎖反應。”
我們看過的源代碼、看過的書并不是沒用的，每一個知識可能在未來的某一時刻被我用到，學習會使我的思路開放，而不是封閉。通過不斷微小的學習，觸發蝴蝶效應，得到巨大的收獲。
不過我好像已經走上了另一條不歸路，油膩代碼大叔之路越走越踏實了!
【本文是51CTO專欄作者張開濤的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】
