團隊做業——總結

 這個做業屬於那個課程 <課程連接> 
 這個做業要求在哪  <做業要求>
 團隊名稱  軟件夢之隊
 這個做業目標  總結每位團隊成員在本課程的得失

 

 

 

 

 

 


 

  • 團隊成員列表:
學號 姓名

201731041215html

王陽git

201731062302程序員

鮮雨珂github

201731062128算法

鄧捷編程

201731062305網絡

周蓉svn

201731062131函數

龍繼平工具

201731062304

楊夢欣

201731035120

張欣

201731062301

梅晨

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 王陽 201731041215:

閱讀做業博客連接: 博客連接

博客要求內容:

1.Goto語句在大量使用時會使程序結構化設計被破壞甚至極大的影響程序的可讀性,可理解性,爲什麼這裏又提倡使用呢,爲什麼不能專門寫一個異常出口函數來進行呢?

  答:並不是每種狀況都適合goto語句,可是當有多種選擇時,如有goto,那麼goto是最好的選擇,由於他很簡便,同時在某種程度上少去了if—else跳轉的程序多層嵌套狀況,而只須要幾個goto,那麼能夠大大提升程序易讀性。

 

2.那若是對於動態語言/腳本語言(例如 Python等),又該如何呢,編譯是自動完成同時採用動態步進,像這種語言編寫的模塊是直接嵌入而後進行測試仍是隻進行單步調試過程呢?

  答:對於大型的項目,每一個模塊都必須有相應的單元測試,同時每一個模塊都必須進行調試以及單元測試,纔會進行集成測試。

 

3.這個基準線到底該如何肯定,對於一個大型軟件包含上百模塊時,採用迴歸測試,這個基準線該如何去評定呢,而回歸測試大多采用自動化方式,不可避免這個測試模塊自己也會出現問題,這時候又該如何去處理呢?

  答:每一個項目的基準線並非一開始就固定的,而是對於整個項目進程進行動態變化的,而對於測試模塊自己的問題,通常項目開發測試與開發是由不一樣的人進行的,根據採起的測試方法不一樣,而採用不一樣標準,而且測試並非僅僅進行一次,它是會貫穿整個項目,因此儘管測試代碼也會有問題,可是對項目測試並不會有太大影響。

 

4.在需求不斷變化的同時如何準確地對客戶需求進行分析呢?保持簡明的同時如何讓整個軟件開發流程條理清晰呢?簡明的同時應對不斷變化的需求,對於文檔的改動是否過大呢?採用敏捷流程開發又該如何去適配開發流程呢?

  答:敏捷開發就是專門針對與需求不斷變化的開發方式,敏捷流程採起每日任務的方式,與需求方一塊兒工做,對於不斷更改的需求每日都會有解決方案,敏捷流程並非一種固定的開發方式,正如其名,它也是不斷變化的。

通過這學期的學習,你掌握到了哪些之前沒有的技能,你是如何掌握的:
          通過一學期的學習,學習到了不少軟件工程的理論知識,同時對一些理論進行了實踐、驗證。在這過程當中學習了許多工具的使用,如:原型開發工具Axzure,專業畫圖工具Visio,對源代碼管理工具GitHub加深了了解。

有什麼深入的體會,對本身一學期學習過程的總結:
          最大的收穫是明白了軟件工程不只僅是寫代碼,甚至能夠說寫代碼只是其中一個很小的環節,重要的是對於整個系統的需求分析,設計,以及小組合做。


鮮雨珂 201731062302

