工作裡面可能會沉澱下來很多的東西，比如文件，程式碼/指令碼，或者圖片，甚至你留下的趣事或者“案底”。
對於修改程式碼，我很多年前就體驗過一次，是修改自己寫的程式碼，記得剛畢業的時候寫了一個小的專案，是使用Java的Swing技術實現的，能夠對一個表格做資料的增刪改查。當時寫得真是昏天暗地，坐地鐵回家的時候都有一種頭重腳輕的感覺。這僅僅是一個開發前的純技術練習而已。寫了一週的樣子，把程式碼推給自己的導師來看，導師從各種角度提出了很多的問題，有的問題確實是硬傷，有的問題感覺是理解的角度不同，所以帶著半推半就的態度開始第二版，第二版很快就迭代出來了，完成的這種感覺就跟你考完試一樣，再也不想看自己寫的程式碼了。第二次的時候，導師從設計模式的角度給我提出了一些建議，然後我開始重新審視自己寫的程式碼，改一改，調一調，看起來是那麼回事了，依稀記得當時使用的是命令模式。這一次自己感覺確實是差不多了，從程式碼的命名規範和“優美”程度來看，感覺已經很難挑出問題了，導師看了下，整體給予了肯定，然後把自己的程式碼發給我，互相參考學習。這個時候換了一個全新的角度，可以發現很多地方自己還是有待改進的地方。程式開發就是如此，總是有很多待改進的地方。
當然我也碰到了一些比較尷尬的情況，比如我們之前開發一個相當複雜的業務，一個類竟然已經被上百個人改過了，看著一條條的程式碼改動標記和註釋，就會對已有的程式能夠穩穩當當執行起來抱有一種崇敬之情。程式的邏輯太多，所以很多時候發現設計模式用不上了，因為滿足業務優先，你做了大的改動，程式碼看起來優美了，業務肯定就崩了，我確實這麼嘗試過，當時的場景也確實很尷尬，所以我們習慣在程式裡面打程式碼補丁，這是我自造的一個詞，意思就是程式碼裡的補丁，比如邏輯判斷的部分，發現某個場景會觸發一些異常，所以我在邏輯判斷的時候塞進去一個if判斷，然後中間來控制一下這個變數的變化，然後又很糾結的重新定義一個變數。業務是跑起來了，後來的人可就慘了，我記得當時看一個類的方法，差不多有上千行，我看邏輯已經快懵了。然後小心翼翼的在裡面新增一堆邏輯，為了不和其他人的邏輯干擾，我自己抽取了一個段程式碼。
程式開始除錯了，還算勉強通過，結果我旁邊的同事有些奔潰了，笨重的伺服器跑起來了，發現程式碼執行邏輯的部分還沒有執行到他寫的程式碼就奔潰了，可以想象那種排隊的感覺有多無奈。
如果程式碼層面的問題得以解決，或者說能行得通，那麼前端部分的糾結也蠻多，記得比較有意思的一個案例就是當時開發的一個網上營業廳的頁面，我們測試了IE的低版本還有firefox,chrome等，顯示都是正常的，當時比較新的瀏覽器版本是IE8,結果客戶反饋一上線發現頁面的字型顯示有些錯亂，細細瞭解了下問題，發現原來是客戶的領導的電腦上是這樣的，他的電腦瀏覽器版本比較新，而其他人還是習慣用相對較低的一個版本，都沒有問題，碰到這種情況怎麼辦，改吧，首先要滿足第一層的需求。當時找公司同事來提交補丁改已經來不及了，我現場開啟電腦，檢視程式碼，硬生生的調了一版，想起來除了無助就是無奈。
慢慢的，也確實有了一些經驗，所以會時不時的看看別人寫的程式碼，我覺得基本有兩種狀態。一種是看了之後有種驚喜的感覺，要不是裡面的程式碼風格很清新，程式碼看起來就好比一個裝飾品一般，低調奢華，要不是程式碼的邏輯非常縝密，很多你沒想到的點，這裡都考慮到了，設計中的冪等性在這裡是完美的體現。或者是程式碼的精道，原來的一小段邏輯判斷，可能人家一行程式碼就搞定了，這種情況立馬開啟電腦默默的模仿一些，記下這個絕技，這是好的一方面，當然還有一種情況，也不一定是極端，可能是大多數人都會犯的錯誤，程式就好比一個喝醉的人一樣，只考慮正常的邏輯，不正常的邏輯說明邏輯不正常，不需要考慮，當然我寫的很多程式碼也確實是這樣，從小步快走，快速迭代的方式來說，這種方法是對的，程式碼程式碼不夠充實和健壯，能夠一氣呵成是意料之外的。
還有一個痛點就是經常會看著看著自己就糾結起來，為什麼要這麼實現呢，明明有更好的方法，可能在某個時間看看程式碼，終於能夠體會寫指令碼的人的痛處了，原來是有這麼一個坎，只能不得已為之，當然這種情況確實很少，一方面能耐下心來認真看完程式碼還不如自己去好好實現一版。所以你會在行業裡看到很多類似的情況。
對我來說，程式碼的意義本身就是服務於業務，作為一個服務的載體，程式碼問題肯定無處不在，一味的追求程式碼的完美在工程實踐中還是很可能會做妥協，而不管不顧方法論，只是堆砌程式碼也是萬萬不可的，從某種程度上來說，程式碼的邏輯清晰和設計上好的風格可以保證程式的健壯性，當然還有一點很重要就是最起碼得有一些程式碼的解釋。