論軟件工程師的自我修養：角色、重構與質量

摘要：在本文中，咱們將探討軟件開發過程當中關於角色、重構和質量的問題。

「天天都會有更多的技術發生，每家公司都在互聯網上，每家公司都將成爲一家科技公司。」OKTA首席運營官兼聯合創始人Frederic Kerrest說道，由於他們必須找出使用該軟件的更好方法。軟件不只成爲了一個必需品，更成爲了一個競爭優點。由於衆多公司圍繞軟件而競爭，軟件開發相關的事宜顯得愈加重要。開發軟件的人——軟件工程師正顯得愈加重要。

「對於知識，要求知若渴；對於本身，要虛懷若谷。」優秀的軟件工程師必定是在軟件開發的道路上前行者。自學是其成長的一個重要手段，在自學的過程當中，咱們是能夠經過考試的方式來收斂思緒，督促本身學習，從而提升本身的基本素質。誠然，原則和模式是軟件工程質量的基石。但技術是工具, 是爲人服務的，而不是相反的。咱們不能爲了迎合某種技術而束手束腳，讓本身特別難受。與此同時，要讓本身的能力發揮到極致，良好的心境是必需要有的，由於軟件工程中的一個核心因素是人的因素。

誠然，在軟件開發過程當中，咱們不只要將自身內功修煉好，更應該 「用產品說話」。那麼，在這個過程當中，咱們該如何保證開發的質量呢？在開發的過程當中如何專一於本身擅長的事情呢？在本文中，咱們將探討軟件開發過程當中關於角色、重構和質量的問題。

角色

咱們常常提一句話：革命工做只有分工不一樣，沒有高低貴賤之分。這裏的分工其實就是角色的劃分。角色劃分是爲了讓個體承擔的工做量最小化，從而能夠把咱們從繁文縟節中解放出來，專一於本身擅長的事情。那麼，在軟件工程當中，這樣的理念應該如何貫徹呢？

軟件工做裏面的髒活兒、累活兒通常是指技術老舊而不得不維護的一些工做。還有一些重複性強的工做也被稱爲髒活兒、累活兒。

對於這種活兒，通常工程師都想推脫掉。主要緣由是認爲作這類活兒技術提升的空間很小，再加上技術陳舊，這些技巧學會了之後也用不上，同時也比較枯燥。

這類工做的工程師通常是指派的。須要對相關的工程師進行一些必要的技術培訓或者直接招收懂得相關技術的工程師加入工做。

效率和價值主要體如今幫助客戶解決現有軟件系統中的問題，或者添加新的功能。客戶可能不多願意購買一套嶄新的系統，由於價格相對比較高，因此他們寧願少花點錢去作些修修補補的工做，可以解決燃眉之急就能夠了。

運維工做的價值是把已經開發出來的組件和系統集成起來統一的工做。是推出面向用戶的軟件系統產品的重要一步。我不認爲是邊角料的活兒。

運維相關的工做越簡潔越清晰越好。這部分相關的文檔通常是read me markdown的形式存放在軟件系統的repo中。經過查看這些文檔，應該能夠自行部署整套系統。

系統部署通常會分幾種類別，開發模式，qa模式，staging模式和生產模式。

業界對於軟件開發過程當中的角色有不一樣的理解和見解。筆者觀點以下:

1.項目產品經理負責業務需求的處理，負責跟客戶與開發團隊打交道。

2.項目開發組長必定是全棧，須要統籌規劃，與項目經理一塊兒探討需求分析，與開發組成員一塊兒探討開發設計，任務分配與開發實現。

3.前端工程師負責網絡頁面程序開發，手機端應用開發，桌面端應用開發等等。

4.後端工程師負責API設計與開發, 數據分析處理與消息推送。

5.運維工程師負責部署環境的搭建與看護。

6.針對具體的業務需求，還會有更細分的角色類別，好比說大數據工程師，算法工程師，AI工程師，機器學習工程，深度學習工程師, 中間件工程師。

7.測試工程師負責系統集成後的業務需求案例測試。這一部分的輸入跟開發團隊的輸入是同樣的，都是用戶的需求。輸出則是需求案例對應的測試報告。而開發團隊的輸出就是整個軟件系統。

重構

爲何咱們須要對代碼和設計進行重構？主要是由於咱們發現了更好的作法，如效率更高，更容易維護等等。

簡單的代碼重構咱們都比較熟悉，好比說你經過工具就能夠作一些整理。

通常來講，重構是爲了解決複雜度的問題。

如今比較頭疼的一個話題就是對老產品的重構，一些老產品涉及到上千萬行，上億行的代碼。

