回顧

1、回顧上課之初的五個問題:

問題1:第二章我的技術和流程提到效能分析，我發現提升速度的方法都是經過用軟件自己的代碼來實現或者減小調用函數的次數，我想當一個程序過度的追求它的效能的時候，他的穩定性有保證嗎？

答：這個問題如今沒有困惑了，當在作我的項目做業的時候有過效能分析，提升效能的前提固然是程序可以按照要求正常的運行，因此穩定性是確定的。能夠理解爲先確保程序是可運行的，在此基礎上再進行效能的測試和提升。

問題2:第一章和第三章都提到一個職業的軟件工程師的職業程度須要用一些數據來測量的，就像nba用一些數據來測量一些球員的水平同樣，但是以我目前對nba的瞭解，有些能力是在數據上體現不出來的，好比策應能力和間接助攻能力，因此我想這些數據能夠擴充一些，更全面一些或者按照不一樣人的側重於性格來評價各類方向側重的軟件工程師。

答：這個問題如今沒有困惑了，軟件工程是一個工程類的技術，既然是工程類的技術就要有一個量化的衡量標準，如咱們所作的psp，咱們全部的工做都會擺在檯面上來評價與價值衡量，而爲止付出的鮮爲人知的努力並非客戶所須要的。而關於性格來評價一個軟件工程師原本就是錯誤的，軟件工程師原本就是不摻雜着任何感情因素的，評價一個軟件工程師只能憑藉邏輯和理性的分析來評價，不能該帶有情感的傾向。

問題3:第三章初級軟件工程師的幾種成長中一共列出了5種成長方向，一個是技術技能的掌握的提升，一個是積累問題領域的知識和經驗，一個是對通用的軟件設計思想和軟件工程思想的理解，一個是提高職業技能，最後一個是實際成果。按照我目前我的淺顯的理解，我認爲這5個方面是成梯度呈現的，由於一個初級的軟件工程師也是一個精力有限的人，當他把本身認爲最難的部分處理好，纔會發現一些以前以爲更簡單的問題每每最難處理，就像考試同樣，最後的難題每每是一些定理的證實。

答：根據這個學期的學習，我想這5種成長方向是同時展開的，只是在實際的運用過程當中你的任務會更側重於哪一個方向的發展，像技術技能掌握的提升和積累問題領域的知識和經驗以及對通用的軟件設計思想和軟件工程思想的理解是相輔相成的，進而在不知不覺中咱們的職業技能天然而然的就提高了，也有了一些實際成果。

問題4:第六章提到了敏捷流程，看了不少的方法有點蒙，粗略的覺得有一些明確的任務目標分塊的用敏捷開發比較適合，而一些只有大體方向的用傳統的瀑布式的比較好，但我我想知道當一個項目的開發從開始用傳統的瀑布式的開發後有了明確的目標分塊，這時還能夠轉換爲敏捷開發嗎？

答：我我的理解瀑布式開發和敏捷開發從根本上就是兩個事情，瀑布式開發的核心是文檔，只有在開發的後期才能見到軟件的模樣，並且並不能進行迭代和用戶的反饋。而敏捷開發是一個與之大相徑庭的過程，首先他要快，快才能跟上時代的步伐，其次是以人爲本，要客戶參與進來，實時的進行反饋和更改需求，還有就是要實現小版本，快速的功能展示。因此這兩個東西是不能轉換的，能夠重新開始。

問題5:讀了第8章的需求分析，我終於瞭解了nabcd的含義，分別表明需求，作法，好處，競爭和推廣。又瞭解了功能的定位了優先級，一個正常的需求功能包括了殺手功能和外圍功能，我想這個殺手功能是以一個縱向的發展更好仍是以橫向的發展更好。

答：我我的認爲是縱向的發展更好由於殺手功能是一個項目的王牌功能，是你吸引客戶的功能，便是一個痛點也是一個亮點，而從實際的問題出發，解決一個或者優化一個問題，把它作到的足夠好，須要花費大量的人力資源和時間的，因此殺手功能不多甚至不多是一個橫向的發展，就像汽車行業，奧迪的燈作得很突出，寶馬的操控和奔馳的溫馨以及馬自達前衛的外觀這都是有目共睹和有傾向性的，他們都在外圍功能過得去的狀況下，盡一切努力來縱向發展殺手功能。

 

2、新提出的五個問題:

