軟工第一次博客做業

軟件工程第一次閱讀做業

項目	內容
這個做業屬於哪一個課程	2020春季計算機學院軟件工程(羅傑 任健)
這個做業的要求在哪裏	做業要求
我在這個課程的目標是	可以掌握軟件開發的流程邏輯，鍛鍊本身的團隊溝通能力與動手開發能力
這個做業在哪一個具體方面幫助我實現目標	幫助我思考軟件工程的脈絡體系

一、快速看完整部教材，列出你的5到10個問題。

1）、關於敏捷開發

敏捷的價值在於快速的迭代，利用高效的溝通不斷逼近用戶的實際需求。但對特定項目，敏捷開發可能並不合適。

好比當需求固定時，頻繁的溝通反而會帶來時間的浪費。因此個人問題就是

該以什麼樣的標準判斷當下的項目是否適合使用敏捷開發的思想？

通過查詢老師寫的博客我發現了一個橫向對比的表格：

我認爲該表格描述的較爲詳細，可是我認爲還能夠再進行更加深入的提煉。所謂「大道至簡」，經過我閱讀大量的相關技術博客（博主在這）,我認爲我獲得了一個更爲精細準確的答案：試錯成本低、需求變化快、溝通效率高。我認爲具有以上三點的項目具備很大機率，使用敏捷開發的效果要比其餘辦法更快更好的完成項目。

2）、關於效能分析

我在之前從未使用工具去進行效能分析，可是看了效能分析博客1後我認爲，效能分析必將指導一個項目該如何作出有效地優化，可是我在寫代碼的過程當中，每每會提早注意到，好比使用內聯小函數提高效率。可是第一次使用過效能分析工具後發現，其實這一部分的優化並不能帶來什麼做用，有時候還會變成「自作自受」的小聰明，可是若是不不一開始就注意架構的設計，極可能後期作優化時不免面對重構，因此個人問題是

何時應該開始思考代碼效能的提升，如何有效使用效能分析？如何可以避免屢次重構？

在閱讀了效能分析博客2後我瞭解到，效能分析必須作到靶向定位，精準優化，在進行優化前，須要先進行估計，那一部分是優化的重點對象，而這一部分每每須要豐富的底層知識和經驗的累計，因此在進行效能分析優化以前，須要對整個項目有一個清醒的認識，認識到哪一部分的優化投入產出比最高，這樣才能提升優化的效果和效率。

我認爲，任何一個合格工程師都避不開本身走彎路，豐富的經驗會知道咱們避開曾經掉過得坑，最終造成一種習慣。因此我認爲避免重構的辦法就是多學習別人的設計架構以及多親手實踐，只有coding才能很好地去學習經驗，快速提升本身的編程經驗。

遺憾的是，在項目的哪個步驟開始思考代碼效能的提升，這個問題也許由於我目前項目經驗不足，同時在網上衝浪沒有搜索到很好的解釋，目前這個問題我尚未一個清晰的解答。

3）關於用戶界面和用戶體驗

用戶體驗博客1給了我很大啓發，有許多的經驗，這裏我簡單列舉一下：

1. 從頭至尾都要記住用戶的選擇：不能只專一部分選擇的切換，要作全面的嘗試。
2. 不讓用戶犯簡單的錯誤：預防用戶出錯，關鍵操做有確認提示，及早消除誤操做
3. 可視性原則：系統狀態有反饋，等待時間要合適
4. 系統界面符合現實慣例：使用用戶語言而不是開發者語言，貼近生活實際而不是學術概念或開發者的概念。
5. 用戶有自由控制權 操做失誤可回退
6. 一致性和標準化：同一事物和同類操做的表示用語要各處保持一致
7. 減小記憶負擔：識別勝於回憶，提供必要的信息提示（可視&易取），減小記憶負擔

固然還有不少能夠注意的地方，而我看到這些經驗時，我想起來了不少比較反人類的設計，有些設計我甚至認爲可能還被開發者津津樂道稱爲產品的一大亮點（好比下圖，打字極可能打着打着就關機了）

