軟體工程第1次作業

在閱讀此書的時候，我盡量和自己的實際經歷結合起來思考，的確產生了一些想法。

年輕學生都志向遠大，上了一些課，就很想解決高層次的問題，一些學生非常想做高層次的「科研」，覺得「工程」是基礎，沒意思。而且他們認為「我已經知道怎麼做了」。

我應該是書上例子的反面，最開始就是打算解決中低等層次的問題。在學習理論知識的時候，覺得高層次的問題非常抽象。比如對於高階演算法的學習，常常是花了很多時間學習，但是過一段時間後就忘了，感覺個人收穫很少。

所以沒有把重點放在進實驗室做「科研」的方向上，而是去了解移動端開發和傳統後端開發的知識，著手做小的專案。在完成了能夠執行的**之後，的確覺得在web後端crud搬磚有點無聊，開始涉及機器學習，發現「科研」[演算法]實際上對數學素養的要求很高，而個人數學水準只是應付考試的樣子。

在企業實習之後，發現把自己寫的**被merge到master分支，然後到線上環境被很多人使用，是非常有成就感的事情，所以感覺做「工程」也不止是搬磚，壓力和成就感都是「工程」能夠帶給自己的，並且由於實際需求，很多時候工程開發不一定比**灌水更簡單。

**規範可以分成兩個部分： 1. **風格規範，主要是文字上的規定，看似表面文章，實際上非常重要。

之前其實對**風格是非常不在意的，但是最近重新認識到了良好**風格的重要性。

在企業軟體開發的過程中，個人最開始不注重**風格，結果發現自己寫的**不能通過線上的**規範校驗，採坑舉例：

所有全域性變數必須用g_開始，並且全域性變數的申明之後必修留空一行。

php中不能使用private const字樣，因為這是php6.x之後支援的用法，而已有**很多使用的php5.5和5.6，所以不能使用不相容的語言特性。

後來閱讀別人的**意識到，軟體的研發階段時間是很少的，而維護的時間佔比最大，一般來說，看到的**可能是上乙個離職的人留下的**，況且很多程式設計師根本不寫注釋，這時候如果**命名很爛，風格很差，接手**的人會很痛苦。

在結對程式設計模式下，一對程式設計師肩並肩、平等地、互補地進行開發工作。他們併排坐在一台電腦前，面對同乙個顯示器，使用同乙個鍵盤、同乙個滑鼠一起工作。他們一起分析，一起設計，一起寫測試用例，一起編碼，一起做單元測試，一起做整合測試，一起寫文件，等等。

根據定義，我在網上找到的結對程式設計是這樣的：

然而我在短期的企業實踐中很少觀察到這種程式設計方式，根據我的觀察，如果出現兩個人對著同乙個螢幕，更多時候是在討論為什麼出現了這樣乙個bug，怎樣去修好（並且這種情況下還是因為其中乙個人搞不定），而不是怎樣設計文件以及程式設計的過程。

雖然兩個人一起工作能夠更為全面的審視**，但是個人感覺是一種降低效率的方式，不同的人思維不同，**風格不同，話說兩個人坐在一起寫同乙個函式會不會因為大括號到底要不要換行而吵起來呢？

- 使用者體驗的創新 - www.hao123.com有什麼技術上的創新麼？

關於hao123.com是如何做大的，書中並沒有具體的描述。

在200x那幾年hao123的確是個現象級**，那個時代很多網咖上網導航都預設是hao123。hao123在早期來看的確是乙個沒有技術含量的**，只是單純的收集各種**的鏈結，看起來好像很容易被複製，但是查閱了一些資料總結一下：

實際上是因為保證了**質量，而的確不是因為技術上的創新。

這一章沒有什麼問題，但是更加清晰地認識到了敏捷開發的流程。每個sprint迭代中給每個團隊成員分配卡片任務，時間以天數為單位，同時每週例行站會和每週總結，比較適合快速迭代的開發，但是這種開發模式，文件這些方面會弱勢一些。

『軟體工程』一詞最早是由 margaret hamilton 在阿波羅11號登月計畫準備期間提出的，她最開始使用soft engineering詞是為了和硬體以及其他工程學做出區別。

『軟體』術語最早出現在出版刊物是在1953-8月，被richard r. carhart提出，而最早使用「software」是在jstor電子刊物的一篇調研。

使用排名：

github

bitbucket

launchpad

sourceforge

軟體特點：

mercurial

trac

bugzilla