初窺軟件工程 2020BUAA軟件工程$\cdot$我的博客做業

時間 2020-08-10

標籤軟件工程 2020buaa buaa cdot 我的博客简体版

原文原文鏈接

初窺軟件工程 2020BUAA軟件工程$\cdot$我的博客做業

初窺軟件工程 2020BUAA軟件工程$\cdot$我的博客做業
- 1、做業要求簡介
- 2、正文

1、做業要求簡介

本文是北京航空航天大學計算機學院軟件工程課程的我的博客做業。本次做業的主要目標在於，經過通讀教材《構建之法》，造成對軟件工程這門學問的初步理解，對於不理解的地方，提出困惑之處，在以後這門課程的學習中，經過實踐反覆印證與體會書中方法，找到問題的答案。html

項目	內容
這個做業屬於哪一個課程	博客園班級連接
這個做業的要求在哪裏	我的博客做業
我在這個課程的目標是	得到成爲一名軟件工程師的能力
這個做業在哪一個具體方面幫助我實現目標	造成對軟件工程的初步理解

2、正文

(一) 快速看完整部教材，列出你仍然不懂的5到10個問題

問題1. 單元測試時如何有效拆分單元？輸入數據和輸出數據如何構造？

書中第二章介紹了單元測試的方法，我在面向對象課程中也使用過java的單元測試，不過僅僅流於形式，象徵性完成課程的目標。在作編譯課設的時候，也想過沒寫完一個模塊都要作單元測試。可是我發現了一個難點，有時只有最開頭的輸入數據好構造(甚至能夠構造)，那麼如何對中間一個單元作單元測試？java

好比在測試編譯器的第一個模塊詞法分析的時候，構造數據輸入就特別容易，由於是第一個模塊，直接輸入字符串就能夠了。可是從第二個模塊語法分析開始就麻煩了，它的輸入時詞法分析的輸出，這個輸出是我定義的一個Class的實例，只有在跑完詞法分析以後才能獲得。若是我要對語法分析作單元測試，單元測試代碼裏就必須先跑詞法分析獲得輸入，這跟直接測試整個程序就同樣了，還叫單元測試嗎？git

除了輸入之外，輸出也是問題，有些時候，程序的運行結果人腦很難算出來甚至算不出來，我寫程序的目的其實就是想把他算出來，那麼我怎麼能獲得正確的輸出來測試個人程序呢？好比寫編譯器時，中間的某些結果靠人腦就要花很長時間的推演。咱們一般是靠和其它同窗對拍來作測試，可是實際生產中，可能這一個模塊只有一我的寫，就無法對拍，這種狀況下如何方便地獲得測試標準結果呢？github

還有一個問題就是單元測試要拆分到什麼程度？代碼短的單元沒有測的必要，代碼長的單元定位又不精準。我是以函數/方法爲單元來測，仍是以一個功能塊爲單元測，尺度如何把握？web

問題2. 即便用了源代碼管理工具，也很容易忘記某個版本到底是幹什麼的，如何更好地經過message提示本身？

書中在講代碼管理的時候，提到要儘量多的提交當前的修改，哪怕是隻改了一個小bug，也要及時提交。我在使用git管理代碼的時候，常常遇到這樣的狀況，在寫git commit -m ""的message信息時，總不知道應該寫什麼，愣了半天寫了一句「fix some bugs「或者之類的話。可是這種作法在須要版本回退的時候是很是痛苦的，真的不知道當時修了什麼bug，若是去挨個diff分析本身改了什麼又很低效。數據庫

因此這個message相當重要，可是對我而言有時寫message又真的很難用語言表達我所作的修改，有沒有什麼技巧可以簡潔清楚地描述修改了什麼、目的是什麼從而讓版本回退時一目瞭然？xcode

問題3. 怎麼在源代碼管理工具中更優雅地改bug?

這個問題是我以前寫代碼時遇到的，在讀書中代碼管理時提煉了出來。描述以下：安全

好比要開發兩個連續流程A、B、C、D，順序開發完ABCD，並commit。在開發完D並commit後，發現A中有bug，此時應該怎麼作？是直接在D中改了，無論以前的A的正確性了？仍是回退到A，改bug，commit到新的A‘，以後merge A’ 和D保證D的正確性？服務器

分析一下，這二者都不太合理，首先第一種，若是我以後想版本回退，ABC版本都包含這個bug，那時候可能已經忘了這個bug了。第二種只能保證回退到A'是正確的，BC都無法正確回退。那麼若是把BC也都改了呢？一個問題的是提交的message怎麼寫，"B1：B fixed bug xxx"？假如以後再發現別的bug呢？用B一、B2這麼編號好嗎？另外一個更難搞的是假如AD之間不僅有BC，而是有幾十個commit咋辦？git的管理機制彷佛沒提供在以前某個提交的版本上修改，後面的提交自動改的方法(或者我不知道hh，git太難了)。事實上按照git的機制咱們根本不能修改某次提交，最可能是像從A分出一個改過bug的A‘。最終這個commit樹就變成這樣了，非常蛋疼。網絡