那麼個人問題就是

如何可以完美的肯定本身的設計知足大多數用戶的需求？

在思考這個問題時，用戶體驗博客1給了我很大啓發，我發現了兩個辦法但或許都能解決部分問題。

方法1：dogfood，本身用本身開發的產品，可是這一點的弊端就在於，本身用不必定可以成功將本身代入爲普通用戶，由於每一個人對本身的做品都會帶有些許的驕傲，這份驕傲會掩蓋使用這款產品時的真實感覺。並且由於開發者知道開發時全部的設計細節，本身就像是一本用戶手冊，這和普通用戶自己就存在信息差。可是這一點也可解決顯而易見的設計問題，好比沒有提示不當心刪除本身辛苦編輯的博客。

方法2：大膽作減法，讓大部分不經常使用的功能作適當的隱藏。但這一點就要求用戶再想要使用某項功能時要去查詢用戶手冊（不過我認爲大多數人都不會讀手冊）

我認爲對於試錯成本相對較低的項目來講，試錯是最好的進步，「一件事不作永遠不知道它的結果」，多去嘗試不一樣的設計思路才能提高經驗，才能在試錯成本提升時作出正確的決策。

4）關於測試

經過閱讀測試博客1，我才明白原來測試不僅是打斷點那麼簡單，對於一個項目的測試來講，第一步須要構建合理的測試矩陣，而後須要對實際用戶進行分析，精簡測試矩陣，最終拿到測試矩陣的可行方案。

測試第一步要寫出測試設計說明書，包括：

（1）功能是什麼。

（2）要測試哪些方面？有沒有預期的Bug比較多的地方（對於測試矩陣有沒有要修改的地方）？

（3）如何去測試（什麼具體方法，如何作測試自動化，準備什麼樣的測試數據等）？

（4）功能如何與系統集成，如何測試這一方面？

（5）什麼才叫測試好了（Exit Criteria）？

最終完成測試後須要撰寫測試報告，以便使得咱們肯定以後的測試方向：

（1）多少測試用例經過？

（2）多少測試用例失敗？

（3）多少測試用例未完成？

（4）多少在測試用例以外的Bug被發現？

在這裏我有一個思考：

測試的目標是發現問題並修復，可是這個過程當中若是存在只能經過重構才能解決的問題，可是重構又會帶來新的測試，這個過程如何斷定本身的測試不是增長工做量，解決一個bug可是卻正在創造全新的bug

在這裏我尚未獲得較爲滿意的答案。

5）關於項目經理PM

經過學習項目經理博客1，我瞭解到項目經理更多就是團隊的掌舵者，不只須要處理各類與項目設計相關的問題，還須要協調好內部成員的關係，在這一點上我認爲項目經理更有競爭力的是他的的軟實力，雖然對他也有至關高的硬實力的要求。

對於PM來講，更多的須要掌握交流的藝術，佔領別人思想的高地，在這一點上我認爲其實已經超越了軟件設計這個領域了。對PM的要求是全面的，由於他的工做是分析判斷與協調，須要掌握不少跨學科的知識。

其實個人問題也很簡單了，如何成爲一個優秀的PM？

上述提到的問題我認爲須要很長的時間去積澱，必須從一開始就給本身定下一個決心，正是所謂的「兵謀帥事」，即便如今我可能還不能擔起重任，可是我站在領導者的角度去思考，去學習如何全面認識一個產品，如何認識本身正在作的事，那才能培養出本身獨立思考分析問題的能力，培養成爲PM的潛質。

二、請問 「軟件」 和 「軟件工程」 這些詞彙是如何出現的 - 什麼時候、何地、何人？

軟件：

​ In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that John Wilder Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years. This led many to credit Tukey with coining the term, particularly in obituaries published that same year, although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.

• 上述這段話是維基百科中對軟件(software)的描述
• 維基百科中介紹：「軟件」最先出現於於John Tukey在1958年發表的論文「The Teaching of Concrete Mathematics」中，可是他本人低這一點進行了否定。

