2023年1
月26日
13:52
2023年。
考古隊挖出一塊硬碟
，記錄這
2023年r
公司的**
。他們從
redgate
公司的檔案櫃內找到
reflector
反向出來了這些源
**，發現古人已經在編碼方面注意標準化並且使用工具自動化這個過程。大家驚呼，
哇咦，古人已經很聰明了。
我們的重構流程推行了兩年。經過一段時間對重構流程的梳理、慢慢的建立和拋棄一系列的思想，然後不斷的簡化、淬鍊、抽象，逐步的形成到具體的實踐方法。本文就是我的簡要的思考過程。我希望以此幫助大家了解我們在高質量編碼方面的價值觀，從而更好的實踐新的流程。
重構是有效果的。我從這個過程中得到幾點看法：
1.對產品。經過有意識的、有節奏的**重構，**往往變得更加漂亮；產品也變得比較容易維護。維護**的痛苦有所減輕。 2.
對個人。部分人養成了重構的習慣，知道一些常用的重構手法，知道如何利用工具來做安全的、快速的重構。code reviewer 本身的進步是最大的。
問題也不少。1.
養成重構的習慣的人不多。很多個人的成長看得出來是非常緩慢的，亦步亦趨的。技巧層面的checkerror得到了廣泛的應用，而重構技術方面（系統而全面的）並沒有得到重視。有時候我也需要問問自己：寫出好**的能力難道真的只有少部分人才能夠具備嗎？ 2.
**一旦寫成，即使採用系統的重構方法，代價也還是會很大。 3.
低質量編碼的習慣養成了，就更加難以清除。 4.
code reviewer現在是非常缺乏的。
當前的重構流程好像有些依賴性。這兩年的做法一直是：大家寫**，我來做審查，指出方法，然後討論修改。這樣的做法就像是上游進行汙染、下游加了乙個汙水處理廠一樣——並且編碼者總是不能建立上游治汙的意識——甚至支援大家的新看法：「治汙是汙水處理廠的事情」。於是當**大量的複製，功能大量的增加、組內成員變多後，以「乙個人的力量」來發現問題，提出重構的方案，然後修改的這樣的模式是很難走下去的。培訓做了很多次，聽就聽了，真正動手的是比較少的。個案的解決乙個個的重構問題，然後希望大家的**意識得以提公升是非常困難的，最後依然是時間問題，大家在排出日程來做這個工作方面總是覺得困難。學習和實踐重構是程式設計師的責任。而現在這一點是如此的困難，以至於我們好像是乙個進退維谷的境地！
繼續，闖出新天地。清理下這些年亂麻般的思路，把它變成可以實踐的套路，就是一條：
code diff。
做法的關鍵就是
code diff daily
（每日**差別比較）。要點是定期、流程化、輪值。
1.定期。每天下班前15分鐘就來做。專案組自己有**高質量的意識，信仰高質量**的對產品和團隊的價值,建立開放坦誠的溝通環境，並且通過code diff把理念落實到每一天。 2.
流程化。大家圍在一起，通常是面對投影儀，有時候也是看一台電腦。然後，開啟svn log，把今天提交的**修改一一比較，檢視**問題，提出改進意見。開放環境的建立首先需要管理服務(management as service )。 3.
輪值。code review發起人是輪值的。管理者應該為程式設計師提供更加友善、健康、正面的溝通環境。整個環境不但可以解決**問題，還能夠增進溝通，幫助大家說出想說的，讓大家接受可能是難以接受並且習以為常。一句話，把問題擺在桌面上。 4.
盡可能採用自動化
流程就是這樣，通過流程讓大家更加開放的進行高質量編碼。這是乙個基礎，乙個管理服務。但是僅僅有了流程還是不夠的。大家唯有理解了我們的價值觀，才能讓大家得到更多的益處；否則必然是簡單的亦步亦趨、有樣學樣。這是我不想看到的。
克服乙個拖後腿的「輕浮」想法。有人認為：「指出**的問題是很容易的事情，人人都可以做到看到別人**的問題」。這樣的觀點在我看來是非常輕浮的。重構僅僅在《重構》一書內就有上百的方法，大的原則是消除重複和容易，職責分離等等，小的步驟就非常的多了，遇到乙個具體問題，運用這麼多的方法，首要是投入和學習、實踐，其次是靈活組合多種方法，小步的、安全的達到重構的效果。這些年來，國外的敏捷諮詢機構進入中國的越來越多，比如
thoughtworks
，odd-e
，也有越來越多的公司採用了敏捷，比如
activenetwork
，華為。而敏捷的乙個核心實踐就是重構，是諮詢公司的主要收入源。而從我接觸的一家諮詢公司的評價上看，他們的很多客戶做的並不好。可見，把重構視為比較簡單的事情是過於輕浮的看法。感覺到是一回事，瓜分豆析的執行是另一回事。以前就常常有人說，「你看這個**真的太…」
,然而讓他找出方法，他總是說，「這簡直不可能，要考慮穩定，考慮進度
...」。切。千人諾諾，不如一士諤諤。拿出妥善的、成套路的方法，並且一以貫之，才是這個王道。
觀察高效程式設計師的做法，逐步厭棄低質量**。我發現越是編碼質量高的程式設計師，越是自然的排斥不良的編碼。和他們的交流**，常常發現他們會很憤恨的嘟嘟囔囔：「你看嘛，幹嘛囉嗦，換個方法多簡潔；這裡的寫法根本沒有必要；還有這裡，命名和大小寫都成問題」。因為厭棄，才會逼著自己寫出優秀的**來，逐步養成新的習慣，「下筆如有神」，自然的寫出漂亮的編碼來。而整個團隊的所有人都應該向這個信仰高質量**的程式設計師一樣，信仰高質量**的對產品和團隊的價值，相信自己在今天的投入會在未來得到回報。回報可能包括產品的穩定性、可維護性，個人水平的提公升，產品的競爭力提公升，
balabala。
程式設計師的心理過程需要關注。很多程式設計師在遇到其他人編寫的編碼時，也會有「做好我自己就行「的鴕鳥思想。看到不好的**，常常不好意思直接的指出來——怕傷了面子，也怕被拒絕。理解我們的價值觀，就是為了釋放程式設計師的能力，讓大家可以自由的、不怕爭論的提出自己的做法、精煉自己的實踐。
從源頭狙擊。以往的做法都是編碼後檢查，然後提出修改。存在更好的工具來幫助
code reviewer
從程式設計師一開始編碼就強制規範。如
tfs可以在提交**前自動檢查
naming
規範，複雜度。再比如
teamcity
可以查詢重複**。
reviewer
可以不必花費太多時間查驗基本**規範，做更有價值的架構分析和重構。程式設計師可以清晰的看到規範的存在，如同編譯錯誤一樣很容易定位這一類問題。
**像水一樣，但是你無法保證你就是下游或者上游——他們是相關的，任何人不能保證今天某人寫的**，不會明天流到你這裡來，而你也不能保證你的**某天不會流到某人那裡。所以，建立乙個開放坦誠的環境是必須的。建立乙個高質量的價值觀，並通過
code diff
分解到每一天是必要的。
詳細的做法，請看
code diff. ，我們做了。
@1000copy
，這是我的微博。
暗號是：讓
code
能夠diff
，讓tech
也可以diff
後端測試技巧code diff
為什麼要做code diff 工具 上傳失敗.image 876a3c 1610853267107 上傳失敗.image 88a137 1610853267107 上傳失敗.image 6581c8 1610853267107 上傳失敗.image 4a605c 1610853267107 做cod...
如何code diff 工具篇
前面兩篇文章聊到為什麼code diff 在哪個環節執行，接下來咱們來聊一聊code diff使用到的工具。經常使用的工具有 git beyondcompare intelij idea 簡稱idea gitlab github等。下面介紹一下這幾個工具如何使用 本文使用的工具是以j a語言code...
引入外部css CSS的引入方式筆記
css一共有五種引用方式。1 直接在body h1等標籤裡面寫標籤或者屬性，這種叫做行內式，不過這種基本已經廢棄了 body的背景顏色為紅色 hi標籤居中，並且顏色為紅色 2 在body h1等標籤裡面寫上style，這種叫做style屬性，把樣式寫在標籤上，也叫所style內聯樣式，這種方式會導致...