問題1：我有一個很籠統的疑問，一個項目咱們在作工程控制，好比事先制定好計劃，繪製燃盡圖，要對工程有個預期的時間的把控，還要繪製一些uml圖之類的等等，但在這個信息發展飛速的時代搶佔市場的先機不主要嗎？當咱們作完這些的時候，假如市場已經被別人佔領，豈不是徒勞了嗎？

問題2：在我看書的過程當中，瞭解MSF這一套大型的開發指南。其中介紹了MSF的9個基本原則，最重要的也是最基本的就是推進信息共享與溝通，當中提到會把項目過程當中的每人的錯誤記錄下來，咱們彷佛尚未實行這個提議吧？

問題3：在384頁以後是給任課老師和助教的建議，我想這裏應該加一個（選讀）的字眼，畢竟這本書並非僅僅針對教師來編寫的，加上選讀以後能夠在主觀上看上去這本書是寫給廣大的對軟件工程感興趣的人們，或者改一個標題，具體是什麼沒想好。還有這本書只有大概每章的頁碼，並無每一小節的具體頁碼啊，我仍是但願可以加上的，這樣找的時候方便一些

問題4：在114頁和115頁敏捷流程的經驗教訓中，第6點Scrum估計不是一個「合同」，領導們不要把它當成一個合同，而第七點鐘又說不要和管理層談「流程」，他們只關心結果。那咱們在Scrum談論的不就是流程嗎，既然領導是不關心的徹底不用出席啊，但我想這也失去了意義，還有這個估計可能不夠準確，當你把本身天天訂的都太高的時候，但實際沒有完成，領導是否會以爲你對本身估計不夠準確、不夠專業。而天天都訂的太低的時候，領導又以爲你是在消極的態度或者能力不夠。4

問題5：在122頁練習與討論中，瀑布式開發和敏捷開發這兩種模式該選擇哪個，我也很困惑，下面也列出了幾個選項供人們參考，從這些選項中我能夠理解當咱們環境相對比較惡劣的時候就用瀑布式開發嗎，但我認爲軟件開發的初期都是環境比較惡劣的啊。

 

3、對學弟學妹說的話：

剛上軟件工程這個課的時候，你可能會對楊老師會有一個比較深的印象，他會顛覆你在大學中對課程的概念（上過《構建之法》這門課的除外），你可能會想楊老師又是一個形式主義者，他說的什麼分數啊、測評啊都是扯淡的。當你這樣想的時候，你就會以爲接下來很痛苦、很驚訝，由於他的做業徹底是按照他對大家的計劃執行的。這個時候大家不要去抵抗（由於抵抗並無用），選擇接受，並且盡你最大的努力去完成，記得是按時完成（之後就明白了），你就這樣在一每天的抱怨中上着楊老師的課，也在一每天的成長，當你一個學期以後下來你會發現你懂的收穫挺大的，無論是語言的表述仍是對工程的控制，不能作得那麼準確，但最起碼你用過，下次會作的更好。不要以爲楊老師不近人情（確實不近人情），由於在他的字典裏工程是沒有人情可言的，他也是對事不對人的。最後，祝願大家可以在一學期的風雨中能挺過來，當烏雲散去的時候，你翻翻你的博客記錄寫着你對下一屆的寄語，發現這是一件挺有趣的事情。

 

4、若是從新來過

一、我會在一開始就在交做業的前幾天就開始準備，不能該等到快交做業的前兩天開始着急，弄到半夜。

二、我會在一開始就學一門面向對象的語言，而不是在學期中才開始學習c#。

三、我會在團隊項目開始以前對準備好的項目進行大量的學習，這樣就不會在項目開發中顯得手忙腳亂。

四、我會在過後諸葛亮會議中更加踊躍的提出本身的看法，雖然有時候以爲很蠢。

 

5、對老師說的話：

感謝的話就不說了，感受老師你也不太興這套。

一、老師應該先交咱們一些實際的東西，由於有些東西你第一次提出來咱們真的很難理解，而後上網去查也是以爲雲裏霧裏，因此有些人就選擇放棄了，我以爲能夠你講一點而後讓咱們自學一點，這樣效果會更好。

二、老師能夠將開始做業留的再少一點，由於都是一些生疏的知識，咱們也很難消化，有些底子的同窗可能就勉強完成，沒有底子的同窗真的很難完成，這樣就會增長抵觸情緒。

三、雖然感謝的話打算不說的，可是仍是以爲您是一位受人尊重的老師，仍是要感謝您一下，老師注意一點身體，雖然你和咱們在課上老是用金錢來衡量一些東西，但我感受的出來你也是一個不光只談錢有夢想的人，咱們可能拖累你的夢想了，這裏感到抱歉了。。。