20162330 2017-2018-1《程序設計與數據結構》第二週學習總結

時間 2019-11-14

標籤程序設計與數據結構第二學習總結欄目軟件設計简体版

原文原文鏈接

2017-2018-1 學習總結目錄：　1　2　3　5　6　7　9　10　11　12
html

Comparator 接口：強行對某些數組或集合進行排序，在一個獨立的類中實現比較。算法
Comparator接口與Comparable接口的區別：首先，存在於不一樣的包中，Comparator 位於 java.util 包下，Comparable 位於 java.lang 包下。其次，前者在一個獨立的類中實現比較（其他類結構不變），然後者將比較代碼嵌入自身類中。兩種接口各有千秋，只有多練習才能體會到其優點。數據庫

2. 泛型方法設計

泛型：具備一個或多個類型變量的類。一個類保存、操做並管理直到實例化時才肯定類型的對象，尖括號內指定元素對象的類型。
例如：構造一個保存 Employee 對象的數組列表：
ArrayList<Employee> staff = new ArrayList<Employee>();
兩邊都使用類型參數 Employee 有些繁瑣。在Java SE 7 中，能夠省去右邊的類型參數：
ArrayList<Employee> staff = new ArrayList<>();
這樣，new ArrayList<>()便賦值給一個類型爲ArrayList<Employee>的變量了，這就是所謂的 菱形語法 。編程
泛型方法：泛型方法能夠定義在普通類中，也能夠定義在泛型類中。數組

3. 團隊學習：《構建之法》

合做分工 → 大體內容框架 → 提出問題安全

Members	Chapters
袁逸灝	第一、二、3章
劉偉康	第四、五、6章
劉先潤	第七、八、9章
馬軍	第十、十一、12章
劉誠昊	第1三、1四、15章
莫禮鍾	第1六、17章

第 1 章概論

1.1 軟件 = 程序 + 軟件工程
軟件工程的核心部分（狹義，廣義）、軟件工程的地位、軟件開發不一樣階段的不一樣表現。服務器
1.2 軟件工程是什麼
軟件工程的定義、軟件工程所包含的領域、軟件開發的難點、工程的定義、軟件工程並不等於計算機科學，二者有着不一樣的側重點，軟件工程的知識領域，軟件工程的目標，初步學會軟件工程須要達到的要求。數據結構

第 2 章我的技術和流程

2.1 單元測試
保證覆蓋率爲100%，好的單元測試的標準，單元測試能夠提升軟件開發的效率，迴歸（迴歸到之前不正常的狀態）測試。
2.2 效能分析工具：Visual Studio（抽樣、代碼注入）
不經分析就盲目優化，也許會事倍功半。
2.3 我的開發流程（PSP）
PSP任務清單（大學生VS工程師），PSP的特色。
2.4 實踐
當前程序設計做業簡單，無太多擴展、擴展的方面、作項目的時候須要對項目的處理；
開放 – 封閉原則：容許擴展，不容許修改。

第 3 章軟件工程師的成長

3.1 我的能力的衡量與發展
我的能力在團隊中的做用與影響、我的應當承擔的責任、我的的成長記方式。
3.2 軟件工程師的思惟誤區
不要總想着在短期內搞個大新聞，要結合自身實際，求穩，而後再擴展。
3.3 軟件工程師的職業發展
3.4 技能的反面
注重本身的技術，要避免懂得「技術」但仍然常常犯一些低層次的問題。

第 4 章兩人合做

4.1 代碼規範（風格、設計）
4.2 代碼風格規範（簡明、易讀、無二義）
縮進（4個空格）、行寬、括號、斷行與空白的{}行（每一個{和}獨佔一行）、分行、命名、下劃線、大小寫、註釋（What、Why）。
4.3 代碼設計規範
函數、goto、錯誤處理（參數處理、斷言）、處理類。
4.4 代碼複審（自我、同伴、團隊）
爲何（早發現早修復、互相瞭解）、步驟、覈查表（概要、效能、可讀性等）。
4.5 結對編程（極致）
爲何（高投入產出比）、不間斷地複審、角色互換。
4.6 兩人合做的不一樣階段和技巧（萌芽、磨合、規範、創造、解體）
影響他人的方式、正確反饋（多層次）。

第 5 章團隊和流程

