讀《構建之法》第4、17章有感
詩雲:半畝方塘一鑒開,天光雲影共徘徊。問渠哪得清如許?為有源頭活水來。
這是宋代理學大家朱熹對閱讀一本好書的感受。這幾天我看了鄒欣老師寫的《構建之法》第4、17章之後,產生了一點點類似的感受。下面我來點評一下。
關於“第4章 兩人合作”的點評:
問題一:
原文(見第68頁):另外,註釋(包括所有源代碼)應該只用ASCII字符,不要用中文或其他特殊字符,否則會極大地影響程序的可移植性。
個人見解:可移植性是指代碼在不同平臺能否執行。註釋會被執行嗎?不會。那麽,註釋就與可移植性無關。中文註釋也是註釋,所以中文註釋也與可移植性無關。
問題二:
原文(見第73頁):發現算法錯誤,比如使用的算法不夠優化,邊界問題沒有處理等。
個人見解:“算法不夠優化”不能算是“算法錯誤”吧!@鄒欣老師
關於“第17章 人,績效和職業道德”的點評:
問題一:
感覺這章幹貨很少(僅對我而言)。或者說,我在看完之後都沒產生什麽想法。
一本書,如果讀者能夠認真閱讀,並在閱讀後作出理性批判,那麽,我覺得這才是對作者最好的尊重。與諸君共勉。
讀《構建之法》第4、17章有感
相關推薦
讀《構建之法》4、17章所思所感
技術分享 實現 內容 估計 cal 評估 最小 做了 依賴 僅針對這2章的閱讀,主要講的是團隊之間,不僅是2人之間的,更是整個團隊在完成一個項目、在一起工作時需要的各方面的力量,也有對領導力、績效以及職業道德方面的講述。 以下就是我在讀完1、2、16章後的一些問題和
讀《構建之法》第4、17章有感
理學 尊重 績效 不能 共勉 body 所有 產生 style 詩雲:半畝方塘一鑒開,天光雲影共徘徊。問渠哪得清如許?為有源頭活水來。 這是宋代理學大家朱熹對閱讀一本好書的感受。這幾天我看了鄒欣老師寫的《構建之法》第4、17章之後,產生了一點點類似的感受。下面我來點
讀構建之法第四、十七章有感(作業四)
關系 img 作用域 src 而在 clas com 不同的 第十七 第四章: 問題: 看到這裏的時候,才註意到代碼中的“下劃線”這個東西,在之前的敲代碼過程中並沒有怎麽遇到下劃線,在經過百度後得到了一些答案: 這只是Python中下劃線的一部分應用,在不同的語言中
構建之法第八、九章學習
周期 常用 bcd 快速 區別 利益相關者 自省 生命 獲取 第八章:需求分析 這一章主要講述了軟件需求的類型、利益相關者、獲取用戶需求的常用方法和步驟、競爭性需求分析的框架NABCD、四象限方法、項目計劃和估計的技術。 確認軟件需求有以下步驟:1.獲取和引導需求、2.分析
構建之法第六、七章讀後感
敏捷 關註 團隊 項目 提前 敏捷流程 準備 讀後感 合作 Agile——敏捷開發,作為CMM神話崩潰後被引入的一套新的軟件開發模式,這幾年來被廣泛引起關註,並被寄予厚望。 敏捷流程及其原則告訴我們個體和交互勝過過程和工具,盡早為客戶需求做準備和交付有價值的軟件,時時總結如
讀《構建之法》第4,17章有感
程序設計 client 效率 nbsp 其他 pos 我們 授權 質量 讀《構建之法》第4,17章有感 第四章:兩人合作 原文:另外,註釋(包括所有的源代碼)應該只用ASCII字符,不要用中文或其他特殊字符,否則會極大地影響程序的可移植性。 我的問題和看法:對於英語水平沒有
構建之法第4.17章讀書筆記
4.3 pan 快捷鍵 設計規範 快捷 代碼 討論 程序 不知道 第四章:兩人合作 問題1:4.2中註釋這一版塊,因為之前有學長跟我強調過代碼規範的問題,所以對這方面比較重視,後來當使用每個IDE的時候,都會去註意代碼縮進的快捷鍵,比如IDEA的Ctrl+Alt+L等等
讀構建之法 第三章:軟件工程師的成長
知識點 可維護 vid -s 評估 不同 fun 可靠 科研 本章理論和知識點:評價軟件工程師水平的主要方法 軟件工程把相關的技術和過程統一到一個體系中,叫“軟件開發流程”,軟件開發流程的目的是為了提高軟件開發、運營、維護的效率,以及提升用戶滿意度、軟件的可靠性和可維護性。
讀構建之法 第四章:兩人合作
應用 結對編程 使用 一對一 測試 一個 比較 以及 領域 程序員寫的代碼最終是人在看,所以代碼規範很重要,原則是:簡明,易讀,無二義性。 不光是程序書寫的格式問題,還牽涉到程序設計、模塊之間的關系、設計模式等方方面面。 代碼復審的正確定義看代碼是否在代碼規範的框架內正確的
讀構建之法 第五章:團隊和流程
min 這樣的 程序員 希望 成員 eat 貢獻 核心 不能 團隊有一致的集體目標,團隊要一起完成這目標。一個團隊的成員不一定要同時工作,例如接力賽跑。 團隊成員有各自的分工,互相依賴合作,共同完成任務。 軟件團隊有各種形式,適用於不同的人員和需求。基於直覺形成的團隊模式未
讀構建之法第四章第十七章有感
限制 選擇 class blog 了解 什麽 靈活 多重循環 價值 第四章 1、原文;“函數最好有單一的出口,為了達到這個目的,可以使用goto.只要有助於程序邏輯的清晰體現,什麽方法都可以使用。——P69” 問題:關於goto,我記得老師講過,這個在編程中是盡力避
構建之法第三四五章總結
職業 驅動 技能 自動操作 人的 階段 提升 理解 成員 軟件開發流程不光指團隊的流程,還包括個人開發流程,因為軟件團隊是由個人組成的。在團隊的大流程中,是沒一個具體的人在做開發,測試等,因此,個人在團隊中也有獨立的流程,把每個人的工作有序組織起來,就是團隊的流程。
構建之法第六七八章
可用 模型 定義 快速原型 最有 自主 適應 投資 敏捷流程 第六章 敏捷流程 敏捷流程開發原則 1.盡早並持續的交付有價值的軟件以滿足顧客需求 2.敏捷流程歡迎需求的變化,並利用這種變化來提高用戶的競爭優勢 3.經常發布可用的軟件,發布間隔可以從幾周到幾個月,能短則短 4
構建之法第八,九章
自省 程序員 第八章 說明 銷售 作用 相關 項目 觀察 第八章:需求分析 這一章主要講述了軟件需求的類型、利益相關者、獲取用戶需求的常用方法和步驟、競爭性需求分析的框架NABCD、四象限方法、項目計劃和估計的技術。 確認軟件需求有以下步驟: 1.獲取和引導需求 2.分析和
構建之法第十一、十二章
交互 業界 用戶體驗 可用性 找到 方法 認同 我認 設計 用戶體驗有幾個層次:1 最基礎的是在交互環節,就是usablity,可用性,或者說易用性,大家說得最多的;要把可用性做好,不是太難,業界有成熟的方法,不需要太多天賦,兩個字:“用心”即可。 2 更高層次的乃情
我讀《構建之法》四、十七章
什麽是 com 4.2 基於 公開 匈牙利命名法 是我 問題 註釋 這幾天我都在讀《構建之法》第四章和第十七章,看的比較緩慢也比較認真。根據精讀的要求和個人看書的習慣,我總共讀了三遍,第一遍是大致瀏覽了一遍內容,第二遍是靜下心來圈畫、標註疑惑內容,第三遍是重新
構建之法 第五章 團隊和流程
ini 之前 組織 第五章 團隊 mod 交互 然而 逆轉 典型的團隊開發模式和流程,完全是新的內容;涉及到更多的術語和有意思的策略性東西 1.團隊模式【我比較認可的】 主治醫師模式 由首席程序員(相當於首席醫生)負責整個工程,周圍人員各司其職,配合支持中心人物的工作;
構建之法-第三周
合作 工作 軟件 評價 方差 數據 同時 接收 此外 構建之法第三章-軟件工程師的成長 本章主要的理論和知識點是評價軟件工程師水平的主要方法、技能的反面以及TSP對個人的要求。 首先,不同的數據能夠從不同方面一個展示軟件工程師的技術和能力,例如,通過完成時間平均值的比較
構建之法第三章讀書心得
如何 讀書心得 初級 知識 技能 任務 項目 標準 技術 在構建之法第三章中,我們主要學習了個人能力的衡量與發展。 初級軟件工程師有以下幾個成長階段:1、積累軟件開發相關的知識,提升技術技能。 2、積累問題領域的知識和經驗。
《構建之法》4
軟件工程 應該 跟蹤 核心 開發 調研 事情 當前 總結 第六章,講的是敏捷流程。主要的內容是敏捷流程及其原則,方法論,以及各種軟件開發論的優缺點,選擇軟件流程的根據。在軟件工程的語境裏,“敏捷流程”是一系列價值觀和方法論的集合。敏捷開發的原則:1、盡早並持續地交付有價值的