個人作業-Week1
阿新 • • 發佈：2017-09-28
適應 結構 而不是 bug 作用 一個人 cno 想法 防護
幾個問題：
- 1.就第五章團隊與流程的練習與討論中的第6題發表一點自我的觀點：
有人說——現代軟件工程分為四個階段：和PM吵，和設計吵，和測試吵，和用戶吵；你覺得應該如何避免吵架？
-
- 首先，我認為應該增加各個團隊之間的交流，有一些外國的公司會專門留出一些下午茶時間，這個時候整個公司的各種人員都會聚集到一起，談天說地，雖然有時候不會談關於工作的問題，但是即使這樣也能拉近各人之間的距離。一起做項目的時候也有很多共同語言，甚至能因為這個項目找到和自己愛好相同的人，就會談到更多和項目有關的東西。在這種過程下，能夠升級到吵架程度的問題就被化解了。
- 2.關於第八章中的“殺手功能”的一點不同的理解：
我們決定做蟹黃小籠包，什麽是殺手功能？當然是蟹黃！
- 有的時候，隨我們來說，殺手功能往往是在我們看來超凡脫俗的，一般是那種在行業前沿的新技術。但我認為這樣的殺手功能也許只是開發人員認為的殺手功能，用戶可能並沒有聽說過它的名字，即使有人聽說過，但那也只是起到博人眼球的作用，到底這個功能算不算好，那只能是用戶決定。有的人覺得蟹黃小籠包好吃，但有的人覺得灌湯包好吃，都是因人而異的，就像有的地方菜拿到外面就沒有人買一樣。最近有一款Tecno手機在非洲火起來，其性能看起來也一般，在國內就從沒聽說過，但他的特點就是對非洲人專門設計的美顏功能，而一般手機的美顏功能就只能把非洲人美顏得只剩牙齒。僅在2016上半年，Tecno就高居中國出口量榜首，在非洲最大經濟體尼日利亞也擁有40%的市場占比。所以，就像一些在行業最棒的產品往往不是最火的產品這個道理一樣，所謂的“殺手功能”有的時候不是前沿新技術，而往往是最適應“環境”的。
- 3.讀完第12章後關於用戶調研的一些思考：
- 我在生活中經常看見很多軟件的調研問卷，問題都涉及廣泛，基本上能夠反映用戶的意願，但那些我不關心的軟件，我就不會管它的調研問卷。以前看Ted的時候聽過一個故事。二戰的時候，工程師決定為飛機增加防護板，因為當時修理廠的飛機所受的傷害都集中在駕駛艙附近，飛行員的意願也是增強駕駛艙的防護，但有個老兵建議增加發動機附近的防護。事實證明，在增加發動機的防護之後，飛機的生還幾率大大增加。因為發動機是飛機的致命弱點，那些發動機被損害的飛機完全無法回到修理廠。這也就和調研問卷一樣，那些對這個軟件真正失望的人群是不會去填的。所以，我認為調研必然只能反應一方面的問題，真正重要的問題會出現在調研所發現的問題之外。
- 4.關於第4章的閱讀代碼的思考：
- 在讀完http://kb.cnblogs.com/page/192086/之後，加上自己看過室友寫的一些代碼，看別人寫的代碼真的很難，命名風格、縮進格式、代碼結構都是很不相同的；但我認為如果一個人能夠把代碼結構寫好，像上次OO課學的，面向對象式編程，如果能夠將代碼的封裝做好，那是不是也能夠加快別人的閱讀呢？
- 5.第16章能夠創新的團隊：
- 以前看過一些Ted,提到“雞群效應”，也就是團隊中能力強的人員相互競爭，造成資源的浪費。我認為好的團隊應該是技術水平都差不多，即使有那種非常出眾的人才，也應該照顧到其他個體的感受，能夠讓每個人的付出時間差不多，既能減少大家的壓力，也能讓團隊相互了解，甚至互相垂青，出於想讓別人了解自己的想法，想讓別人提出他的更精彩的觀點而付出，而不是競爭的關系。
“軟件” 和 “軟件工程” 這些詞匯是如何出現的 - 何時、何地、何人？
- “軟件”是由1935年圖靈在一篇題目為“omputable numbers with an application to the Entscheidungsproblem (decision problem)”的論文中提出的
- “軟件工程”是1968 年北大西洋公約組織在前聯邦德國開會提出的
【附加題】：大家知道了軟件和軟件工程的起源，請問軟件工程發展的過程中有什麽你覺得有趣的冷知識和故事？
- 現在微信中輸入15個中文句號會崩潰。
上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麽優缺點？
- Git:
- 優點：分支能力強大，開源
- 缺點：使用難度大
- Mercurial:
- 優點：跨平臺，簡單上手
- 缺點：分支管理不好
- Trac:
- 優點：靈活
- 缺點：核心功能少
- Bugzilla:
- 優點：有強大數據庫支持
- 缺點：界面不夠友好
個人作業-Week1