閱讀做業博客連接:博客連接
博客要求內容
       1.(2.1)對於迴歸測試的具體內容還不是特別清楚明瞭,書上說對於「迴歸測試」中的「迴歸」,咱們能夠將其理解爲「迴歸到之前不正常的狀態」,這句話應該怎樣理解?
       答:通過查閱資料,迴歸測試是指修改了舊代碼後,從新進行測試以確認修改沒有引入新的錯誤或致使其餘代碼產生錯誤。迴歸測試是驗證新的代碼的確把缺陷改正了,同時驗證新的代碼沒有把模塊的現有功能破壞,沒有Regression,因此對於「迴歸測試」中的「迴歸」,咱們能夠理解爲「迴歸到之前不正常的狀態」。
 

      2.(4.5)對於結對編程,既有好處也有壞處,咱們應該在什麼狀況下采用結對編程的形式來使效率和正確性達到最大化?
       答:結對編程最主要的因素是技術與挑戰相匹配。若是技能和挑戰能互相匹配,最高產的模式就是流模式以及一個更有效的模式指導模式。流模式指的是兩個程序員共同從事一個有趣又有挑戰性的問題。他們會有不一樣的技術、遇到不一樣的挑戰,可是它們都善於找到好的解決方法。他們可以結合彼此的腦力、知識及經驗來共同處理複雜的任務, 從而創造出最好的解決方案。指導模式則是老練的程序員在解決問題方面有經驗和知識,能夠與其餘不能有效地獨自解決問題的程序員分享。後來加入的程序員有足夠的理論基礎來理解這些解決方法和程序的實現。他會在學習中慢慢進步,成爲更優秀的程序員。這兩種模式都能提升全隊當前與將來任務的生產率。
 

      3.(5.3)TSP的原則第二點爲團隊的各個成員對團隊的目標、角色、產品都有統一的理解,我認爲一個團隊的成員每一個人在開發過程當中可能有本身不一樣的想法,那咱們如何作到對這些的統一?
      答:每一個人都是不一樣的個體,具備不同的思想是正常的,對於軟件開發過程當中每一個人的不一樣想法,我以爲最有效的辦法是面對面的交流,不少時候不一樣的人會有不一樣的創意和想法,都會給彼此帶來不少啓發,經過不一樣人提出本身的意見和建議,隊長綜合全部人的想法進行考慮來使理解儘量達到統一。
 

      4.(6.1)敏捷流程的第三步衝刺階段是時間驅動的,一到時間就結束,那若是在具體的項目實踐中,衝刺階段的任務並無完成,這個時候應該怎樣處理?
      答:在這種狀況下,衝刺任務不能如期完成已成定局,衝刺階段的任務沒有按時完成的緣由多是計劃不夠準確,隊內成員某些技術方面的問題等等,我認爲這時項目經理應該進行組內人員的調整和協做,儘量彌補。
 

      5.(3.2)軟件工程師可能產生如分析麻痹、過早優化等思惟誤區,那麼咱們在實際的軟件開發中,怎樣去避免或者解決這些問題?
      答:在這種狀況下,軟件工程師應該普遍聽取團隊組員的意見,以及用戶的建議,固然最主要的是軟件工程師要會意識到這些問題,不要一無所知,有的時候沒有意識到本身的問題纔是最大的問題。

通過這學期的學習,你掌握到了哪些之前沒有的技能,你是如何掌握的:
          通過一學期的學習,掌握到了不少結構化分析和設計工具的使用,如visio,學習到了github源代碼管理工具的具體用法,瞭解到了用github克隆項目以及提交代碼的全過程。同時也學習到單元測試等軟件測試方面的技能。

有什麼深入的體會,對本身一學期學習過程的總結:
          這學期在軟件工程這門課中,我學到了不少,不只僅是技術方面的接觸和學習,更多的是學習到了關於軟件開發項目過程的不少方法和技能,讓我明白了開發軟件並非簡單的寫程序,更多的是要作好整個項目的計劃、需求分析、設計等,讓我能將這些方法運用到之後的項目實踐中。

  


楊夢欣 201731062304

閱讀做業博客連接:博客連接

