軟件工程第一次閱讀

閱讀《構建之法》後的一些問題

一、第三章「技能的反面」

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

我認爲如今這個問題仍是廣泛存在的，進入了計算機系之後感受同窗們的水平仍是有差距，畢竟有些人先前接觸過編程，或者已經對計算機十分熟悉，但有些同窗是初學者，在學習了一些基礎知識之後，就很着急地去作一些很深奧的研究。我曾經也想去實驗室裏作一些項目，可是發現本身的基礎水平實在不夠，什麼東西不會就現場查，用了之後就忘記了。仍是要認清楚本身的實力，經過不斷練習，把最底層的問題解決之後，才能去解決更高層的問題。

二、關於第四章中的兩人合做

在4.5.2中，做者提到「在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔等。」

以前對結對編程的理解有誤，認爲是兩人一組討論以後各自分配任務，而後各自完成各自的部分。而書中這種結對編程的形式在我看來開發效率會下降，特別是兩我的的水平層次不同的時候。書中強調告終對編程的優勢：可以隨時複審和交流，省下來不少修改測試的時間。但個人疑問是，兩我的一塊兒開發，原本可以用兩倍的效率被縮減到了一半，而且在交流過程當中可能會浪費不少時間。而且兩我的若是開發習慣不一樣，思惟方式不一樣，很容易產生分歧。

在閱讀相關論文"Case study: using pair programming in development of a complex module."[1]後，論文提出告終對編程須要知足的條件：

一、結對成員必須在一些編程觀念上達成一致

二、結對成員之間必須保持良好的交流，願意相互合做

三、結對成員技術知識必須具備可比性。若是一個經驗豐富的成員和一個沒有經驗的成員一塊兒工做，他們能夠創建良好的指導關係，但他們不一樣的經驗水平不利於有成效的結對編程。

可見結對編程也是有必定適用範圍的，而且開發效率也要看具體的狀況，不肯定的因素十分多。

三、第六章中的敏捷流程

找出完成產品須要作的事情—Product Backlog。Backlog翻譯成「積壓的工做」、「待解決的問題」、「產品訂單」，均可以。產品負責人主導你們對於這個Backlog進行增／刪／改的工做。

看到這個地方我仍是不太明白Backlog是須要如何來制定和展示，如何評定優先級和進行初始的評估。文章後面也提到，各個需求和任務之間是由各類複雜的依賴關係的，這是咱們在除了優先級意外須要考慮的。

並且若是有優先級相等的任務和需求而且無依賴關係，能否將兩個backlog平行執行呢？

四、第十六章中的創新迷思

"其實，大部分紅功的創新者都不是先行者，例如搜索引擎，Google是很晚才進入這個領域的。"

這個地方引發了個人思考，爲何一些先行者會最後在競爭中被淘汰呢。書中提到了Intuit這個公司，是第四十七個進入我的財務軟件這個市場的，最後卻成爲行業的老大。

我在網上上查閱了Intuit的歷史,在和微軟的競爭當中，微軟的Microsoft Money軟件因爲設計人員的經驗不足而設計週期過長，Intuit就利用經驗的優點縮短升級產品的推出週期來打擊微軟。另外，微軟並無盡心盡力奪取Intuit的市場。表面上，微軟擁有編程隊伍的豪華陣容，但就我的財務軟件領域來看，1994年，Intuit有1000多名僱員專職於我的財務軟件和相關軟件研究，微軟專門從事該領域的僅60人左右。

在企業的競爭中，強與弱並非絕對的，一個有效的競爭策略加上公司資源的合理配置和使用，每每起到決定性的做用，由於巨人也並不是無懈可擊。

五、第十五章穩定和發佈階段：砍掉功能

「沉沒成本」（Sunk Cost）從你作事的歷史來看，若是相似的功能須要N個單位時間才能最終完成，那麼咱們沒有理由相信新功能會花少於N個單位時間。

在臨近發佈的時候若是有一個模塊看來不能實現預期的設計需求，時間快到了，書中建議砍掉該功能。在實際的開發中，我也有遇到過相關的問題，老是想着再花點時間把功能趕忙作出來。在網上查閱了沉沒成本的相關概念，「沉沒成本」是指以往發生的，但與當前決策無關的費用。從決策的角度看，以往發生的費用只是形成當前狀態的某個因素，當前決策所要考慮的是將來可能發生的費用及所帶來的收益，而不考慮以往發生的費用。

