軟工實踐（二）——構建之法讀後感

1、前情提要

• 在完成軟工實踐第一次做業以後，老師在個人博客中評論佈置了一個任務，用一週的時間通讀構建之法，而後提十個問題。原本我還擔憂這本書會不會很枯燥，能不能按時間看完，沒想到這本書看起來妙不可言，讓我欲罷不能，裏面有不少的小故事和案例不只生動有趣，還包含了軟件工程這門學科的一些專業知識。看完以後收穫良多。如下是其中的一個十分有趣的片斷：
  
  
  
  

• en，爭取作一隻豬或一隻雞，而不是作一個鸚鵡，O(∩_∩)O。

---

2、結合我自身

個人開發經歷

• 在大二暑假時，十分有幸的加入到了一個初創團隊中進行開發，團隊由我——程序員，老闆——創業核心，美工——圖片設計，運營——業務推廣，一共四名成員構成。
• 個人主要職責是和老闆溝通，商量好需求、並設計產品和編碼。這真是一個粗糙的團隊啊（看完構建之法後的感慨）。
• 可是咱們有共同的遠景，那就是提供一個好的可信的平臺，商家發佈兼職，同時用戶能夠接受兼職。傳統的兼職是以羣爲基礎的，商家在羣裏發兼職招人廣告，可是這些廣告參差不齊，其中甚至包含一些欺詐的廣告，商家也很難招到人。咱們就是受這樣的痛點啓發，想要開發一個產品，貫穿兼職的招人、完成兼職、發佈工資的過程。在需求分析階段，咱們仔細的分析了傳統的兼職招人過程，設計了咱們產品的一些主要功能（發佈兼職、查看兼職、製做簡歷，接受兼職、工資結算，錢包），還有一些附加功能（積分商城、排行榜、任務系統等）。咱們並無對用戶進行問卷調查，依靠着對一些從業者（兼職中介）的調查就開始了工做。
• 如今看完了構建之法，我發現咱們的一個總體需求分析仍是大概符合NABCD的，咱們分析了用戶的需求Need（商家的、和兼職用戶的），咱們找到了思路來解決用戶的痛點Approach（搭建平臺貫穿整個兼職流程），咱們清晰的知道這麼作的好處Benefit，能幫到用戶哪些地方，同時爲了作的更好和吸引用戶，咱們還開發了（積分商城、排行榜、任務系統）的功能，咱們研究了咱們的競爭產品Competitors（鬥米兼職、大學生兼職、南姐兼職等），發現他們雖然也實現了兼職的發佈和接受過程，可是其上的虛假信息仍是不少，並且沒有咱們的福利系統，咱們計劃使用微信小程序平臺來製做應用，由於這樣更方便咱們推廣Delivery和用戶分享。
• 咱們的團隊是典型的以老闆驅動的流程，而且由於開發的過程由於只有我一我的，沒有能夠參考的或者學習的人，我就就着本能來進行了開發：
  • 沒有寫需求文檔，和Spec
  • 進行了簡單的數據庫設計，畫了思惟導圖，可是沒有畫UML圖、ERD圖、等其它任何圖
  • 進行了項目的進度規劃，可是沒有仔細的規劃每一天
  • 沒有使用軟件進行原型設計，可是簡單的畫了界面外觀草圖
  • 沒有進行單元測試，可是每個組件開發完成後會進行功能測試，基本頁面製做完成後我進行了場景測試
  • 沒有遵循瀑布模型、而有些相似敏捷開發，在產品上線後，咱們設計了新的功能，在業務運行的同時進行產品的迭代開發
  • 使用了源碼管理git，但因爲程序員只有我一個，其中並無遇到什麼衝突問題
  • 註釋和代碼規範

這是咱們的產品

歡迎使用並提意見，由於老闆在外出差，如今暫停了業務上的推廣，可是2.0版本已經在開發日程上了。

粗糙的開發過程必然會致使一些問題

• 開發的過程當中，經常由於一個需求的不明確而須要進行大的改動
• UI設計欠缺，產品的美觀度還達不到高水平
• 缺少進度的規劃，致使項目的開發比原預期慢了好多個月
• 測試的少，致使代碼後面出了BUG，花了好幾天修改，最後查明確實一個很小的問題沒注意

若是是多人開發

我預想若是這個項目是多人開發，可能還會出現更多的問題，例如代碼合併上、設計和測試上、後續維護上。單獨開發避免了這些問題，卻也給我帶來了更大的工做量。（在這邊替我老闆發個招人廣告，會微信小程序或者python django框架的，有興趣一塊兒接着作這個項目的，歡迎聯繫我O(∩_∩)O，讓我一塊兒通力合做，搭建出一個好的兼職平臺，服務那些勤工儉學的小夥伴們，讓他們沒必要爲了兼職的質量而擔心）

參考了衆多的APP UI以後，咱們設計了新的設計圖

---

3、個人思考和問題

讀後感