但願經過以後對git的進一步理解，可以更優雅地解決這個問題。

問題4. 多人合做時，如何解決push衝突問題，如書中11.5.4所述

當Apull下來解決merge衝突，並測試無誤以後，想要push，發現又有人push過了，這就還得再pull下來，解決衝突，並測試。這個無疑很浪費時間，可是彷佛也沒辦法，書中提到了用一些寬和嚴的制度來規定這個處理方法。我以前沒經歷過多人合做開發，實際遇到這個問題時咱們應該怎麼辦呢？

問題5. 如何解決開發基礎差的問題？軟工課上如何解決？

在11.6的討論中，若是有隊員的基礎差怎麼辦，好比你們要用C#開發，但我不會C#，得現學現用，致使開發效率低，且容易出bug。軟工課上要怎麼解決這個問題呢？讓基礎差的同窗作PM或者測試嗎？他們不肯意怎麼辦？

問題6. 初創公司如何找到技術創新與營銷經營的平衡點？

在閱讀第16章創新的時候，書中有這樣一個論斷，當一個產品要發佈的時候，一般都留有一些已知的bug而不去改。一方面緣由是產品要即便發佈纔能有盈利，另外一個緣由是爲下一階段的產品迭代留有餘地，團隊會更有幹勁。

這裏涉及到一個把握平衡的問題，若是你尚未解決一些問題就發佈，這個產品可能沒法獲得用戶承認；可是若是一味追求解決全部技術問題，永無止境地作技術創新和技術改進，而不去經營營銷，這樣又無法盈利。因此如今有很多由技術出身的人辦的初創公司面臨着這個平衡的問題。有些公司一味地追求改進技術，忽略了經營營銷的重要性，這樣也是不可取的。那麼如何找到這個平衡點呢？但願軟件工程課能給我一些體會。

問題7. 軟件工程有沒有什麼解決不了的問題？軟件工程的痛點在哪？

讀完了整本書，涵蓋的內容十分繁雜，設計的領域也很是多，包括計算機，軟件，經濟，管理，方法論等等。也針對不少特定的問題給出了軟件工程的解決方案。那麼，有沒有軟件工程無法解決的問題呢？有沒有人類使用了軟件工程方法也無法實現出的軟件？軟件行業目前面臨的痛點在哪？軟件工程應該針對這些痛點提出什麼新的方法呢？...

這些問題可能用一生的軟件開發經歷都不能徹底回答，可是我但願經過軟件工程這門課，加之從此軟件開發的經歷，可以認真思考這個問題，爭取爲軟件工程的發展進步提出本身的看法。

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

軟件(Software)

術語"軟件"(Software)的最先發表記錄是在1958年John Wilder Tukey發表的論文"The Teaching of Concrete Mathematics"中。然而沒有證據能證實是Tukey發明了"Software"這個詞，其最先發明時間可能更早，在1953年Richard R. Carhart曾在engineering context中使用過這個詞，是目前最先的"Software"術語的使用記錄。

簡要介紹John Wilder Tukey

Tukey(1915-2000)是美國的數學家，其最知名的成就是發明了快速傅里葉變換(FFT)和箱型圖(box plot)。1947年，在貝爾實驗室工做的Tukey發明了術語"bit"，並且還有諸多術語都是以Tukey命名的，如Tukey's range test, Tukey lambda distribution, Tukey's test of additivity, Tukey's lemma, 和 Tukey window

軟件工程(Software Engineering)

術語"軟件工程"(Software Engineering)被認爲是在1968-1969年與NATO組織的會議上提出的。在60年代，因爲大的複雜的系統開發困難，人類面臨"軟件危機"(Software Crisis)。所以人們提出引入工程化方法指導軟件開發，從而下降軟件開發的成本，提高開發效率。

在NATO會議正式提出"軟件工程''術語以前，就曾有屢次提出此術語的嘗試，早在50年代 Douglas T. Ross 在MIT的講座中就曾提到軟件工程這個詞，以後 Margaret H. Hamilton正式命名了這個術語。

簡要介紹Margaret H. Hamilton

Hamilton是著名的美國女性計算機科學家，系統工程師和企業家。她最重要的貢獻就是曾擔任MIT儀器實驗室軟件工程部主管，幫助開發阿波羅計劃中航天器搭載的飛行軟件。其編寫的程序都以最大程度防止崩潰爲目的，從而防止了阿波羅11號登月計劃中綴。

(三) 請問軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

微軟2001年推出WindowsXP系統時，好不容易想好了廣告語「prepare to fly」，911事件發生了。沒辦法，微軟只好把「帶你飛」，臨時換成「你能行」。這一換，前期砸進去的兩億美圓宣傳費，就正式打水漂了。