人們在決定是否去作一件事情的時候，不只是看這件事對本身有沒有好處，並且也看過去是否是已經在這件事情上有過投入。可是這些不可回收的支出其實對將來的效益並無改善。

「軟件」和「軟件工程」

• 軟件最先是由Alan Turing在他1935年的關於可計算數字的論文中提出的，但他所指的軟件並非咱們今天所理解的軟件。最先在工程背景下出版的術語「軟件」是在1953年8月由Richard R. Carhart在蘭德公司提出的。

• 「軟件工程」一詞第一次出如今1965年6月出版的「COMPUTERS and AUTOMATION」中。瑪格麗特·漢密爾頓（Margaret Hamilton）提出了將該學科命名爲「軟件工程」的想法，以此做爲賦予其合法性的一種方式。

經常使用源程序版本管理軟件和項目管理軟件分析

在維基百科上找到了開源版本管理軟件的排名

• 一、github：約31,000,000用戶量

• 二、SourceForge：約3,700,000用戶量

• 三、Bitbucket：約5,000,000用戶量

• 四、GitLab：約100,000用戶量

各類項目管理軟件的優缺點：

• Microsoft TFS

  • 優勢：任務版上能將需求、項目進度盡收眼底，對於小團隊而言，它集成了項目管理、版本控制、BUG跟蹤，能有效實現SCRUM與VS無縫接合。易於管理，熟悉的界面以及與其餘Microsoft產品的緊密集成。容許持續集成。

  • 缺點：我的成本上的消耗相對來講更大一些。整個系統是用 asp 實現的，用瀏覽器訪問至關慢。搭建與維護過程麻煩，硬件要求高。始終須要鏈接到中央存儲庫。執行簽入和分支操做的速度很慢。

• Mercurial

  • 優勢：從版本控制遷移很容易；提供很好的文檔；分佈式模型；使用python輕鬆擴展。
  • 缺點：只有命令行系統，沒有官方的GUI；全部加載項必須用Python編寫。

• Git

  Git是一款免費、開源的分佈式版本控制系統，用於敏捷高效地處理任何或小或大的項目。做爲一個開源的分佈式版本控制系統，能夠有效、高速的處理從很小到很是大的項目版本管理。

  • 優勢:

    1．適合分佈式開發，每個個體均可以做爲服務器。每一次Clone就是從服務器上pull到了全部的內容，包括版本信息。

    2．公共服務器壓力和數據量都不會太大。

    3．速度快、靈活，分支之間能夠任意切換。

    4．任意兩個開發者之間能夠很容易的解決衝突，而且單機上就能夠進行分支合併。

    5．離線工做，不影響本地代碼編寫，等有網絡鏈接之後能夠再上傳代碼，而且在本地能夠根據不一樣的須要，本地新建本身的分支。

  • 缺點：上手不是很簡單，須要時間磨合

• Trac

  • 優勢：

    一、Trac是一個SCM配置管理平臺，意味着它有良好的擴充性

    二、Trac的權限體系是比較完備的設計

    三、很是靈活，能夠爲所欲爲的定製，能夠和TortoiseSVN集成。

  • 缺點：

    一、不支持多項目，

    二、需求和缺陷沒有分離，

    三、用 wiki 來替代 Word 等工具編寫文檔對於產品策劃來講門檻過高了，

    四、核心功能不多，不安裝插件基本上無法用。

• Bugzilla

  • 優勢：

    免費的開源的一款功能強大的Bug管理系統，好比強大的檢索功能，強大的後端數據庫支持, 豐富多樣的配置設定等；

  • 缺點：

    安裝須要Perl和配置MYSQL數據庫，過程比較繁瑣，修改配置文件比較麻煩；英文版的，能漢化可是漢化後容易出現亂碼；

參考資料

[1][Case study: using pair programming in development of a complex module.](https://www.thefreelibrary.com/Case+study%3a+using+pair+programming+in+development+of+a+complex+module.-a0246014267)

[2]https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

[3][版本控制軟件比較](https://en.wikipedia.org/wiki/Comparison_of_version-control_software)