第一次閱讀做業

項目 內容
本次做業所屬課程 北航軟件工程2019
本次做業要求 要求詳情
我在本課程的目標 熟悉瞭解現代軟件工程,提升自身能力
本次做業的幫助 在《構建之法》的幫助下更好了解軟件工程

1. 在閱讀《構建之法》後的思考與疑問

  • 在第16章IT行業的創新中做者老師在16.1.2 迷思之二:你們都喜歡創新中講了這樣一個例子:

假如你發明了電報,創辦了電報公司,這時一個年輕人上門推銷了他的創新——電話。你敏銳地看到這個創新將會顛覆目前的電報產業,這時你會怎麼想?會不會恨這個新發明?html

在這個問題上我可能有一點不同的見解。創新是爲了咱們的社會和時代向着未知的遠方邁進,是給咱們每一個人帶來愈來愈方便高質量生活的一條必經之路。尚且不說每一個人都有如此高尚的道德品質與以人 類發展爲目標的信仰,即便是爲了利益,我認爲當一個發明電報的人看到新發明電話的時候想的並非恨。我相信每個聰明人更多想到的應該是吸取與發展,由於他已經看清楚這個創新會顛覆目前的一切,那爲何不選擇參與這個創新而進一步昇華自我?我以爲當咱們承認一個創新的時候,不論它會對咱們形成怎樣的影響,咱們仍是喜歡如此的創新。若是夾雜了太多的主觀情感與因素,那麼這是對創新的一種不負責任,也就談不上本身於創新有什麼關係了。git

  • 在閱讀了16章中16.1.7 迷思之七:成功的團隊更能創新與16.3.1創新的招數中的SWOT分析框架後我感覺到這樣的矛盾:

在前面關於創新的幾個問題探討過程當中做者曾屢次提到專家們對於顛覆性技術的預測每每是錯誤的——由於顛覆性技術的市場還不存在,而我也查了一些資料而且深有體會:通常的人是不會看到這些匪夷所思的顛覆性創新在將來不久將會有如此的市場,並且即使是創新者本人在這個問題上也不是特別的肯定,每每會對本身的想法持有懷疑的一面。結合書中所提到的SWOT框架以及我本身查閱到的一些關於SWOT分析框架的內容,無非是分析企業在當前社會市場中的優劣勢與利害關係。那麼問題就來了,企業的專家在分析一個創新的時候固然也會想到這些,可是他們不少的分析預測卻與實際相反,那咱們爲何還要以如此方式去分析本身創新的將來?是顛覆性技術創新的未知因素太多?仍是專家在分析預測時不夠客觀全面?github

  • 本書第8章需求分析中8.5和16章的16.3.6都提到了四個象限劃分產品與投入,在這裏我有一點小小的問題:
  • 第一象限(解決剛需且殺手功能):建議採起「差別化」的辦法,盡心盡力投資在這個領域。
  • 第二象限(解決剛需提供外圍能力):建議採起「抵消」和「優化」的辦法。
  • 第三象限(不是剛需且是輔助功能):建議採起「維持」的辦法,以最低代價維持此功能。
  • 第四象限(不是剛需但咱們有獨特的辦法作的更好):建議採起「維持」的辦法,或者限制「不作」,等待好時機。

書的8.5中提到過要把用戶從競爭對手那裏吸引過來,團隊本身的產品要有一個差別化的焦點,在這個焦點上,咱們的團隊能作得比別人好10倍(10X原則)。也就是咱們全身心投入到一個殺手功能也就是第一象限上去,可我覺的有時候咱們的關注點反而應該在第二象限纔對,也就是用戶必要的外圍功能。既然是用戶必要的功能,那我能夠理解爲是這個產品的基礎功能。咱們可不能夠有一個相似於推動式創新的想法就是把這些基礎外圍功能作到比別人好2倍,我暫稱它爲「廣泛2X原則」,由於據我所知所感,有不少好的軟件在全方位的功能與體驗上比競爭對手都要好出一個檔次,好比一款用來背英語單詞的APP——墨墨。因此從性價比上來看(可能10X原則付出會更多更難)優化提升第二象限的產品功能是否是比只關注殺手功能更好一些?web

  • 在17章中做者老師講了一個蘿蔔與白菜的故事,探討的主要是企業中不一樣的兩類人:一是任務完成很快,能夠涉獵不少項目模塊,卻很容易出現功能上的問題;另外一類是本身負責的模塊完成很好很穩定,同時也沒有時間和精力去關注其餘的。關於這個有趣的問題我有一點小小的見解和問題:

我覺的產生這兩類人的主要緣由仍是我的的性格問題,對於我來講我大機率會是上面談到的第二類人。我是比較傾向於先把本身的事情作到心安理得,再去管其餘的事情。由於一直以來不管是老師的教導仍是在實際的體會中,一旦你在某一個項目中留下了不少漏洞,你再回來補救所花的時間可能要比當時全面周到完成項目的時間更多。但第一類人的活躍又能獲得更高的曝光率,這裏我有一個問題就是如今的企業或者公司中更看重的是「蘿蔔快了不洗泥」型的仍是「慢工出細活」型的開發人員呢?編程

  • 關於第6章敏捷流程有一些不太懂的地方:

