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

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

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

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

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

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

[[212907]]

回歸正題。

當我在設(shè)計開發(fā)一個系統(tǒng)時，一開始覺得自信滿滿，一切在控制當中。隨著時間流逝，出現(xiàn)了各種各樣的問題，項目交付時間一二三的被延期。心里想自己到底做錯了什么，為什么呢?

當我在維護一個系統(tǒng)時，為什么總是不穩(wěn)定，修復一個BUG又出現(xiàn)另一個，出問題后不斷的重啟系統(tǒng)，總是被業(yè)務(wù)方投訴，為什么它就不能老老實實的好好運行，讓我省點心。我們到底做錯了什么?

先來看看我們開發(fā)一個系統(tǒng)需要做些什么吧：

1. 首先產(chǎn)品會出PRD，大家一起評審，此時程序員需要去理解其中的邏輯：業(yè)務(wù)語言、流程、功能、異常;
2. 接著定義業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)，是分布式還是單體，業(yè)務(wù)和系統(tǒng)模塊怎么劃分，邊界如何界定，業(yè)務(wù)上下游依賴和邊界是什么;
3. 接著開始進行項目搭建，用Java還是Go，用Git還是SVN，是基于Maven構(gòu)建還是Gradle;
4. 接著進行一些技術(shù)選型，用SpringCloud還是Dubbo，要不要用Guava，用Slf4j還是直接Log4j;存儲選什么;用不用緩存;
5. 明確分工，構(gòu)建各自的模塊和系統(tǒng)，碼代碼;
6. 進行模塊集成或系統(tǒng)集成;
7. 測試、交付上線。

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

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

1. 提升工程開發(fā)效率;
2. 魯棒性、可維護性、可擴展性;
3. 高并發(fā)、高可用、SLA;
4. 兼容性;
5. A/B測試;
6. 可回歸測試;
7. DevOps;
8. 管理復雜度;

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

1. 當我們在解決一個類似問題時，有些人是通過抽象來解決;有些人覺得反正代碼邏輯超簡單，復制代碼來解決;
2. 有些不應(yīng)該出生的代碼出生了，維護一些亂七八糟的代碼;
3. if/else嵌套超過三層;
4. 看框架源碼又不能幫我提高寫代碼的速度，浪費我時間;
5. 反正我能看懂，不寫注釋和文檔了;
6. 復雜的解決方案沒有迭代優(yōu)化;
7. 明天就上線，今天必須交付，然后就沒然后了;
8. 重啟來解決問題;
9. 不去學習解決問題的工具;
10. ……

可以看出開發(fā)一個系統(tǒng)從來不是一件簡單的事情，除了完成業(yè)務(wù)邏輯，還要考慮很多非功能性需求，其中一個沒有做好都會引起蝴蝶效應(yīng)。用戶/數(shù)據(jù)量大會導致大的風暴，而用戶/數(shù)據(jù)量小可能就是下點小雨。

蝴蝶效應(yīng)定義：

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

我們看過的源代碼、看過的書并不是沒用的，每一個知識可能在未來的某一時刻被我用到，學習會使我的思路開放，而不是封閉。通過不斷微小的學習，觸發(fā)蝴蝶效應(yīng)，得到巨大的收獲。

不過我好像已經(jīng)走上了另一條不歸路，油膩代碼大叔之路越走越踏實了!

【本文是51CTO專欄作者張開濤的原創(chuàng)文章，作者微信公眾號：開濤的博客( kaitao-1234567)】

戳這里，看該作者更多好文