構建之法第4.17章讀書筆記
第四章：兩人合作
問題1：4.2中註釋這一版塊，因為之前有學長跟我強調過代碼規範的問題，所以對這方面比較重視，後來當使用每個IDE的時候，都會去註意代碼縮進的快捷鍵，比如IDEA的Ctrl+Alt+L等等；
我對自己寫的代碼還算比較滿意，但是在註釋這一塊確毫無頭緒，不知道什麽是標準，以前看過標準的註釋，記得好像是在每個程序寫好該程序的作、創作時間等等一系列的羅列，實際開發的過程中難道每個類都要寫這些東西嘛？會不會有些沒有用處？
引用4.3代碼設計規範
問題2：之前做四則運算時就有這個疑問了，在代碼設計這一塊，因為緊接著要做結對項目嘛，所以這兩天也討論了一下代碼"模塊化"的設計，那麽在代碼設計規範中，一個類內部實現多個功能的方法好，還是一個類單獨地實現一個或幾個方法好？是因為耦合度的原因嘛？
第十七章：人、績效、職業道德
問題：小團隊和大團隊哪個更好一點？怎麽樣才能讓自己更快度過磨合期？
構建之法第4.17章讀書筆記
相關推薦
構建之法第4.17章讀書筆記
4.3 pan 快捷鍵 設計規範 快捷 代碼 討論 程序 不知道 第四章：兩人合作 問題1：4.2中註釋這一版塊，因為之前有學長跟我強調過代碼規範的問題，所以對這方面比較重視，後來當使用每個IDE的時候，都會去註意代碼縮進的快捷鍵，比如IDEA的Ctrl+Alt+L等等
《構建之法》第4.17章讀書筆記
martin orm 科學 說過 事件 比較 筆記 虛擬 負責人 《構建之法》第4.17章讀書筆記 第四章 原文語句： 異常不能跨過DLL或進程的邊界來傳遞信息，所以異常不是萬能的。 提出問題： 1.什麽是DLL？DLL是來解決什麽問題的？
構建之法第五六章讀後感
例子 spa scrum 過程 困難 老板 敏捷開發 統一 學習 鄒欣老師的這本書，寫得形象生動，第五章用體育運動等團隊例子引出軟件開發團隊的形式。軟件團隊形式多樣，適用於不同的人員與需求。團隊可能會演變的模式有：主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊、特
構建之法第十一章讀後感
思維導圖 我們 加減乘除 圖形 計算 每日 導圖 case 中間 本周進行了構建之法的第十一章軟件設計與實現的學習； 第十一章主要講了典型的開發流程，常見的分析和設計方法：ERD，DFD，UML，開發階段的一些管理方法：每日構建，小強地獄，構建大師； 分析和設計方法包括以文
構建之法第15,16章
基礎上 line 測試 需要 span bsp 開發 成員 開發者 15穩定和發布階段 在穩定階段的初期，團隊只要決定需要修復哪些缺陷，然後團隊成員就會進行必要的設計、實現、測試工作，並簽入代碼修改。但是，隨著項目進展和發布日期的臨近，團隊還要保證修改方案不會給產品帶來負面
構建之法第三章讀書心得
如何 讀書心得 初級 知識 技能 任務 項目 標準 技術 在構建之法第三章中，我們主要學習了個人能力的衡量與發展。 初級軟件工程師有以下幾個成長階段：1、積累軟件開發相關的知識，提升技術技能。 2、積累問題領域的知識和經驗。
構建之法第四章讀書心得
算法 邏輯錯誤 規範 審核 領域 之間 心得 使用 部分 代碼風格規範——主要是文字上的規定，看似表面文章，實際上非常重要 代碼風格的原則是：簡明，易讀，無二義性 代碼設計規範——牽涉到程序設計、模塊之間的關系、設計模式等方方面面的通用原則 代碼設計規範不光是程序書寫的格
構建之法第五章讀書心得
多個 功能需求 優先級 周期 基礎 第五章 高效 包括 交付 這一章我們主要學習了團隊和流程。團隊簡而言之就是開發一個軟件工程的團隊，那麽團隊究竟怎樣在一起開發這一軟件便有了多種多樣的方法。 比如所有人都一起做的一窩蜂模式，但這樣模式弊端很大，雖然都做了許多工作，但結合起來
讀《構建之法》4、17章所思所感
技術分享 實現 內容 估計 cal 評估 最小 做了 依賴 僅針對這2章的閱讀，主要講的是團隊之間，不僅是2人之間的，更是整個團隊在完成一個項目、在一起工作時需要的各方面的力量，也有對領導力、績效以及職業道德方面的講述。 以下就是我在讀完1、2、16章後的一些問題和
構建之法 第五章 團隊和流程
ini 之前 組織 第五章 團隊 mod 交互 然而 逆轉 典型的團隊開發模式和流程，完全是新的內容；涉及到更多的術語和有意思的策略性東西 1.團隊模式【我比較認可的】 主治醫師模式 由首席程序員（相當於首席醫生）負責整個工程，周圍人員各司其職，配合支持中心人物的工作；
讀構建之法 第三章：軟件工程師的成長
知識點 可維護 vid -s 評估 不同 fun 可靠 科研 本章理論和知識點：評價軟件工程師水平的主要方法 軟件工程把相關的技術和過程統一到一個體系中，叫“軟件開發流程”，軟件開發流程的目的是為了提高軟件開發、運營、維護的效率，以及提升用戶滿意度、軟件的可靠性和可維護性。
構建之法第八、九章學習
周期 常用 bcd 快速 區別 利益相關者 自省 生命 獲取 第八章：需求分析 這一章主要講述了軟件需求的類型、利益相關者、獲取用戶需求的常用方法和步驟、競爭性需求分析的框架NABCD、四象限方法、項目計劃和估計的技術。 確認軟件需求有以下步驟：1.獲取和引導需求、2.分析
構建之法 第六章 敏捷流程
小時 所有 管理層 log 匯報 薪水 quest 功能 任務 敏捷是一種很“年輕態”的思路/策略，是以“萬事萬物都在不停地發展變化”為指導去組織軟件工程的需求分析、內部的調和、代碼編寫甚至維護，所以我讀起來會覺得很有共鳴。然而並不是所有的地方都適合讓“敏捷”去闖一闖。 1
構建之法第三四五章總結
職業 驅動 技能 自動操作 人的 階段 提升 理解 成員 軟件開發流程不光指團隊的流程，還包括個人開發流程，因為軟件團隊是由個人組成的。在團隊的大流程中，是沒一個具體的人在做開發，測試等，因此，個人在團隊中也有獨立的流程，把每個人的工作有序組織起來，就是團隊的流程。
構建之法第六章學習心得
效率 用戶 當前 決定 復雜 技術 原則 核心 back 這周我學習了構建之法第六章敏捷流程，本章主要介紹了敏捷流程及其原則，Backlog、Burn-down、Sprint、Scrum方法論。以及什麽時候選擇敏捷的開發方法，什麽時候選擇其他方法。.敏捷開發的原則是盡早並持
讀構建之法 第四章：兩人合作
應用 結對編程 使用 一對一 測試 一個 比較 以及 領域 程序員寫的代碼最終是人在看，所以代碼規範很重要，原則是：簡明，易讀，無二義性。 不光是程序書寫的格式問題，還牽涉到程序設計、模塊之間的關系、設計模式等方方面面。 代碼復審的正確定義看代碼是否在代碼規範的框架內正確的
構建之法第六、七章讀後感
敏捷 關註 團隊 項目 提前 敏捷流程 準備 讀後感 合作 Agile——敏捷開發，作為CMM神話崩潰後被引入的一套新的軟件開發模式，這幾年來被廣泛引起關註，並被寄予厚望。 敏捷流程及其原則告訴我們個體和交互勝過過程和工具，盡早為客戶需求做準備和交付有價值的軟件，時時總結如
構建之法第六七八章
可用 模型 定義 快速原型 最有 自主 適應 投資 敏捷流程 第六章 敏捷流程 敏捷流程開發原則 1.盡早並持續的交付有價值的軟件以滿足顧客需求 2.敏捷流程歡迎需求的變化，並利用這種變化來提高用戶的競爭優勢 3.經常發布可用的軟件，發布間隔可以從幾周到幾個月，能短則短 4
構建之法第七章學習心得
思想 studio 開發 咨詢服務 生活 int bsp partner har 構建之法第七章學習心得 這周我學習了構建之法第七章MSF的介紹。MSF有9個基本原則，針對信息共享，團隊內部運營，市場，還有客戶。同樣是強調效率，人性，靈活，還有前景。 MSF對信息共享和溝通
構建之法 第八章 需求分析
lock 焦點 ron 寫到 模型 優先 產品 輔助 討論 其實這是“啃硬骨頭”的第一步，就是如何從“茫茫”中鎖定需求相關方、挖出來需求的方法論 1.挖取需求 獲取和引導需求。需求不僅是來自外界，甚至也可以來自技術成員團隊內部； 分析和定義需求。主要是對需求進行量化； 驗