1.總結:html
通過了軟工M1和M2階段的歷練,我提高了對軟件工程的認知,在對一個工程的分層解耦,架構和接口設計上提高到了一個新的高度。另外在代碼規範和團隊合做上,我也有了更明確的認識。學習了這門課程, 還有老師們的多元化教課,不但讓我從理論上掌握軟件工程,還有從不一樣的實例,讓理論和實踐獲得了很好的結合。整一個學期下來,總的來講仍是學到了不少東西 的,有不少地方是值得確定的,其實在我看來,軟件工程與其說是一門課程,不如說是一門思想。是一個如何去分析和處理問題的過程,應該說其範疇已經遠遠不止 侷限於該門課程,成爲了一個綜合的一個可以解決問題的思想集合。前端
2.之前問題的博客:web
http://www.cnblogs.com/hoerwing/p/4830486.html數據庫
3.解決的問題:後端
(1)軟件開發時,好比web2.0的rest風格架構,先後端徹底分離,然而其交接時,極可能出現問題,而且由於徹底分離,因此有可能出現開發不一樣步的問題,先後端的交互耦合,開發同步的問題該如何解決。安全
這種大前端式的開發,很是重要的一點就是要在前期作好接口文檔,而且在開發過程當中嚴格按照接口文檔進行編碼,若是接口有修改,要及時讓各個部分的開發人員同步最新的文檔。這樣在最後的對接階段才能迅速對接,並減小bug。服務器
(2)數據操做,和邏輯操做,實體操做等如何分離解耦。這和架構
(3)若是有效果的分層解耦,三層框架是什麼。其實差很少是一個問題:併發
三層架構(3-tier application) 一般意義上的三層架構就是將整個業務應用劃分爲:表現層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)。區分層次的目的即爲了「高內聚,低耦合」的思想。app
a.表現層(UI):通俗講就是展示給用戶的界面,即用戶在使用一個系統的時候他的所見所得。(負責展現而已)
b.業務邏輯層(BLL):針對具體問題的操做,也能夠說是對數據層的操做,對數據業務邏輯處理。(關鍵在於由原始數據抽象出邏輯數據)可以提供interface\API層次上全部的功能。,「中間業務層」的實際目的是將「數據訪問層」的最基礎的存儲邏輯組合起來,造成一種業務規則
c.數據訪問層(DAL):該層所作事務直接操做數據庫,針對數據的增添、刪除、修改、查找等。(關鍵在於粒度的把握)要保證「數據訪問層」的中的函數功能的原子性!即最小性和不可再分。「數據訪問層」只管負責存儲或讀取數據就能夠了。
(4)過分解耦,或者大規模模塊化開發時遇到的依賴冗餘問題如何解決。
這就要把握一個度,模塊化粒度的度。這是在初期架構時就決定的,咱們要對各個功能的開發成本,複用頻度,效率問題等作一下評測,以後再決定在架構中的模塊如何劃分,粒度是怎樣的,這種劃分形成的依賴冗餘會形成多大成本和影響,綜合考慮,將其影響降到最低。
(5)如何在開發成本和收益之間權衡需求,如何判斷剛性需求,僞需求。
(6)如何在開發過程當中設計框架和預留接口使得迭代更加高效,維護更加輕鬆。
這要考驗項目之初對用戶需求的分析程度和架構師對架構的理解和對將來功能的展望。對我本身來講,我一般是考慮到後來跟這個功能有關的擴展時纔會考慮這個問題,我以爲這樣仍是不夠的,我但願能找到一套工程化的通用規範或者方法來高效的解決這個問題。
5.產生了哪些新的問題,請提出:
(1)如何進行高效的測試,自動化測試,黑盒測試,產品的安全性應該如何保證。
6.同時咱們還讀了8篇軟件工程相關的論文或博客,你回頭再看看這些文章,有沒有新的體會?
沒有。。。。。滿篇英文再讀仍是那麼費勁【捂臉】
7.知識點:
(1)需求:要從用戶出發,作好用戶定位,用戶需求調查,市場調查,而且分析用戶究竟想要什麼,而不是他說他想要什麼。
(2)設計:框架搭建時要注意分層解耦,又要注意依賴冗餘,必定要作好接口文檔和代碼規範。
(3)實現:源代碼管理要作好各個版本的迭代,各個模塊之間對接時尤爲要注意代碼管理。還要注意爲之後的開發迭代預留好接口。
(4)測試:迴歸測試和單元測試都要進行。壓力測試要和日誌相結合,解決併發效能問題。
(5)發佈:要作好宣傳工做,要從用戶獲得反饋。
(6)維護:要作好日誌監控和數據備份。服務器的性能信息也要作好監控。