以後要接觸更多代碼管理的知識——2015踩坑有感

前言

學習是沒有止境的，管理代碼的能力也永遠須要提升。

前幾個月還以爲R語言，業務上要用的都學得七七八八了呢，這幾個月在自家部門吭哧吭哧搞報表自動化時，各個坑一踩一個準，才明白寫代碼，懂得一點語言特性當然重要，弄一套科學地管理代碼的方法，倒是勢在必行。

所以在這裏總結一下這幾個月來我踩過的種種坑，以及以後在查閱種種大神的經驗，以及學軟件工程這門課時看到的一些比較穩當的方法，算是這幾個月的一個總結。2016年的時候，真的要多學學如何科學地管理代碼，科學開發

請注意，由於我屬於跨專業半路出家寫代碼，剛剛入門剛剛入門，軟件工程的課也纔上到一半，確定有不少概念沒有釐清，下面講的要麼過小白要麼有錯漏，歡迎各位指點方向，多多交流多多交流

 吐槽一下踩過的坑

不在博客園上閱讀時纔會看到的，這篇博文歸博客園@尾巴AR http://www.cnblogs.com/weibaar全部

僅保證在博客園博客上的排版乾淨利索還有代碼塊與圖片正確顯示，他站轉載請保留做者信息尊重版權啊

我自7月左右開始，逐個把部門的報表需求用R語言自動化以來，代碼越積越多，需求也逐漸累積，就開始不斷踩坑，

（跟這段業務需求有些關係的博文見 1 2 3 ）

這些坑總結一下大概有如下幾種：

一、報表需求愈來愈複雜，邏輯自己就很複雜了，而後要作各類處理，致使代碼越寫越長，還很難定位說寫到哪裏，丟三落四

二、好不容易寫好代碼測試好運行，報表自動化正確了，結果業務跳出來講，要加這個圖那個圖，加這個數據那個數據，回去改的時候，發現代碼到處牽連，每每改一個地方，就要跟着改N個地方，還容易出錯漏改，維護困難

三、發現有些報表用的代碼是重複的，譬如一樣讀取同一個數據，作一樣的處理，可是由於代碼經常維護，一樣的步驟出現了N個版本遍及在N個程序裏，容易出錯

四、隨着對編程語言的理解，漸漸有了更高效的方法，回首過去，以爲有些地方邏輯很混亂，效率低，可是牽連過深，不敢改

總之就是，發現過去埋頭寫代碼行不通了，代碼行數上了必定的量，修改量也上去了，在維護方面產生了更多問題。

而後就糾結啊想一想想，先本身想了不少土方法，後來按着學習進度接觸了一下軟件工程，才發現這些問題早已經被人碰過了，而後還有了系統的解決方法，因此在這裏列一下目前我以爲比較有用，值得進一步研究和實踐的理念：

要用工程管理的思惟去管理軟件開發，在前期儘量劃分清楚需求，中間開發按模塊劃分，並設置好統一的接口，區分好易變與不易變的業務，作好基礎分析的輪子工程，保證重複利用。

 接下來細講一下：

一、要用工程管理的思惟去管理軟件開發

 在學堂在線-軟件工程課上有說起道，軟件開發複雜的而又多變。由於這個複雜性，纔會有人引進工程的概念來管理軟件開發，因此若是編程時有這個工程的底，嚴格掌控一下進度，學一些方法的話，能夠得到事半功倍的效果。

二、要在前期研究需求，並拆分好清晰的功能塊，以便逐個擊破。

研究好需求的話，需求確認，返工的概率就不大，並且方向明確，不容易在分析分析過程當中迷失一切。

而後需求確認，就能夠把程序的大致架構給設計出來，劃分好功能塊了。而後一來，在組織代碼時，能夠按功能塊分區，易於定位長代碼（譬如分不一樣的腳本，或者用{}等括起來，用notepad++打開時，能夠直接把這一部分的代碼塊按層次摺疊）

其次呢，功能塊拆分清楚了，就能夠羅列一下它開發的難度啊關聯度啊，排個進度表，有空時就專門盯着裏面一塊模塊作，一次就解決一個問題，直接，方便，輕巧。

三、劃分功能塊後，經過流程圖結構圖的方式，把大的功能塊鏈接起來，統一接口

在研究需求，劃分大的功能塊以後，整個程序的大致流程圖與結構圖也基本能夠畫出來了。