5.1 非團隊和團隊
非團隊（獨立、烏合之衆）、團隊（共同目標、合做）。
5.2 軟件團隊的模式（~~窩蜂模式~~）
主治醫師、明星、社區（衆人拾柴火焰高）、業餘劇團（不一樣角色）、祕密團隊（無干擾）、特工團隊（高手）、交響樂團（各司其職）、爵士樂（個性化表達）、功能團隊（小組交流）、官僚（不提倡）。
5.3 開發流程（統一體系）
寫了再改、瀑布模型（分析-->設計-->實現-->銷售-->維護）、統一流程、漸進交付（MVP）、TSP原則

第 6 章敏捷流程

6.1 敏捷的流程簡介（找出待解決的問題 --> 決定當前目標 -->衝刺（每日例會）--> 改進）
6.2 敏捷流程的問題和解法（計劃：體現依賴關係-->描述細化到技術層面 --> 跟蹤三個時間 --> 總結教訓）
6.3 敏捷的團隊
自主管理（本身挑選任務）、自我組織（聯合負責）、多功能（全面負責）。
6.4 敏捷總結
質量控制、短期迭代、極致編程、經驗教訓。
6.5 敏捷的問答
敏捷是一種價值觀、總結思想、最佳實踐TDD、適用範圍、宣言（左項）。

第 7 章 MSF

微軟解決方案框架（Microsoft Solution Framework，MSF）,是微軟公司經過吸收各部門積累的業務經驗並隨着時代更新的軟件開發方法。其主要原則有9點：推進信息共享與溝通、爲共同的遠景而工做、充分受權和信任、各司其職，對項目共同負責（不只要完成本職工做，更要對項目負責）、重視商業價值、保持敏捷，預期變化、投資質量（投資的效率，時期並要求長期）、學習全部的經驗（要堅持總結和分享）、與顧客合做（從用戶角度出發）。
用戶調研（User Study），A/B測試，經過態度、行爲、定性、定量來規範調研的尺度。

第 8 章需求分析

軟件需求
將需求進行分類、清楚軟件產品的利益相關者、獲取用戶需求（用戶調研）、競爭性需求分析的框架、功能的定位和優先級、目標估計和決心、找出估計後面的假設、最後分而治之。
經驗公式： Y = X ± X ÷ N
工程師的經驗公式實際時間花費主要取決於兩個因素—對某件事的估計時間X，以及他作過相似開發工做的次數N。
提案，評估和WBS
NABC model（N--need需求、Approach--作法、Benefit--好處、Competitors--競爭、Delivery--推廣方式）
評估：目標（根據實際的需求來定）、決心（它承諾在特定日期交付預約義的功能，做爲特定的質量級別）、估計（單個任務花費的人力、時間）
WBS – Work Break Down
分而治之，頂層（產品）→中層（功能）-用戶視角→較低級別（功能實現）-團隊透視圖（PM，test）→最低級別（模塊）-開發透視圖

第 9 章項目經理

風險管理
第一步：確認風險、根據不一樣的來源對風險進行分類；
第二步：分析和優先級劃分；
第三步：計劃和管理風險
應對風險的方法：進一步研究、接受、規避、轉移、下降、制定應急計劃
項目經理（PM），PM負責除產品開發和測試以外的全部事情，包括正確地作產品和正確地作流程。
PM的做用：收集需求、設計用戶界面，編寫規範、協調市場、文檔、測試、定位、帶領團隊達成決策
【注】項目經理是和你們平等工做，而且作具體工做，和其餘團員一塊兒造成決議，只管事無論人的，和領導型經理是不同的。

第 10 章典型用戶和場景

1、典型用戶

1.典型用戶
定義：描述了一組用戶的典型技巧，能力，須要，工做習慣和工做環境。
電影用戶的角色：也有受歡迎的和不受歡迎之分。
典型用戶的完善：定義了一部分典型用戶後繼續與其中表明進行溝通，進一步完善需求理解。
2.從典型用戶到場景
場景：也能夠是故事，用戶爲達到目標使用系統時經歷的全部過程。
場景的使用：設計者模擬用戶，設計一個場景入口，描述用戶在這個場景的內外部因素，給場景劃分優先級並寫場景。
3.從場景到任務
分層：沿着子系統/模塊的所屬關係把場景劃分開。（例如：P221.UI層，邏輯層，數據庫）
任務與場景：不一樣的任務將會把一個場景編織起來，獲得開發任務後，能夠建立和分配測試任務。

