一、讀後感:算法
對於計算機相關專業的學生來講,咱們學習了不少的專業課程,像編程語言、算法、數據結構、編譯原理、軟件工程等。可是我相信不少同窗和我同樣仍然對於咱們如今學到的課程在以後有什麼用心存疑惑。也就是說,你們都以爲理論和實踐之間有着不可逾越的鴻溝。然而在讀到鄒欣老師的這本書《構建之法 現代軟件工程(第二版)》的時候,我解決了我一直糾結的這個問題。編程
由於做業要求,第一遍是快速閱讀,雖然仍然對書裏的一些內容有些疑問,可是仍然以爲這本書有不少特色:數據結構
(1)文字+圖畫;不少專業書都有一個問題就是整本書都是字,雖然不乏內容優質的書可是很容易讓讀者在閱讀的時候睏倦疲憊,我一直接觸到額計算機相關的書大部分也都是那樣,因此鄒欣老師新穎的編書模式很吸引我,也是我一個星期能讀完這本書的緣由之一。本書包含了不少有趣的圖片,讀者也能夠經過這些圖片加深對相關概念的理解。數據結構和算法
(2)理論+實踐;本書介紹了軟件工程的相關概念,如:軟件工程、單元測試、軟件開發流 程、敏捷開發、軟件需求、用戶體驗、軟件測試、質量保障等。然而在介紹這些基本概念的同時,鄒欣老師也全面地詮釋了它們在實際的研發工做中是如何表現的,它們又是如何與每一個開發和測試人員息息相關的。在介紹這些概念的時候,鄒欣老師常常舉例,也使得你們更加的容易理解。 編程語言
(3)幽默+嚴謹;軟件工程裏面的概念比較的枯燥和單調,鄒欣老師爲了加強學生的興趣,描述的語言十分幽默詼諧,好比書中用「阿超」、「國棟」、「小飛」、「小李」等角色之間的對話來揭示一個概念的本質,經過他們之間風趣的對話又加深了對相關概念的理解。同時有做爲專業技術的指導書,鄒欣老師在不少技術介紹時也都使用了數據,真實狀況等分析,嚴謹而認真。性能
二、我的疑問:單元測試
(1)咱們在作一個軟件對軟件的質量應該有多高的要求?當咱們的代碼的規模很大時基本上不可能作到沒有bug。不少軟件在還未修復調試好的時候就發佈使用,雖然基本功能都能完成,可是仍是有不少bug,最後會致使修改一些bug成本太大,或者形成的影響太大。可是咱們若是一味追求高質量,一直壓着修復調試發佈太晚也會形成很多的損失。咱們應該如何把握好這以前的度,可以較爲和平的維持雙方關係?學習
(2)在團隊項目中,工做量如何分配?若是是一個專業成熟的團隊,每一個人技術都足夠優秀,徹底能夠考慮小組成員平均分配,或者按照我的能力技術問題按比例分工。可是對於咱們如今分工的團隊,在咱們小組分工的時候徹底把握不到這個度,甚至都不清楚都須要作什麼工做,我的能力的認知上可能也有缺陷。測試
(3)關於bug與測試。從最開始接觸計算機編程咱們就明白不可能有人的程序編的毫完好陷,bug是一直都會有的。可是怎麼判斷這些bug的重要程度?怎麼肯定對某個bug的修改不會影響其餘功能?怎麼分析這個bug對於整個程序的影響?有沒有一種比單元測試更簡單快捷的方式來保證全部單元的正確性?即便咱們通過了足夠的測試,仍是不能保證在實際運行中不會出錯,尤爲是當開發面向對象的網站或者軟件時候,由於使用對象的多樣性會遇到不少問題 。那麼在維護階段出現bug有沒有比打補丁更規範適用的方法?優化
(4)咱們除了寫程序也要學會分析程序,在不少時候分析程序性能要比寫程序更重要,書裏面也不少介紹了代碼模塊的執行效率,着重優化耗時長內存大的部分,也由於咱們須要優化一些基礎代碼而後有了數據結構和算法,可是不少時候你不會第一時間就想到一個合適的算法適合這個功能,如何根據測試結果思考一個合適的算法呢?
(5)書中有一段對話頗有意義,大概講一個新人進入公司看到前輩寫的一些程序以爲很垃圾想要推到重寫,這時候一個老員工告訴他他如今看到的這些程序也是前輩剛進入公司的時候以爲程序很很差改寫的結果,反而尚未原來的好用。咱們在前人的基礎上去使用這些軟件可是不表明咱們以爲他很差咱們就有能力寫的比他好,因此該如何正確對待別人的程序呢?可能有你以爲很差的地方,可是確定也有你要學習的地方。