書中對於敏捷開發提到了不少條的原則,可其中不少條好比「以有進取心的人做爲項目核心,充分支持信任他們」卻徹底沒法讓我與「敏捷」聯繫起來。在我搜索查閱了敏捷開發等相關內容後大概瞭解了一點就是一個項目的模塊化,也沒有更多的深層次理解。而咱們這門課的微信羣名中也提到了「敏捷工程」,這使我覺的敏捷開發必定是現代軟件工程中十分重要的一環,因此我想知道敏捷流程與敏捷開發具體須要咱們在從此不管學習工做中怎樣實踐?他們更深一層的內涵是如何的?api

2. 「軟件」 和 「軟件工程」 這些詞彙是如何出現的?

  • 關於「軟件」一詞:

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that 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.服務器

——引用自維基百科微信

  • 關於「軟件工程」一詞

Margaret H. Hamilton "is the person who came up with the idea of naming the discipline, "software engineering", as a way of giving it legitimacy." According to Hamilton:
During this time at MIT, she wanted to give their software "legitimacy", just like with other engineering disciplines, so that it (and those building it) would be given its due respect; and, as a result she made up the term "software engineering" to distinguish it from other kinds of engineering.
Hamilton details how she came about to make up the term "software engineering":
When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.
When Hamilton started using the term "software engineering", software engineering was not taken seriously compared to other engineering, nor was it regarded as a science. She began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering. Over time the term "software engineering" has gained the same respect as any other discipline.The IEEE Software September/October issue celebrates the 50th anniversary of software engineering.Hamilton talks about "Errors" and how they influenced her work related to software engineering and how her language, USL, could be used to prevent the majority of "Errors" in a system. "At MIT she assisted in the creation of the core principles in computer programming as she worked with her colleagues in writing code for the world's first portable computer".Hamilton's innovations go beyond the feats of playing an important role in getting humans to the moon. "She, along with that other early programming pioneer, CoBOL inventor Grace Hopper, also deserve tremendous credit for helping to open the door for more women to enter and succeed in STEM fields like software."框架

——引用自維基百科electron

3. 軟件工程發展的過程當中有趣的冷知識和故事

  • Java之父James Gosling是Sun公司副總裁,Sun研究院院士。他在12歲的時候就用報廢的電話機和電視機中的部件作了一臺電子遊戲機,而且能夠幫助鄰居修理收割機。15歲就在一所大學的天文系當了一名臨時編程員,編寫分析衛星天文數據程序。

4. 目前流行的源程序版本管理軟件和項目管理軟件以及其各自優缺點(除了GitHub其餘管理軟件都沒有找到有關用戶人數的資料或新聞報道)

  • GitHub(3100萬用戶)

    • 優勢:GitHub是一個很是萬能的工具。對於任何大小的項目,他都是理想的工具;他也是偉大的web工做流工具。首 先,他能夠做爲一個版本控制系統和協做工具,用它來發布工做。利用GitHub,你能夠將項目存檔,與其餘人分享交流,並讓其餘開發者幫助你一塊兒完成這個項目。優勢在於 ,他支持多人共同完成一個項目,所以大家能夠在同一頁面對話交流。建立本身的項目,並備份,代碼不須要保存在本地或者服務器,GitHub作得很是理想。學習Git也有不少好處。他被視爲一個預先維護過程,你能夠按本身的須要恢復、提交出現問題,或者您須要 恢復任何形式的代碼,能夠避免不少麻煩。Git最好的特性之一是可以跟蹤錯誤,這讓使用Github變得更加簡 單。Bugs能夠公開,你能夠經過Github評論,提交錯誤。在GitHub頁面,你能夠直接開始,而不須要設置主機或者DNS。
    • 缺點:學習成本大。由淺入深的過分很漫長,須要大量時間的投入。Git版本庫須要頻繁的手動維護。
  • Microsoft TFS(Team Foundation Server)

    • 優勢:任務版上能將需求、項目進度盡收眼底,對於小團隊而言,比甘特圖更有用。集成了項目管理、版本控制、BUG 跟蹤,能有效實現 SCRUM。能與 VS 無縫接合
    • 缺點:搭建、維護tfs比較複雜,硬件要求也比較高。
  • Trac

    • 優勢:Trac作一個SCM配置管理平臺,意味着它有良好的擴充性。Trac的權限體系是比較完備的設計。很是靈活,能夠爲所欲爲的定製,能夠和TortoiseSVN集成。
    • 缺點:不支持多項目,需求和缺陷沒有分離,用 wiki 來替代 Word 等工具編寫文檔對於產品策劃來講門檻過高了,中文化不完整,美術人員接觸起來困難重重,不顯示中文名,本地化作得不好,核心功能不多,不安裝插件基本上無法用。
  • Mercurial

    • 優勢:學習門檻較低。總體上看,hg須要掌握的命令要比git少不少。能夠一鍵徹底恢復到歷史版本的某一個切面。封裝好。相比git,hg不多暴露一些實現內的細節。照顧 svn 的遷移用戶。hg 的不少命令是遷移自 svn 命令的,目標實際上是爲了讓 svn 用戶更容易接受。這使得已經習慣 svn 命令的團隊,幾乎零成本的切換到 hg。hg 的 pull 更多的時候可讓你避免建立分支。hg 比如蘋果系統,git 比如 Linux,前者在經常使用命令上更好用更易用,後者在功能上更強大更靈活。hg的版本庫不須要維護。
    • 缺點:分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。大型團隊不肯使用。

以上資源引用自:

博客1
博客2

相關文章
相關標籤/搜索