2、用例(Use Case)

1.用例：與典型人物，典型場景的方法相似，一樣是很經常使用的需求分析工具包含這樣的一些基本元素：標題，角色，主要成功場景，步驟，拓展場景。
用例的原則：
- 1.經過簡單的故事來傳遞信息。
- 2.保持對全系統的理解。
- 3.關注用戶的價值。
- 4.逐步構建整個系統，一次完成一個用力。
- 5.增量開發，逐步構建整個系統。
- 6.適應團隊不斷變化的需求。
用例的侷限性：
1.比較適合故事/人物/場景交互的系統。可是對於算法，速度，拓展性，安全性以及和系統技術相關等需求則不適用。
2.故事的粒度沒有統一標準與具體項目有關，初學者較難掌握。
3.既要把UI的細節嵌入每一個故事，又要保證其簡明性是一個難題。

3、功能說明書（Spec）

1.規格說明書
軟件功能說明書：說明軟件的外部功能和用戶的交互狀況。（軟件是一個黑盒子，看不到內部）
軟件技術說明書：又稱設計文檔，說明軟件的內部的設計規範。（透明盒子）
2.功能說明書
從用戶的角度描述軟件產品的功能，輸入，輸出，界面，功能的邊界問題，功能的效率（to user），國際化，本地化，異常狀況等，不涉及軟件內部的實現細節。
3.制定一份Spec
定義好相關的概念，規範好一些假設；避免一些誤解，界定一些邊界條件（定性且定量）；描述主流的用戶/軟件交互步驟；一些好的功能還會有反作用，服務質量的說明。
4.Spec的弊端
枯燥乏味，沒法跟上時間的變化。
5.技術說明書
設計文檔，用於描述開發者如何趨勢線某一功能，或相互聯繫的一組功能。實現軟件功能沒有固定的模板，但總存在着一些規律。

4、功能驅動的設計

設計過程：
構造整體模型 --> 構造功能列表 --> 制定開發計劃 --> 功能設計階段5實現具體功能

第 11 章軟件設計與實現

1、分析和設計方法

1.四個過程：
- 1.需求分析：抽象出咱們真正關心的屬性，實體之間的關係。用戶的需求，如何解決？
- 2.設計與實現階段：軟件如何解決這些需求，現實生活中的實體和屬性在軟件系統中怎麼表現和交換信息？
- 3.4.測試,發佈階段：真的解決了這些需求嗎，軟件解決需求的效率如何，用戶還有什麼新的需求嗎？
2.經常使用方法：
文檔、圖形爲主構造的模型（思惟導圖，流程圖等）、數學語言的描述、用類天然語言 + 代碼構造的描述（Literate Programming）、源代碼加註釋描述。

2、圖形建模和分析方法

表達實體和實體的關係
思惟導圖、實體關係圖、ERD.UCD；表達數據的流動、表達控制流、統一的表達方式（UML）。

3、其餘設計方法

1.形式化的方法：用無歧義的，形式化的語言描述咱們要解決的問題，而後用嚴密的數學推理和交換一步步把軟件實現出來，或者證實咱們的實現的確完整和正確地解決了問題。
2.文學化編程：與「寫程序，時不時寫一些註釋」相反,「寫文檔，時不時寫一些代碼。」

4、從Spec到實現

1.預估開發時間
2.寫一些快速成型代碼，看當作效，查找問題。
3.看到初始效果與瞭解實現細節後，開始寫設計文檔，並與同事進行復審。
4.按照設計文檔寫代碼，解決遇到的問題。
5.寫好代碼後先根據設計文檔與代碼指南進行自我複審，重構代碼。
6.重建或更新單元測試。
7.獲得一個能夠測試的版本，交予相關測試人員測試或者公開測試。
8.修復測試中發現的問題。
9.根據代碼複審的意見修改代碼，完善單元測試和其餘相關代碼，把新的代碼簽入到數據庫中。
2. 把修改集集成到代碼庫中
根據場景和開發任務來決定集成的次序、互相依賴的任務要一塊兒集成。
在測試場景時，要保證端對端的測試。
場景的全部者必須保證場景徹底經過測試，而後把場景的狀態改成「解決」。
3.開發人員的標準工做流程（以下圖所示）