軟件工程：

The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) 「letter to the ACM membership」 by the ACM President Anthony A. Oettinger;it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering. Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy.

• 上述這段話是維基百科中對軟件工程(software engineering)的描述
• 維基百科中介紹：「軟件工程」是由Margaret Hamilton在阿波羅計劃早期提出的，地點是MIT Draper實驗室。
• 也有資料顯示：1968年秋季，NATO（北約）科技委員會召集了的一次會議上第一次提出了軟件工程（software engineering）。今後軟件工程做爲一個正式的術語肯定了下來。

三、你們知道了軟件和軟件工程的起源，請問軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

一個軟盤的故事

用戶：「我在辦公室和家裏都用計算機。但是辦公室裏和家裏的計算機使用的磁盤大小不同家裏用的是大磁盤，辦公室裏用的是小磁盤，我怎樣才能在辦公室使用我家裏的大磁盤呢？」

工程師：「你須要先把大盤上的數據拷貝到小盤上。」

用戶：「好, 謝謝！」

次日，這個用戶又打來電話。

用戶：「我把盤放到我辦公室的計算機裏，但是計算機總是發出很奇怪的聲音，而且我找不到我在家裏打的文件，我該怎麼辦？」

工程師：「 你是否是先把大盤上的數據拷貝到小盤上了？」

用戶：「我想是吧。我用剪刀把大盤的四周剪掉大盤不就變 成了小盤了嗎？我這樣作難道不對嗎？」

工程師：「„„„„„„„„„„」

四、上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？

名稱	使用人數	優勢	缺點
Microsoft TFS	Microsoft	是對敏捷，msf，cmmi等項目、過程管理、過程改善的支持。任務版上能將需求、項目進度盡收眼底，對於小團隊而言，比甘特圖更有用。	能應用起來的團隊、公司的數量極少，多數真正用起來，也就是源代碼管理這部分，這也僅僅是佔TFS極小部分功能。
Git	31,000,000	分佈式的版本管理，適合分佈式開發，強調個體; 公共服務器壓力和數據量都不會太大; 速度快、靈活;擁有良好的分支機制，git的分支只要不提交合並，對其餘人沒有任何影響。	git沒有嚴格的權限控制，通常是經過系統設置文件的讀寫權限來作權限控制。工做目錄只能是整個目錄，而svn能夠單獨checkout某個有權限的目錄。git上手可能沒有svn那邊順手，須要通過學習一下
Mercurial	*	有revset，擴展性，append only的存儲結構 ,命令行簡單，易於上手。	分支管理不靈活， 跨平臺性能較差 。
GitHub	31,000,000	分佈式的版本管理，適合分佈式開發，強調個體; 公共服務器壓力和數據量都不會太大; 速度快、靈活;擁有良好的分支機制，git的分支只要不提交合並，對其餘人沒有任何影響。	git沒有嚴格的權限控制，通常是經過系統設置文件的讀寫權限來作權限控制。工做目錄只能是整個目錄，而svn能夠單獨checkout某個有權限的目錄。git上手可能沒有svn那邊順手，須要通過學習一下
Bitbucket	5,000,000	免費支持私有倉庫， 支持 hg/git ， 擁有靈活的權限管控，可自定義域名。	系統不夠穩定 。
Trac	*	有良好的擴充性，權限體系比較完備，很是靈活，能夠爲所欲爲控制能夠和SVN集成。	功能不是很強大。
Bugzilla	*	目前免費，支持中文版本。	只能管理缺陷 。
Apple XCode	*	能夠自動建立分類圖表 ；編譯速度快，操做快速輕鬆；自動提供撤消、重作和保存功能，無需編寫任何編碼。	更新版本後，某個插件可能會失效。

五、調查完目前流行的源程序版本管理軟件和項目管理軟件後，請你選擇其中至少2個軟件來進行動手實踐。

1）git修改readme

2）github建立倉庫