如下爲當時提出的五個問題與回答linux
來自第2章 p36android
PSP有如下的特色:web
- ...
- PSP依賴於工程輸入數據,記錄工程師的各項活動,這自己就須要不小的時間代價
- 若是數據不許確或者有遺失,怎麼辦?讓工程師編造一些?
- 若是一些數據不利於工程師本人(例如:花不少時間修改缺陷),咱們怎麼才能保證工程師願意如實地記錄這些數據呢?
個人問題是,PSP是否不適合學生?算法
正如書中所言,PSP這一模型在實施的時候彷佛有一些困難的地方,尤爲是對於學生來講,例如:編程
問題提出的緣由是與我在平常學習生活中的經驗矛盾windows
回答
如今認爲PSP適合學生,但在實施上是有一些問題,以前提出的問題都發生了,統計時間的時候確實很麻煩,最後只能採用模糊估計的方式編程語言
來自第4章 p87函數
如何結對編程單元測試
- 駕駛員:寫設計文檔,進行編碼和單元測試等XP開發流程。
- 領航員:審閱駕駛員地文檔;監督駕駛員對編碼等開發流程的執行;考慮單元測試的覆蓋率;思考是否須要和如何重構;幫助駕駛員解決具體的技術問題。領航員也能夠設計TDD中的測試用例
- ......
我認爲,結對編程可能在現今的大學環境下難以發揮效果。學習
首先看到書中關於結對編程的例子,通常都是公司內部的兩個工程師,兩者同爲一家公司的工程師,那他們之間通常來講技術、關於技術的思想等等就不會差距太大,而這個技術差距偏偏是學生之間和工程師之間的不一樣之處。好比說用0到10的數字表示一我的對有關結對編程中使用技術的掌握程度,兩個工程師是4和7,而學生之間甚至可能出現0和1的狀況(沒有其它人比學生更瞭解學生,做爲計算機學院的學生,四年下來連要求的某些編程語言的基本語法都沒有學會的也不是沒有)。這樣的狀況下,根本無法結對,別說設計單元測試了,可能連表述出來的設計需求都聽不懂。
問題出發點一樣是與學習環境中的經驗不符。
回答
結對編程確實在大學中可能難以發揮效果,不過鍋在學校和學生自身上,0和1的問題都是學生自身未盡到學生的職責所致使的。
來自第7章 141
保持敏捷,預期和適應變化......
以及 第3章 p53
「過早優化是一切罪惡的根源」......
當我看到敏捷的思想的時候,就回想起了在本書前面看到的過早擴大化/泛化等的問題。前者的要點是:要預料變化,適應變化,對變化作好準備;然後者的要點是:不要過早地泛化......我感受這兩種思想彷佛有着衝突的地方,問題是該如何在兩者在過早泛化和提早爲變化作好準備之間找到平衡點呢?
舉個更具體的例子,我要用C++寫一個web/linux/windows/iOS/android上均可以使用的我的事項管理軟件。我打算從windows客戶端開始設計,在設計其中一些方法的時候,我是應該將函數所有泛型化,抽取出變化的部分所有設置成參數?仍是先將這一平臺的當前需求以合理的資源和算法結構等先設計實現出來呢?
回答
根據實際項目的期限和目標等肯定,有經驗做爲指導才能作好決定。
來自第13章
章節中的各類測試技術的應用場景......
在閱讀軟件測試等章節的時候,我認爲確實單元測試和軟件測試等等都是十分有必要的,那麼一個GUI軟件該如何更好地測試呢,或者說GUI軟件的自動化測試有沒有必要呢?
這是我找到的部分觀點:
在我看來,GUI測試因爲其變化可能性大,測試(覆蓋率/成本) 率高,因此難以進行大規模的自動化測試,就像某前輩所說的
keep the UI very, very thin—all it does is forward user gestures to some underlying code, and display the results. No logic. Definitely no database access.
UI就該作UI的事情,而且只作那件事
在測試問題上,該如何找到最佳的GUI測試方案呢
回答
仍是要根據項目規模和期限資源等適當抉擇,例如:對於將會持續變化的部分,自動化UI測試將是不現實的,也是在資源人力上沒法接收的。而若是是變化不大的部分能夠考慮適當的自動化測試(通常沒有)。
來自第17章 p411
軟件工程師的職業道德
其中有一個規範:
原則1 公衆
軟件工程師的行爲應與公衆利益一致
原則2 客戶與僱主
軟件工程師應以其客戶和僱主利益最大化的方式作事,與公衆利益保持一致
......
看到這種一條一條的的準則,就會產生疑問:
舉個例子
某大廠開發的一款即時通信軟件,在發佈後因爲其出色地整合了許多同類應用的優秀功能而大火。以後僱主(公司老闆)要求工程師設計出一套付費vip的服務,對於使用該應用的用戶來講,這固然不利於他們的利益,可是從僱主的角度來講,他能夠憑藉該應用的巨大用戶基數怒賺一筆
回答
審視本身的心裏:你爲什麼從事這個職位。
若是爲了生存那隻能維護本身的利益,尊重僱主的利益。
若是爲了興趣或是信仰啥的,該離開就離開,不要爲虎做倀。
通過Alpha階段,發現項目開發的過程當中老是可能會出現忽然狀況,影響項目的進度,甚至致使項目沒法完成,那麼如何在項目準備階段有效的考慮到這些變量並更準確地作好項目估計呢?
團隊已經組建好了,項目開始後,發現有一些隊友的水平沒法有效的完成分配的任務,這種狀況下,做爲PM該如何處理?
在本課程中,咱們每一個同窗都分擔了不一樣的角色,那麼咱們通過這個階段的學習,對於大部分人來講,都是根據PM的分配完成本身的任務,那麼軟工課程主要學習的是什麼呢?
一方面,不懂開發的PM在與開發交流的時候不免會有代溝,而另外一方面,掌握太多開發細節的PM將會在管理的時候陷入細節,影響自身的判斷。
軟件工程自己做爲工程,固然絕大部分都是工程相關的知識,那麼這些知識對於哪些要研究學術、要考研的同窗有什麼幫助呢?