5、開發階段的平常管理

1.閉門造車（Leave me alone）：集中於某一件事情，將本身投入其中，拒絕其餘人的干擾。
2.每日構建（Daily Bulid）：打好基礎，精益求精。
3.「構建大師」：對於一個致使構建失敗的成員，授予這個稱號，並讓他：
負責管理構建服務器 --> 調試構建，負責找錯，並分析出錯的緣由 --> 將這個稱號和責任交予下一位致使構建失敗的成員 --> 構建大師爲團隊「構建之法基金」存入50元，以供你們團隊構建之用。
4.寬嚴皆誤：制定寬嚴標準，以及根據團隊的狀況（勢）所反映的狀況。成員行爲影響我的的儘可能寬鬆，而影響團隊的則要嚴格處理。
5.小強地獄（Bug Hell）：相似於構建大師的選取：選出那些超過bug數標準的成員，讓他們進入小強地獄專職於小強地獄處理bug，直到知足標準出獄，每週公佈進出獄名單。

6、實戰中的源代碼管理

軟件 = 程序 + 軟件工程
軟件的質量 = 程序的質量 + 軟件工程的質量
代碼須要版本管理
在源代碼基礎上進行修改後，留下新版本以及對應的負責人記錄，記載bug的內容，處理人，處理時間，是否處理完成等內容以備查驗。

7、代碼完成

兩個階段：
1.task完成了，設想變成了能夠運行的現實。
2.Bug仍等待着工程師去尋找，修正。

第 12 章用戶體驗

1、用戶體驗的要素

1.用戶的第一印象：5W1H來判斷：Who When Where Why How，用以判斷用戶對產品的設計需求。
2.從用戶的角度考慮問題：從用戶的立場上去使用本身的產品。而不是做爲一個開發者，一個熟知產品構造的人去體驗。
3.軟件服務始終都要記住用戶的選擇。
4.短時間刺激和長期影響：短時間的刺激並不能成爲客戶長期使用的依據。
5.不讓用戶犯簡單的錯誤：設計能讓客戶儘量地避免出錯。例如航班上的閱讀燈與呼叫空乘客按紐。若是把緊急彈射座椅放在經常使用按鈕面板按錯的後果。除了文字徹底沒有區分度的Submit，Cancel按鈕。
6.用戶質量和體驗：有時候質量要給用戶的體驗讓步，才能讓產品更具備吸引力。
7.情感設計

2、用戶體驗設計的步驟和目標

用戶體驗設計的一個重要目標就是下降用戶的認知阻力，即用戶對於軟件界面的認知和實際結果的差距。
以下表：

3、評價標準

1.儘快提供可感觸的反饋。
2.系統界面符合用戶的現實管理。
3.用戶有控制權。
4.一致性和標準化。
5.適合各類類型的用戶。
6.幫助用戶識別，診斷並修復錯誤。
7.有必要的提示和幫助文檔。

4、貫穿多種設備的用戶體驗

第 13 章軟件測試

