軟體過程與方法---課堂總結3 第四章 敏捷過程模型
敏捷陣營
傳統方法學家陷入了誤區，樂於生產完美的文件而不是滿足業務需要的可執行系統。
傳統軟體工程陣營
敏捷方法學家是一小撮自以為樂不起的黑客，他們妄圖將其手中的玩具軟體放大到企業級軟體而製造出一系列轟動。
問題：
Ø 什麼是最佳實現途徑？
Ø 如何構建滿足使用者當前需要的軟體，同時展示具有能滿足客戶長期需求的擴充套件能力？
兼顧兩派的優點則雙方都能得到很多好處，而相互誹謗則而這都將一無所獲。
（3）敏捷過程中“人的因素”
l 敏捷開發關注個人的才智和技巧，根據特定人員和團隊來塑造過程。
l 敏捷過程是可以滿足人員及團隊需求的過程模型。
敏捷開發是以人為核心的，是迭代的，是循序漸進的。
（4）有效的敏捷團隊，其成員應具備的特點
ü 基本能力
ü 共同目標
ü 精誠合作
ü 決策能力
ü 模糊問題解決能力
ü 相互信任和尊重
ü 自我組織
4.3敏捷過程模型
所有敏捷過程模型都遵循敏捷軟體開發宣言和敏捷原則，每種模型又各有特點：
極限程式設計（XP） 8%
SCRUM 49%
自適應軟體開發 22%
（1）XP（極限程式設計，eXtremeProgramming)由KentBeck在1996年提出，是一個輕量級的，靈巧的軟體開發方法，使用面向物件方法作為推薦的開發範型。
l 適用於10人一下專案組，開發地點集中的場合。
l 廣泛用於需求模糊和揮發性強的場合。
（2）XP的基本觀點
軟體開發是人與人合作進行的過程，因此成功的軟體開發過程應該充分利用人的優勢，而弱化人的缺點，突出人在軟體開發過程中的作用。
（3）XP的核心價值觀
溝通問題往往是由於開發人員與設計人員，設計人員與客戶之間的溝通不暢造成的。
簡單在系統可執行的前提下，做最簡單的工作。時刻保持程式碼的簡單，無冗餘。
反饋儘快獲得使用者反饋，越詳細越好，使得開發人員能夠保證自己的成果符合使用者的需要。
勇氣“擁抱變化”對於使用者的反饋，要用於對自己的程式碼進行修改，丟掉壞的程式碼。
（4）XP適用範圍
xp適合規模小，進度緊，需求變化大，質量要求嚴的專案
功能需求可以固定的，可以作比較精確的需求設計的，生命週期很長的，超大型軟體專案不適於適用XP方法。
n XP是一種高度動態的過程，它通過非常短的迭代週期來應付需求的變化。
n XP體現開發團隊的人員價值，激發參與者的情緒，最大限度地調動開發者的積極性，提高開發的軟體質量。
（5）XP過程框架
4.3.1極限程式設計2
XP包含4個框架活動 策劃 設計 編碼 測試
（1）策劃
l 建立使用者故事
l 確定故事權值（優先順序）
l 確定故事成本（開發週數）
l 確定一下個釋出版本，排序待開發故事。
第一個發行版本釋出之後，XP團隊將計算專案的速度。專案速度用來幫助團隊建立後續發行版本的釋出日期和進度安排，同時判斷整個專案是否存在過分承諾。
（2）設計
l 嚴格遵循KIS原則 （keep it simple)
l 提供故事的實現原則（不多也不少，不做額外功能性設計）
l 組織和當前增量相關的物件和類，CRC建模（類名，類的職責，類的協作關係）CRC卡片
l 對設計困難的故事提出Spike Solution
l XP鼓勵構建重構和設計重構
設計和編碼同時發生。設計隨著系統的構建連續進行，構建又為設計提供指導。
(3)編碼
l 測試驅動開發（TDD) 程式碼未動，測試先行XUnit JUnit NUnit CPPUnit
l 結對程式設計 兩個人一起組隊
l 持續整合 每日整合
(4)測試
l 建立通用測試集，每日整合
l 使用測試自動實施框架，支援即時迴歸測試 （黃金測試集）
l XP驗收測試
(5)XP的12個優秀實踐
ü 現場客戶
ü 計劃博弈
ü 系統隱喻
ü 簡單設計
ü 結對程式設計
ü 集體擁有程式碼
ü 測試驅動
ü 小型釋出
ü 程式碼重構
ü 持續整合
ü 每週40小時工作制
ü 程式碼規範
**現場客戶
l 隨時能聯絡到客戶是XP方法的基本要求之一
l 所有階段要求客戶強參與
u 編寫需求
u Release反饋
u 參與測試
**計劃博弈（Planning Game)
(1)劃分迭代週期
(2)要求結合專案進展和技術情況，確定下一階段要開發與釋出的系統範圍
技術人員作出具體的成本和科技估計
客戶根據成本和商務價值來選擇要實現的特性
**系統隱喻（System Metaphor)
l 通過一個簡單的關於整個系統如何運作的隱喻性描述(story)指導全部開發
l 隱喻可以看做是一個高層次的系統構想，通常包含了一席可以參照和比較的類和設計模式。
l XP不需要實現進行詳細的架構設計。
**簡單設計（Simple Design)
l XP認為：需求是會經常變化的，因此設計不能一蹴而就，應該是一項持續進行的過程。
l 簡單設計應滿足以下原則：
n 向開發人員清晰描述編碼及其內在關係
n 儘可能包含最少的類和方法
n 不包含重複的程式碼
n 成功執行所有測試
**結對程式設計(Pair Programming)
（1）
|
兩個程式設計師，同一套裝置，一起工作 一個駕駛，一個導航
（2） 角色
（3） WHY？可以提高質量
（4） Who not suitable do?
（5） Xper's Quality?
（6） HOW TO
二
l 提供不間斷的Design review ,UnitTest Review,Code Review,Document Review提高程式碼質量。
l 互相督促可以提高程式碼的可讀性和可維護性
l 培養Teamwork精神，避免個人英雄主義
l 頻繁的交流，增進知識經驗的交流
三
l 角色呼喚可以讓程式設計師輪流工作，從而避免出現過度思考而導致觀察力和判斷力出現偏差。
l 同伴的潛在壓力，使得程式設計師更認真的工作。
l 每個人每天的有效工作時段不超過3-4個小時。
l 潛意識的有利競爭。當人在一個團隊中工作，總是下意識的努力展現自己的優點。
l 工作及時得到同伴的肯定，自信心和成就感增強。
l 覺得工作是一件愉快的事情
四不適合的人：
太過自負
l 不能容忍別人的一件
l 我總是對的
l 我吃鹽多過你吃米
太過自卑
l 沒主見
l 沒責任心
五XPer應該具備的基本素質：
誠實，公正，開明，勇敢，謙卑
在這些素質的基礎之上，才是對技術水平，能力和天分等的要求。
(6)HOW TO 結對程式設計?
l Driver
u 寫設計文件（class diagram等）
u 編碼（unit test and businessobject)
l Navigator
u 審閱Driver的文件
u 審閱程式碼
u 考慮Unit Test的覆蓋程度
u 是否需要和如何Refactoring
u 幫助Driver解決具體的技術問題
l 不斷輪換角色，每小時休息15分鐘
l 主動參與
**集體擁有程式碼
（1）開發小組的每個成員都有更改程式碼的權利，所有的人對於全部程式碼負責
這並不意味著開發人員可以互相推諉責任，而是強調所有的人都要負責。如果一個開發人員的程式碼有錯誤，另外一個開發人員也可以進行BUG的修復
**測試驅動
（1） 先測試，在編碼，程式碼未動，測試先行
l Unit Test （正常性和異常性）
l Acceptance Test(Functional Test)
l Regression Test （重用已經建立的所有的測試單元）
l Nightly Test
l Stress Test
（2）所有的測試都應該獨立的自動的執行
**小型釋出
在非常短的週期內以遞增的方式釋出新版本，從而可以很容易地估計每個迭代週期的進度，便於控制工作量和風險；同時，也可以及時處理使用者的反饋。
**程式碼重構（Refactoring）
（1）強調程式碼重構的作用，認為應該經常進行重構。
程式碼重構是指在不改變系統行為的前提下，重新調整，優化系統的內部結構以減少複雜性，消除冗餘，增加靈活性和提高效能。
（2）Why Refacing？
l 是對軟體內部結構的一種調整，目的是在不改變外部行為的前提下，提高其可理解性，降低其修改成本。作用：
l 改進軟體設計
l 提高程式碼質量，使其更易被理解
l 提高開發速度
（3）When Refactoring？
1.新增新功能時
2修補錯誤時
3 Code Review時
通常有兩個關鍵點應該進行重構；
一個功能實現前和實現後。
（4）When No Refactoring？
1.程式碼太混亂，設計完全錯誤
2明天是DeadLine
3 Refactoring的工作量影響最後的期限
（5）Refactoring Vs Add New Feature
Add New Feature：不應該修改既有程式碼，只管新增新功能。
Refactoring：不能再新增功能，只管改程序序結構。此外你不該新增任何測試（除非發現有先前遺漏的東西）
（6）Refactoring Vs Design
設計難以貫穿軟體開發全過程
需求改變---------》設計變更，
How About our Codes？ 用重構去輔助設計！！
（7）Refactoring Vs Performance
重構常常會使軟體執行更慢，但它也使軟體的效能優化更易進行。
當你擁有了重構的經驗，你也就有能力在重構的基礎上來改程序序的效能。
（7） How toRefactoring ？
《重構—改善既有程式碼的設計》[美]Martin人民郵電出版社
l 重新組織你的函式
l 在物件之間搬移特性
l 重新組織資料
l 簡化條件表示式
l 簡化函式呼叫
l 處理概括關係
**持續整合
提倡在一天中整合系統多次，而且隨著需求的改變，要不斷的進行迴歸測試。因為，這樣可以使得團隊保持一個較高的開發速度，同時避免了一次系統整合的惡夢。
**每週40小時工作制
要求專案團隊人員每週工作時間不能超過40小時，加班不得連續超過兩週，否則反而會影響生產率。
不加班，不熬夜。
**程式碼規範
強調通過制定嚴格的程式碼規範來警醒溝通，儘可能減少不必要的文件。
沒有一個統計的編碼規範會造成團隊的每一個成員無法迅速的掌握其它開發人員寫出的程式碼，影響團隊整體的協作性。
（1）Scrum是一個輕量級的敏捷開發框架，是一個增量的，迭代的開發過程。其核心準則就是自我管理和迭代開發。
l 自我管理：管理者不再發號施令，由團隊自己尋找最佳的工作方式完成任務
l 迭代開發：專案由若干個開發週期構成，每個週期均提交一個系統的增量版本
（2）Scrum目標
ManageComplexity,Unpredictability and Change through Visibility,Inspection andAdaptation通過高透明性，檢驗和適應性來管理複雜性，不可預測性和變化。
（3）SCRUM的核心價值觀
承諾：建立在目標之上的來自內心的接受和應許
專注：不準一注意力，把經理全部集中在承諾的事務上
公開：保持一直讓任何有興趣的人員都可以獲知專案當前狀況
尊重：每個團隊成員都必須被尊重的看待，大家一起制定工作規範
勇氣：為負責任的交付產品，有足夠的勇氣來說”不“
（4）SCRUM的運作原理
哲學基礎
授權於開發團隊，滿足客戶需求。
管理文化
幫助他人完成目標
技術工具
通過學習過程作出基於適時的決策。
溝通和反饋是一切的基礎，即時的反饋是擁抱變化的前提條件。
（5）SCRUM框架
Scrum的三個角色、Scrum的五個儀式和Scrum的四個工作
（6）Scrum的產品Backlog
l 產品Backlog是按照商業價值排序的需求列表
l 列表條目的體現形式通常為使用者故事
l 產品呢負責人負責產品Backlog的內容，可用性和優先順序排序
l 產品Backlog的內容和排序都是動態的
（7）SCRUM的Sprint
ü Sprint的長度通常為2-4周，一旦確定不允許延長或縮短。
ü 每個Sprint中，團隊從產品Backlog中挑選最有價值的需求進行開發，一個Sprint週期內需求不發生變更。
ü 團隊構成和質量目標在Sprint中均保持不變
ü 在每個迭代結束時，Scrum團隊將交付潛在可交付的產品增量。
ü Sprint之間沒有時間間隔。
（1）Scrum的三個角色
**產品負責人（Product Owner）
Ø 確定產品功能，負責提出和維護產品Backlog
Ø 決定產品的釋出日期和釋出內容
Ø 為產品的投資回報率（ROI）負責
Ø 根據市場價值確定功能優先順序
Ø 在每個Sprint開始前調整功能和調整功能優先順序
Ø 在Sprint結束時接受或拒絕接受開發團隊的工作成果
**Scrum Master
Ø 保證團隊資源完全可被利用並且全部是高產出的
Ø 保證各個角色及職責的良好協作
Ø 解決團隊開發中的障礙
Ø 作為團隊和外部的介面，遮蔽外界對團隊成員的干擾
Ø 保證開發過程按計劃進行，組織會議
Ø 記錄每天完成的工作量，更新燃盡圖
**Scrum團隊
SCRUM團隊負責在每個Spring中將產品Backlog中的條目轉化成為潛在可交付的功能增量
Ø Scrum團隊的規模控制在5-9個人
Ø Scrum團隊是跨職能的團隊
Ø Scrum團隊是自組織的
（2）Scrum的五個儀式
**釋出計劃會議
Ø 確立專案整體釋出目標和預期結果
Ø 確定具有最高優先順序的產品Backlog條目，重大風險和釋出所包含的全部特性和功能
Ø 確立大致交付日期和費用，以每個Sprint為基礎調整發布計劃
Ø 產品負責人確定產品Backlog的優先順序排列
Ø 團隊成員為產品backlog條目做工作量估算
Ø 使用計劃指派進行工作量估算
Ø 工作量估算的單位為“故事點”
Ø 一個故事點相當於理想的1個人天的工作量
**Sprint計劃會議（8小時以內）
Ø 把既定產品Backlog，Sprint時間表，Sprint評審會議的結果，Sprint回顧會議的結果公開給所有人
Ø 產品負責人向團隊闡述產品願景，介紹最高優先順序的產品Backlog條目
Ø 團隊選擇產品Backlog條目，確定Sprint目標
l 利用“昨日天氣”計算“投入程度”（focus factor)
(focus factor)=(actualvelocity)/(available man-days)
l 利用投入程度計算本次Sprint中可以完成的“故事點”
(availableman-days)*(focus factor)=(estimated velocity)
Ø 團隊成員將Backlog分解為多個1天以內可以完成的任務，考慮所有工作細節，調整目標
Ø 任務列表構成Sprint Backlog
**每日站會（15分鐘）
團隊成員間工作進度的溝通和協調
Ø 維護Sprint Backlog上的所有任務（增刪改，重新排序）
Ø 確認任務狀態（“待處理”，“正在處理”，“已完成”）
Ø 問題：
ü 上次會議時的任務哪些已經完成？
ü 下一次會議之前，你計劃完成什麼任務？
ü 有什麼問題阻礙了你的開發（如果有阻礙你開發進度的問題，把該障礙加入到障礙Backlog中）
“任務板”
**Sprint評審會議（4小時）
根據本Sprint所釋出的版本，評審相關Backlog中的條目，檢查是否已達到Sprint的目標。
Ø 團隊按Sprint Backlog中的條目，逐個的介紹結果，演示新功能。
Ø 如果產品負責人想改變或對功能有新的想法，則新增新條目到產品Backlog中
Ø 如果小組報告專案遇到問題現在還沒能解決則把該問題加入到障礙Backlog。
**Sprint回顧會議（3小時）
通過總結以往的時間經驗來提高團隊生產力
Ø 回顧會議以頭腦風暴的方式Review Sprint過程和結果，發現和列舉存在的問題
Ø 與會人員投票決定需要在下個Sprint中解決的1-3個問題，探討解決方案，確定時間方式。
ü 本次Sprint中最為重要的是什麼？
ü 成功經驗是什麼？
ü 有什麼地方能夠改進的？
（3）Scrum的四個工作
l 產品Backlog
l SprintBackLlog
l 釋出燃盡圖
l Sprint燃盡圖
**Sprint燃盡圖
燃盡圖（BURN DOWN CHART)是在工作完成之前，對需要完成的工作的一種視覺化表示。
**釋出燃盡圖
Ø 前期：產品負責人整理業務需求，形成Product Backlog庫
Ø 執行：
ü 以Sprint為單位迭代式的完成Sprint Backlog
ü 每個Sprint以Sprint Planning開始，通過每日例會跟蹤進度和issue
ü Spirnt結束時進行評審，交付可執行的產品
Ø 後期：
ü 每個Sprint完成後，通過Sprint回顧發現問題和改進點
ü 制定下個Sprint要引入的新的實踐
（4）Scrum特點：
l Scrum規定了一個非常簡單的開發流程，是現有設計流程的總結。
l Scrum以團隊為基礎，是一種在需求迅速變化情況下迭代的，增量的開發系統和產品的方法。
l Scrum是一個控制由利益和需求衝突導致的混亂的流程。
l Scrum是改善交流並最優化合作的方式。
l Scrum是一種檢測產品開發和生產過程中障礙並將其取出的方式。
l Scrum是最大化生產率的一種方法。
Scrum適用範圍
Scrum適用於列印的專案到整個企業，可以以控制並組織多個具有相關性的產品開發，擁有超過千名開發者和執行者的專案實施過程。
Scrum能讓每個參與者都對自己所做的工作以及自己做出的貢獻感到驕傲，並讓他們發揮到最佳水平。
（5）Scrum VS XP
l XP與Scrum是敏捷方法中被業界採用最為廣泛的郎中實踐。
l Scrum注重的是管理和組織實踐，而XP關注的是實際的程式設計實踐，兩者都聚焦於資訊價值流和資訊溝通除了迭代長度稍有差別外，大多數Scrum實踐與XP是相容且相互補充。
組合使用Scurm和XP會有顯著收穫！
結對程式設計，測試驅動開發，持續整合等XP的最佳實踐仍然可以在Scrum中使用。
4.4小結
（1）敏捷開發是一種以人為核心、迭代、循序漸進的開發方法
l 敏捷過程強調適應性而非預見性
l 敏捷開發方法“面向人”而非“面向過程”
（2）敏捷過程模型有利於解決慣性過程模型中的問題：
Ø 版本釋出的時間越來越長
Ø 無法按時釋出
Ø 釋出最後階段讓軟體穩定的時間越來越長
Ø 制定計劃時間長，不準確
Ø 釋出期間難以進行變更
Ø 質量持續惡化
Ø 穩定化階段拼命加班挫傷士氣
（3）敏捷開發的誤區
l 誤解一：敏捷對人的要求很高
l 誤解二：敏捷沒有文件，也不做設計
l 誤解三:敏捷好，其他方法不好
l 誤解四：敏捷就是XP，就是Scrum
l 誤解五：敏捷很好，要制定標準，所有專案都要遵循這個標準
相關推薦
軟體過程與方法---課堂總結3 第四章 敏捷過程模型
敏捷陣營 傳統方法學家陷入了誤區，樂於生產完美的文件而不是滿足業務需要的可執行系統。 傳統軟體工程陣營 敏捷方法學家是一小撮自以為樂不起的黑客，他們妄圖將其手中的玩具軟體放大到企業級軟體而製造出一系列轟動。 問題： Ø 什麼是最佳實現途徑？ Ø 如
【知識點總結】第四章 類與對象
分享 ima src 對象分配 height ted 公有 功能 簡化 面向對象程序設計的基本概念和特征 抽象性：對對象進行概括，抽出一類對象的公共性質並加以描述的過程。【數據抽象、行為抽象】 封裝性：將抽象得到的數據、行為、功能相結合，形成一個有機的整體。就是將數據與
_.NET深入體驗與實戰精要.pdf第四章
blog windows開發 -1 這一 函數 center 定位 應用 以及 _.NET深入體驗與實戰精要 第四章 這一章節主要向我們介紹了如何認識Windows窗體編程， 向我們描述了Windows窗體編程的好處，能夠提供豐富 的用戶體驗，以及對本機系統環境
《文獻管理與信息分析》第四章
cnblogs post 期刊 分析 關系 命令 .com 未使用 -m 第四章主要介紹了中文數據庫的使用，將之前未使用過的功能或特色總結如下： 1.CNKI的文獻互引網絡功能：將所選文章選中，點擊計量可視化分析，即可得到所選文章之間的關系。 2.萬方收錄偏期刊文獻，支持
Windows核心編程之核心總結（第四章 進程（一））（2018.6.8)
Windows核心編程之核心總結學習目標 第四章進程的學習可謂是任重而道遠，雖然不難，但知識量很多，也比較零散，需要多總結，腦海裏才有進程的框架。所以，我把本章分為幾個小節來講完。我還是一如既往的添加輔助性內容，希望對於小白有所幫助。而比我流弊的大有人在，大神們可以跳過輔助性內容。本小節的學習目標如下：1.C
Windows核心編程之核心總結（第四章 進程（二））（2018.6.17)
函數的參數 設置 函數詳解 可執行文件 一次 HA AC 關聯 原型 學習目標 上一節我們了解了進程、入口函數和進程實例句柄等內容，在進入進程的命令行學習前，有一個全局變量初始化問題需要測試一波。本節的學習目標如下：1.測試C/C++運行庫啟動函數初始化哪些全局變量2.進程
Windows核心編程之核心總結（第四章 進程（三））（2018.6.21)
擁有 mar eset cto 繼續 detached iat head opera 學習目標 本章節將學習以後經常用到的CreateProcess函數，聽網上的人說有些面試官喜歡問這個函數的大概功能和參數作用哦，可見這個函數是十分重要滴，那我們來詳細了解和測試這個函數的功
計算機網路自頂向下方法 習題參考答案 第四章
複習題 R1. 網路層分組叫做資料報。路由器處於第三層的，鏈路交換機是第二層 R2. 資料報網路中兩個最重要的功能是：轉發和路由，虛電路網路中增加了一項：連線建立 R3. 轉發是指在路由器內部將輸入埠的分組轉移到正確的輸出埠；而路由是指路由器決定從源到目的地的路徑
資料結構與演算法分析課後習題第四章：樹
習題4.1 4.2 4.3 解答：三題考察樹的基本性質，以下貼出樹的基本概念： 結點的度：節點擁有子樹的數目 葉子：度為0的結點 分支結點：度不為0的結點 樹的度：樹中結點的最大的度 層次：根結點的層次為1，其餘結點的層次等於該結點的雙親結點的層次加1 樹的高度：樹中結點的最大層
【總結】第四章 數組
src 增強for 有序集合 常用類 new ++ 二分查找 [] ava 1. 數組是相同類型數據的有序集合。 2. 數組的四個基本特點： -- 其長度是確定的 -- 其元素必須是相同類型 -- 可以存儲基本數據類型和引用數據類型
【總結】第四章 陣列
1. 陣列是相同型別資料的有序集合。 2. 陣列的四個基本特點： -- 其長度是確定的 -- 其元素必須是相同型別 -- 可以儲存基本資料型別和引用資料型別
資料結構與演算法分析課後習題第四章(4)
4.40 Write a routine to list out the nodes of a binary tree in level-order. List the root, then nodes at depth 1, followed by nodes at dep
HeadFirst設計模式總結_第四章工廠模式
讀後總結：(主要參考P160+P161) 1.依賴倒置原則：P142（抽象化的思想設計，面向介面程式設計，面向擴充套件而不是面向修改。） 變數不可以持有具體類的引用；（基類使用new，即持有具體類的引用，使用工廠方法將new具體類部分下放到子類中，即行如。。= ne
Python之旅.第四章.模塊與包.總結（未完待遇）
standard 後綴 att 擔心 lse 綁定 做的 業務 搜索 一、模塊 模塊： 一系列功能的集合體，在python中一個py文件就是一個模塊，模塊名就是py文件的文件名； 模塊的好處： 1.減少重復的代碼 2.拿來主義 定義模塊： 就是創建一個py文件；
組合語言課堂總結3——記憶體訪問
記憶體中字的儲存 8086CPU中，用16位暫存器儲存一個字，而在前面的學習中瞭解到記憶體是以位元組為單位劃分的，所以一個字要用兩個地址連續的記憶體單元來存放，這就提出了字資料的存取原則（小端法）：高—高，低—低，即，字資料的低位位元組存放在低地址記憶體單元；字資料的高位位元組存放在高地址記憶體單元；取
Linux內核設計與實現 總結筆記（第四章）進程調度
什麽 原則 好的 nic 調度系統 相交 中間 使用 就是 進程調度 調度程序負責決定將哪個進程投入運行，何時運行以及運行多長時間。 調度程序沒有太復雜的原理，最大限度地利用處理器時間的原則是，只要有可以執行的進程，那麽就總會有進程正在執行。 多任務 多任務系統可以劃分
《第一行程式碼Android》學習總結第四章 Fragment的執行狀態與生命週期
一、Fragment四種狀態 1、執行狀態 當一個Fragment是可見的，同時它所關聯的Activity正處於執行狀態，則該Fragment也處於執行狀態。 2、暫停狀態 當一個Activity處於暫停狀態，與它關聯的可見碎片就會處於暫停狀態。 3、停止狀態 &
第六章 儲存過程 總結
第六章 儲存過程 定義： 儲存過程類似於C#中的函式或JAVA中的方法，主要用來執行管理任務或，應用複雜的業務規則，不僅可以帶引數還可以返回結果，它可以包含資料操縱語句，變數，邏輯控制語句等。 優點： 1.允許模組化程式設計， 一次建立多次使用，並可獨立於程式原始碼
資料庫中介軟體tddl與mycat使用總結
做訂單中心專案的時候正好涉及到了資料庫中介軟體，翻了翻以前的筆記，整理下曾經學習使用過的兩款中介軟體，嗯，簡要總結下。 tddl是淘寶在幾年前推出的一款基於客戶端分片的資料庫訪問中介軟體，mycat(社群活躍)是開源社群基於服務端分片推出的資料庫中介軟體，具體的介紹百度上都