[buaa-SE-2017]我的做業-回顧

我的做業-回顧

提問題的博客：[buaa-SE-2017]我的做業-Week1

Part1: 問題的解答和分析

1.1

問題：根據書中「除了前20的學校以外，計科和軟工沒有區別」因此計算機科學這個專業也許在咱們學校是和軟件工程有區別的，可是能夠料想的是大多數人未來都會是碼農，那麼咱們專業和其餘學軟件工程的人相比有什麼優點呢？

如今仍然不清楚，由於每一個人的狀況不一樣，也許是咱們基礎好一點吧？實踐出真知，之後工做以後也許會知道。

1.2

問題：既然用戶的需求是不斷變化的，那麼如何才能在設計過程當中最大限度地使得軟件易於擴展？另外一方面，若是這樣考慮會不會又進入了過早優化的思惟誤區呢？

設計一個健康的系統結構，讓軟件變得易於擴展是必須的，可是過早的預測用戶需求的變化是不須要而且多餘的，真正須要的是保持和用戶的頻繁接觸，有更短的迭代週期和更頻繁的反饋，簡而言之，保持敏捷。

1.3

項目經理看起來是一個須要具備多領域知識的人（管理、營銷、計算機），但大多數人都不會在大學畢業時就具有這些知識，那麼若是未來想成爲項目經理，如今能夠作什麼準備呢？各個部分的知識須要掌握多少？

這個問題如今看起來最好的解決方法除了多積累知識之外最重要的仍是去公司實習，參與到實際的項目中，畢竟就算從書本中得到再多的東西，不能在實際中運用仍是沒有用的。

1.4

團隊開發中一個比較困難的問題是，團隊成員之間如何更有效地溝通？特別是在學校的時候咱們除了軟工之外還有不少課程，平時也很忙，這樣成員之間的溝通就很是困難了。

此次團隊項目雖然有的時候後端會出現問題，可是一些簡單的問題我能夠本身修復，同時大問題PM會解決，因此一天一次的scrum對我來講已經足夠，不過不知道當項目規模變大這種問題會不會出現。

1.5

第四章中提到，變量命名的時候須要避免沒必要要的修飾詞，判斷必要或者沒必要要的方法是問本身，可是這種方法是否太過武斷？畢竟看程序的都不是寫程序的，對本身易懂，對別人就必定易懂嗎？

如今我認爲命名太長或是過短都是很差的，如何命名每一個人應該都有本身的方法，但關鍵並不在這裏，而是我的應該有統一的命名風格，若是是團隊也是同樣的。

1.6

16章中討論了技術創新的問題，並用金錢和知識的轉換過程來闡明科研和創新之間的關係，可是科研和創新是否真的是對立的過程？Viterbi創造的Viterbi算法讓無數人受益，也讓他得到了名譽和金錢，因此這二者之間也許並不是是對立的，畢竟工業界的要求是要work，科研須要的東西也包括這一點。

創新和科研是不一樣的過程，發現知識的人也能夠是創新的人，沒有新知識的驅動創新也很難發生，而創新一般也會激發對新知識的探索，它們之間相互促進，二者是不一樣的概念，不過並不對立。

Part2: 知識點的總結

2.1 需求階段

咱們在需求分析階段採用了調查問卷的方式來了解需求，這個調查問卷獲得的結果和咱們討論的並不同，好比咱們最初但願項目的核心功能是對課程的評價功能，不過問卷的結果顯示用戶最須要的是下載課件資源的功能，還有一個當時我以爲基本不怎麼起眼的自定義課表的功能也獲得了不少票，因此說我的的需求和總體的需求是會有不少誤差的，真正的需求還應該從用戶那裏獲得。

同時如今回顧一下我認爲咱們當時還應該有一個進行深刻面談或是組建焦點小組的需求分析的過程，由於調查問卷只是用戶對問題的直覺上的回答，用戶極可能沒有深刻想過這些問題，同時他們的需求可能和他們表達出來的並不同。

2.2 設計階段

咱們的架構基本實現了先後端的分離，因此設計起來基本沒有困難。不過Ui界面的設計和後臺系統結構的設計徹底是兩回事，在Ui界面設計的時候，你須要爲了一個分割線的顏色考慮不少，好比這個顏色是否過於醒目，是否會干擾用戶的體驗，你還須要不停地調整字體的大小和顏色，同時你也須要考慮元素之間的間隔，界面設計一般須要不斷地打磨。

