201771030118-司紹斌 實驗一 軟件工程准備—博客園首秀

項目	內容
課程班級博客鏈接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/
本次作業要求鏈接	https://www.cnblogs.com/nwnu-daizh/p/12369881.html
我的課程學習目標	大概閱讀《現代軟件工程—構建之法》，對本學科有一定的了解
這個作業在哪些方面幫助我實現學習目標	軟件工程基礎理論知識，學習博客發布的方法

任務要求

快速瀏覽鄒欣老師博客或《現代軟件工程—構建之法》，參照參考文章的提問模板，嘗試擬定3個准備從課程學習中找到答案的問題，並以寫博客形式記錄下來，博客要求使用Markdown排版。

請參考這篇博客修改博客園博客默認編輯器。

請參照這篇博客，在博客撰寫中練習 MarkDown，有余力的同學可以進一步優化博客的閱讀體驗。

博客作業格式符合以下要求，詳情請參照這篇博文

問題一

• 我在《現代軟件工程—構建之法》 一書中看到了這樣一段話

  問：為什么非得做代碼復審不可？難道開發人員沒有能力寫出合格的代碼？既然你招我進了公司，就是相信我有這個能力，對不對？

  答：首先，在代碼復審中發現的問題，絕大多數都可以由開發者獨立發現。從這一意義上說，復審者是在替開發者干開發者本應干的事情。

  問：這么說如果開發者做到完美，復審者的時間和精力就是一種浪費了？

  答：不對，即使是完美，代碼復審也還有“教育”和“傳播知識”的作用。更重要的是，不管多么厲害的開發者都會或多或少地犯一些錯誤，有欠考慮的地方，如果有問題的代碼已簽入到產品代碼中，再要把所有的問題找出來就更困難了。大家學習軟件工程都知道，越是項目后期發現的問題，修復的代價越大。代碼復審正是要在早期發現並修復這些問題。

  另外，在代碼復審中的提問與回應能幫助團隊成員互相了解，就像練武之人互相觀摩點評一樣。團隊中有新成員加入時，代碼復審能非常有效地幫助新成員了解團隊的開發策略、編程風格及工作流程。

  問：新成員是否應該在完全掌握了這些方面之后再寫代碼？

  答：理論上是如此。但是如果我們要“完全掌握”，可能需要比較長的時間，另外，如果不開發實際的軟件，這樣的“完全掌握”有意義么？還是在實際中學習吧。這也是“做中學”（<spanlang=EN-US>Learning by Doing）思想的體現。

• 對於上一段話，我有了這樣一個問題

  為什么要進行代碼復審，一個項目復審的頻率應該怎樣把控，復審過程中應該注意的問題有哪些

• 自我看法

  1. 代碼復審的首要目的是改善和保證代碼質量，預防 bug。此外還有益於制定團隊代碼規范，形成團隊技術氛圍，加深技術團隊成員溝通，老帶新互助成長。

  2. 目前我們所接觸到的項目是比較小的項目，無論是代碼量還是各種功能，所以現階段我們更多的是要學會自我復審。當一個項目是兩個或兩個人以上來共同完成時，可以進行同伴復審，這樣有助於發現更多問題，因為自身可能會過度自信而忽略掉一些問題。

  3. 需要注意的問題：同伴復審和團隊復審時應該做到對事不對人，學會把握說話的度。並且學會適當的誇贊別人，給一個團隊的人一些鼓勵，有助於團隊的團結。復審過程中盡可能不要提和復合無關的問題，比如討論功能或者完成用戶需求，這樣會影響工作效率。

• 我的疑問

  1. 一個項目正常的復審頻率應該保持在一個怎樣的頻率比較合適？

  2. 新成員技術沒有老成員完善，這時代碼審核能起到什么作用，對新成員的促進作用大不大？

問題二

• 我在《現代軟件工程—構建之法》 一書中看到了這樣一段話

用戶安裝軟件之后，軟件第一次啟動，軟件設計者要給用戶什么樣的第一印象？用戶頭一回來訪問你的網站，你要給他們什么樣的第一印象？

很多軟件設計者把用戶界面等同於給領導匯報的工作成績單，所有的功能都爭先恐后地出現在用戶面前，唯恐用戶沒有注意到。但是用戶往往會被繁亂的界面弄得暈了頭，無所適從。現在電視的遙控器大多數就是這樣設計的。

