改和看別人的代碼是一種什麼感受

工作裡面可能會沉澱下來很多的東西， 比如文檔， 代碼/腳本， 或者圖片， 甚至你留下的趣事或者“案底”。

對於修改代碼， 我很多年前就體驗過一次，

是修改自己寫的代碼， 記得剛畢業的時候寫了一個小的項目， 是使用Java的Swing技術實現的， 能夠對一個表格做資料的增刪改查。 當時寫得真是昏天暗地， 坐地鐵回家的時候都有一種頭重腳輕的感覺。 這僅僅是一個開發前的純技術練習而已。 寫了一周的樣子， 把代碼推給自己的導師來看， 導師從各種角度提出了很多的問題， 有的問題確實是硬傷， 有的問題感覺是理解的角度不同， 所以帶著半推半就的態度開始第二版， 第二版很快就反覆運算出來了， 完成的這種感覺就跟你考完試一樣， 再也不想看自己寫的代碼了。 第二次的時候， 導師從設計模式的角度給我提出了一些建議， 然後我開始重新審視自己寫的代碼， 改一改， 調一調， 看起來是那麼回事了， 依稀記得當時使用的是命令模式。 這一次自己感覺確實是差不多了， 從代碼的命名規範和“優美”程度來看， 感覺已經很難挑出問題了， 導師看了下， 整體給予了肯定， 然後把自己的代碼發給我， 互相參考學習。 這個時候換了一個全新的角度， 可以發現很多地方自己還是有待改進的地方。 程式開發就是如此， 總是有很多待改進的地方。

當然我也碰到了一些比較尷尬的情況， 比如我們之前開發一個相當複雜的業務， 一個類竟然已經被上百個人改過了， 看著一條條的代碼改動標記和注釋， 就會對已有的程式能夠穩穩當當運行起來抱有一種崇敬之情。 程式的邏輯太多，

所以很多時候發現設計模式用不上了， 因為滿足業務優先， 你做了大的改動， 代碼看起來優美了， 業務肯定就崩了， 我確實這麼嘗試過， 當時的場景也確實很尷尬， 所以我們習慣在程式裡面打代碼補丁， 這是我自造的一個詞， 意思就是代碼裡的補丁， 比如邏輯判斷的部分， 發現某個場景會觸發一些異常， 所以我在邏輯判斷的時候塞進去一個if判斷， 然後中間來控制一下這個變數的變化， 然後又很糾結的重新定義一個變數。 業務是跑起來了， 後來的人可就慘了， 我記得當時看一個類的方法， 差不多有上千行， 我看邏輯已經快懵了。 然後小心翼翼的在裡面添加一堆邏輯， 為了不和其他人的邏輯干擾， 我自己抽取了一個段代碼。

程式開始調試了， 還算勉強通過， 結果我旁邊的同事有些奔潰了， 笨重的伺服器跑起來了， 發現代碼執行邏輯的部分還沒有運行到他寫的代碼就奔潰了， 可以想像那種排隊的感覺有多無奈。

如果代碼層面的問題得以解決， 或者說能行得通， 那麼前端部分的糾結也蠻多， 記得比較有意思的一個案例就是當時開發的一個網上營業廳的頁面， 我們測試了IE的低版本還有firefox,chrome等， 顯示都是正常的， 當時比較新的流覽器版本是IE8,結果客戶回饋一上線發現頁面的字體顯示有些錯亂， 細細瞭解了下問題， 發現原來是客戶的領導的電腦上是這樣的， 他的電腦流覽器版本比較新， 而其他人還是習慣用相對較低的一個版本，

都沒有問題， 碰到這種情況怎麼辦， 改吧， 首先要滿足第一層的需求。 當時找公司同事來提交補丁改已經來不及了， 我現場打開電腦， 查看代碼， 硬生生的調了一版， 想起來除了無助就是無奈。

慢慢的， 也確實有了一些經驗， 所以會時不時的看看別人寫的代碼， 我覺得基本有兩種狀態。 一種是看了之後有種驚喜的感覺， 要不是裡面的代碼風格很清新， 代碼看起來就好比一個裝飾品一般， 低調奢華， 要不是代碼的邏輯非常縝密， 很多你沒想到的點， 這裡都考慮到了， 設計中的冪等性在這裡是完美的體現。 或者是代碼的精道， 原來的一小段邏輯判斷， 可能人家一行代碼就搞定了， 這種情況立馬打開電腦默默的模仿一些， 記下這個絕技， 這是好的一方面，當然還有一種情況，也不一定是極端，可能是大多數人都會犯的錯誤，程式就好比一個喝醉的人一樣，只考慮正常的邏輯，不正常的邏輯說明邏輯不正常，不需要考慮，當然我寫的很多代碼也確實是這樣，從小步快走，快速反覆運算的方式來說，這種方法是對的，代碼代碼不夠充實和健壯，能夠一氣呵成是意料之外的。

還有一個痛點就是經常會看著看著自己就糾結起來，為什麼要這麼實現呢，明明有更好的方法，可能在某個時間看看代碼，終於能夠體會寫腳本的人的痛處了，原來是有這麼一個坎，只能不得已為之，當然這種情況確實很少，一方面能耐下心來認真看完代碼還不如自己去好好實現一版。所以你會在行業裡看到很多類似的情況。

對我來說，代碼的意義本身就是服務于業務，作為一個服務的載體，代碼問題肯定無處不在，一味的追求代碼的完美在工程實踐中還是很可能會做妥協，而不管不顧方法論，只是堆砌代碼也是萬萬不可的，從某種程度上來說，代碼的邏輯清晰和設計上好的風格可以保證程式的健壯性，當然還有一點很重要就是最起碼得有一些代碼的解釋。

這是好的一方面，當然還有一種情況，也不一定是極端，可能是大多數人都會犯的錯誤，程式就好比一個喝醉的人一樣，只考慮正常的邏輯，不正常的邏輯說明邏輯不正常，不需要考慮，當然我寫的很多代碼也確實是這樣，從小步快走，快速反覆運算的方式來說，這種方法是對的，代碼代碼不夠充實和健壯，能夠一氣呵成是意料之外的。

還有一個痛點就是經常會看著看著自己就糾結起來，為什麼要這麼實現呢，明明有更好的方法，可能在某個時間看看代碼，終於能夠體會寫腳本的人的痛處了，原來是有這麼一個坎，只能不得已為之，當然這種情況確實很少，一方面能耐下心來認真看完代碼還不如自己去好好實現一版。所以你會在行業裡看到很多類似的情況。

對我來說，代碼的意義本身就是服務于業務，作為一個服務的載體，代碼問題肯定無處不在，一味的追求代碼的完美在工程實踐中還是很可能會做妥協，而不管不顧方法論，只是堆砌代碼也是萬萬不可的，從某種程度上來說，代碼的邏輯清晰和設計上好的風格可以保證程式的健壯性，當然還有一點很重要就是最起碼得有一些代碼的解釋。