構建之法第十一章讀後感
本周進行了構建之法的第十一章軟件設計與實現的學習;
第十一章主要講了典型的開發流程,常見的分析和設計方法:ERD,DFD,UML,開發階段的一些管理方法:每日構建,小強地獄,構建大師;
分析和設計方法包括以文字為主的文檔,以圖形為主構造的模型,用數學語言的描述,用類自然語言+代碼構造的描述,原代碼加註釋也能描述;
圖形模型和分析方法;1表達實體與實體之間的關系如思維導圖,實體關系圖,Use Case Diagram。2.表達數據的流動。3.表達控制流。4.統一的表達方式。
其他的設計方法包括形式化的方法,文學化編程。
開發階段的日產管理包括以下問題:閉門造車,每日構建,構建大師,寬嚴皆誤,小強地獄。
然後關於要做的四則運算應用程序,我們初步研究了一下要求和目的。我們需要做的是編一個代碼使其可以完成加減乘除的真分數的運算,還要具有退格和清屏的功能,可以讓用戶輸入,程序判斷對錯。以及在多運算符計算和倒計時中間選一個。我們目前尚未編出代碼,做出GUI對我們有一定的難度。但我們會盡最大的努力完成這個項目。
構建之法第十一章讀後感
相關推薦
構建之法第十一章讀後感
思維導圖 我們 加減乘除 圖形 計算 每日 導圖 case 中間 本周進行了構建之法的第十一章軟件設計與實現的學習; 第十一章主要講了典型的開發流程,常見的分析和設計方法:ERD,DFD,UML,開發階段的一些管理方法:每日構建,小強地獄,構建大師; 分析和設計方法包括以文
構建之法第十一、十二章
交互 業界 用戶體驗 可用性 找到 方法 認同 我認 設計 用戶體驗有幾個層次:1 最基礎的是在交互環節,就是usablity,可用性,或者說易用性,大家說得最多的;要把可用性做好,不是太難,業界有成熟的方法,不需要太多天賦,兩個字:“用心”即可。 2 更高層次的乃情
構建之法第五六章讀後感
例子 spa scrum 過程 困難 老板 敏捷開發 統一 學習 鄒欣老師的這本書,寫得形象生動,第五章用體育運動等團隊例子引出軟件開發團隊的形式。軟件團隊形式多樣,適用於不同的人員與需求。團隊可能會演變的模式有:主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊、特
構建之法第15,16章
基礎上 line 測試 需要 span bsp 開發 成員 開發者 15穩定和發布階段 在穩定階段的初期,團隊只要決定需要修復哪些缺陷,然後團隊成員就會進行必要的設計、實現、測試工作,並簽入代碼修改。但是,隨著項目進展和發布日期的臨近,團隊還要保證修改方案不會給產品帶來負面
構建之法第4.17章讀書筆記
4.3 pan 快捷鍵 設計規範 快捷 代碼 討論 程序 不知道 第四章:兩人合作 問題1:4.2中註釋這一版塊,因為之前有學長跟我強調過代碼規範的問題,所以對這方面比較重視,後來當使用每個IDE的時候,都會去註意代碼縮進的快捷鍵,比如IDEA的Ctrl+Alt+L等等
作業三:讀《構建之法》1-5章讀後感
not 測試 自己的 對比 span 什麽是 行業 什麽 軟件 由於放了國慶假所有看書的效率不是很快,只能慢慢的去研讀研讀,不過正是這研讀才能使我有了深刻的體會。 第一章:概論 第一章主要內容是講述了計算機科學的領域,軟件工程和計算機科學
.NET Core實戰專案之CMS 第十一章 開發篇-資料庫生成及實體程式碼生成器開發
上篇給大家從零開始搭建了一個我們的ASP.NET Core CMS系統的開發框架,具體為什麼那樣設計我也已經在第十篇文章中進行了說明。不過文章釋出後很多人都說了這樣的分層不是很合理,什麼資料庫實體應該跟倉儲放在一起形成領域物件,什麼ViewModel應該放在應用層結構倉儲層與UI層。其實我想
《構建之法》第四、第十七章讀後感
可能 學習 www. 我沒 方式 去掉 bat log http 第四章 在這一章最後一頁“ 讓{}獨占一樣還有一個好處:一眼就能看出是否有多余的代碼行 ,還有些情況下是致命的錯誤”給出的參考鏈接http://lpar.ath0.com/2014/02/23/l
構建之法第六、七章讀後感
敏捷 關註 團隊 項目 提前 敏捷流程 準備 讀後感 合作 Agile——敏捷開發,作為CMM神話崩潰後被引入的一套新的軟件開發模式,這幾年來被廣泛引起關註,並被寄予厚望。 敏捷流程及其原則告訴我們個體和交互勝過過程和工具,盡早為客戶需求做準備和交付有價值的軟件,時時總結如
構建之法第四章讀後感
可維護 編程思想 可維護性 有著 人在 經歷 項目 能夠 疑惑 第四章讀後感 在經過對第四章的閱讀後,我更加清晰地認識到了在項目開發中,規範二字的重要性,也新學到了除開代碼規範以外,其他對於團隊協作也很重要的東西,比如說構造函數的使用,模塊化的編程思想,當然自己也對一些問題
讀構建之法第四、十七章有感(作業四)
關系 img 作用域 src 而在 clas com 不同的 第十七 第四章: 問題: 看到這裏的時候,才註意到代碼中的“下劃線”這個東西,在之前的敲代碼過程中並沒有怎麽遇到下劃線,在經過百度後得到了一些答案: 這只是Python中下劃線的一部分應用,在不同的語言中
構建之法第四章第十七章
height 多文檔 缺失 後來 更強 最大的 fun 影響 手機 一、關於goto函數:濫用goto語句會使程序變得很難理解,而不是所有人能正確的使用goto函數,我的問題是:是不是因為這樣所以很多文檔規定禁用或少用goto函數?但其實如果可以正確的使用goto語句就不能
讀構建之法第四章第十七章有感
限制 選擇 class blog 了解 什麽 靈活 多重循環 價值 第四章 1、原文;“函數最好有單一的出口,為了達到這個目的,可以使用goto.只要有助於程序邏輯的清晰體現,什麽方法都可以使用。——P69” 問題:關於goto,我記得老師講過,這個在編程中是盡力避
構建之法 第五章 團隊和流程
ini 之前 組織 第五章 團隊 mod 交互 然而 逆轉 典型的團隊開發模式和流程,完全是新的內容;涉及到更多的術語和有意思的策略性東西 1.團隊模式【我比較認可的】 主治醫師模式 由首席程序員(相當於首席醫生)負責整個工程,周圍人員各司其職,配合支持中心人物的工作;
讀構建之法 第三章:軟件工程師的成長
知識點 可維護 vid -s 評估 不同 fun 可靠 科研 本章理論和知識點:評價軟件工程師水平的主要方法 軟件工程把相關的技術和過程統一到一個體系中,叫“軟件開發流程”,軟件開發流程的目的是為了提高軟件開發、運營、維護的效率,以及提升用戶滿意度、軟件的可靠性和可維護性。
構建之法第八、九章學習
周期 常用 bcd 快速 區別 利益相關者 自省 生命 獲取 第八章:需求分析 這一章主要講述了軟件需求的類型、利益相關者、獲取用戶需求的常用方法和步驟、競爭性需求分析的框架NABCD、四象限方法、項目計劃和估計的技術。 確認軟件需求有以下步驟:1.獲取和引導需求、2.分析
構建之法第三章讀書心得
如何 讀書心得 初級 知識 技能 任務 項目 標準 技術 在構建之法第三章中,我們主要學習了個人能力的衡量與發展。 初級軟件工程師有以下幾個成長階段:1、積累軟件開發相關的知識,提升技術技能。 2、積累問題領域的知識和經驗。
構建之法 第六章 敏捷流程
小時 所有 管理層 log 匯報 薪水 quest 功能 任務 敏捷是一種很“年輕態”的思路/策略,是以“萬事萬物都在不停地發展變化”為指導去組織軟件工程的需求分析、內部的調和、代碼編寫甚至維護,所以我讀起來會覺得很有共鳴。然而並不是所有的地方都適合讓“敏捷”去闖一闖。 1
構建之法第三四五章總結
職業 驅動 技能 自動操作 人的 階段 提升 理解 成員 軟件開發流程不光指團隊的流程,還包括個人開發流程,因為軟件團隊是由個人組成的。在團隊的大流程中,是沒一個具體的人在做開發,測試等,因此,個人在團隊中也有獨立的流程,把每個人的工作有序組織起來,就是團隊的流程。
構建之法第六章學習心得
效率 用戶 當前 決定 復雜 技術 原則 核心 back 這周我學習了構建之法第六章敏捷流程,本章主要介紹了敏捷流程及其原則,Backlog、Burn-down、Sprint、Scrum方法論。以及什麽時候選擇敏捷的開發方法,什麽時候選擇其他方法。.敏捷開發的原則是盡早並持