• 軟件 = 程序 + 軟件工程， 在以前的課程中咱們學習了怎麼寫程序，而並無教咱們怎麼作工程，曾經我忽視了軟件工程（這不就是合做寫程序嗎？），其實並非這麼簡單，其中的區別就像你們一塊兒搬磚和你們一塊兒蓋大廈的區別這麼大...

• 雖然把構建之法看了一遍，可是時間倉促，雖然有作了一些筆記，可是仍是以爲有些囫圇吞棗，其中提到的一些思想和方法還須要在之後的實踐中進一步熟悉和掌握。這是一本須要一有時間就拿來翻翻看看、仔細揣摩的書。
  

個人問題

在看書過程解決的問題

一些在看書早期中記錄的問題，都在後面的閱讀中獲得瞭解答。
例如： 開發的過程當中，學習到了新的技術可以促進開發，該怎麼辦呢? 這個問題在第十五章給瞭解答：

15.1.4　招數：設計變動（Design Change Request）

通過Alpha/Beta階段，移山團隊收到了很多用戶的反饋，有些是意料之中的，有些是意料以外的。你們都看到，原來的設計也有很多要改進的地方。有了用戶反饋，你們也可以取得比較一致的意見。另外，你們也有了不少新想法。一時間，衆說紛紜，不少人都嚷嚷着——DCR，DCR！

重寫或重構

小飛：咱們的某某模塊真是太爛了，我以爲必須重寫，並且如今又有了新的技術叫「我佩服」（WPF）[或插入任一最近時髦的技術]，它能作很酷的效果，爲何不呢？

二柱：咱們先要看看，原來爛到什麼程度，如今是否能完成功能？你所說的問題有多嚴重？是功能不能實現？或者界面有問題？或者不能擴展（例如：不能支持更多用戶）？

大栓：另外，是重構，仍是重寫？重構——在儘可能保持原有界面的基礎上優化部分代碼。重寫——從新實現原有功能，同時，要分清是所有重寫原有功能，仍是偷偷加上許多新的功能（Feature Sneak）？

小飛：我們找領導去，超總，看看我新寫的功能。

阿超：你不是在修復這個模塊的Bug麼？怎麼開始寫新的功能了？

小飛：對，不過你是否是以爲我加的這個新功能很酷，嗯……如今是有點慢，可是若是數據庫再作一些對應的修改，好比增長緩衝之類的，那就更好了。

阿超：用戶提到了這個功能麼？這和咱們項目的遠景有什麼關係？數據庫修改後，原來的用戶數據要如何遷移到新的Schema下面？
小飛：嗯，可是用戶若是看到了，就會喜歡的。

阿超：不少程序員有這樣的衝動，在作修改的同時，想到本身還能作更多的事，有一個「東西」一直想作，可是提出幾回都沒人重視，那如今有機會，就「加進去」算了。或者還有不少靈機一動的想法。打個比方——原本是要修廚房頂上一個有時漏水的水管，結果修理工來了，修好了水管，同時靈機一動，加了一個帶淋浴的豪華衛生間。

小飛：但這畢竟是新的想法，我覺得你會喜歡的。

阿超：記住項目的當前階段是一個阻尼振盪的過程，要收斂和穩定。等到下一個版本開始的時候再進行發散的思考吧。若是你以爲目前的設計有問題，咱們要用DCR來管理。

怎麼作DCR？阿超給你們列出了DCR的要點：

如何提出DCR？

1）在提交一個DCR時，選用任務做爲工做件類型，並在標題中標明DCR。

2）在DCR的描述文字中，說明：

a. 問題在哪裏，問題的影響；

b. 若是不修改，會有什麼後果？

c. 幾種修改方案，各類方案的優缺點和成本。

除了這個問題在看書中解決以外還有不少，就不一一列舉了

尚未解答的困惑

1. 對一個要去找工做的學生來講，專業成績和實踐能力哪一個更被企業看重？
2. 開源的代碼有必要附帶測試代碼和開發文檔嗎？
3. 資金和人力有限的創業公司須要嚴格的執行軟件開發流程嗎，還有分工上，有時候並無產品經理，也咩有測試人員，這時候有什麼適用的軟件開發流程嗎？
4. 在需求分析中，能夠不經過用戶，直接從現有市場的競爭軟件中取長補短嗎？
5. 怎麼看待互聯網或者說軟件只是把傳統搬到電腦上或者網絡上這種說法？業務有時候並無變更，這算是行業創新嗎？
6. 測試人員的技術須要比開發人員厲害嗎？
7. 在現實的小公司中，產品經理通常都是兼任開發職責的，利會大於弊嗎？
8. 管理 != 技術，面對不會技術的管理要怎麼協調工做？
9. 我在開發的過程當中發現，有不少的時間都花在了分析業務流程上（兼職流程），可是若是不理解業務，開發出來的產品壓根無法使用，在實際的企業開發中，寫代碼的時間和不寫代碼的時間（需求分析、設計等）哪一個比較多？