小酌重構系列[25]——終篇總結

時間 2019-11-09

標籤小酌系列終篇總結简体版

原文原文鏈接

前言

《小酌重構系列》是我在博客園的第一個系列文章，這個系列歷時一個多月終於完成了。
完成這個系列後，內心有一些感慨想和你們分享一下。html

初衷

寫這個系列的初衷是爲了團隊培訓，爲何要作這個培訓呢？
是由於在項目的開發過程當中，咱們遭遇了一些「代碼的痛苦」。程序員

代碼的痛苦

寫代碼是程序員的基本工做，但寫出好的代碼不是一件容易的事情。
寫不出好的代碼，就可能產生痛苦。學習

代碼的痛苦包含哪些方面呢？編碼

通常來講，包括可讀性較差、不夠簡潔、缺少可擴展性、缺少可維護性等等。
簡單地說，就是代碼質量不高。code

「代碼的痛苦」也是開發者的痛苦，低下的代碼質量可能會下降系統的穩定性。
系統最終是要交付於客戶的，系統若是不穩定，客戶用的時候會痛苦會抱怨，維護時你不只要忍受客戶的抱怨，還要痛苦地去維護「代碼的痛苦」。htm

痛苦的誘因

這些痛苦並不是是無根之源，痛苦的產生是多方面的，不只和編碼有關，也和管理脫不開關係。
在這裏，我僅從編碼角度去分析這些痛苦的緣由。blog

編碼風格的差別

在項目開始前，咱們是約定了一些編碼風格和規範的。
但實際作下來，因爲各成員的編碼風格差別，使得有些代碼看起來「五花八門」。
爲了統一項目的代碼風格，一些成員不得不返工去修改代碼，而且返工不止一次。ip

編碼習慣的不一樣

每一個人已經造成了必定的思惟方式和編碼習慣，即便是一些很差的習慣。
這使得一些曾經發生過的問題，在後續的開發過程當中仍然反覆地發生。資源

編碼意識的匱乏

有些成員專一於功能開發，對代碼的規範、整潔度和質量看得較輕，也沒有意識去思考如何寫出優秀的代碼。
固然這也和編碼習慣有關，習慣性的不去思考代碼質量的問題。開發

代碼審查的匱乏

限於時間和資源問題，在項目中咱們只能花費較少的時間來進行code review。
雖然每次code review能發現一些問題，但每次代碼問題的解決方式都只到表面，內裏沒有獲得根本性地解決，這也是一些問題反覆發生的緣由之一。

指望的目標

代碼的痛苦就比如一個慢性疾病，如今咱們已經知道了本身得的是什麼病，以及病發的緣由。
接下來要作的就是如何科學有效地治療這個疾病，讓本身漸漸康復起來。
因而在團中，我就作了這個培訓，這個培訓主要有如下幾個指望目標：

提升團隊成員的編碼質量
促使團隊成員造成統一的編碼風格
提升團隊成員的編碼意識，養成思考和自主code review的習慣
但願最終的交付物不只能知足客戶的需求，還具有良好的維護性

僅通過一時的培訓，是不可以解決代碼的痛苦的，因而咱們採起了培訓+實踐的方式來解決痛苦。
在通過大約2周的培訓，以及近2個月的反覆實踐後，團隊成員總體的代碼質量已經有所提升。
關鍵的是，一些缺少意識的團隊成員已經產生了自主思考的意識，知道去思考代碼的一些細節了。

關於這個系列

草稿和大綱

在開始這個系列以前，我使用Onenote基本打好了全部的草稿，這些草稿的內容大可能是一些文字和圖示，代碼則單獨地放在VS解決方案中。
因此在開始正式寫第一篇文章時，我就列出了整個系列的大綱。
草稿終歸是草稿，真正動鍵盤時，仍是發現草稿中有不少瑕疵存在，以至於草稿中的文字我基本沒有用到。
草稿並不是沒有做用，每次我都會站在第三者的角度去審視和思考草稿的內容，它指引我向更深處去思考一些問題。
限於本人淺薄的知識和窮乏的描述能力，有些深刻思考的內容沒能在文章中表達出來。

計劃和堅持

若是隻有一天的計劃，讓本身按時作完這一天的事情，我相信絕大多數人都可以作到。
生活和工做每一天都在繼續，我寫這個系列，是想讓本身每一天都能按計劃進行下去，更是想讓本身長期地堅持下去。

在開始這個系列時，我樂觀地計劃天天應該完成一篇。
誠實地講，我知道本身不可能100%的完成這個計劃，能有80%就不錯了。
由於天天都會有不一樣的事情出現，有些事情你是不得不去優先處理的，其餘的事情極可能致使完成這件事情的週期被拉長。
定這麼個計劃，是爲了時刻督促本身要堅持完成這個系列，不要半途而廢。
不少事情要作就作完，作一半還不如不作。

我我的比較欣慰的是，雖然中間由於假期暫停了將近10天，但假期一結束後，我當即接續完成了最後的幾篇文章。

收穫

這個系列帶給個人收穫主要有兩點：

寫文章是但願能教一些東西，寫文章的過程也是再思考再學習的過程，就像《暗時間》裏所說的「教是最好的學」。
這個系列完成後，不只能夠分享一些知識，也使得本身對重構的認識又上升了一個臺階。
本人的文字描述能力一直比較欠缺，特別是文字佔了較大篇幅的文章，這樣的文章更考究做者的思路和邏輯。
經過這個系列自我感受文字能力有所提高，在團隊的一些會議中，我的的現場描述能力也有所提高。