博客要求內容:

 

  •  問題一:

         代碼複審 4.4

         文中提到代碼複審有三種形式:自我複審、同伴複審和團隊複審。

         個人疑問:最好是有經驗、熟悉代碼的人來複審,而代碼做者必定是最熟悉本身代碼的,但他本身複審,會有思惟的侷限性;若是同伴複審,就不存在思惟的侷限性,那麼是選擇一個同伴複審,仍是兩個同伴複審,甚至更多呢?若是是團隊複審,最大的侷限是效率不高。那麼三種方式該如何抉擇?

         答:通過我的項目、結對編程和團隊項目的實踐,本人認爲主要根據項目的大小來選擇代碼複審的形式。像我的項目就是自我複審;結對編程就是同伴複審;而團隊項目,通常來講,同伴複審就足夠了,如果項目比較大,又是特別核心的部分建議團隊複審。

 

 

  • 問題二:

         結對編程  4.52

         書中舉有例子:越野賽車和駕駛飛機,二者共同特色是在高速度中完成任務,任務有較高的技術要求,任務失敗的代價很高。

        個人疑問是,開發程序時,什麼樣的狀況是相似於文中舉的例子,須要進行結對編程?是否有公司實行過結對編程?效果如何?對於合做的兩人,是兩人水平至關,仍是一高一低?有什麼特別的具體的要求嗎?合做兩人的適應期通常是多長時間呢?

         答:看了書本,我想應該是時間緊張的狀況下須要結對編程。確實有公司進行過結對編程,如Microsoft(Bill Gates, Paul Allen),Apple(Steve Jobs, Steve Wozniak),Yahoo(Jerry Yang, David Filo),Google(Sergei Brin, Lawrence Page),效果都不錯。對於兩人的水平沒有什麼要求。他們的適應期須要經歷四個階段:萌芽——磨合——規範——創造。最重要的是如何磨合:向同伴提供容易接受的反饋意見時,採用三明治法。

 

  • 問題三:

        與顧客合做 7.2.9

        文中提到MSF強調產品團隊與顧客的交流合做,由於「我以爲」和「用戶以爲」是兩碼事。

        個人疑問:那麼遇到哪一種類型的問題須要與顧客交流?大概多久進行一次呢?如果交流時遇到「對牛彈琴」的狀況該如何處理、如何交流?

        答:本人認爲遇到業務領域的問題,須要與顧客屢次且深度交流。交流頻率主要視實際狀況而定。若交流有障礙,能夠進行一些調查方法:跟班做業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫等,再設計出原型圖與顧客溝通交流。

 

 

  • 問題四:

        目標、估計和決心 8.6.1

        文中提到若是咱們混淆了目標估計和決心,那就會犯錯。其中軟件時間的估計是多個估計值的乘除法(估計的需求、估計的複雜度等等)。

        個人疑問:那麼,究竟每一項估計該怎麼估計才比較準確呢?

         答:上課時老師有提到項目作多了,天然而然就估計偏差就越小。每一項的估計仍是得看經驗吧。

                 參考文章:http://www.javashuo.com/article/p-yzfbuaqp-kv.html

 

 

  • 問題五:

        PM作開發測試外的全部事情 9.3

        文中提到微軟公司有好幾類PM,以及一名優秀的PM應有的能力。

        個人疑問:不管是哪一類PM,是都必需要擁有文中所列舉的那些能力嗎?仍是說負責內容不一樣,有不同的要求?

        答:書本中提到三類PM,分別是:Product Manager(產品經理),Project Manager(項目經理),Program Manager(微軟的職位名稱)。成爲 一個合格的PM必需要擁有如下能力觀察、理解和快速學習能力;分析管理能力;必定的專業能力。所以對於負責內容不一樣的PM,他們需必備的專業能力是不一樣的。

 

總結:

        通過本次課程的學習及項目實踐,瞭解了軟件工程的原理,確確實實體驗了一次軟件開發。最大的收穫不是在課堂上學習的,也不是最終答辯所展示的,而在於整個軟件開發過程所經歷的,學習到的知識。


鄧捷 201731062128

閱讀做業博客連接: 博客連接

博客要求內容:

