軟工第一次閱讀

所屬課程：https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_RJ/
所屬做業：https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_RJ/homework/2626
課程目標：及格，在此基礎上儘可能多拿點分。
做業回報：_(:з」∠)_看了N久書……百度了N次……

1. 閱讀

1

2.1    "因此，寫單元測試沒有比做者更適合的人選了。"

首先我以爲寫好一個單元測試自己是和寫好一個功能有時候是等價的事情。

咱們何時會寫很差一個功能呢？

• 有時候是由於粗心、失誤寫錯了一部分代碼。這種錯誤就是腦子裏的代碼和寫下來的代碼不一致。
• 有時候是由於對他人寫的模塊的功能的誤解。這種就是腦子裏的代碼和別人已經寫下的代碼不一致。
• 而有的時候是由於對功能自己的理解就不對。也就是腦子裏的代碼自己就不對。

本身寫的單元測試對於前兩種錯誤是有效的，但對於第三種錯誤是無效的。

那麼第三種錯誤該如何避免呢？我以爲讓別人來寫單元測試是一種可行解。一我的理解錯誤機率較高，兩我的就比較低了，三我的就更低了。

因此我以爲寫單元測試的最合適的人選不該該只是代碼做者自己，還應該包括功能指定人，就是負責設計產品功能的人，甚至包括想用這個產品的人。

2

3.1 "軟件工程的奠定人之一瓦茨·漢弗雷總結說，軟件領域能夠分爲兩個方面：一方面是技藝創新的大爆發；而另外一方面是堅持不懈的工程工做，包括軟件的改善、維護和測試等，這一方面佔了90%—95%的比例。"

我對這句話用在我的評價這裏是否合適抱有疑問。

按照個人理解，他所說的應該是整個軟件的工程實現中，工程工做佔據了90-95%。也就是說，對於團隊內部處於不一樣層級的工程師而言，工程工做的佔比應該不一樣。

一個高級的工程師可能不該該老是在作可重複的任務？一般的認知應該都是這樣的纔對。

因此我認爲對於一個高級工程師而言，工做中的「技藝創新的大爆發」可能不止5-10%？那麼將標準方差做爲評價標準就是一個有待商榷的方式了。

3

3.3 技能的反面

我以爲不該該將低層次的問題解決變成不用通過大腦的自動操做，由於咱們這個行業的「低層次問題」變化過快、過大。

我在上大學前基本是隻敲C那一族的語言的，剛上大學那會兒對一些基本的代碼確實能夠不經大腦思考來自動操做。可是這對我學習新的語言造成了障礙，由於我已經構建了不少條件反射了。說到這個就是那個，←就這種感受。

固然，也能夠再對新的語言進行訓練，而後又多一族新的條件反射。可是如今這樣每月幾乎都有新的技術的環境下真的值得去進行這種訓練嗎？我對這個觀點抱有疑問。

4

4.2 "另外，註釋（包括全部源代碼）應該只用ASCII字符，不要用中文或其餘特殊字符，不然會極大地影響程序的可移植性。"

這點我以爲在如今的編程環境中有待商榷。如今支持utf8編碼形式源代碼的編譯器不在少數，不如說正在變成主流的感受？

不過我也相似地以爲註釋不該該使用中文，理由不是編碼帶來的移植性問題，而是由於如今進行開發每每是全球性的。代碼丟到github上之後鬼知道fork的人是哪國人了。

5

4.3 "函數最好有單一的出口，爲了達到這一目的，可使用goto。"

誠然，示例中的Goto Error這類狀況，使用goto確實能使得代碼更加清晰。但應該避免使用goto這點從我學編程開始就一直被這麼說着了。

我以爲在缺少合適的異常處理機制，或者一些特殊的內核代碼實現的狀況下，使用goto是能夠的，確實有助於代碼邏輯的清晰、實現的簡潔。但若是僅僅只是爲了單一出口而使用goto我以爲不可。

我以爲多處使用return致使了多個函數出口帶來的壞處是小於過多使用goto致使的零散代碼塊的弊端的。

6

4.4 在todo標記那裏加上人名

我以爲一份代碼的存在應該獨立於人，也就是說，不該在代碼中標註人名，這樣要是團隊中發生了人員更迭，那就須要修改代碼來更新這些人名標記，而這種代碼修改要是出如今提交歷史裏面我以爲是一種冗餘，由於並無任何功能上的更新，而只是行政的變化。

我以爲經過外部的管理軟件來指定負責人更好。

7

4.5 "若是團隊的人員要在多個項目中工做，不能充分保證足夠的結對編程時間，那麼成員要常常處於等待的狀態，反而影響效率。"

此次的疑問不是對書的疑問，而是對課程的疑問。由於事實上咱們大學生就是處在這樣的狀況。咱們有多個項目，並且由於選課制致使項目還都不太同樣。咱們不得不互相等待對方的時間。

8

5.2.5 祕密團隊

這種模式感受不適用於僱員團隊，而只適合創業團隊那種感受。這種對團隊成員自身的能動性、自律性等等有較高要求。

舉個例子，目前公認的一個結論是較小的生態圈很難自給自足，稍小的擾動就會致使生態系統崩潰。對於團隊也是這樣的。祕密團隊意味着和外界隔絕，也就是造成了一個獨立的較小環境。對於這種環境的可靠性、可維持性，我報有疑問。

2. 調研軟件

software: 2000, Fred Shapiro, "The Teaching of Concrete Mathematics"
軟件工程：阿波羅11號的軟件開發期間，Margaret Hamilton

4. SCM比較

經過stackoverflow的這個調查能夠看出，絕大多數人都用git。

• git: git是我一直在用的，或者說我周圍人也一直用這個。在我看來這就是SCM的基準點吧。

• TFS: TFS我以爲更像是個團隊軟件開發管理程序，git的功能只是它的一個小分支罷了。在微軟實習的時候用過一小會兒，事實上那時候我提交代碼其實仍是用git提交的，而後review之類的行爲的時候纔是登上TFS去搞的。

• mercurial: 這個按照這篇博客的說法，是易用性比git強。

• github: 呃……github不是一個獨立的SCM吧，我總以爲它內核用的仍是git。我猜測這指的是github desktop。這也是我一直在用的，我以爲這玩意兒主要是讓上手更容易了。github desktop用起來可比git bash順手多了。並且github提供了個隨手就能存的源代碼管理網站，變得可以隨意使用git了，雖然得open-source就是了。

• bitbucket: 這個我偶爾會查到某些庫用這個網站來存着。和github同樣，我總以爲這貨應該也是用mercurial做內核，而不是一個獨立的SCM。根據這篇博客的說法，bitbucket更注重私人倉庫，github更注重公開倉庫。

• trac: 這個根據它官網上的介紹，它和TFS相似是個團隊軟件開發管理程序，不過trac是開源的，並且基於BSD，這意味着能夠定製本身的trac。

• bugzilla: 這個彷佛是個bug追蹤系統，雖然也是個團隊開發管理程序，但側重於bug追蹤。

• Rational: 根據百科的介紹（我打不開IBM上rational的頁面……），這彷佛是個巨大的開發平臺，反正是要錢的，格調很高的樣子。

• Apple XCode: 根據官網上的介紹的介紹，這是個IDE吧……並非一個獨立的SCM，但支持挺多SCM的樣子。這個應該主要都是ios平臺東西的開發吧。