構建之法閱讀筆記 01
在之前做作業的時候，總是習慣性地直接code，結果經常花更多時間停下來思考，這樣反而會更耽誤時間，提高了出錯的幾率。之前的編碼格式也不是很規範，命名規則很亂，總是找比較簡單的變量進行命名，這樣無疑也會對團隊合作造成很大的影響。之前也經常會把所有東西都寫到一個類裏面，這樣就看起來比較麻煩，找錯誤的時候也不好找。
在今後的任務中，我會先理清思路，做好規劃，註重編碼的規範性，註意命名規則，增強團隊的合作。建立自己的數據庫，越來越完善自己的能力。
構建之法閱讀筆記 01
相關推薦
構建之法閱讀筆記01
style 提高自己 結合 bsp 思想 宋體 玩具 spa nbsp 構建之法閱讀筆記01 在網上找到《構建之法》這本書的電子版，經過幾天的閱讀瀏覽，對於這本書，我覺得有很多的優點，但是更多的有一種感覺，這本書更註重的對編程者的思想的啟發。書裏提供了很多的實例以及模型或者
構建之法閱讀筆記 01
規則 規範 麻煩 簡單的 筆記 合作 閱讀 編碼格式 錯誤 在之前做作業的時候，總是習慣性地直接code，結果經常花更多時間停下來思考，這樣反而會更耽誤時間，提高了出錯的幾率。之前的編碼格式也不是很規範，命名規則很亂，總是找比較簡單的變量進行命名，這樣無疑也會對團隊合作
構建之法閱讀筆記
.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
比較 文字 不存在 沒有 時間 開發程序 失去 人在 想法 在團隊的合作中，代碼的規範性很重要，其可以分為兩個部分，一個是代碼行為規範，主要是文字的規定，二是代碼設計規範。牽涉到程序設計，模塊之間的關系，設計模式等方面的通用原則。如果一個人的代碼沒有任何的規範性
構建之法閱讀筆記02
了解 不同 開發流程 功能設計 軟件工程 好的 學習 階段 3.3 構建之法閱讀筆記02
構建之法 閱讀筆記04
總結 求和 應該 核心 最有 交流 工作量 開發 分支 敏捷開發原則：1.盡早並持續地交付有價值的軟件以滿足顧客需求。2.敏捷流程歡迎需求的變化，並利用這種變化來提高用戶的競爭優勢 3.經常發布可用的軟件，發布間隔可以從幾周到幾個月，能短則短 4.業務人員和開發
構建之法 閱讀筆記05
產品 交互 一個 閱讀 自己 設計 問題 決定 應該 典型用戶不再是一個抽象的概念，而應該是一個活生生的人。一個典型用戶描述了一組用戶的典型技巧、能力、需要、想法、工作習慣和工作環境。在設計軟件的過程中，我們往往會以自己使用產品的習慣對軟件行業的熟悉程度出發設計，忘記
構建之法閱讀筆記04
規模 對待 構建 思路 階段 學會 力量 適合 功能模塊 構建之法閱讀筆記04 發布日期：2017.6.16 通過結對合作，令我意識到了編寫程序不僅僅要自己能明白，也要便與他人查看和理解自己的程序。 4.1大節提到的代碼規範，我們編寫代碼時要註重代碼風格規
構建之法閱讀筆記（1）
等等 結合 工程 註意 幫助 需求 系統 需要 功能實現 構建之法閱讀筆記（1） 這周我開始了我的閱讀之路，閱讀了構建之法的第一二章。 構建之法的第一章講的是軟件和軟件工程是什麽:軟件=程序+軟件工程。我一開始對軟件工程的理解就是敲代碼，寫程序，其實，事實不是這樣，從書上得
構建之法閱讀筆記3
clas 是我 一個 筆記 自己 dba 漢堡 不能 並且 正確給予反饋： 誰人人前不說人，誰人背後無人說。 反饋的三個層次： 最外層: 行為和後果 當反饋是關於行為和後果時，行為可以改正，後果可以彌補，對方還是有挽回局面的機會。 中間層: 習慣和動機 當
構建之法閱讀筆記4
多少 驗收 廣告 入口 進行 行動 今後 設計師 提供商 典型用戶分析： 寫一個軟件的時候要為用戶考慮，用戶在哪裏，有多少用戶是團隊在需求分析和設計階段要反復琢磨的問題。 百分之百按照用戶要求做是不行的，還要 1、找到用戶語言行動背後的動機。 一個典型用戶描述了一組用戶的
構建之法 學習筆記04
部分 使用 用戶 != 工作 應該 覆蓋率 錯誤處理 必須 關於軟件工程的一些基本概念和技術 單元測試 絕大部分軟件都是由多人合作完成的，大家的工作互相有依賴關系。最典型的的例子就是，某人負責的模板的功能被其他人調用。軟件的額很多錯誤都是來源於程序員對模塊功能的誤解、疏忽或
構建之法——讀書筆記（5）
exp 時間 微軟 padding 層次結構 敏捷 參加 解決問題 企業 第七章 MSF What is MSF?——Microsoft Solution Framework（微軟解決方案框架）即一個方法論，也就是微軟推薦的軟件開發方法。 MSF基本原則： MSF沒有像敏捷
構建之法閱讀隨筆一
什麽 的人 超級 年輕人 他也 工作效率 隨筆 批評 那是 《構建之法》一書已完成了第一遍的閱讀，接下來，我將隨機抽取其中的一段進行精讀。 移山公司的項目進行了一段時間，TFS上也積累了不少數據。大栓做了“數據挖掘”，整理出來一些統計信息，向各位領導匯報。 大牛：哇！前端組
浪潮之巔閱讀筆記01
微軟公司 發展 應該 協議 新的 bsp 用戶 自己 微軟 浪潮之巔閱讀筆記01 這本書是一本IT行業歷史書，從一百年前算起，AT&T 公司、IBM 公司、蘋果公司、英特爾公司、微軟公司、思科公司、雅虎公司和Google公司都先後被幸運地推到了浪尖。雖然，它們來自不
構建之法——讀書筆記（9）
add 體驗 領域 color 讀書筆記 幫助 做什麽 目標 網站 本周粗略的過了一遍第12章。 第12章 用戶體驗 其實，計算機軟件的用戶界面（User Interface， UI）和用戶體驗（User eXeperience，UX）是一個有著豐富內容的學術領域，軟件工
構建之法-----閱讀問題（一）
閱讀 原因 開發流程 閱讀內容 簡單的 天都 不能 作者 敏捷開發 閱讀內容：第六章 敏捷開發流程 在敏捷開發流程中，作者提出了一個觀點-----每日立會，在聽老師講的過程中，覺得這種模式很好，在每日立會中，定義好任務究竟是什麽？完成這個任務的時間是什麽？能夠及時發現自己
《2017-12-01構建之法：現代軟件工程-閱讀筆記》
導致 goto 邏輯錯誤 空白 時間 模式 程序 出席 斷言 1.代碼規範可以分為兩個部分： （1）代碼風格規範。主要是文字上的規定，看似表面文章，實際上非常重要。 （2）代碼設計規範。牽涉到程序設計、模塊之間的關系、設計模式等方方面面的功用原則。 1.1 代碼設計風格：（
構建之法之閱讀筆記01
計算 增加 避免 維護 方便 需求 構建 修改 完全 在閱讀了阿超的所經歷的事情後，讓我了解到了軟件構造的過程，從一開始的出計算題目，到用戶（老師和學生）的要求，需要實現以下功能：題目避免重復，可以定義出題的數目，以及算式的種類，等等。從出我得出，一個軟件的構建的開始是
《構建之法》閱讀筆記01
數據 數據結構 方法 bsp 系統 運營 探索 愛好 復雜 我們之前常說“程序=數據結構+算法”，但很多人都對這個結論有很多的分歧，認為正確的結論應該是“軟件=程序+軟件工程”，確實後邊的結論是前邊的改善，比如當寫了一個二叉樹的遍歷算法的實現，在這裏二叉樹是數據結構