測試方法名稱很是多，但只不過是從各個方面描敘了軟件測試，並非說有這麼多獨立的測試方法，只要分類處理，也就不會很難理解。
13.1 基本名詞解釋與分類
三個基本名詞：
- Bug：軟件的缺陷
- Test Case：測試用例
- Test Suite：測試用例集
Bug又可分解爲：症狀(Symptom)、程序錯誤(Fault)、根本緣由(Foot Couse)。-
測試設計有兩類方法：黑箱(Black Box)和白箱(White Box)。
【注】是測試的「設計」方法，而非測試方法。
黑箱從軟件的行爲，而非從內部設計出發來設計測試；白箱則可「看到」軟件系統內部。
按測試的目的分類：功能測試、非功能測試。
按測試的時機和做用分類：測試「烽火臺」，以及其餘測試方法。
13.2 各類測試方法（該部分書中爲舉例瞭解）
① 單元測試(Unit Test) 和代碼覆蓋率測試(Code Coverage Analysis)
② 構建驗收測試：驗收系統的基本功能。
③ 驗收測試：拿到一個「可測」的構建之後，按測試計劃測試各自負責的模塊和功能。
④ 「探索式」測試：爲了某一特定目的而進行的測試，且僅此一次，之後通常不重複測試。
⑤ 迴歸測試
⑥ 場景/集成/系統測試：在開發必定階段對軟件進行一個全面系統的測試以保證軟件的各個模塊都能共同工做。
⑦ 夥伴測試
⑧ 效能測試：軟件在設計負載可否提供使人滿意的服務質量。
⑨ 壓力測試：嚴格地說不屬於效能測試，驗證軟件在超過設計負載的狀況下可否返回正常結果。
⑩ 內部/外部公開測試：讓特定用戶使用正在處於開發階段的版本，以便收集更多反饋。
⑪ 易用性測試
⑫ 「Bug」大掃蕩
13.3 實戰中的測試觀念：
1.從項目開始測試人員便要開始介入，從源頭防止問題的發生。
2.測試並不是必定要根據規格說明書來測，更要從用戶的角度出發來測試軟件。
3.測試人員的代碼質量必定要特別高，由於測試人員是最後一道防線。
4.若爲了讓問題儘快顯現，用Debug版本；若爲了儘量測試用戶所看到的軟件，用Release版本。
文檔：在計劃階段就寫出測試總綱與測試計劃，它們主要說明產品是什麼，要作什麼樣的測試，時間安排如何，誰負責哪方面，各類資源在哪等。
13.4 運用測試工具
運用工具記錄手工測試及自動測試。
測試效能：除功能方面的測試，還有「服務質量」
【例子】效能測試： 100個用戶的狀況下，產品搜索必須3S內返回結果。
負載測試： 2000個用戶的狀況下，產品搜索必須5S內返回結果。
壓力測試：壓力高峯期（4000個用戶）持續48小時的狀況下，產品搜索必須保持穩定而不至於崩潰

第 14 章質量保障

14.1 軟件的質量
軟件質量 = 程序質量 + 軟件工程質量
程序質量體如今軟件外在功能。例如一個字處理軟件可否拷貝/粘貼等
軟件工程質量：軟件在功能、成本、時間三方面知足利益相關者的需求。
軟件工程的質量以一套比較成熟的理論CMMI進行衡量。
質量成本組成部分包括預防、評審、內部故障、外在故障四個方面。
14.2 軟件質量的保存工做
軟件的質量保障（QA）和軟件測試（Test）是有很大區別的，所以——測試的角色要獨立出來，全部人均可以參與QA工做，但最後要有一我的對QA這件事負責，最後軟件發佈時，必須獲得此角色的簽字保證。儘管有專人負責測試工做，但保證質量還是全部成員的職責。
不能盲目信任「專業人士」扮演的角色，即便有專業人士扮演的角色，還得有專人獨立地檢查驗證質量。
分工不能「畫地爲牢」，爲了不出現局部最優而全局未必最優，同時也避免因爲軟件被切碎而致使總體不太行。
分工不能無明確責任。

第 15 章穩定和發佈階段

15.1 從代碼的完成到發佈
軟件生命週期的最後階段每每是最考驗團隊的，不但考驗團隊項目管理水平、應變能力，也考驗團隊的「血型」。
原計劃的軟件發佈時間快到了，可是軟件還存在各類問題，因而有了4種團隊血型：
A型：他們知道優秀的軟件公司會發布有已知缺陷的軟件。
B型：他們不相信這一點。
O型：他們不知道這一點，所以嘴巴驚訝成O型。
AB型：他們對於本身開發的軟件是A型，對於別人開發的軟件是B型。

從代碼完成到最終發佈軟件
會診小組：軟件團隊的各個表明組成會診小組，處理每一個影響產品發佈的問題，對於每個Bug，會診小組要決定採起何種行動：1.修復 2.設計原本如此 3.不修復 4.推遲
複雜項目的會診招數：
設計變動、搞定全部已知Bug、最後迴歸測試、砍掉功能（不能由於之前花了成本，就要求之後必定要完成某個任務）、修復Bug的門檻逐漸提升、逐步凍結。
15.2 使用不一樣頻率和不一樣覆蓋範圍的漸進發布
產品同時對不一樣的目標用戶用不一樣的頻率發佈，以適應不一樣羣體的需求。
15.3 發佈以後——過後諸葛亮會議
這個軟件生命的週期結束之後，如屍體解剖同樣，把給軟件的開發流程剖析一下。

問題集錦