控告之路，1994年蘋果公司把微軟告上法庭，理由是侵權。對此比爾蓋茨是這麼說的「咱們有一個富鄰居——施樂，他家有一臺電視。當咱們想偷的時候，發現早就被喬布斯偷走了，可他卻說咱們是小偷。」什麼意思呢？EyeOpener簡單「翻譯」下，就是「你也是偷別人（施樂）的，好意思出來告我？」。在微軟被告時，施樂以類似的理由把蘋果也告了，固然最後的結果是：原告們都輸了官司。

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

Git
- 是一個分佈式版本控制軟件，最初由林納斯·託瓦茲創做，於2005年以GPL發佈。最初目的是爲更好地管理Linux內核開發而設計。
- 優勢：適合分佈式開發，強調個體。公共服務器壓力和數據量都不會太大。速度快、靈活。任意兩個開發者之間能夠很容易的解決衝突。離線工做。
- 缺點：學習週期相對而言比較長。不符合常規思惟。代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。命令設計混亂，不直觀。(參考)
GitHub
- GitHub是經過Git進行版本控制的軟件源代碼託管服務平臺
- 優勢：使用用戶衆多，最大的開源代碼倉庫。pull request和issue功能是亮點
- 缺點：因爲使用普遍，其安全性近些年很有討論。曾忽然封鎖某些國家地區的使用，對其形成影響。並且上面反華勢力嚴重。
Microsoft TFS
- 微軟的團隊代碼管理服務平臺Team Foundation Server，是微軟開發的項目管理工具。
- 優勢：與Visual Studio無縫結合，方便開發者進行源代碼管理，支持代碼審閱與討論，支持郵件通知，支持Web訪問與管理，支持工做項以及BUG等管理，不會上傳.NET開發時生成的垃圾文件，自帶版本合併以及比較工具，支持數據庫版本管理，自帶不少管理工具（測試管理器、反饋客戶端、界面設計工具等等）
- 缺點：能應用起來的團隊、公司的數量極少。(參考)
Mercurial
- Mercurial是跨平臺的分佈式版本控制軟件，主要由Python語言實現，但也包含用C語言實現的二進制比較工具。Mercurial一開始的主要運行平臺是Linux，如今Mercurial已經移植到Windows、Mac OS X和大多數的類Unix系統中。Mercurial主要由命令行程序組成，如今也有了圖形用戶界面。對Mercurial的全部操做都由用不一樣的關鍵字做爲參數調用程序「hg」來實現，Hg是參考水銀的化學符號而取的名字。
- 優勢：命令行簡單、容易上手。
- 缺點：功能不夠強大。沒有命名空間，多人合做時易出現重名問題。改寫歷史版本很麻煩。分支模型的設計有缺點(參考)
Bitbucket
- Bitbucket是Atlassian公司提供的一個基於web的版本庫託管服務，支持Mercurial和Git版本控制系統。Bitbucket既提供免費賬號，也提供商業付費方案。Bitbucket提供的服務相似於GitHub（僅支持Git）。BitBucket的目標用戶是開發專有軟件的專業開發者，在2010年它被Atlassian收購後此定位更加明確。
- 優勢：支持Hg同時支持Git。
- 缺點：GitHub私有倉庫再也不收費後市場減小。
Trac
- Trac是Edgewall公司開發並維護的開放源碼網頁界面項目管理、缺陷追蹤軟件。Trac的靈感來自於CVSTrac，由於可以與Subversion接口，因此最初叫作svntrac。
- 優勢：很是靈活，能夠爲所欲爲控制能夠和SVN集成
- 缺點：功能不是很強大(參考)
Bugzilla
- 是一款用於軟件缺陷的追蹤管理網絡程序，由Mozilla計劃開發和應用。1998年，網景公司開放其源代碼後，以Mozilla公共許可證協議許可。有許多組織採用其做爲旗下軟件（特別是自由軟件）的產品缺陷追蹤系統。
- 優勢：是bug管理工具，比較出名的開源軟件。
- 缺點：只能管理缺陷，界面效果差。
Rational
- 優勢：採用迭代式開發模式，以下降項目風險；專一於構架，開發出更有彈性的系統，以迅速適應不斷變化的業務需求。
- 缺點：對於我的用戶的功能開發遠不如github方便
Apple XCode
- Xcode是蘋果公司向開發人員提供的集成開發環境，用於開發macOS、iOS、WatchOS和tvOS的應用程序。
- 優勢：功能強大的蘋果軟件IDE，也是蘋果官方出品。其上集成了強大的代碼管理工具。能夠自動建立分類圖表。自動提供撤消、重作和保存功能，無需編寫任何編碼。
- 缺點：功能太多，上手較慢，做爲一名蘋果用戶至今沒敢觸碰的IDE。。。