第一~第四章：
1、是不是一定要程序理解，程序理解中說新成員要盡快讀懂已有的程序，了解程序的設計，那么如果已有的程序很龐大，很復雜，不懂其編程思想，新成員要讀懂它不是要花很多時間嗎？還要花精力去學習新的，這樣不是要浪費時間與精力嗎？（第一章 P4）
答：若是團隊中有新增加了新成員，對于已有的程序，要想減少時間與精力的浪費，可以讓寫程序的本人給大概地給新成員展示講解一下，或者說如果一個團隊已經組成，最好就是不要再增加新成員，或者盡量在項目開始之前就估量好團隊所需要的人力，一旦組成了成員數就不要再有所變化。
2、如何編寫單元測試？是不是每個程序都要有單元測試？編寫單元測試有哪些方法？如果某個程序所預算可能出現的問題很多，那是不是每個可能出錯的地方都要寫單元測試？如果單元測試編寫錯誤呢，那么這個單元測試是不是就沒用了？（第二章 2.1.2）
答：單元測試分為白盒測試與黑盒測試。單元通俗的說就是指一個實現簡單功能的函數。單元測試就是只用一組特定的輸入(測試用例)測試函數是否功能正常，并且返回了正確的輸出。白盒測試是將程序的核心代碼進行包裝，并放在一個新建的類中，在這個核心代碼類中建單元測試，選中要測試的函數，驗證測試結果是否與預計的一致，若是不一致，則可能是程序中有bug；白盒測試要有測試的覆蓋種類（包括語句覆蓋、判定覆蓋（也叫分支覆蓋）、條件覆蓋、判定——條件覆蓋、條件組合測試、路徑測試）而黑盒測試則是對程序進行容錯，比如輸入框中輸入的類型是數字，若是輸入字符要由相應的提示錯誤、或者輸入數字范圍溢出等等。
3、成為一名出色的軟件工程師是不是一定要每次都進行自我評估？（第三章3.2.4）
答：是。要及時得進行自我評估，提高發現問題和解決問題的能力，并評估自身溝通能力，比如可以和產品，設計，上下級的溝通。
4、代碼規范不就是要求在打代碼時注意格式，使得代碼看起來清晰，好看，易懂，那如果后面只有一條語句，其花括號是不是可寫可不寫，比如P58里的
if(condition)
DoSomething();
else
DoSomethingElse();
中，判斷語句if()后面只有一條語句，不加花括號與加了花括號，有時會發生不一樣的結果，這是為什么？（第四章4.2.4）
答：最好是寫，寫了可以保證百分比沒錯，不寫就很難保證會不會出問題。
5、什么叫斷言？斷言有什么用處？怎么用？（P63 4.3.3第二點）
答：編寫代碼時，我們總是會做出一些假設，斷言就是用于在代碼中捕捉這些假設；使用斷言可以創建更穩定、品質更好且不易于出錯的代碼；當需要在一個值為FALSE時中斷當前操作的話，可以使用斷言。單元測試必須使用斷言（Junit4）。
6、什么叫可兼顧封裝和效率？（P64 第四點與第五點）
答：兼顧的意思是同時照顧幾個方面，因此兼顧封裝和效率是指可以同時照顧封裝與效率兩方面，現在看這個問題才發現我當初理解錯了這句話。
7、團隊合作是小組成員之間分配好各自負責的版塊，設計好后將每個人負責的程序搭建在一起，這樣不會出現混亂？因為一個項目是很大型的，代碼也是幾千甚至是幾萬行，如果是每個人分工合作，那么每個人完成了特定的程序后如何將各自負責的程序合在一起，每個人的編程理念與思想以及風格都不同，這樣不會造成混亂和難以尋出的問題嗎？（第五章）
答：既然是團隊在做項目，那就說明已經有很多的經驗了，知道怎么做項目，怎么拼湊在一起，因此有了經驗，就不會出現混亂。
9、命名一個變量時一定要加前綴名嗎？不加會怎樣？怎么加？
答：這是不一定的，看是什么語言，每種語言都有各自的命名規則。
第五~第七章：
1、如何將各個模塊通過手工或者自動化的手段，將可執行的系統搭建出來？搭建時是不是包括驗證模塊也要搭建進去？（P95 5.3.4）
答：要，在實現工作流中，工程師按照計劃實現上一步產出的設計，將開發出的組件，連同驗證模塊，提交到系統中，同時，工程師們集成由單個開發者所產生的結果，把可執行系統搭建出來。
2、在配置和變更管理中，如何做到并行開發與分布式開發？（P95）
答：建立一個完整的全面的配置管理基礎架構，對各種類型的項目進行有效的監管。這個管理基礎框架，不僅應包括完善的管理制度、規范標準，還包括為高效率實現上述管理手段而建立的軟件配置管理系統，以及其他的相關擴展領域，為今后的長遠發展奠定堅實的基礎。
3、敏捷流程大概的意思是不是就是互相監督，互相學習，共同進步的意思？（第六章）
答：敏捷流程是一系列價值觀和方法論的集合，不過也是團隊中個成員的相互學習，共同進步。
4、MSF是否可以解決所有的問題？如果出現了難以解決的問題怎么辦？是不是軟件中可能出現的所有問題都可以解決？（第7章）
答：這個我也不知道，我百度找了一下沒有搜到相應的答案。
第8~第10章：
1、做項目了解用戶需求是最重要的，但是如果連用戶自身也無法描述他所想要的，或者說是用戶只是大概說明了自身所需，而項目人員無法了解用戶的真正需求，那怎么辦？（第8章8.3）
答：讓一個對客戶的要求理解能力較強的人去與客戶交際。
2、若是一個團隊人員已定了，那么如果這個團隊里面找不到適合的人做項目經理怎么辦，那么還是要在這個團隊中找一個當項目經理還是要另外找一個是適合？（第9章9.4）
答：找不到適合的就自己去鍛煉自己的這個能力。
3、分析用戶需求，是否需要寫一份文檔來說明？還是只需要團隊的人員之間的口頭傳達？還有就是團隊做一個項目，需要準備那么多的說明書嗎？既要規格說明書，又要功能說明書，那要是寫完這些不會很耗時間嗎，是不是只要是團隊做項目都要按照這個流程來？（第10章）
答：我覺得最好是先寫一份文檔，寫了之后才能記住客戶需求。團隊做項目最好就是按著流程來，這樣不會混亂。
第11-第12章：
第11章問題：開發階段還有日常管理，這樣不會浪費團隊做項目的時間，做一個項目既要做Sprint計劃，又要每日例會，還要規格說明書、功能說明書、列典型用戶與典型場景 描述等等，當這些完成后，確定還有時間弄項目嗎？（第十一章11.2節）
答：開發項目的團隊就說明已經是做過項目的，有了一定的經驗和能力，進行起來就不會很耗時。
第12章問題：用戶體驗和質量，有時候并不能同時做到很好，那么這兩個當中那個要重要一點？要犧牲哪個取哪個？（12章12.1.6）
答：體驗是質量的一部分， 取決于項目特點，看情況。
第13-第17章：
第13章問題：軟件測試有那么多種測試，萬一不夠時間完成所有的測試，那么哪種軟件測試是最重要的，而且，完成一項項目就要花很多的時間，真的夠時間完成所需要的全部的軟件測試嗎？（第13章13.2）
答：這個我也不知道，對于軟件工程我理解的還不是很透徹，也不是很清楚，只是大概知道了軟件工程的一些流程與方法以及概念、思想等等。
第14章問題：什么叫績效？什么叫優化角色績效？（第十四章14.2.2問題三）
答：績效就是一個人在團隊中的勞動成果。
第15章問題：怎么培養對用戶、行業、軟件開發的洞察力？（第15章15.1.1）
答：多實踐，實踐出真知，很多事要去做了才知道效果如何。
第16章問題：怎么練習創新的招數？（第16章16.3）
答：可以多去參考參考他人的創新成果，然后自己多思考、多動手、多嘗試。
第17章問題：有沒有很公平又讓大家都很樂意接受的績效考核方法？（第17章17.3）
答：我覺得應該是沒有的。
文章列表
留言列表