一、第七章第二節:其中提到的MSF基本原則中有一條是「充分受權和信任」,但咱們如何保證在給予了充分受權和信任的狀況下,團隊成員可以按時按質的完成本身的任務,不敷衍了事?

  團隊項目是團隊成員的共同責任,不只須要隊員的自覺性,隊友在項目完成過程當中也應該相互監督相互提醒。

 

  二、第十四章第二節:講到測試人員,假如開發人員每一個人都對本身的代碼進行了初步的測試,而且有些公司的人後期也會使用本公司的產品,使用過程當中也會逐步發現一些BUG,那麼在這些狀況下測試人員的做用會不會逐步的下降甚至變得無關緊要?

  不會,測試是軟件編碼過程當中的重要一環,也是軟件質量的重要保障,測試人員系統的測試更能發現一些開發人員自身沒有發現的問題,對軟件的完善有很大的推進做用

 

  三、第八章第三節:說到對用戶需求的獲取,提到了調查問卷的方法,但現實是大部分的調查問卷都並無獲得用戶足夠的重視,或者有些用戶即便認真回答了也不必定可以獲得調查人員的正確理解,或是提出的意見並無足夠的價值,在這種狀況下怎樣保證瞭解到的需求是有意義的?

  除了最開始對用戶調研,開發人員在軟件開發過程當中也應該常常與用戶溝通,在軟件每完成一部分的時候

 

  四、第八章第六節:提到軟件工程師對實際花費時間的預估公式,但如何保證本身對事件的估計時間在合理範圍內,若是低估了時間又該怎樣彌補?

  這個主要應該靠開發人員本身的經驗積累,低估了時間就只能想辦法拉快進度

 

  五、第十三章:怎樣識別軟件的故障是內部問題仍是外部問題?

  通常是先軟後硬的原則。從新分區,低格全部分區後用標準系統安裝盤重裝系統,若是故障依舊,那基本是硬件問題了。

 

我的收穫:

  認識到在項目完成中文檔與類圖,用例圖,時序圖的重要性,軟件項目不是一我的的事情,更多的是團隊的交流協做。


周蓉 201731062305

閱讀做業博客連接: 博客連接

博客要求內容:

 對於問題一:當初覺得程序正確,若是加上正確後面的程序,是不會出錯的。在團隊合做中,本人體會到隊長在合成咱們的各個模塊的時候,後面新建的模塊若是出了問題一樣會影響前面的功能,邏輯,物理結構,特別是傳參數的時候,一但新構建的模塊出了問題,它的輸出,停止都會影響後續的模塊,之前模塊功能的正常使用。迴歸測試能夠找出退化的軟件(有了新模塊,可能功能崩了)的錯誤,改進軟件。這也是

軟件測試的目的是爲了發現錯誤而執行程序的過程;測試是爲了證實程序有錯,而不是證實程序無錯(發現錯誤不是惟一的目的)

        對於問題二:這個問題,本人想結合下在面向對象課程中一些體會,線下調查已有軟件知足了用戶什麼需求,用戶體驗或者說別人想讓軟件工程師實現什麼。而在需求分析中,咱們構建的任何想法,其實都是創建在人類須要,既有需求的目的去開展的。

       做爲製做軟件的成員,在最初就用該對使用用戶有個定位,事實上咱們對它應該完成了可行性分析,那麼在調查問卷問題設置上就是有方向的,經過定位人羣去找到有效反饋。

需求獲取主要方法:文檔「考古」法,用戶表明訪談法,問卷調查法,運營數據分析法,同類方案研究法,虛擬用戶構想法

  對於問題三:得知,產品經理就是經過了解用戶需求去設計原型給軟件工程師實現,那麼正確的獲取需求,我想在之後工做中才能獲得解答(若是有機會的話,考慮的前進方向中了)。

       對於問題四:創新,本人對於它的理解有了新的體會,用戶體驗其實也是「新」的東西,同類型的軟件,勝出的地方就在它給用戶帶來的感受,just like QQ and TIM,後者就更爲簡潔,這也是創新呀。技術的創新,在原有的技術上實現算法,或者結構上的改變,使得更爲簡單。

  對於問題五:在團隊項目中,本人是貢獻最少的吧,隊長分配「網絡編程」模塊給我,可是我最終也沒完成,回首過來,我纔是「抱大腿的人」。我想團隊合做中,團隊意識最重要吧,有榮與焉,你們都在學新東西,菜雞也是要有團隊榮譽感的,固然也有關隊長的分配了。

