一、個人總結

第一部分：硬的問題

第二部分：軟的問題

二、回答問題

問題一：

我看了這一段文字

軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程。

那麽軟件工程到底有什麽用呢？

回答：

• 軟件工程的思想目的和其他學科的工程方法（比如土木工程等）並無太大差異，主要是降低軟件系統的復雜性、提高其可控性，以此在軟件開發、維護、測試等各個階段提高效率。
• 讓整個軟件系統“大而不亂”，井井有條。減少程序員工作的負荷並提高軟件需求、設計、開發、測試、維護的效率。

問題二：

我看了這一段文字

從學生到職業程序員，並不是更加沒完沒了地寫程序——花在寫代碼的時間反而少了許多。

職業程序員的能力比學生強多了，會做的東西就更多了，就會敲更多的代碼了。那為什麽職業程序員花在寫代碼的時間反而少了許多呢？

回答：

因為職業程序員任務的質量要求不一樣。職業程序員在“需求分析”和“測試”這兩方面明顯地要花更多的時間。但在具體編碼上，花費的時間會比學生少。從學生到職業程序員，並不是更加沒完沒了地寫程序——花在寫代碼上的時間反而少了許多。

問題三：

我看了這一段文字

在軟件工程的語境裏，“敏捷流程”是一系列價值觀和方法論的集合。

那麽敏捷流程到底是什麽東西呢？

回答：

敏捷開發以用戶的需求進化為核心，采用叠代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。總結如下：

• 不斷交付軟件以滿足客戶需要
• 歡迎需求的變化
• 可以工作的軟件是進度的主要衡量標準
• 對卓越技術與良好設計的不斷追求將有助於提高敏捷性
• 簡單——盡可能減少工作量的藝術至關重要

感覺敏捷是態度而不是流程，是氛圍而不是方法。

三、再提問題

第4章 兩人合作

我看了這一段文字

代碼復審就是看代碼是否在“代碼規範”的框架內正確地解決了問題。

Q1：

那如果開發人員在寫代碼的過程中就嚴格按照代碼規範來寫，做到完美，那此時代碼復審不就毫無意義了？復審者本就是在替開發者幹開發者本應幹的事情，那意味著開發者自己做好的話，復審就沒必要了？

第5章 團隊和流程

我看了這一段文字

軟件團隊有各種形式，適用於不同的人員和需求。基於直覺形成的團隊模式未必是最合適的。

Q2:

如果要開展一個全新的項目，到底該怎麽選擇“合適”的團隊模式呢？課本中僅僅是介紹了各種模式，但並未教我們到底該如何選擇。

第7章 MSF

我看了這一段文字

二柱：軟件工程講的凈是一些奇妙玄幻的概念，拗口的專業名詞加上紛繁復雜的流程，其實做軟件完全沒那麽難，主要靠的還是程序員自身的修養和完成工作的素質。

Q3：

我覺得這段話講得很有道理啊，請問你怎麽看呢？

第12章 用戶體驗

我看了這一段文字

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

Q4：

既然用戶體驗設計的目的就是為了用戶，那是不是可以理解為要根據大眾的想法來設計？但我們平時使用的一些軟件，比如知乎，這些公司對於用戶體驗設計應該都是很在行的，但為什麽在用戶體驗這一方面會越做越爛呢？
我的問題是，是什麽原因導致了這種情況的發生。每次出新版本，每次都會受到用戶的大量吐槽，為何會一直在錯的路上一直走下去呢。如果在內容和功能上，加入了可以獲利的東西尚可理解，畢竟一個公司都是需要收入的。那麽UI越做越醜，怎麽就不會改回去呢。

第16章 IT行業的創新

我看了這一段文字

不但大眾不喜歡創新，甚至連創新者自己都不例外，有些創新者甚至恨創新。

Q5：

我反對作者的這個觀點，而且反對作者關於這句結論的一個設想。

作者說：假設你發明了電報，創辦了電報公司，並花費畢生的精力建起了覆蓋全國的電報網。這時有個年輕的發明家上門推銷他的創新——電話。這個早期的電話看起來其貌不揚，後面還拖著一條尾巴。可是你敏銳地看到，這個創新將會顛覆目前的電報產業，它預示著你辛辛苦苦建立起來的電報公司將會失去市場，這是你會怎麽想？會不會恨這個發明？

依我的看法，作者的結論是錯的。這並不是說有些創新者不喜歡創新或者恨創新，這根本就是利益沖突的問題，是一個創新者的利益被另一個創新者所破壞，不是不喜歡創新或者恨創新。單就創新而言，若創新者不喜歡創新抑或恨創新，那他如何創新？他如何實現創新？他做不了，他根本就不會成為一個創新者。

軟工網絡15個人作業4——alpha階段個人總結