我的做業收官———軟工實踐總結

我的做業收官———軟工實踐總結

  從心心念念期待軟工實踐的開始，到戀戀不捨和軟工實踐作別。這短短的三個月，遇到了nice的隊友，嚐到了軟工實踐的甘苦，學到了前端開發的技能。時間匆忙，每件事情都有一個終點。我就用這篇博客做爲軟工實踐課的終點，記錄一下所學所感。

---

回顧

  在軟件工程的開篇博客裏，我給本身定了一個目標：軟工實踐課上作出的東西，可以真正地有實用價值，可以被一部分人所須要。在軟件工程實踐課結束的這個時候，我終於能夠說這個目標正在慢慢地被達成。開項目開始的時候，我對 html、css、javascript 等前端的內容還一無所知，就是純純的菜鳥。擔憂本身的不能作到 「learning by doing」，可是在通過一週斷斷續續的自學，慢慢開始對前端有一個大概的瞭解。期間，看了廖老師的 javascript 教程、w3c教程。對於初學者來講的我，這些教程頗有幫助。

---

提高

  在接觸軟工實踐以前，平時最經常使用使用的就是IDE 就是AndroidStudio，而最常使用的語言天然就是java了。由於參加服創比賽的緣故，花在android上的時間是比較多的。對其餘的軟件和語言涉獵的比較少。軟工實踐向我敞開了探索新世界的大門。在軟工實踐結束的如今，我得到了下述的新技能：

• git: 瞭解 git 流程，明白了工做區，暫存區，HEAD 的概念。可以比較地熟練使用 git-bash。對版本回退，分支合併，衝突解決等經常使用操做的使用沒有鴨梨。在項目部署中使用了 git hook ，方便對項目的即時更新
• javascript: 掌握了 js 的基本語法。在學習js的過程當中，接觸到了不少之前沒有接觸過的新概念。好比，高階函數，閉包和js特殊的繼承機制原型鏈等。js除了用於前端開發還可以用於，後臺的開發。這些都讓我長了眼界。項目的編碼中用到了 vue.js 作模型視圖綁定，解決了本身手動作數據顯示的困擾
• putty+ ubuntu: 因爲項目須要部署到服務器，學習了一些經常使用的linux命令。
• phpstorm+ webstorm: 使用了這兩個IDE
• axureRP: 結對編程，使用的原型工具

再來講說程序我寫的程序代碼。此次軟工實踐中，我主要負責的是前端。下面一些 js 代碼行數的截圖，來感覺一下:

)：

總行數：438+468+(484-343)+242+263 （╯' - ')╯ ┻━┻

雖然，有點少，可是這是作了重構後的代碼（跑~~~）

小插曲。我是個不安分的前端。在小組剛開始使用git協做時，因爲每一個人本地部署路徑的不一樣。致使每次只要有人更新完項目，那些路徑就會和本地的路徑不符，致使頁面顯示不正常。每次都修改路徑，很繁瑣，並且要修改的文件不少。剛好我在linux上部署php項目時，用到了php超全局變量$_SERVER。就想到，能不能經過這個變量來獲取本地地址的前綴。這樣使用動態變化的前綴就能夠解決路徑不一致的問題。因而，寫了下面的php代碼。

在引入靜態文件時，使用這些前綴。路徑不一致的問題就解決了。

---

人月神話，後知後覺

  在動手寫代碼前，能夠先參考一下目前比較流行的作法。這是一個「慘痛的教訓」。因爲要實現先後端分離，須要前端主動向服務器請求數據，而後把數據更新到界面上，以實現局部刷新。看到這個需求的第一個想法就是，經過ajax向後端請求數據。獲取數據成功後，在回調函數裏用字符串拼接的方式，將數據鏈接和html標籤拼接在一塊兒，轉換成html代碼。這種作法，能夠實現需求，可是代碼維護起來很難受。

代碼看起來是這樣：

後面接觸了流行框架 vue.js，發現了一種清新的寫法

它長這樣：

這樣的只要改變數據，視圖就能作出相應的改變。而不用本身手動地經過js來替換html代碼，讓代碼邏輯清晰。只要關注數據的變化就行了，至關的方便。

  編碼規範很重要。在alpha版本結束以後，我忽然體會到了這一點。在剛開始敲代碼的時候，我以爲編碼規範簡直就是一種反人類的約束。自由發揮不是才更加有效率嗎。可是，事實沒有這麼美好。alpha版本結束後，中間隔了大概有一週多的時間，纔開始beta版本。由於需求有改變，要對以前的代碼作修改。修改代碼的時候，我一時間竟然沒看懂本身的代碼！(心想: 這是什麼鬼？爲何會有這麼多奇怪的命名？) 費了好一會勁，才把捋順思路，把代碼改好。要是一開始就是遵循編碼規範的，保持同一種編碼風格。應該就不會出現這種狀況。

  最後，是個人commit貢獻圖。能夠看出來了，中間有明顯的兩個衝刺階段。可是除了這兩個階段外，其餘時間編碼的比較少。若是可以把時間在前期均勻分配的話，後面的階段能夠多花點時間在優化和測試上。

