回顧，再出發
| 項目 |
內容 |
| 這個作業屬於哪個課程 |
2020春季計算機學院軟件工程(羅傑 任建) |
| 這個作業的要求在哪裡 |
提問回顧與個人總結 |
| 我在這個課程的目標是 |
完成一次完整的軟件開發經歷
並以博客的方式記錄開發過程的心得
掌握團隊協作的技巧
做出一個優秀的、持久的、具有實際意義的產品 |
| 這個作業在哪個具體方面幫助我實現目標 |
為自己一學期的努力畫上句號
對下一個階段的展望 |
作業要求：
- 鏈接到以前提問題的博客
- 請嘗試對自己曾經提出的問題進行解答，並闡明，是如何通過看書，實踐，或者討論弄清楚的。
- 是否原來的問題還不明白？如果有，請分析。
- 是否產生了新的問題？如果有，請提出。
- 軟件工程這門學問有很多 “知識點”， 這門課強調 “做中學” – 在實踐中學習知識點。
- 請問你們在項目的 需求/設計/實現/測試/發布/維護階段（一共6 個階段）中都學到了什麼“知識點”，每個階段只要說明一個知識點即可。
- 結合自己在個人項目/結對編程/團隊項目的經歷，談談自己的理解或心得。
序
2020年3月3日下午16:48，在博客園發表了本學期軟件工程的第零篇博客——停下來，回頭看 ——記2020BUAA軟工第一次作業-熱身！ ，1萬5千字的長文收穫了1256次閱讀和6個評論，其中ScalersTalk作者Scalers專門註冊了博客園在我的評論下方留言回復2500字，令我備受鼓舞，還有鄒欣老師和寶玉老師的建議我牢記在心，mio4學長的經驗之談也對我很大啟發。懷着對所有閱讀過我的文章和評論我的文章的人的感激，踏上了軟件工程的學習道路。
2020年3月8日臨晨2點56分，發出了軟件工程這門課正式的第一篇博客——初窺構建之法——記2020BUAA軟工個人博客作業 ，這片博客中都是在閱讀完鄒欣老師的《構建之法》后，對書中存疑的地方提出的問題，並加入自己的思考和理解。這片博客收穫了594次閱讀9條評論，有其他學校的軟件工程老師，還有仰慕已久的SivilTaram學長在我的博客下留言。最令我沒有想到的是，負責鄒欣老師的《構建之法》和吳軍博士的《浪潮之巔》出版的周筠老師聯繫了我，加了我的微信，帶我走進了大神們的世界，周筠老師的群聊中有吳軍博士，有輪子哥，還有各行各業的優秀人士，看着他們在群里的討論愈發能夠感受到自己所學和認識的狹隘，除了自己的學習之外，還需要更多的與優秀的人的交流，在交流中增長自己的眼界。為了完成這篇博客，我將《構建之法》每一個章節都進行了閱讀，書中還有很多博客的鏈接我也大多點開來看，對於提出的問題也事先在網上做了充分的調查和搜尋，給出了自己的理解和嘗試性的解答。雖然一周的閱讀時間很短，但是這個過程真的十分漫長，看完《構建之法》感覺自己在理論上已經開始嘗試着從軟件工程的思維去思考問題。特別是對PM的章節，除了書之外還搜索了很多地方關於Program Manager和Product Manager的區別，並嘗試着將自己代入體驗。
2020年3月10日下午18:59，發布了“深度評測官”——記2020BUAA軟工軟件案例分析作業，對候選素材中最難啃的OCR識別表單的開源工作進行了測評，做第一個吃螃蟹的人，後面總結了經驗推廣開來，陸續也出現了幾篇OCR的測評，收穫了1754次閱讀，成為了後面團隊開發時的產品介紹。在這次作業中，開始體會軟件之間的差異，開發軟件需要側重什麼，什麼樣的軟件是一款優秀的軟件。
2020年03月21日，我和我的組員拼裝成了一個團隊，並給我們的團隊發布了第一篇博客——“介紹一下自己吧”——記2020BUAA軟工團隊介紹和採訪：
我們是 BUAA軟軟軟件工程小隊 ，簡稱 軟軟軟，但是大家也可以看到我們的博客的 TITLE 是 HARD_CORE_SE，指的是 “硬核的軟件工程” ，軟軟軟其實是希望我們遇到硬核的軟件工程也可以 化硬為軟，直面困難，在我們的眼裡沒有 硬核 二字，一切困難在團隊面前都是紙老虎！
雖然我們都沒有大型的工程經驗，是一直拼裝起來的軍隊，但是我們相信通過我們團隊的配合一定能夠在軟件工程這門課中發揮出色，不只是取得成績，而且能做出像樣的、能流傳的、實用的項目出來。
雖然當時我們還沒有選好題目，但是我們核心的目標已經確定——做出像樣的、能流傳的、實用的項目出來。
2020年4月1日，我們團隊發布了項目選擇博客——“媽媽再也不用擔心我忘交作業了！”——記2020BUAA軟工團隊項目選擇，結合本學期的疫情分析了同學們的痛點，決定開發一款幫助同學規劃提醒日程的Web應用，而我作為想出這個點子的人，對這個應用有什麼頁面，有什麼功能，能夠實現什麼最為清楚，因此成為了團隊的負責人。
2020年5月5日，修復完所有的Bug、走過不知道多少次流程，我們確定首次公開發布我們的產品——DDLKiller，一款專門面向北航本科生設計的日程提醒助手，並在朋友圈，班級微信群，QQ群等小範圍內進行推廣：
從後台統計數據來看，發布第一天註冊用戶達到77人，第二天達到148人，僅僅使用两天的時間就已經超額完成預期的100人，並且從反饋來看，同學們對這一款簡潔美觀、功能強大的日程管理助手非常滿意，並且积極給我們提供反饋意見，幫助我們在Beta階段做的更好。
第一次發布說實話是非常忐忑的，我們熬了無數個夜晚，開了無數的視頻會議，做了無數次測試的軟件，突然開放給大家，不知道大家是喜愛，還是無感，我們當天晚上守在後台，看着註冊登錄的日誌，看着註冊的人數一個一個往上漲，一個一個開始新建事項，使用我們的功能，守到過了午夜1點仍然沒有異常，我們的心才放了下來，大家相互鼓勵，洗洗睡了。
2020年6月2日，又經過一輪的迭代，我們發布了Beta版本的DDLKiller，雖然是6月2日發布，但是用戶們早已體驗過新的功能，結合很多人性化的新功能進行二次推廣，用戶量達到240人，相比Alpha階段增長90人。後來經過最後一次項目展示答辯，我們的軟件工程這門課程，結束了。
但DDLKiller還沒有結束，就像我們UltraSoft – Beta – Postmortem事後分析中所說的：
BUAA – UltraSoft – 軟軟軟小組 2020春大三下學期的軟件工程， 全劇終。
但我們DDLKiller的故事還在繼續，不要走開，馬上回來
我們還留了兩個功能沒有實現，我們感受到了大家對客戶端和小程序的呼聲，我們希望在自己的大學生涯中，甚至在未來的生活中，依然繼續使用這款我們親手打磨，親手建設的產品，說實在的，我們還挺不捨得的。雖然在專業人士的眼中看來這個實現非常簡單，可能一個前端大神两天就能做完的事情，一個後端大神一天就能寫完的東西，我們卻花了整整一個學期。
可是，我們在這個學期裏面不是學習的如何寫前端，如何使用Vue，不是學習如何寫後端，如何使用Django，我們團隊的賬號發表了39篇博客，技術博客都是在我們的個人賬號中發表，這說明什麼，團隊博客中所記錄的，是實實在在的軟件工程。那一篇篇設計與規劃、Scurm Meeting、發布說明、測試報告、項目展示、事後分析，是DDLKiller像一個新生兒一樣，成長的記錄。
我們學會了團隊成員之間如何高效合作，我們學會了如何使用Github、Gitee管理團隊項目，我們學會了使用MockPlus設計產品原型，我們學會了如何權衡需求和實際。確實專業的工程師照着我們的網站實現一個是很快，但是他可能很難做到從0到1的過程。他沒有進行痛點的分析，他不知道用戶真正需要什麼，他沒有一個需求和實際使用之間的權衡，他的開發確實了團隊協作的樂趣。
說實話剛開始團隊開發的時候我還是不習慣多人協作，覺得一個人做完了事就可以省去交流的時間，後來我才發現不是我不會開發，是我不會交流。我們團隊後期自研創新的交流方式非常高效，一個石墨文檔把鍋和坑明確到人，每個人不需要問自己需要干什麼，還可以干什麼；一天十幾個小時在線的騰訊會議，有問題直接進來說，語音來的總比打字快，共享屏幕來的總比截圖直接。大家高效交流之後整個難度就下來了，只要說好了誰負責開發什麼模塊，最晚什麼時候需要驗收，還有不懂的我們共享屏幕聊，幾乎不會產生歧義或者推鍋的情況出現。作為一個PM我的體會最深：在Alpha階段的前期由於缺乏有效的溝通，PM和組員都很累，每個人都有點不清楚自己要干什麼，我知道大家要干什麼卻不能很好布置下去，每天群里的提問和回答帶來的卻只有效率的低下，我也想着自己一個人做好就算了，要那麼多人干什麼，但也發現自己越是想全部做完做好越是什麼都做不完做不好。這是一段非常難忘的經歷，是軟件工程這門課提供給我的，給了我一個在步入社會前體驗社會毒打的經歷，幸好是在課內體會到的，不至於“死”得太慘。
回首望去，覺得這學期很長，也不知道是不是疫情在家的緣故，還是無窮無盡的騰訊會議的緣故，雖然只過了3個月，但是感覺自己做了很多事情一樣。3個月後再看自己的第一篇博文，確實有了些不一樣的體會。
回答自己
在初窺構建之法——記2020BUAA軟工個人博客作業中，我提出了七個小問題，其實在當時已經回答的差不多了，但現在有了一定的軟件工程經驗之後，又有了一點小的看法。
問題一：是否真的沒有銀彈
“把重點放在質量上，生產力將隨之而來”，這是Jones的觀點。基於這個觀點我當時提出了這樣的觀點：
我之所以對銀彈是否存在持有懷疑態度是因為在大環境下，有一些本可以提高的生產力沒有提高，還有很多團隊會出現文檔與實現分離的情況，出現進度卡在某一個人負責的環節的情況，這些情況都是我們會在後續的團隊編程中可能會遇到的，所以我覺得現在就應該思考，如何在團隊中破除沒有銀彈的詛咒，提升團隊的整體水平和能力。
我們團隊的生產力就有一個拐點，從一開始的效率低下到後來的慢慢摸索再到後來形成體系之後組員們心照不宣。是否真的沒有銀彈？我們組可能找到了自我協作的方式，充分將每個人的能力在其崗位上發揮，做到了效率的最大化和能力發揮的最大程度，整體生產力得到了提高，是否一定程度上找到了銀彈？
其實大家都在尋找屬於自己的“銀彈”，我看到每個小組都有自己組內的成熟的管理機制和協作方法，大部分是Github的Issue和Pull Request，還有一個Github的看板，還有一些在線文檔。並沒有說Github上面使用的管理方式就比石墨文檔更有技術，我們團隊覺得上Github的速度太慢，石墨文檔就能很好的解決我們的問題，也可以定位到人，還有具體的任務細節：
Beta階段開發明顯更加得心應手一些，外加Gitee上面的清晰的Issue和Pull Requests：
無論是對內的石墨文檔還是對外的Gitee，都對我們的實際開發極大提高了生產力。
問題二：如何選擇合適的團隊模式
當時鄒欣老師給到我的回答是：
想請教老師和助教，業餘劇團模式的具體形式能夠結合助教的經歷或是老師的觀察給一個更加清晰的講述嗎？
就是大家可以選擇各種角色來扮演， 在下一個項目中，又可以有全新的分配方式。
你們就是用‘業餘’ 時間來開發的， 比較適合這樣的模式。
在實際的開發中，我們確實也是業餘劇團的模式，大家先分好了大方向，前端和後端，然後分配一個模塊的任務吧，如日曆視圖、課程視圖等，如數據庫、爬蟲等，在實際的開發中，主體上不太發生改變，在細分的任務上比較靈活自由。特別是在Alpha發布之後，項目已經成型，大家已經不再限制於模塊的開發，細化到功能的開發，比如要實現一個快速創建的功能，可以在日曆中，也可以在日程列表中，兩個都進行添加。甚至前端的同學可以來優化一下後端的代碼，後端的同學學習一下前端的實現，都是“互通有無”的。
問題三：每日例會的效果如何？
在這個問題下面我當時又提出了一個問題：
敏捷開始是否是一個偽命題？
當時找到了Vczh輪子哥的回答：
敏捷不是一群開發者對着甲方的第一版需求猛做幾天，而是在做的過程中始終和甲方進行有效的、不間斷的溝通，來幫助甲方更加清晰地認清自己的需求，也幫助整個團隊確定一個當前的完成進度，也就是一個迭代中的需求分析和驗收。
經過兩輪的迭代和20餘次的Scrum Meeting，感受到了一些敏捷開發的意義：雖然我們沒有甲方，但是我們自己就是自己的甲方，我們不斷反省和思考着自己需要什麼功能，自己不需要什麼功能，認清自己的需求，掌握團隊的進度，不斷驗收。
每日例會一開始是拒絕的，我們在Alpha階段還弄錯了例會的時間，導致缺少兩篇，覺得這些東西在Github上都有，為什麼還要記錄呢？後來其實發現每日例會重要並不在於記錄，其一在於每日隱隱地督促着每一個成員，“今晚要彙報，自己做了什麼？”；其二在例會，一個常規的，團隊的固定“節目”，有例會才像是一個成熟的團隊而不是一個個散兵，在例會中大家可以找到歸屬感，大家可以有問題在例會中大膽提出來，有什麼想法提出來大家一起實現，有什麼功能其實沒有什麼用大膽刪去，例會還是一個平台，提供給大家自由說話、表達意見和想法的平台，在例會中每個人都有說話的權利，每個人的話都能被所有人所聽見，這是我理解的每日例會的意義。至於效果，見仁見智吧，我們團隊的例會效果我還是比較滿意的，大家都有準時參与，都敢說，都是為了我們DDLKiller更好的發展去說。
問題四：為什麼除了微軟很少見到Program Manager
當時我其實沒有找到這個問題合適的答案，也是遺留了下來，自己作為這個學期軟軟軟團隊的PM，無論是Product Manager也好還是Program Manager也好，談一下自己的看法。
很多地方都在吐槽產品經理，說產品經理不管需求是否能夠實現，產品經理是程序員的天敵諸如此類，無非就是在說產品經理不動技術，只懂調研和分析需求。作為我們團隊的PM，我也參与了調研，我也確定了產品的需求，但我也在我的崗位——後端、部署、測試上工作，所以當我有新的需求的時候，作為一名程序員，我也會要麼憑藉自己的經驗對需求的實現難度進行預估，要麼根據已經實現了的功能對需求進行預估。比如臨時加入一個消息中心，我其實也是從前端小白到了解了一點前端的知識，我知道這個功能並不麻煩，前後接口一設置分別實現就行了，所以大膽的安排了下去這個臨時的任務，我得力的組員也很快完成了，經過我的連接和測試，一天內用我們的“業餘”時間就上線了這個功能，提供了極大的便捷。
至於為什麼除了微軟很少見到Program Manager，希望我能夠親身去微軟和其他公司體驗一下吧。
問題五：對於小團隊而言小強地獄是否可行？
“小強地獄”聽着特別可怕，但其實在我們的實際開發中沒有太多遇到，首先是代碼總量不大，經過幾次定位就可以找到問題所在；其次是我們保證了合併進入主分支錢經過“充分”的測試，這裏的充分之所以打上引號是因為100%的充分並不存在，就像我們的同步課程中心的爬蟲核心功能，在我們團隊的幾個人的賬戶上測試都沒有出現問題，結果小範圍的內測立刻炸鍋，趕忙修復然後加大內測的範圍，在幾輪的測試都無誤之後我們才正式上線功能，這也是為什麼我們發布比較晚的原因。
我們團隊也並沒有測試這個職位，大家前端和後端自己先測試自己的代碼，然後連接的時候再測試連接的代碼，不需要不參与開發的人去讀代碼，只要提供充分的測試樣例就行了。小團隊連開發都人數有些不夠，在項目的尾期設置專門進行覆蓋性測試的測試人員即可，這種開發方式在我們的項目中並沒有出現什麼大礙，所以小強地獄這種東西，只是一個提出來的權衡feature和bug的模式，每個團隊可以根據自己的實際情況進行調整。
問題六：迷思之六：技術的創新是關鍵？
我們的項目有創新嗎？可以說有：我們使用郵件給用戶進行提醒，只要有網就能收到提醒；也可以說沒有，有一部分的用戶是被我們的美觀的界面吸引過來的，可能並沒有使用郵件的功能，而且其實我們的產品有類型的原型——Microsoft的ToDo。但是我們創新性地將同學們的所需以一個更好的形式呈現了出來，進行了高度集成再展現的過程，這也不失為一種創新。
我們在開發的時候想過創新嗎？說實話我沒有。用戶在使用到這樣一款產品的時候會主動想到有什麼創新嗎？可能也沒有。無論是開發者還是使用者，大家都在關注一樣東西——是否解決痛點。我們可能從來沒有想過郵件提醒是一種創新，靈感來源於博客園的作業提醒，我們想的是如何解決用戶沒有在日程的DDL前被提醒的痛點，郵件只是解決這個痛點的一個可行方式罷了。
我不是在否認創新的重要性，只是在說有的軟件可能目的不在於創新，也能夠贏得大家的喜愛。新鮮感固然是好東西，但是新鮮感不能持久，當新鮮感褪去，用戶是否還會對我們的產品滿意？是否會選擇其他更具有新鮮感的東西？這些是根據用戶的需求是否被解決所決定的，也是一個產品的核心部分，真正被考量的部分。
問題七：最難的問題——排座次
當時提出這個問題時，還是太嫩了，其實排座次在實際執行起來是整個開發中最簡單的事情，就像鄒欣老師說的，有的人想得60分有的人想得90分，根據大家的Pull Requests和實現的功能的工作量就可以看出來。我們團隊的成員大家都非常积極，甚至主動找我領取任務，所以在最後的打分大家都差不多；其他組比如NAG2020就可以看到，其中有一名成員就是想拿60分的，兩個階段的貢獻分都是最低，代碼貢獻也是最少，自然就給了最少的分數。
使用Gitee、Github等項目管理軟件之後，每個人的积極程度、活躍程度、項目的貢獻量都一目瞭然，所以排座次的問題，客觀公平公正得到了解決。
新的問題
疫情之下，我們體驗到了全新的軟件工程，可能我們是唯一一屆在線上開展軟件工程這門課的學生，我們線上開會，線上協作，線上發布，線上展示。Work From Home 成了疫情中主流的工作方式。之前看到Vue的開發團隊就是分佈在世界的各個角落，線上交流和協作維護，他們已經形成了一種十分成熟的WFH的工作方式。
試想，在WFH是否會成為未來的發展方向？特別是對於程序員而言，WFH其實可以在不影響開發的前提下能節省很多的時間，如通勤等等，很多大公司已經或者開始嘗試WFH，包括美國的巨頭Google、Facebook、Twitter等等，請問老師和助教覺得，本學期的WFH與之前學期的線下軟工有什麼區別，有意料之外的提高嗎？
“做中學”
需求階段
學會取捨：衝刺只有兩周，而且我們是業餘開發，所以不可能將所有的功能都實現，甚至在Alpha階段我們僅有的反饋中有一項是希望在課程列表中加入測試模塊，這個想法在Beta設計與規劃前是列入到了Todo List中的，然而在Beta設計與計劃實際的權衡中我們將其丟棄了，替換為了課程的通知，因為通知使用的更多，幾乎每門課都有，而測試只有少量的一兩門課有。
設計階段
顏值即正義：一款顏值高的產品不一定是最好的但一定是最吸引用戶的，我們的Web程序也是因高顏值吸引了不少用戶，大家對於課程中心陳舊的排版感到視覺疲勞的時候看到我們的產品會眼前一亮從而想要體驗，這是在推廣階段特別重要的一點。
實現階段
考慮可擴展性、注意代碼風格：以我負責的後端爬蟲來說，從開始時的只爬取課程作業和課程資源到迭代中加入爬取課程通知再到期末季中爬取考試日程安排，這幾樣東西應該做到合理歸類與分離，以免造成代碼太過臃腫接手的人難以及時上手。
測試階段
回歸測試和覆蓋測試的重要性：在發布新功能時，要一併考慮到舊有功能是否正常運行，我們在迭代中就遇到這樣的問題，比如在Beta階段我們支持了重複日程的提醒，向日程中加入了字段 repeat，然而我們只測試了常規的添加日程，沒有考慮下方的快速添加日程和模板添加日程，導致發布之後出現內部錯誤，檢查日誌才發現錯誤所在然後緊急修復。如果每個新功能在發布的時候都能夠有回歸測試則可以避免這一問題。
發布階段
漸進式發布：當一個應用的新功能準備發布的時候，會進行一些測試，比如灰度測試，即選取一小部分用戶可以體驗到該功能，其他用戶維持原來的功能不變，以查看新功能的運行效果和用戶反饋意見，在我們的開發中，我們有多台主機可以進行訪問，所以會先使用其他主機的ip訪問使用“內測版本”的DDLKiller，然後過一段時間再發布。在Alpha的正式發布前我們也做了小範圍的內測，讓一些自己的舍友和朋友先使用，看看有沒有問題，還有么改進的地方，確實內測找出了一些問題，幫助我們在正式發布的時候減少很多事情。
維護階段
文檔文檔文檔：經驗教訓是有心東西一定要以文字的形式在文檔中呈現，首先是提高了團隊內部的溝通效率，大家不用反覆詢問可以直接查閱文檔，其次是積少成多，為後面接手的同學做充足的準備。特別是前後端分離的團隊開發，只要文檔維護得好，直接事半功倍，反之事倍功半。
理解、心得
個人項目->結對項目->團隊項目，是一個課程組有意設計的一個遞進的關係，在這一點上我覺得羅老師和任老師班級的軟工做的最好，相比於歐陽老師班級的個人項目直接到團隊項目，我們中間有一個過渡期，很多人其實在過渡期的時候就知道自己想要干什麼了，大致可以分為前端和後端了，這樣一來在團隊中的項目分工也簡便了很多。
在個人項目中，我們實現了一個求交點的程序，沒有頁面显示，只有命令行的交互；在結對項目中，我們加大了求解交點的難度，同時用圖形化的界面將交點的位置呈現在了眼前；在兩個衝刺，前後兩個月的團隊項目中，我們分工更加細緻，實現了一個軟件。一步步走來，感覺越來越難了，但是也越來越簡單了。難在項目確實更大，從技術上來說難度確實增大了；簡單在我們不是一個人在戰鬥了，我們身邊從沒有人到一個人再到一群人，集體的力量是不容小覷的，每個人都有自己擅長的部分，這一點感觸特別深。在團隊中，一個人花了很久不能解決的事情，丟出來大家都积極主動伸出援手，一起將困難啃下來；在這個學期學習是在很累的時候，也是我們團隊的成員陪伴着我，在此感謝陪我熬夜最多的Kkkk，有時候大家就算不需要說話，只要會議室裏面有人，心靈就能得到慰藉——“我背後還有一個團隊”。
在團隊項目中，我既是PM又是後端開發，還負責部署，這個工作可能比有的團隊PM只負責文書麻煩一些，但也暴露出來了一人多職的缺點。由於Alpha階段對時間的理解錯誤外加新項目開發難度大，導致Scrum Meeting有一兩次開會了但是沒有及時記錄導致會議紀要缺失的情況，還有就是寫完代碼之後沒時間寫文字了於是產生拖延，這一部分應該專人來記錄會好一些。在團隊項目階段確實學習到了很多新知識，無論是Django開發還是NGINX部署，都需要啃官方文檔，特別是NGINX和Uwsgi的兩個官方文檔還有不清楚的地方需要自己解決，在五一的五天假期連肝五天才總算把前後端連接和服務器部署徹底啃下來，終於在五一假期的尾聲進行小面積的推廣。這也讓我對網絡與系統這一方面產生了興趣，在暑假期間我會嘗試涉獵一些分佈式和網絡編程相關的內容，如果感興趣的話希望有機會往這方面發展下去。若是因軟件工程這門課能夠找到我自己的真實興趣所在，也是太值得了。
作為PM，特別感謝我的軟軟軟團隊的隊友們，包括Alpha階段結束之後轉走的Dz，一樣非常感謝。是你們一起幫助我完成了我的一個想法，讓他不再是一個想法，成為了一個真正能夠使用，大家都可以使用，甚至受到好評的一款軟件。其實DDLKiller是我實在找不到一款可以提醒我日程的軟件下的“被迫選擇”，想要一款DDLKiller這個念頭在我剛開學的時候就有了，當時和舍友嘗試了Tower協作也不好用，嘗試了Microsoft的Todo也不好用，自己又開發不了，但是居然在團隊開發中被我們做出來了，和我預想的完全一致，甚至某些功能超出預期。是你們讓我第一次體會到想法到實現的喜悅，第一次切身體會到代碼的魅力，第一次感受到團隊的強大，體會到1+1+1+1+1+1+1>7。DDLKiller就是我的軟軟軟團隊的孩子，離不開每一個人的付出。
我們在第一篇自我介紹中說到：
雖然我們都沒有大型的工程經驗，是一直拼裝起來的軍隊，但是我們相信通過我們團隊的配合一定能夠在軟件工程這門課中發揮出色，不只是取得成績，而且能做出像樣的、能流傳的、實用的項目出來。
至少在我自己看來，我們已經成功了。
最後想說的
大概的都說的七七八八了，若是要用幾個詞語總結這學期的軟件工程課程的話：
魔幻、刺激、充實、欣慰
在每次的個人作業前面老師都讓我們寫下這門課程的目標，我寫的是：
完成一次完整的軟件開發經歷
並以博客的方式記錄開發過程的心得
掌握團隊協作的技巧
做出一個優秀的、持久的、具有實際意義的產品
現在看來，我都已經做到了：
-
一次完整的軟件開發經歷：從使用MockPlus畫出草圖，到真正用網址就能訪問
-
博客團隊的開發：39篇團隊博客就在BUAA軟軟軟件工程小隊中
-
團隊協作的技巧：我們甚至自研了石墨文檔+騰訊會議的創新性協作方式
-
優秀的、持久的、具有實際意義的產品：DDLKiller——懂你的日程管家
從UltraSoft – Beta – Postmortem事後分析中摘取一段話出來：
如果下一年有學弟學妹問我：軟件工程哪個老師的課好？
我會如實回答：如果你對自己有要求，如果你想這個學期不碌碌無為，如果你想學期結束收穫滿滿，如果你想逼自己一把，選擇羅傑、任健老師的班級吧。過程會很痛苦，你會看到別人都在玩的時候你在寫博客，你會看到別人開發的時候你在寫博客，你會看到別人只開發一次就結束的時候你在寫博客，你在開例會，你在Beta階段開發，但是當你的博客得到了老師的認可，得到了助教的讚賞，得到了《構建之法》作者鄒欣老師的點評，得到了輪子哥Vczh對你的提問的親自回復，得到了《持續行動》《刻意學習》作者Scalers為你特地開賬號的留言，你會感覺，這一切都值了。
慶幸當初的自己沒有聽到負面的評論就退縮，堅持選擇了羅老師和任老師的班級，做出了像樣的東西。我確實心裏吐槽過博客，用心寫真的很累，每次博客能花上3～5個小時，每次都是動輒上萬字，但是確實寫完之後獲得了有意義的評論和建議心裏特別舒服，讓我受寵若驚的是第一次的Scalers為我註冊博客園賬號留言7500字，讓我感覺到自己的博客沒有白費。自己也是北航面向對象課程的助教，也能夠一定程度上理解老師和助教的良苦用心，很多東西學生在做的時候是會不理解甚至罵出聲的，但是做完之後又是另一種感受了，老師和助教只能委屈成為暫時的惡人，逼着同學去思考，逼着去寫下文字，逼着做看不到短期利益的事情，等待着一切都結束時候的理解。
軟件工程這門課雖然結束了，但我們的軟件開發依然在繼續，回顧，為的是更好的出發。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※教你寫出一流的銷售文案?
※聚甘新