一、軟件構建的過程當中，何爲連接參數？

二、在程序理解階段，爲了可以使不一樣的人接手非本身的代碼，打代碼的時候應該要注意什麼方面？

三、商業模式是否真正地直接可以決定一個軟件企業地成敗？

四、在軟件開發階段中愛好者怎麼才能晉升爲先行者？

五、軟件工程開發有着較高的難度，但不表明不能進行開發，如何能使咱們可以克服軟件開發過程當中的難題呢？

六、該如何使單元測試給自動化？

七、主治醫師模式：在一個團隊中如何避免一個學生幹活，其他學生跟着打醬油？

八、明星模式：如何使團隊的利益最大化，而不是在明星光芒四射時使自身利益最大化？

九、如何在不影響效率的狀況下有效記錄三個跟蹤的時間值：實際剩餘時間、預估剩餘時間、實際花費時間？

十、如何培養一我的或者一個團隊把重要和有效的作法發揮到極致的能力？

十一、軟件工程和咱們的課程程序設計與數據結構有什麼不一樣？構建之法上的哪些內容能夠徹底應用到咱們的課程中？

十二、在進行用戶調研的過程當中，爲何不能調研細微到毫釐，即作調研作過頭？

1三、一個團隊成熟的標記，就是對風險的管理，在《構建之法》中如是說，咱們對待風險該採起什麼樣的態度呢？

1四、關於項目經理PM，書中提到一個團隊能夠有不少PM，若是一個團隊中針對一個項目造成了多個決議，這種窘況該如何解決呢？

1五、project manager 和 program manager 的區別在於前者管事也管人，後者只管事無論人，因此PM須要有很強的領導力嗎？

1六、在設計用例時如何既鑲嵌UI的細節又保證故事的簡明性？

1七、用戶的體驗和產品的質量一樣重要，那麼他們衝突時應該平衡至什麼地步？

1八、在設計典型場景時須要保持模擬內容的簡明性仍是模擬全部可能發生的事件，不管是否與需求有關？

1九、成本的主要組成部分是由什麼而產生？

20、結構和實現又有什麼樣的關係？

2一、代碼覆蓋率是什麼？它重要在哪？

2二、理想的覆蓋率分析工具是怎樣的？

【返回目錄】

本週學習中的問題和解決過程

【問題】我在最開始接觸泛型時以爲泛型的語法有些麻煩，對於數組來講自身就有定義方式，那麼相對於其餘類、其餘方法，泛型有哪些的好處，又有哪些弊端？
解決方案 ：課堂上聽完婁老師對泛型的講解，課後也閱讀了相關資料，大體瞭解了泛型的好處。首先，泛型程序設計意味着編寫的代碼能夠被不一樣類型的對象屢次重用，然而在Java增長泛型以前，ArrayList類也能夠彙集任何類型的對象，爲何後來要增長泛型呢？原來是由於 ArrayList 這種方法有兩個問題：第一，當獲取一個值時必須進行強制轉換，例如：

ArrayList files = new ArrayList();
String filename = (String) files.get(0);

第二，這裏不便於錯誤檢查，能夠向數組列表添加任何對象。
因而，泛型就提供了 類型參數 解決這兩個問題，這使得代碼具備更好的可讀性：

ArrayList<String> files = new ArrayList<>();

【注】省略的類型能夠從變量的類型推斷得出。
固然，泛型也是有侷限性的，例如：不能使用基本類型實例化類型參數，不能用類型參數代替基本類型，這即是我所認爲的「麻煩」之處；除此以外，泛型也不能實例化類型變量，不能構造泛型數組，也不能實例化參數化類型的數組，例如：

List<String>[] ls = new ArrayList<String>[10];

可是可使用通配符建立：

List<?>[] ls = new ArrayList<?>[10];

這是我在書上查到的能看懂的弊端，其餘內容還須要大量實踐去驗證。

【返回目錄】

代碼調試中的問題和解決過程

【問題1】：在實現遍歷測試代碼時，參考了網上的示例代碼，發現有幾種方法都是在 Iterator 類實例化對象後使用 hasNext 迭代循環，爲何會這樣固定搭配？與 next 方法有何不一樣？例如：

Iterator it = c.iterator();
        for(;it.hasNext();)
            System.out.println(it.next());