關於老產品整改的問題。若是隻是縫縫補補的話，可能起不到化繁爲簡的目的。其實作相似這種工做的話，有一個比較可行的方案。就是把現有的產品當作一個成型系統也就是現有運行的產品，不要作大的改動，頂多就是修改bug。

而後以這些成型的系統爲基準，去寫新的系統。至關於參照一個大的白盒就寫一個小的白盒，這樣新的小的白盒質量上確定比大的白盒性能上要有優點。

這樣子循序漸進去作的話，就會比較靠譜。

有朋友會說上面的作法是重寫，字面意義上沒錯的。

實際上不矛盾。區別就是重構的方式應該從下往上仍是從上往下。好比說咱們如今大部分的重構都理解爲從下往上來作。也就是感受這個文件裏頭有壞代碼的味道，而後就改這個文件，這樣作是沒有問題的。前提是這項工做的上下文比較單純，無技術債務。

不少狀況不是如此幸運的，好比如今有些人遇到的問題，就是發現上下文不是很清晰，這個代碼爲何要這麼寫？爲何一個文件有1萬行或者3萬行，這個前因後果不是很清楚。

這個時候可能就須要從整個子模塊來進行一個自上而下的分析。梳理出這個子模塊的功能需求是怎樣的，須要有多少個公共接口？內部公共接口的實現方式是否是應該像目前這樣的？

一個文件可以寫成1萬行或者3萬行，確定是有必定歷史緣由的，絕大程度是因爲全局把握的編程能力不夠形成的。

像這種狀況，若是從這個文件自己去作重構的話，難度很是之大，可是若是從上往下，從模塊的整個設計角度來作重構的話，可能就容易一些。

對於這樣的龐然大物，最好的辦法就是分而治之。首先要肯定系統的功能邏輯點，針對這些邏輯點，要編排好對應的檢測點，也就是說等咱們完成了重構之後，咱們得確保咱們的重構是沒有問題的，這些檢測點就是作這個的，咱們能夠理解成集成類的測試。

這些集成類的測試必定要確保能夠在當前未重構以前的系統上正常運行。

有了這個設施之後，咱們就能夠開展咱們的重構工做。重構的方法有不少，好比採用比較好的工具，函數和變量的命名改變，調用方式的改變等等。這些是在現有代碼的基礎上進行的重構。這裏咱們重點說一下重寫的方式來實現重構。所謂重寫呢，就是另外開闢一套代碼底座。甚至能夠選用不一樣的編程語言。

這種狀況下重構首先要重用已有的業務邏輯，實現針對業務邏輯集成測試100%的經過率。

具體無論採用哪一種方式都要一個模塊一個模塊的進行推動。驗證完成一個是一個，千萬不能急於求成，試圖一次性的把某些問題搞定。若是出現不少次失敗，有可能會消磨掉你的自信心。因此必定要一點一點的往前推動，始終是在進步當中。採用了這種方式之後，無論當前的系統有多麼的龐大，你只要堅持作下去，就必定可以把重構工做完全完成。

這個時候須要作的具體步驟能夠參考以下:

1. 根據功能需求定義公共接口。

2. 根據公共接口寫出測試案例代碼。

3. 這個時候能夠按照測試驅動開發的理念去填充代碼。

4. 代碼能夠從現有的代碼中抽取出來。

5. 在抽取的過程當中進行整理重構。

這樣，這個子模塊完成之後，就能夠嘗試去替代現有的子模塊，看看能不能在整個系統中安全的運行。

對於整個系統來講，咱們又能夠分紅不少個子模塊。而後又能夠對各個子模塊各個擊破，最終完成對整個系統的重構。

若是一開始對整個系統進行重構的話，也是能夠從自上而下的角度來看的。

好比說開始的時候先把全部的子模塊當作一些佔位符，假定他們已經完成他們的接口了。那對於整個系統來講，它自己就是一個子模塊，屬於提綱挈領的那個模塊。

這個過程，從字面意義上能夠理解成重寫，實際上，它也是一個重構的過程，由於咱們確定會重用這個系統自己的一些現有代碼和現有的邏輯。

上面咱們是假定系統在已經完成的狀況下進行的重構，其實重構能夠貫穿於軟件開發的始終。軟件開發的首要目標是實現業務邏輯，可以解決客戶的問題。這個目標實現之後，咱們就要追求代碼的乾淨度，複雜度可以降到最小，當前的技術可以用到最早進。

因此只要有機會，咱們都應該對代碼和設計進行重構。

質量

