需求分析：https://www.cnblogs.com/Clover-yee/p/11771395.html
詳細設計：https://www.cnblogs.com/Clover-yee/p/11882669.html
原型設計：https://www.cnblogs.com/Clover-yee/p/11934420.html
會議記錄1：https://www.cnblogs.com/Clover-yee/p/12045955.html
會議記錄2：https://www.cnblogs.com/Clover-yee/p/12045997.html
web展示：http://ylnzk.cn:8081/BLM/index.html
web前端Github：https://github.com/Ceilzcx/blm
web&app后端Github：https://github.com/Clover-yee/blmAPI
app前端Github：https://github.com/startproge/baolema
ios端：https://github.com/wamgsongg/baolm_ios
數據庫：https://github.com/wamgsongg/baolm_db
一、項目概述
1.1 需求回顧
針對高校內就餐高峰時段風味餐廳人流量大導致部分學生選擇訂外賣的現象，“飽了么”系統致力於為高校學生提供提前校園內風味餐廳提前預定服務，緩解就餐時段的風味檔口的人流壓力，同時減少校外外賣預定，保證學生舌尖上的安全，同時，“飽了么”通過評分評價機制，提高商家的競爭意識，改善餐飲服務水平。
1.2 知識儲備
由於項目需要實現app-mysql-web之間的信息交互和前端操作，所以需要前端設計、數據庫操作、后端業務處理等基礎知識，前期要求項目組成員至少需要熟悉一個方面的知識。
二、項目個人總結
2.1 工作概述
在本次團隊項目中，我被分配為處理web后端業務邏輯。
2.1.1 需求分析和詳細設計階段
在項目前期我們小組在第一次例會上具體分析了項目需求和業務邏輯，基本確定了每個人的分工，由於之前我只接觸過php，對網頁后端的業務處理有一定的了解，所以小組同意我負責web后端，和前端程序員約定web開發用jsp+servlet+hibernate+mysql為主體框架，采用MVC模式，並且約定好具體的功能和前后端接口。數據庫采用mysql騰訊雲數據庫，項目部署到阿里雲服務器上，變量采用駝峰式。
因為對jsp和servlet不太熟悉，所以前期我也花了一定時間熟悉jsp和servlet的處理機制，因為之前的php開發經驗，所以學習起來還不算困難，在編碼階段前已基本了解jsp和servlet的主要內容。
2.1.2 編碼階段前期（demo檢查前）
這段時間內我基本實現了后端操作數據庫的dao層和處理基本業務邏輯的service層，並且開始編寫servlet處理前后端數據交互，但是在本階段我們組項目的最大問題開始暴露——在數據量還不算大的情況下，網頁的信息顯示速度就非常的慢，在排除數據庫性能、網絡傳輸和硬件性能的原因后，基本確定是由於后端采用hibernate使得在數據庫查詢后需要將數據庫記錄實例化，然而用hibernate查詢和實例化雖然編碼實現容易，但是在查詢后的結果集持久化對象化的過程中需要大量的開銷，而且hibernate映射的關聯也非常的多，相當於每次查詢都在進行子查詢，而前端需要的信息又往往很少，導致消耗的時間大部分在dao層上，顯示的速度就非常慢，用戶體驗非常的差。
在對模塊功能進行測試的時候，我們發現網頁的CSS渲染有時候會失效，通過分析，我們發現是因為jsp實際上在運行過程中被翻譯成了servlet，有時候會受到tomcat緩存的影響，有時會出現找不到路徑的情況，debug過程相當痛苦。
同時，采用jsp+servlet+hibernate+mysql這種框架並不能實現前后端的真正分離，配置也相當麻煩，在編碼階段中前后端程序員還是得參與進對方的編碼內容，后端需要處理頁面的跳轉和信息的傳遞，前端獲得的並不是請求的數據而是對象，jsp需要通過JavaBean獲取信息，前后端的耦合度還是太大，有時候我和前端程序員會因為對需求的不同理解而產生分歧影響項目進度。
在和app后端程序員交流后，我們發現其實app后端和web后端的部分業務存在重復，可以共享部分代碼，而且app后端采用springboot，速度相對較快，編碼也更加容易。在demo檢查完后，在總結老師的反饋結果和小組成員的一致同意下，我和web前端程序員放棄jsp+servlet+hibernate+mysql，果斷采用html+ajax+springboot，由於springboot又是新知識，我花了半天的時間速成springboot后投入到新的編碼階段。
2.1.3 編碼階段后期
編碼后期，由於我和app后端程序員共同編輯同一份代碼，所以我們兩個的Github版本控制相當重視，為了和app的數據傳輸格式保持一致，web數據也采用base64。
后期最大的困難是圖片存取問題，后端springboot無法接收前端傳過來json數據，導致圖片成為我們項目進度的瓶頸，在查閱了大量的資料后，我發現需要前端ajax將數據打包為FormData，后端用HttpServletRequest接收才能正確接收json包。但是得知前端數據顯示還是較慢，為了減少讀數據庫的讀取，我們用緩存機制處理數據交互，盡量減少對數據庫的讀操作，提升性能。
在討論數據傳輸問題后，我們約定對一些業務判斷邏輯前后端可以采用狀態碼來進行判斷，根據狀態碼來決定是否進行信息反饋和數據庫讀取，這也是一個減少信息交互處理的方法。
后期我主要編寫Controller層和dao層，處理前端請求，這時我和前端程序員才真正實現前后端分離，我不必關心前端如何實現，我只需要和前端程序員約定好接口處理請求便可以，這時期我們的意見也趨於統一。在驗收前我們web組合完成了功能實現和優化，並進行了大規模測試。
2.2 工作小結
在編碼前期，我工作的重點主要在實現具體的功能上，向前端傳送數據。而后期我主要從事性能優化，和前端程序員和app開發人員交流實踐具體的優化策略，爭取提高用戶體驗。
2.3 項目反思
在老師驗收后，我和其他一些下午班的同學交流的過程中得知，我們的“飽了么”系統其實可以采用分布式架構，數據讀取過慢的情況是由於處理請求需要讀取磁盤，對此可以用redis緩存數據記錄，由於redis是基於內存的，如果每次是讀取redis而不是mysql，速度會大大加快，可以根據局部性原理在請求不太繁忙的時間段內在后台自動將MySQL中的高訪問的數據記錄動態的讀入redis中，這樣就能解決加載緩慢的情況。
“飽了么”需要處理實時訂單，我們處理實時是通過每5秒固定請求服務器查看是否有新訂單產生，有則返回，其實這可以采用Kafka實現實時通信，Kafka是一種高吞吐量的分布式發布訂閱消息系統，對於像“飽了么”這種高並發和實時性要求較高的系統，使用Kafka正合適。
2.4 項目總結
這次軟件工程團隊作業我的收獲很大，之前網頁后端處理我只會用php實現，通過這次大作業，我不僅學會了jsp、servlet、springboot、json等新技術，也學會了如何比較各種技術之間的優劣選擇更適合的技術來實現自身的需求，更重要的是深刻體會到實現功能不是最緊要的，提高用戶體驗讓用戶滿意才是至關重要的。
同時，收獲最大的還是走了一遍軟件工程的流程，熟悉了軟件開發的具體階段，感受到了軟件工程中的一種無以明述的樂趣。在整個流程中，我學會了如何協調團隊任務，如何處理團隊分歧，以前做項目發現問題總是一個人悶頭苦干，現在開始學着去交流促進，取長補短，而且，軟件工程的最大好處是讓我們發揮自己最大的優勢，我們不用學的多學得雜，我們需要學得精學到實處，人盡其才，使我們的項目得到肯定。也許我們也走了不少的彎路，但終究鍛煉了我們的能力。
能和優秀的人一起合作，這也是一種快樂。雖然自己不是最優秀的，但是靠着自己和大家的努力，我們讓整個團隊更加優秀。
三、課程建議
3.1 堅持推廣
希望老師能在以后的《軟件工程》教學中繼續推廣構建之法，對於軟件工程這種實踐要求較高的課程，至少走一遍流程是必須的，而且這可能是我們大學階段僅有的真正實踐軟件工程思想的機會，通過這門課幫助更多的計算機專業的學生感受軟件工程的樂趣。
3.2 堅持自由組隊
針對有些小組完不成項目的現象，老師可能在猶豫以后是否要安排隨機組隊，我的想法是千萬不能隨機分配隊伍。首先，隨機分配可能讓一些不熟悉的人組成團隊，導致在設計開發階段無人響應而組長疲於奔命，有問題沒人解決，最終拖死一片；其次隨機分配會使得優質資源被打亂，部分學生的能力相對突出，他們肯定不想和能力不跟自己在同一條線上的學生一起合作，而水平較差的學生可能會將希望放在核心程序員上而自己水過去，這就違背了老師推行構建之法的初衷，只有能力水平差不多的學生組成一個隊伍，在合作中才會產生火花，才會各盡其才，尤其是對於一些強強聯合的小組，他們也許會有一些與眾不同的想法，這些想法可能會值得我們所有學生和老師學習借鑒，我想這也是一種收獲，而水平參差不齊的學生組成的隊伍往往無法使得能力強的學生發揮他們應有的水平，老師應該也不想看到千篇一律沒有亮點的作業吧。
3.2 老師參與
我們上午班老師參與的比較多，但是我覺得還是不夠，這樣說可能不太合適，但還是希望老師在每個階段結束后詳細的聽取每個小組的匯報，雖然老師每次都查看每個小組的博客，但是博客的內容終歸不會太完備，在這次實戰中我們可能走了很多自己都沒發現的彎路但自己沒有發現，如果在每個階段結束后老師都能聽取指導每個小組的匯報，很多問題都會盡早暴露，不會最后積重難返，對於一些情況特別嚴重的小組，也能盡早想出相應的解決對策。所以希望老師能將將軟件工程的實戰周期再延長幾周，雖然老師壓力可能會非常大，當然只是建議老師可以當我是胡說八道。