構建之法閱讀筆記（1）
構建之法閱讀筆記（1）
這周我開始了我的閱讀之路，閱讀了構建之法的第一二章。
構建之法的第一章講的是軟件和軟件工程是什麽:軟件=程序+軟件工程。我一開始對軟件工程的理解就是敲代碼，寫程序，其實，事實不是這樣，從書上得知，程序和軟件是有很大區別的，程序是軟件的構成部分，但是程序不代表軟件，軟件=程序+軟件工程。一個真正的軟件並不是只寫代碼，而是軟件工程和程序的結合。
同時這本書也對bug這個詞進行了深入的解讀，bug並不只是錯誤的代碼，它是軟件的行為和用戶的期望值不一樣，是軟件功能實現的缺陷。每一個軟件對每一個用戶來說都是不一樣，每個用戶對軟件的期望值也不一樣，用戶對這軟件不滿意的地方也就是一種bug。
軟件其實並沒有我們想的那麽簡單，做軟件是一個系統的過程，需要經歷需求分析，軟件架構，代碼實現，發布軟件，軟件測試，軟件維護等等，所以說需要我們學習的還有很多。
同時寫代碼也要註意加註釋和代碼的格式，這對自己以後工作有很大的幫助。
構建之法閱讀筆記（1）
相關推薦
構建之法閱讀筆記（1）
等等 結合 工程 註意 幫助 需求 系統 需要 功能實現 構建之法閱讀筆記（1） 這周我開始了我的閱讀之路，閱讀了構建之法的第一二章。 構建之法的第一章講的是軟件和軟件工程是什麽:軟件=程序+軟件工程。我一開始對軟件工程的理解就是敲代碼，寫程序，其實，事實不是這樣，從書上得
構建之法——讀書筆記（5）
exp 時間 微軟 padding 層次結構 敏捷 參加 解決問題 企業 第七章 MSF What is MSF?——Microsoft Solution Framework（微軟解決方案框架）即一個方法論，也就是微軟推薦的軟件開發方法。 MSF基本原則： MSF沒有像敏捷
構建之法——讀書筆記（9）
add 體驗 領域 color 讀書筆記 幫助 做什麽 目標 網站 本周粗略的過了一遍第12章。 第12章 用戶體驗 其實，計算機軟件的用戶界面（User Interface， UI）和用戶體驗（User eXeperience，UX）是一個有著豐富內容的學術領域，軟件工
構建之法-----閱讀問題（一）
閱讀 原因 開發流程 閱讀內容 簡單的 天都 不能 作者 敏捷開發 閱讀內容：第六章 敏捷開發流程 在敏捷開發流程中，作者提出了一個觀點-----每日立會，在聽老師講的過程中，覺得這種模式很好，在每日立會中，定義好任務究竟是什麽？完成這個任務的時間是什麽？能夠及時發現自己
數學之美閱讀筆記（1）
大一的時候就開始看吳軍博士第一版的《數學之美》，苦於那時年少無知不懂事，加上自身數學知識的體系不健全，翻著翻著也就沒有了後文。現在讀了研究僧，也許是換了個視野，看到書的開頭“中國教育最失敗的就是學生從上課的第一天到考試結束，都不知道學的東西能幹什麼。”，果然是大
《構建之法》學習（7）——MSF
發現 解決方案 msf 我們 基本原則 無法 strong 出了 微軟 《構建之法》學習（7）——MSF 1.MSF簡史 微軟解決方案框架，也就是微軟推薦的軟件開發方法 2.MSF基本原則 推動信息共享與溝通 所有信息都保留並公開，討論要包括所有
構建之法閱讀筆記
.cn htm logs com .com cnblogs log html http 1.http://www.cnblogs.com/a1264393659/p/5610786.html 2.http://www.cnblogs.com/a1264393659/p/56
構建之法閱讀筆記03
比較 文字 不存在 沒有 時間 開發程序 失去 人在 想法 在團隊的合作中，代碼的規範性很重要，其可以分為兩個部分，一個是代碼行為規範，主要是文字的規定，二是代碼設計規範。牽涉到程序設計，模塊之間的關系，設計模式等方面的通用原則。如果一個人的代碼沒有任何的規範性
構建之法閱讀筆記01
style 提高自己 結合 bsp 思想 宋體 玩具 spa nbsp 構建之法閱讀筆記01 在網上找到《構建之法》這本書的電子版，經過幾天的閱讀瀏覽，對於這本書，我覺得有很多的優點，但是更多的有一種感覺，這本書更註重的對編程者的思想的啟發。書裏提供了很多的實例以及模型或者
構建之法閱讀筆記02
了解 不同 開發流程 功能設計 軟件工程 好的 學習 階段 3.3 構建之法閱讀筆記02
構建之法 閱讀筆記04
總結 求和 應該 核心 最有 交流 工作量 開發 分支 敏捷開發原則：1.盡早並持續地交付有價值的軟件以滿足顧客需求。2.敏捷流程歡迎需求的變化，並利用這種變化來提高用戶的競爭優勢 3.經常發布可用的軟件，發布間隔可以從幾周到幾個月，能短則短 4.業務人員和開發
構建之法 閱讀筆記05
產品 交互 一個 閱讀 自己 設計 問題 決定 應該 典型用戶不再是一個抽象的概念，而應該是一個活生生的人。一個典型用戶描述了一組用戶的典型技巧、能力、需要、想法、工作習慣和工作環境。在設計軟件的過程中，我們往往會以自己使用產品的習慣對軟件行業的熟悉程度出發設計，忘記
構建之法閱讀筆記04
規模 對待 構建 思路 階段 學會 力量 適合 功能模塊 構建之法閱讀筆記04 發布日期：2017.6.16 通過結對合作，令我意識到了編寫程序不僅僅要自己能明白，也要便與他人查看和理解自己的程序。 4.1大節提到的代碼規範，我們編寫代碼時要註重代碼風格規
構建之法--探索篇（一）
構建 編寫 裏的 set namespace 對象 之前 定義 時也 問題一： 在Cust中無法找到telephone的get方法，這裏是因為我之前沒有telephone的成員變量，加上之後有沒有寫telephone的get方法； 解決方案：只要在Cust這個類裏面，加上
構建之法學習回顧（二）
保持 競爭 增量 版本 工作 集合 tro 以及 完成 學習完構建之法五到八章之後，發現這本書更加貼近於當代，一般的軟工教材為了追求更廣更久的接受度，在內容上會趨於保守，而這本書不同，許多生硬的知識都得到了新的活力。 在第五章的學習中，主要講了典型的軟件團隊模
構建之法學習回顧（一）
第三章 多人合作 認識 案例 回歸 實用 效能 可執行 代碼規範 在學習完構建之法一到四章之後，作為軟件工程專業的一名在校生，有了一些全新的認識，作者把軟件工程開發的方法和案例講的清晰有趣而又實用，我們的思維水平也升級了不少。 在
leveldb 閱讀筆記（1） 內存分配
erp ant 保存 系統調用 tin assert blog 方便 png 內存管理對於任何程序都是很重要的一塊，leveldb自己也實現了一個簡單了內存分配器，而不是使用一些其他開源軟件tcmalloc等，避免了對其他軟件的依賴。 自己實現內存分配器有什麽好處呢？
構建之法閱讀筆記 01
規則 規範 麻煩 簡單的 筆記 合作 閱讀 編碼格式 錯誤 在之前做作業的時候，總是習慣性地直接code，結果經常花更多時間停下來思考，這樣反而會更耽誤時間，提高了出錯的幾率。之前的編碼格式也不是很規範，命名規則很亂，總是找比較簡單的變量進行命名，這樣無疑也會對團隊合作
構建之法閱讀筆記3
clas 是我 一個 筆記 自己 dba 漢堡 不能 並且 正確給予反饋： 誰人人前不說人，誰人背後無人說。 反饋的三個層次： 最外層: 行為和後果 當反饋是關於行為和後果時，行為可以改正，後果可以彌補，對方還是有挽回局面的機會。 中間層: 習慣和動機 當
構建之法閱讀筆記4
多少 驗收 廣告 入口 進行 行動 今後 設計師 提供商 典型用戶分析： 寫一個軟件的時候要為用戶考慮，用戶在哪裏，有多少用戶是團隊在需求分析和設計階段要反復琢磨的問題。 百分之百按照用戶要求做是不行的，還要 1、找到用戶語言行動背後的動機。 一個典型用戶描述了一組用戶的