質量直接關係到客戶是否對咱們的產品滿意。那咱們應該如何保證軟件開發的質量呢？

要遵循整個開發團隊的共識才能保證質量。共識是一個可大可小的術語，大到理想、哲學、人生觀；小到軟件設計原則，設計模式，代碼風格。若是是打造一個團隊那就是長期的目標，共識必定要從大的方向上入手。若是僅僅爲了開發一個項目，共識能夠從具體的細節着手。

軟件質量的保證，須要整個團隊造成共識，你們都遵循這個共識。這個共識體如今開發原則，設計模式和代碼上，具體表如今架構代碼和模板代碼上，在項目最初的開發階段，開發速度必定要慢，就是爲了通過反覆的推敲夯實，把代碼的共識部分創建起來。

風格上的目標是，無論這個團隊有多少我的，寫出來的代碼，就像一我的的代碼同樣，風格是一致的。

代碼的質量也體如今複雜度上。複雜度的目標是，在目前的技術條件下，當前的代碼的複雜度應該爲最低。

另外一個軟件高質量的重要指標是代碼的白盒可測性。測試的框架應該在項目開始階段搭起來。等部分代碼成型的時候，逐步的添加必要的測試案例。測試案例的選取能夠按照環形複雜度的計算方法來肯定，也能夠根據集成測試對應的用戶需求來肯定。

接下來進一步細說一下軟件開發中的測試。與代碼相關的測試，通常有單元測試,集成測試和系統級的測試。

單元測試，通常被認爲很是繁瑣。單元測試的繁瑣主要體如今測試案例的選取上, 若是使用全覆蓋方式來選取測試案例的話，會產生大量的測試代碼，之後維護起來也是一個負擔。若是採用環形複雜度來選取測試案例的話，會產生適量的測試代碼，可是環形複雜度的計算也是一個很大的時間開銷。

集成測試跟客戶的實際業務需求相關。在這個過程當中須要理清接口的輸入與輸出，以及運行路徑，而後據此來設計測試案例，寫出測試案例代碼。

開發人員通常不會拒絕寫集成測試。由於她帶來的好處是實實在在的，會極大的提升你的開發效率和調試效率。尤爲是對於無界面的程序接口尤其重要。

系統級測試是大系統中子系統之間的集成測試。這個主要包含兩個方面：

一個方面是有界面的自動化測試，經過這樣的測試架構來模擬人類用戶的使用過程，同時增長一些隨機性的行爲，試圖可以找出系統的一些漏洞。

另外一種是無界面的測試，體如今多個服務系統之間的調用上或者相似瀏覽器自動化框架的使用上。

一套完整的測試系統，能夠幫助工程師提升開發效率，減小之後系統維護和重構的成本。

從測試的緊迫性上來講，集成測試最爲必要，系統間的測試有時候使用手工測試經過一些測試工具來代替。單元測試能夠有很廣闊的討論空間，這部分要具體問題具體分析。

若是隻是爲了應付檢查而寫測試代碼，是沒有意義的。

若是測試代碼沒有起到應有的價值，寫測試代碼也是沒有意義的。

工程師是軟件高質量的主要執行者。項目組長，架構師和開發經理是軟件高質量的護航者和守護者。

因此不能聽任讓工程師從下而上的去保證軟件質量，這個要求對工程師來講太高了。

小結

最後提一下工程師文化和主人翁精神。對於工程師文化的內涵，我認爲包含以下幾點：

• （1）工匠精神，對於所作的事情有着精雕細琢的熱忱。
• （2）試錯文化，敢於嘗試，願意作第一個吃螃蟹的人。
• （3）自律，這個自律是指「吾日三省吾身」。不斷的自我糾錯檢討提升。

對於主人翁精神，無論作什麼工做，只要想充分發揮本身的能力，真正的作些事情，無論級別如何，薪水多寡，簡單地說，就是時刻把所作的事情看成本身的事情來作。不然的話，時刻斤斤計較，咱們作事情的時候就沒法盡心盡力。

若是抱有患得患失的心態，咱們的工做效率就會降低。長此以往，不只賺不到想賺的「大錢」，也會阻礙本身能力和心境的提升，可謂是撿了芝麻，丟了西瓜。時間是寶貴的，真的不容浪費。

對於主人翁精神的一些具體表象不少，諸如：歷來不說「這不是個人事」；作事情不爲了短時間利益而犧牲長期利益；等等。

經過本文，筆者梳理了一下從事軟件工做二十多年來的心得體會，但願能給你們帶來一些有意義的啓示。

點擊關注，第一時間瞭解華爲雲新鮮技術~