還有的軟件把自己當成-一個毫無感情的工具，早期的一些字處理軟件就是這樣。用戶啟動軟件后，看到屏幕上部出現了一行菜單，緊接着好幾行小按鈕，下面就是全白的屏幕。

有更好的設計么？

• 對於上一段話，我有了這樣一個問題

  怎樣注意用戶體驗，在考慮用戶體驗的時候需要注意的問題有哪些？

• 我在鄒欣老師的書中找到了以下答案

  1. 要注意的兩個問題：

     • 誰會是我們的目標用戶?他們是什么樣的人?他們的使用方式是什么樣的?用戶是從哪里進人到這個軟件或網站?他們知道這個產品是做什么的嗎?用戶想達到什么目的?怎樣讓他們盡快找到相應的功能人口，完成任務?我們的軟件可能比較難用(學習曲線較陡),怎樣才能讓用戶盡快掌握基本功能?

     • 用戶和軟件的第一次使用， 很大程度上決定了用戶對軟件的評價。怎樣讓用戶在第- -次使用的時候，少花時間(或者不花時間)在對用戶沒有價值的部分上？

  2. 學會從用戶角度考慮問題，把自己想成用戶，想象用戶需要怎樣的用戶體驗，怎樣更加方便用戶使用軟件

• 自我看法

  1. 比如用一個網頁做例子，現在的人們一天會瀏覽很多的網站，哪些網站是好網站，用戶是怎樣進行評價的。我想第一位的應該是一個網站的打開速度，當然排除自身網速的問題，如果光打開一個網頁就需要5秒或者更久，那么我想用戶體驗的第一感覺就是很差。其次應該是整體的布局及色調的使用，用戶第一眼看上去應該是舒服的，並且可以很快的通過導航欄等其他地方找到自己想要看到的內容。最后用戶才會關注網站里面的具體內容是否解決了他的問題，是否是他所需要的內容。

  2. 針對不同用戶，軟件的用戶體驗也是不同的。如果我們在做一個大學的官網，那么它的基調就應該是嚴肅簡潔的，不需要太多的色調和圖片。但是如果我們在做一個幼兒園的官網，那么活潑可愛應該是這個網站的基調。大學官網更多的是老師和同學，而幼兒園的官網小朋友是主要人群，學會“因材施教”。

• 我的疑問

  1. 任何事物都有兩面性，在保證用戶體驗的同時，怎樣保證用戶需求的完整性？

問題三

• 我在《現代軟件工程—構建之法》 一書中看到了這樣一段話

用戶使用軟件，不光是希望軟件能夠提供一定的服務，而且還要求服務的質量要達到一定的水平。軟件的效能是這些“非功能需求”或者“服務質量需求”的一部分。

• 對於上一段話，我有了這樣一個問題

  效能測試時應該更注意時間還是空間方面的效能

• 自我看法

  1. 我們目前所接觸的項目數據都比較小，數據量也不是很大。但是當數據很大，訪問量也很大時，我們的效能會有什么改變，這是我們在項目完成過程中需要注意的問題。不能等到出問題了再去修改，這樣用戶體驗會很差。我們常說的某個網站或者軟件“崩了”，很大原因可能就是訪問量過大，數據過多導致的。

  2. 我們應該在保證用戶需求的前提下，在效能測試階段應該加入更多的數據或者訪問量，盡可能模擬最多的情況，這樣才能保證在實際運行過程中少出問題。

• 我的疑問

  1. 有時候我們在開發階段為了保證時間效率可能會犧牲空間效率，這樣的做法在效能測試階段會有什么樣的影響？

  2. 在時間和空間方面應該怎樣權衡，有沒有一個絕對的比例？

總結

通過大概閱讀鄒欣老師的《現代軟件工程—構建之法》，讓我對軟件工程這門學科有了一定的了解，明白了一個軟件的完成並不是我們想的那么簡單。我相信在老師的帶領下，可以學好這門學科，並且把它用到平時的軟件開發中。

作業參考文獻列表

類型	詳情
專著	[1]鄒欣.現代軟件工程：構建之法.人民郵電出版社,2017.