舉 例來講，用R作一個有4-5個源數據的自動化報表時，能夠把源數據一、二、三、4等都羅列在讀取源數據這個功能下，再把他們之間的關係、篩選條件、處理方 法等，都畫在流程圖上。把源數據、中間步驟、最終結果在編程前都羅列上去，這樣這個自動化報表的流程是能夠複製的，並且開發和優化時，就能夠快速定位代碼 位置，能夠作小範圍的迭代開發，一步一步把複雜系統完善掉，避免寫着寫着代碼就迷失了方向。

不在博客園上閱讀時纔會看到的，這篇博文歸博客園@尾巴AR http://www.cnblogs.com/weibaar全部

僅保證在博客園博客上的排版乾淨利索還有代碼塊與圖片正確顯示，他站轉載請保留做者信息尊重版權啊

而 這個還有一個好處，就是流程圖能夠清晰看到功能塊之間的關係。那咱們就能夠在寫各模塊或函數以前，先釐清它們之間共同的一個接口。以免說，修改某部分代 碼，而後在不知情的時候，影響了後續全部代碼的開發。保證每一塊之間都是相互獨立，關係明朗的，這個能夠減輕不少後續的編程工做。

請看下圖爲一個簡單的示例：

四、注意區分易變與不易變的需求，在處理業務時，提煉業務，積累代碼庫。

有據說一個觀點，一個好的程序員，每每能應用自如不少通用的功能模塊。在作系統開發時，他們每每不是從零開始編程，而是把一些通用的模塊堆積木同樣堆到系統上，再釐清各方面的關係與兼容性，實現一個快速開發的過程。

而事實上，在業務中，有些需求是經常出現的。

譬 如說我去作R語言的自動化報表，一個部門裏經常使用的源數據，每每也就那麼幾類。我徹底能夠專門寫一個小的模塊去處理一類的源數據，而後每次作分析時，就把相 應的讀取數據模塊取出來，直接引用到新的分析裏。並對讀取數據的模塊作統一的管理和調度，保證版本統一。如此往後若是要作什麼分析，就不用從另外一個程序腳 本里把代碼複製過來，而是修改這個讀取數據的流程，保證其有相應的分類，這樣，修改一處，或者哪一個出BUG ，咱們只要處理一個流程、一個腳本文件就能夠了，修改的是輪子，最後積累下來的不是一個又一個獨立的程序，而是能夠反覆使用的輪子

這樣作的話，隨着在業務上代碼寫得越多，遇到重複的需求越多，咱們的開發效率也就越快，這可使咱們更專一於新功能的實現，總體系統的設置，以及程序之間的差錯等等。最終達到所謂「越老越吃香」的知識積累。

而作到以上這些，須要咱們對開發時易變與不易變的需求進行一個精煉與提取，要及時意識到，什麼是反覆要作的，什麼是偶爾要作的。把複雜的業務拆分，精簡，提煉，看透事務本質。

資料參考

 

回首上文，感受有些地方我寫的還不是特別清楚。畢竟軟件工程等仍是新學，並且目前的代碼量尚未大到須要協同合做的時候。

而隨着軟件，編程規模越大，其管理的複雜性也就越高，像我只是本身給本身寫些幾千行的代碼，就已經陷入管理這些代碼的困境良久。有時真的很難想象，在企業級的軟件開發過程當中，由幾百號人一塊兒維護一個代碼庫，還不能讓它崩潰且時時有更新。

相信隨着資歷的增長，以及對世面見識的擴大，管理整個過程的複雜性，會成爲咱們必需要邁過的一道檻。

感謝迷茫時期參考的各類資料，並不徹底羅列，想起來就追加：

學堂在線-軟件工程

知乎問答

有哪些老鳥程序員知道而新手不知道的小技巧

維護一個五六百行的程序就已經力不從心了怎麼辦？

業務代碼相關

程序員新人怎樣在複雜代碼中找 bug？

在最後，附上本身的blog 博客總目錄，博客園@尾巴AR：http://www.cnblogs.com/weibaar/p/4507801.html

以及最近也在按2016年計劃  嘗試運營一下微信公衆號，微信搜「尾巴說數」便可，暫時剛起步還沒什麼內容，計劃博客裏放一些更有技術含量的博文，公衆號裏雜文多一點，有興趣多交流。

啊哈哈2016也要堅持每個月至少一博。。。