總結:

  解答完本身的問題,回到「無力」,「愧疚」,「羨慕」這三個詞語,是我在本課程的體會。在結對編程中,我是參與其中,本人十分感謝隊友在他的博客中給我留足了面子,在我在爲某個版塊費勁頭腦的時候,隊友已經完成功能,而最終我完成的模塊,卻成爲敗筆,多餘的,我是很受打擊的。在項目中,我忘不掉,我跑去圖書館一層,打着手機燈在書庫裏面找網絡編程書的過程,當時我內心的愧疚已經打敗我害怕黑的感覺了。連續幾周都在看網絡編程,連作夢都是。哭過,由於「無力」。在項目展現中,我"羨慕"那些優秀的同窗,由於我一無可取。

       很惋惜的是,臨了了,我仍舊沒有找到本身的專業方向,可我真的很想在互聯網專業從事一些工做啊。本人邏輯思惟真的不好,編程對於我來講,或許準確的來講算法,日常人一兩遍就能弄好,我可能要十遍,寫上不少頁紙才能弄懂。

  掌握的技能:自學,專一,需求分析能力。新的問題:如何在團隊中起到做用?  

  最後很感謝在團隊合做中隊友們對個人幫助和鼓勵。


 

龍繼平 201731062131

閱讀做業博客連接: 博客連接

博客要求內容:

  問題一:在瀑布模型中十分強調文檔的做用,那麼在其餘開發的過程當中是否也須要嚴格編寫文檔?還有文檔的做用是否過於誇大,我也據說過,過於詳細的文檔不如沒有,那麼文檔要多仔細爲好?怎麼樣把握度量?

  個人理解:我在這門課程的過程當中開始理解文檔的重要性。老師不斷給咱們強調文檔的重要性。一個好的項目80%的時間是在設計文檔。20%的時間用於把文檔實現爲代碼。在大型項目時,文檔是必須的,文檔也是越詳細越有條理符合規範爲好。在我的小項目時,能夠省略部分文檔,只寫重要的設計部分文檔。

 

  問題二:在這一節提到「咱們要在競爭性的環境中實踐軟件工程,那就要作實用求創新的項目」,那麼在需求分析的時候,是以創新爲主仍是穩定爲主?如何處理需求與創新之間的矛盾?如何可以使需求合理化,符合軟件設計要求?

  個人理解:需求分析時以穩定爲主,咱們的目標是設計符合客戶要求的軟件,因此第一要素是知足客戶需求,其次再是創新。需求設計要實事求是,不要天馬行空。

 

  問題三:在開發過程當中不一樣程序員的進度不一,若是程序員更新錯了代碼會不會致使程序崩潰?那麼在管理源代碼過程當中會不會出現版本衝突吶?在版本衝突的時候如何回退前一個版本?回退事後開發進度會不會跟不上任務要求?

  個人理解:源代碼的管理通常是由svn的版本管理工具管理的。使用十分方即可以實現代碼的對比,而後在上傳,也可以實現版本回退。

 

  問題四:在進行效能測試時,每每都會測試不過全面,有時候也不可以達到測試的條件,在這種狀況下如何測試?怎樣才能使效能測試更加全面,高效?

  個人理解:效能測試要涉及測試代碼的每個方面,儘可能的作到測試全面,測試也應該覆蓋每個條件的分支,並獲得想要的結果,才能測試全面。

 

  問題五:這裏介紹了軟件的各個版本,beta也就是咱們常說的嚐鮮版,一般嚐鮮版會有各類bug這個版本的發佈會不會影響用戶體驗?其次各個版本之間如何有效的辨別?

  個人理解:beta版本基本能夠正常使用,beta版本測試是爲了提升測試的效果,可以有更多的額人員參與軟件的使用,從而發現問題修改問題。其次beta版本也是通過了必定的測試階段,基本不影響正常使用,有的只是微小的bug,也多是爲了軟件開發的新功能,來獲取用戶的反饋,從而更好的開發軟件。