---

這是一個很棒的團隊

  我有個故事講給你聽。
  萌芽階段。如今回憶起來，滿腦子都是奶茶店的場景，一區、四區，古茗、青卟。那個時候，還在項目的開始階段。PM帶着咱們轉場於各個奶茶店，討論和肯定需求以及任務分工。你們都很積極的討論，提出本身想法。開端很棒。

  磨合階段。要開始編碼的時候，咱們就遇到了一個問題：項目要臨時變動，從android端變成web端。而隊友們的安卓經驗比較豐富，咱們小組的項目從開始的就定下來要作安卓。但是考慮到要作有實用性的軟件。臨時想要改作畢設導師智能分配系統的web端。作web端須要用的後臺語言是php，前端的是js+html+css。這些都和咱們已有的編碼經驗不符。因而，在決定要不要作web的問題上，咱們出現了分歧。由於對php，咱們小組只有齊民大腿有項目經驗。咱們通過了兩個晚上"嚴肅認真"的討論，分析了作web的可行性。最後，投票決定了，咱們要作web端！實踐「Learing by dong！」

  規範階段。alpha版本階段。通過幾周的磨合。咱們對相互之間的編碼和習慣，都有了一些瞭解。這個時候，咱們把場地轉移到了活動室！你們聚在一塊兒敲代碼。遇到問題，咱們就能夠當即的提出來，而後商量着解決。這種氛圍，應該就叫團隊吧！

  創造階段。又經歷了alpha版本。在bate版本，咱們在協做得愈來愈順暢，就像有了「套路」同樣。此次的衝刺咱們沒有通宵熬夜，issue都在bate版本截止時間以前完成了。

  遇到這麼多nice的隊友，真是一種緣分。

---

「長麪條」到「小函數」

  Open Source Software Development Should Strive for EVEN GREATER CODE MAINTAINABILITY

論文中只是討論了開源的可維護性。

論文中衡量代碼質量的標準有：

• 代碼行數（LOC，lines of code）

  衡量程序的物理（physical size）大小，不包括空行和註釋

• 註釋佔比（PerCM）

  註釋行數/LOC，描述了代碼的自解釋性

• Halstead Volume

  n1,不一樣的運算符；n2，不一樣的操做數；N1，總的運算符；N2，總的操做數

  n = n1 + n2，N = N1 + N2

  V = N * log2(n)

  一種可供選擇的，用於衡量程序大小的度量

• 環路複雜度（Cyclonmatic Complexity）

  用於度量組件的結構複雜性

MI指標：

MI值越大，系統的可維護性就越高
  寫第一個前端界面，我是想到什麼寫什麼，這樣就形成了一個函數的會被寫的特別的長。裏面充滿了各類邏輯判斷。在後來的編碼中，就意識到了這個問題很嚴重。因而就開始把大段的函數分紅幾個小函數來寫。這樣既能夠減小單個函數的代碼長度，還能夠經過使用好的函數命名，增長代碼的可讀性。我的以爲，本身代碼的解釋性和可維護性仍是挺強的（跑 ε=ε=ε=(~￣▽￣)~~

---

怎樣證實你學會了軟件工程？

• 研發符合用戶需求的軟件

  畢設導師智能匹配系統，在開發以前就和棟哥確認了需求。若是有幸上線的，可以被下一屆的學生和老師使用到。大概會有200~300的用戶

• 經過一系列工具，流程，團隊合做，可以在預計的時間內發佈「足夠好」的軟件

  是足夠好，可是還須要不斷改進完善。要是實際使用的話，還須要應對不少併發的問題。畢設導師智能分配系統，是經過git，來協做開發的。總共有562個commit，2個分支和121個已經關閉的issue。

• 並經過數據展示軟件是能夠維護和繼續發展的

  有readme.md文檔、需求規格說明書、項目的提交記錄和詳細的issue

---

寫給學弟學妹們

  這是一個坑！一個坑！一個巨坑！重要的事情說三遍。可是，若是你願意花不少的時間來有效地提高本身，而不是隻想「水一水」這門課。那麼，義無反顧的來吧，這是一個很好的選擇。

---

惜別

  呀！又到了告別的時候了。那麼我先來介紹一下本身。個人叫黃偉煒，若是語速快的話可能會念成「v v」。軟工實踐的過程雖然幸苦，可是在辛苦事後再回首，又是別有一番滋味心頭。感謝棟哥和助教的辛勤付出。讓我有了這段歷程，和此次成長！後會定有期。

---

留念