2.3 實現階段

一個好的設計是好的實現的前提，一般若是你在實現過程當中感到舉步維艱，只要不是由於你對技術的瞭解太少，那確定是設計出了問題，同理若是你在設計的時候感到頭昏腦脹，也許你還沒搞清楚需求（這是從另外一個項目得來的經驗= =）。

2.4 測試階段

因爲前端基本能夠實現毫秒級別的反饋，因此測試很是方便，不過應該儘早編譯代碼在服務器上運行，由於實際的界面效果和在開發時候的也許會有不一樣。
測試必定不是在完成所有編碼工做以後再作的，而是隨着代碼的增長而不斷進行的，發現bug的時間越早就越容易修復。

2.5 發佈階段

像上一節提到的，程序實際在服務器上運行的時候的效果和在開發時候的效果有些不一樣，因此在發佈階段以前爲測試預留充分的時間是頗有必要的。

2.6 維護階段

由於咱們維護工做沒有不少，因此並無太多的經驗，不過及時修復bug確定是須要的，發現一些影像功能的bug以後應該在24小時以內修復。

Part3: 我的角度看團隊過後分析

昨天PM發佈了Beta階段的時候分析，仔細看了以後發現有不少感慨和以前沒有注意到的地方，在這裏想針對這篇過後分析談談本身的體會。

下面全部的引用都來自咱們團隊的Beta階段過後分析。

3.1 關於宣傳

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
儘早宣傳，因爲咱們宣傳得比較晚，致使最終的用戶量和彙報時用戶量相差比較大。應該把反饋功能儘早銜接到網站上，而不是依賴於用戶羣。

關於宣傳的晚這一點，我深有同感，咱們在開發階段和用戶的接觸太少了，更理想的作法是在每開發一個新功能以後就及時和用戶進行溝通，從而有一個更快的響應速度。

3.2 關於進度估計

咱們達到目標了麼?
基本達到了目標。可是計劃實現的功能太多了，最終只實現了大多數功能，一些非核心功能就被棄掉了。

我認爲對項目總體進度的估計不足也是咱們beta階段的一個不足，我認爲這其中主要的緣由就在於咱們對進度估計的不重視，實際上咱們沒有理由不重視估計這一步驟，由於若是因爲估計不許而致使核心功能實現不足，那可能就意味着整個項目的失敗，況且咱們也沒有用於防止這種狀況發生的緩衝區。固然實際咱們所面臨的狀況並非那麼糟，至少咱們已經實現了大部分的核心功能。

必需要認可的是個人經驗並非很充足，若是還有下一次，也許能夠用相關模型或是公式估計一個粗略的時間，最好能把任務儘量地分解，從而實現細粒度的估計。

3.3 關於bug

博文功能Bug最多，這裏主要是前端，一是人手不足，二是bug不太好解決，自己實現難度也比較大。

因爲我是前端，因此這裏仍是要反省一下本身。前端bug多的緣由，一方面就像引文中提到的那樣，因爲前端都由我一我的搞定，一人難扮多角，因此測試的時候基本都只是測一些基本的功能場景，而不會進行全面的測試；另外一方若是不考慮粗枝大葉這樣的狀況，此次前端總體的架構也是不夠健壯的，總體的結構存在不少問題，這樣很容易出現bug，關於這一點我須要檢討。

3.4 關於質量保障

咱們在這一階段太過注重功能的實現了，時間又緊，人力資源又少，一直處於一個很緊張的狀態。若是重來一遍咱們會放棄一部分功能，將更多的時間用在代碼管理上，> 保證軟件工程的質量。

這一點我也有同感，咱們確實沒有在工程質量上下太多功夫，人數不夠加上初期對功能的重視都致使了這一點，比較好的一點的是咱們採用的先後端分離的模式大大下降了整個系統的複雜度，某種程度上避免了整個項目變成一個"Big Ball of mad"。

不過從另外一方面說，咱們組的組員都很給力，你們都認真負責爲了項目全力以赴，雖然可能有一點小瑕疵，可是我認爲咱們已經盡力作到了最好。