總結:

  我學會了UML繪製類圖,用例圖,時序圖。在團隊項目的開發過程當中,我開始認識到文檔和溝通的重要性,我在這門課最大的收穫就是開始正視文檔,明白了軟件工程這個專業不只僅是技術,而咱們更多的是學會去寫文檔,而後實現爲相應的軟件。


 

張欣 201731035120

閱讀做業博客連接: 博客連接

博客要求內容:

 

問題一:

  在教材中第二章我的技術和流程中,所講到的單元測試,是對軟件項目中的每個小的模塊進行test,是對後面工做的正確性的保證,同時也是以後的單元測試的基礎,其中提到的代碼的「覆蓋率」,當時學C語言時有頭文件,當寫一個函數時,須要到頭文件的那個文件夾中區尋找相同的功能代碼,覆蓋並運行,不知道我這種理解是否是正確。

 

 答:所謂實踐出真知,真正的去實踐事後,才能更加深刻的去理解本身的疑問,通過課程的各次實踐,本身明白了覆蓋率究竟是怎麼回事情,可是就像我知道了1+1=2同樣,可是依然不知道爲哦什麼1+1爲何就是等於2同樣,不知道在究竟是怎麼樣編譯器能夠知道已經對代碼路徑實行了覆蓋。

 

問題二:

  在學軟件工程的課程的同時,咱們也在學數學建模的課程,在數學建模的課程上,老師講了一個尋找臨界點的問題,當時大多數同窗都回答,找幾個臨界點的值,進行帶入計算測試,而老師說,這個就是咱們在接受軟件工程教育是固有的思惟模式,我在想這種思惟模式是通過多年的思惟習慣以後造成,會不會被困於這種思惟模式跳不出了。

 

答:每一個人都有本身在通過多年的事和物的磨練以後所造成的固有的思惟模式,在通常狀況下,倒是是沒法跳出本身的這種思惟模式,可是在之後能經歷更多的事以後,每一個人的能力以及想法也都會發生變化,可否跳出來,也算是本身的一種能力。

 

問題三:

  1.在壓力測試中,沿着時間軸延長,通常模擬48小時的高負載才能認爲系統經過測試,在如何模擬,是對其中的數據進行調用模擬仍是,尋找真正的用戶進行模擬;如若沒有經過測試,系統崩潰以後,咱們應該採起什麼樣的措施來補救?

 

答:在這個問題中。因爲在項目的開發中本身並無負責這一部分,因此也沒有更深刻的去針對這個問題進行求證,本身將在之後的學習生活當中,對這個問題進行實踐而且求證。

 

  2.一樣也是test的問題,是在教材中第十三章軟件測試中所講的A/BTest,其中用了奧巴馬競選的例子來講明,A/BTest是同時爲用戶提供多種服務,仍是隨機測試,或者在給用戶提供服務以前,讓用戶進行選擇,本身想要的服務。儘可能在測試的時候講損失降到最低。

答:不管是作事仍是作人都要勇於去作出嘗試,纔能有更好的發展,而作軟件應該也不會例外.

問題四:

  在課上講的是在能夠在開發代碼完成以前,先寫好測試代碼,而在教材中的第十三章中講到,開發時有開發說明書,測試同時也是有測試設計說明書的,其中要是有些功能尚未作好,不知道功能的具體狀況,而時間有很緊急,這時候要如何去作開發代碼的測試?