解決方案 ：查看了課本以後發現上學期的接口內容有所遺忘，Iterator 接口中的兩個基本方法是 hasNext 和 next ，hasNext返回一個布爾結果，next返回一個對象。這兩個方法都不帶任何參數。若是還有等待處理的數據項，hasNext 方法返回真，而next方法返回下一個對象。對於hasNext方法來講，若是仍有元素能夠迭代，則返回 true。這至關於：若是 next 返回了元素而不是拋出異常，則返回 true。hasNext有一個索引功能，即判斷下一個元素是否存在。之因此這樣搭配，就是爲了迭代循環，從而成爲遍歷一個集合或者泛型對象的經常使用方法。
【問題2】：看了婁老師本週的教學進程以後，學習任務中有一點是：掌握Java中泛型類，泛型方法的設計。那麼要如何正肯定義一個泛型方法？
解決方案 ：首先說說泛型類，一個簡單的泛型類以下：

// 定義一個泛型類，這個T能夠出如今這個泛型類的任意位置,泛型的數量也能夠爲任意多個
    static class Pair<T> {
        private T value;

        public Pair(T value) {
            this.value = value;
        }

        public T getValue() {
            return value;
        }

        public void setValue(T value) {
            this.value = value;
        }
    }

測試類獲取並替換參數值，再獲取：

public static void main(String[] args){
        Pair<String> pair = new Pair<>("Hello"); //實例化泛型對象Pair
        String str = pair.getValue();
        System.out.println(str);
        pair.setValue("World");
        str = pair.getValue();
        System.out.println(str);
    }

在掌握了定義一個簡單的泛型類以後，我從網上找到一個泛型方法的示例（僅選取一段）：

public class Generic<T>{
            private T key;

            public Generic(T key) {
                this.key = key;
            }

            public T getKey(){
                return key;
            }
        }

        // 在public與返回值之間的<T>必不可少，這代表這是一個泛型方法，而且聲明瞭一個泛型T
        public <T> T showKeyName(Generic<T> container){  // 定義一個帶有類型參數的簡單方法
            System.out.println("container key :" + container.getKey());
            T test = container.getKey();
            return test;
        }

例子比較簡單，容易理解。固然，關於泛型的實用性更多體如今集合中，上文說起的 Comparable 接口自己也是一個泛型類型。

【返回目錄】

代碼託管

本週代碼上傳至 ch13 和 Practice 兩個文件夾裏：

（statistics.sh腳本的運行結果截圖）

本週考試錯題總結

本週無考試，上週考試錯題詳見第1周學習總結。

【返回目錄】

結對及互評

莫禮鍾本週狀態不是很好，和上週相比落差較大，老是須要督促學習，更糟糕的是最近迷上了「狼人殺」，每天玩，通宵玩！能夠說在學習上很難調動興趣，只能憑藉一時的熱度，而對於生活中的其餘方面顯得頗有情趣，我仍是會繼續督促他，但願他有一天可以意識到學習的重要性。

本週結對學習狀況

20162319：未發表博客
結對學習內容：
- 簡單學習了《構建之法》中的內容

其餘（感悟、思考等，可選）

　　這周學習的內容慢慢多了起來，課上的例子主要針對泛型、Map類和Comparable接口講解了一些簡單示例，咱們小組的團隊博客也漸漸開設起來，本次由於是分配學習，而後彙總寫入博客，因此有我負責編輯格式。說實話，小組成員每一個人本身總結的格式不一樣，彙總起來就比較頭疼，咱們會在之後慢慢改進磨合。構建之法中我也瞭解到所謂的「敏捷的團隊」，也但願在咱們每一個人的貢獻下，咱們的團隊也能成爲這樣的團隊。
　　團隊內容佔用了比較多的時間，總的來講效果不錯。相比之下，我這周課下泛型的學習還不夠深刻，只會使用幾個簡單的例子，所以在複習git和調試時也要多鞏固泛型的語法，爲下週的考試和後期學習作好準備。

【返回目錄】

學習進度條

	代碼行數（新增/累積）	博客量（新增/累積）	學習時間（新增/累積）	重要成長
目標	5000行	30篇	400小時
第一週	234/234	1/28	14/14	瞭解算法效率、大O符號等理論內容
第二週	255/489	1/29	12/26	瞭解敏捷的團隊、泛型的使用