軟體工程第一次閱讀作業

2022-09-04 13:27:17 字數 2608 閱讀 7213

本作業屬於軟體工程

本作業要求

第乙個問題:究竟是對計算機各種領域都有所涉獵,還是專精其中之一,對我們今後的職業生涯更有幫助呢?

在《構建之法》的第三章裡,作者提及了專與精的關係,但又淺嘗輒止,並未深入討論。在此我不免產生疑問:對於我們以後的職業生涯來說,到底是對各種領域各種技術都有所涉獵,還是專精一種比較好呢?一般人都會希望自己會的越多越好,對於自己所開發的專案方方面面都能掌握,甚至自己獨立開發。然而小的專案還好,大型專案幾乎是不可能自己獨立完成的。但儘管如此,多方涉獵是否還是更好一些呢?

第二個問題:結對程式設計中兩個人具體的職責是什麼?能否給出一些例項進行說明?

在《構建之法》的第四章裡,作者一開始是這麼描述結對程式設計的:

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

看到這裡,我想象中的結對程式設計的兩人是一起做設計一起實現,兩人同坐一台電腦前一邊討論這個功能該如何如何實現,一邊進行程式設計,似乎結對程式設計也就是兩個人一起寫同乙份**而已。然而後面又有對駕駛員與領航員各自職責的介紹:

1.駕駛員:寫設計文件,進行編碼和單元測試等xp開發流程。

2.領航員:審閱駕駛員的文件;監督駕駛員對編碼等開發流程的執行;考慮單元測試的覆蓋率;思考是否需要和如何重構;幫助駕駛員解決具體的技術問題。領航員也可以設計tdd中的測試用例。

這裡似乎又把兩個人的關係割裂了開來,乙個做設計與開發工作,而另乙個則負責監督與部分測試。這裡似乎與前面產生了矛盾。

我對此的疑問是:假如兩個人坐在同一臺電腦前一邊討論一邊程式設計,那麼劃分駕駛員與領航員又有什麼意義?因為如果設計與編碼過程都是兩個人一起討論的結果,那麼駕駛員寫文件、寫**也不過只是負責把兩個人討論的結果輸出到電腦上而已,誰都可以做,甚至還可以有第三個人在這裡只負責打字,做個人肉打字機,將這兩人的討論結果輸出到電腦上。這樣與結對程式設計似乎並沒有區別。而假如領航員只是全程在旁**監督駕駛員進行開發工作,起到「旁觀者清」的作用,可以提醒駕駛員他犯的某些小錯誤,這似乎又是一種人力資源的浪費。

第三個問題:子瀑布模型的具體含義是什麼?

在《構建之法》第五章裡,作者提到了子瀑布模型:

-大瀑布帶著小瀑布

為了解決不同子系統之間進度不一,技術要求迥異,需要區別對待的問題,有人引入了子瀑布模型

在這種瀑布群下,要把各個子系統統一到最後做系統測試(system test)的階段,難度不是一般的大啊!另外,在這樣的開發流程中,使用者只有到了最後才能看到結果,使用者真是等不起。

我對此的疑問是:不同子系統具體是指什麼?如果是指同一系統下負責不同功能的各個子系統,那麼最後的統一工作似乎並沒有那麼大的難度吧?如果是指同一系統針對不同使用者的不同版本,似乎又有些沒有必要。

第四個問題:關於敏捷開發的幾點疑問

在《構建之法》第六章裡,作者提到了敏捷開發的原則:

敏捷開發的原則是:

1.盡早並持續地交付有價值的軟體以滿足顧客需求

2.敏捷流程歡迎需求的變化,並利用這種變化來提高使用者的競爭優勢

3......

......

其中,僅就前兩條原則來說,似乎是在鼓勵我們盡早地做出第乙個版本交付給客戶,此後不斷在原來版本的基礎上做修改形成新的版本交給客戶。這似乎是在鼓勵我們採取在第五章中作者提到的寫了再改模式,然而這並不是乙個好的開發流程。對於我個人來說,在之前的一些比較基礎的課程如大計基、資料結構等課程中採取的就是這種模式,每次都是看過需求之後上手就寫,不對再改,改對為止。這種非常差的程式設計習慣導致我在面對計組、物件導向這樣的系統性大型工程開發課程時遇到了比較大的困難。所以是否是我理解有誤?

另外還有乙個疑問是:第二條原則鼓勵我們面對需求的變化,然而我們在快速完成初始版本時,是無法預先得知後續會有什麼樣的需求變化的,因此這會為我們面對後續需求變化時帶來麻煩。比如在物件導向課裡,在無從得知後續新加功能是什麼的情況下,我在寫第二次電梯作業時幾乎是把第一次電梯作業的**完全推倒重來的。這種情況該如何應對呢?

第五個問題:軟體行業真的就是贏者通吃,敗者或者是後來者沒有翻身的餘地嗎?

在《構建之法》第十六章裡,作者在介紹**點遊戲的規則的時候,提到了下面這段話:

贏者通吃這個遊戲規定第一名得到全部的分數,第二名(不管多接近)到倒數第二名都是0分,最後一名還要到扣分。軟體行業就是乙個贏者通吃的環境,最後一名還要把自己的身家倒貼進去。

「軟體」這一詞彙是在2023年8月由richard r. carhart在蘭德公司的研究備忘錄中提出的,「軟體工程」這一詞彙是在19世紀60年代由margaret hamilton在早期的阿波羅登月專案中提出的。

缺點:mercurial

缺點:trac

缺點:microsoft tfs:

缺點:github:

缺點:bugzilla:

缺點:缺點:

軟體工程第一次閱讀作業

專案 內容作業所屬課程 作業要求鏈結 課程目標 了解軟體工程的基本概念 原理和方法。參與乙個軟體的完整開發流程,熟悉軟體的開發過程。參與團隊開發,積累團隊開發經驗 該作業在哪個具體方面幫助我實現目標 在開課前熟悉教材,對教學大綱形成一定的認識 根據書中的介紹,在結對程式設計中,兩人要同時使用同一臺裝...

軟體工程第一次閱讀作業

專案 內容本作業屬於北航軟體工程課程 班級鏈結 作業要求鏈結檢視 作業要求 我在這門課程的目標是 成為乙個具有一定經驗的軟體開發人員 這個作業在哪個具體方面幫助我實現目標 讓我對自己目前的狀況有乙個更加清醒的認識 1.快速閱讀完教材仍然不懂的問題 1.第4章 兩人合作 4.3.4 如何處理c 中的類...

軟體工程第一次閱讀作業

專案 內容這個作業屬於哪個課程 這個作業的要求在 homework 2625 我在這個課程的目標是 完成課程中所要求的任務,通過該課程 這個作業在哪個具體方面幫助我實現目標 理解課程大綱,提出問題 2,書中將大四學生與軟體工程師進行了相應的對比,以此來說明個人開發流程psp的特點 同時引出優秀軟體工...