答:這個問題因爲學姐的解答,以及本身在以後做業中的本身的理解摸索,代碼測試的狀況主要仍是是項目的狀況來肯定,並非必定要按照先代碼後測試的順序,而在現階段,我只經歷過先代碼,後寫代碼測試的模式,但願之後能嘗試進行先寫測試代碼的開發模式。

問題五:

  在第三章軟件工程師的成長中,在對項目完成估計的時間上,有些多是比較常寫的代碼,但老是會用到不經常使用,或者是要去新學的知識,如何能更準確的去估計本身完成時間?

答:通常來講邊學邊作項目相對來講是否是很理想的,可是因爲我的自身的限制只能用這種方式,會大大的拖慢團隊的開發速度,因此必定你要在平時多積累知識,必要時候必定會用得上的。

問題六:

  如何確保本身已經完成的代碼在簽入時和別人的代碼可以很好的對接起來,因爲對團隊開發流程的不瞭解,在這一部分上,仍是有不少的不明白。

答:這個問題依舊沒有明白.

 總結:

  • 是否產生了新的問題?請提出。

   有出現一些問題,可是在項目過程當中,通過同窗朋友的指點,已經解決.

  • 通過這學期的學習,你掌握到了哪些之前沒有的技能,你是如何掌握的。

   通過這學期的學習,我的能力有了必定的提升,可是很不滿意,沒有很努力的去學習接納更多更好的知識;上學期只是簡單的運用VS編寫簡單的程序,這學期對VS有了更加深刻的瞭解;接觸並瞭解了代碼的測試方面的知識;高爾基說書籍是人類進步的階梯是很對的,從書籍中,我得到了許多之前不知道的知識.

  • 有什麼深入的體會,對本身一學期學習過程的總結。

   相對於上一學期,我對這學期的表現更加滿意,可是仍然有很大的進步空間,但願本身能更加努力,越努力的人真的會更加美麗.

 


梅晨 201731062301

閱讀做業博客連接: 博客連接

博客要求內容:

一、過早優化的問題在於:過早關注不重要的部分,而忽略行動和目標自己。讓正確的程序更快比讓快速的程序正確要容易不少,因此,首先應該把注意力放在使代碼儘量性的清楚和可讀上,什麼時候進行優化應該根據軟件開發過程當中的實際狀況來決定。

 

二、結對編程是兩個程序員用一臺電腦,一塊兒工做。兩我的一我的是駕駛員的身份,另外一我的是領航員的身份,對兩我的並無什麼特別的要求,可是在結對的過程當中仍是須要相互磨合達到比較理想的效果,我以爲結對編程須要思考是如何將領航員的職能發揮到最大。兩人合做是一種合做關係,相互幫助。

三、軟件團隊的模式選擇我以爲跟軟件項目自己和軟件團隊能力有着不可分的關係,能夠結合項目自己和團隊自己狀況來選擇一種合適的團隊模式,合適的團隊模式在整個軟件開發的活動過程當中會比較容易解決問題,按時完成項目。

 

四、思惟侷限我以爲是可能會出現的吧,確定須要有專門的測試人員對整個軟件進行測試,這時候其實也包含了對代碼的檢測,使得軟件的出錯率更少。

五、https://blog.csdn.net/wang_lichun/article/details/7267948

總結:

  通過一學期的學習以及相關書籍的閱讀,對於開始不懂的問題有了一些解答,在課程做業的完成過程當中,體會到告終對編程的好處,在編寫代碼有錯誤出現時,會有人及時提醒,在設計代碼的時候,能夠一塊兒討論,融合兩人不一樣的看法和觀點,得出更加好的設計思路,會避免一我的深陷BUG之中。在整個的團隊項目當中,也學習到了一些新的知識,同時深深感受到本身編程能力的欠缺,可是也有很多收穫,更加了解了軟件開發過程,學會了一些軟件開發過程當中必要的技能。


團隊項目Github地址:<連接>

相關文章
相關標籤/搜索