天天看點

PSP總結報告

回顧0:

所屬團隊:拉格朗日2018

團隊項目:飛詞  連結:https://coding.net/u/lglr2018/p/Fly_Word/git/commits/master/

一、在本課程中學習和使用的新軟體新工具:

1. aTimeLogger:一個記錄每日活動時間的應用程式,有助于科學控制和管理自己的時間。

       軟體版本:1.6.2

       連結:

https://appgallery.cloud.huawei.com/grey/uowap/index.html#/detailApp/C6029051?source=appshare&subsource=C6029051

2. Leangoo:比較友善的項目協作工具

       軟體版本:5.8.12

https://www.leangoo.com/product.html

二、在本課程中學習、提高的語言:

       我在本課程中學習了Python語言,掌握了這門語言的許多規範。

       軟體版本:2018.2.3

http://www.jetbrains.com/pycharm/download/download-thanks.html?platform=windows&code=PCC

回顧1:

(1)回想一下你曾經對計算機專業的暢想

當初你是如何做出選擇計算機專業的決定的?經過一個學期,你的看法改變了麼,為什麼?

       經過了一個學期,我對自己選擇計算機專業的看法沒有改變。如前所述,我選擇這個專業是因為大學學的比較差,在未來的工作中也會缺乏競争力,我相信自己能在讀研究所學生的階段豐富自己的專業知識與經曆。盡管經過這一學期,自己所學的專業知識也很有限,但我對自己選擇計算機專業的看法仍沒有改變。

你認為過去接觸到的課程是否符合你對計算機專業的期待,為什麼?經過一個學期,你的看法改變了麼,為什麼?

       我認為過去接觸到的課程和我對計算機專業的期待是不一樣的。有很多課程學了之後幾乎都用不到,如果學的知識無法應用到實際中,我覺得這不符合我對這個專業的期待,計算機專業是一個專業性很強的專業,如果所學的課程無法應用,那麼從這些課程學到的知識一方面很容易忘記,一方面用處也不大。

你覺得計算機是你喜歡的領域嗎,它是你擅長的領域嗎?經過一個學期,你的看法改變了麼,為什麼?

       計算機仍然不是我喜歡的領域,不過我改變了自己的一個看法或者說糾正了自己的一個看法,現在我認為興趣很重要,興趣才是最好的老師。過去的一學期中每次做作業都是以逼着自己盡快完成作業的态度完成的,過程不太舒服,很煩惱。如果以一種享受的心态做每一項任務,我認為是一種很好的狀态,是以,我希望能夠盡快讓自己喜歡上計算機專業。

(2)考取研究所學生,對照前人們走過的路和描述未來發展,現在的你自我感覺你已經具備的專業知識、技能、能力有哪些?

離成為一個合格的計算機學生,在專業知識、技能、能力上還差距哪些?

經過一個學期,你的看法改變了麼,為什麼?

         自己的程式設計能力仍然很弱,我也很清楚的知道,在計算機專業中,程式設計能力就像學習英語中的英語單詞一樣,是一切的基礎也是重中之重,不可能繞過程式設計,唯有面對它,不斷提升自己。

(3)每天都是一個人生選擇的十字路口,學術研究、工程項目、社會實踐 (?) ,不同的選擇有不同的努力方向。

對照以上你閱讀的前人們的經曆,你的選擇是什麼?經過一個學期,你的看法改變了麼,為什麼?

       我現在的選擇傾向于社會實踐,我認為通過社會實踐能讓我清楚的認識到現在自己的計算機行業需要什麼,我需要學習什麼以及如何去學,有了明确的目标,才更願意為之不懈努力。

在這種選擇下,你認為你相比其他同學來說有何優勢,有何劣勢?經過一個學期,你的看法改變了麼,為什麼?

       選擇社會實踐,我認為自己的優勢應該是适應能力比較強,現在的劣勢仍然是專業知識與技能比較薄弱吧。

針對你的選擇,你給自己的本學期的規劃是什麼?經過一個學期,你的看法改變了麼,為什麼?

       我覺得下學期應該向導師、師兄師姐請教明确自己的學習方向和學習方法,但更重要的還是在于自己要努力。

(4)你對這門課的期待是什麼?

你打算平均每周拿出多少個小時用在這門課上?經過一個學期,你的看法改變了麼,為什麼?

       我的原計劃是平均每周拿出25個小時在軟體工程這門課上。經過一個學期,我的看法沒有改變,軟體工程這門課确确實實是需要付出大量時間和經曆的一門課,在課程結束之際,我也确實學到了許多重要的專業知識和技能。

實測結果,每周平均用在本課程上多少小時?

       實際上,每周平均用在這門課上的時間為18.5小時,沒有預計的時間多。

回顧2:

1.

通讀《建構之法》,釋出随筆1篇,要求列出5個問題,可以是讀後不了解的,或者讀後反對的。要求有觀點、有證據或分析。字數不是直接的考核标準,但是要求長到能把觀點表述清楚      

請回顧這5個問題,自己回答一下。當初的困惑是否還在,你現在如何認為,是更深的困惑麼?

(1)在進行結對程式設計時,到底要不要顧及對方的面子?、

         在結對程式設計時,我認為十分需要顧及對方的面子,因為與我們合作的人是同僚或者同學,尤其是因為結對程式設計時隻有兩人合作,如果言語過于激進,會産生一些不必要的負面情緒,這樣十分不利于兩人的合作。

(2)16.3.3節中提到,各類技術産品都有自己的發展周期,從萌芽階段到生命周期的結束,那麼一旦産品技術了生命周期,還有沒有可能經過技術上的改進回到前幾個階段呢?

         我認為一類技術産品即使經曆了生命周期的結束,也有可能回溯到前幾個階段實作重新崛起。能否出現這樣的回溯,我認為和對産品性能和功能的改造有很大關系,如果對産品的改造适應潮流,迎合大衆,服務大衆,而且創新性也強,那麼即使這類産品正處于低谷,也可以實作第二次崛起。

(3)6.2節的隻先一步闆塊中,提到做前沿研究的人,可以早于其他人很多年提出新想法,但是這些想法要等多年以後才能被推向大衆市場,那麼把這種原來超前的想法推向大衆的人還是原來那些做前沿研究的人嗎?還是後來的人們覺得這種想法很好,才将其推廣的呢?

         我覺得把這種超前的想法推向大衆的人一定不是原來那些做科研的人,因為搞科研的人首先是不考慮所做的這項研究能應用到什麼方面的,他們的主要貢獻應該是服務于後者,多年以後人們想應用這項技術的時候,可能發現這項技術在多年以前就已經被研究的很透徹了。

(4)結對程式設計是個漸進的過程,有效率的結對程式設計不是一天就能做到的。那麼開發人員一般要經曆多久才能磨合到有效率的程度呢?是不是超過了一定的時間限度,就可以認定這兩名開發人員不适合結對程式設計呢?

         結對程式設計中兩個人的磨合期是不穩定的,因人而異的,有時候兩個人根被就不适合在一起結對,可以想象這樣一種情況,兩個人都隻會解決問題的方法,或者都隻會編寫程式而解決問題的想法枯竭,那這個結對一定會很艱難。其實兩個人适不适合結對,從第一次合作就可以很清楚的感覺到,并不需要明确的時間限度。

(5)16.3.7節中第三步提到,使用者使用軟體的過程中的回報和産品銷售的方式有關。在一次性付費購買、通過廣告賺錢和戰略性免費這三種銷售方式中,為什麼計算一次性付款購買的回報難度最低,而計算戰略性免費的回報更複雜?隻要使用者付款或者觀看廣告,公司不就會收到回報嗎,那計算回報的難度不應該是一樣的嗎?

         可能是因為在戰略性免費這種銷售方式中,涉及的中間商比較多,采取的方式也是層出不窮,是以難度應該更高。

2.

請根據本學期的學習、收獲、困惑,再提出5個問題,可以是讀後不了解的,或者讀後反對的。有求有觀點、有證據或分析。體驗一下,這5個問題,是不是更有深度了 。

(1)”第一個吃螃蟹的人是值得人佩服的”,為什麼實作了世界上第一個創意的人到了最後更容易被後來者比下去呢?——教材第345頁

         很抱歉我沒有更多其他問題。

3.回憶整個學期,你有什麼話想對後來的學弟學妹們說。

  軟體工程是一門對于我們在校的學生來說很合适的一門實踐性與社會性質很強的一門課程。從一開始的個人任務,到結對程式設計,再到交流性極強的團隊合作,總是其中會有些許不快與煩惱,但每一段經曆都讓我們受益匪淺。我認為這是一門值得我們去付出的課程,希望學弟學妹也能認真對待。

4.如果重新來過一次,你打算做哪些(技術上,而不是态度上的)改變--基于希望得到什麼樣的更好結果,你才希望這樣改變的;更重要的是,你根據什麼估計這些改變會有預期的結果。

  在我們的團隊項目“飛詞”中,我們是手動錄入資料庫的,這樣的詞庫大小非常有限,而且費時費力,如果當時我們使用簡單的方式導入資料庫,就會省去很多不必要的時間與麻煩。

5.終于我們即将不再是師生。當你結束本課程,你和我就站在同樣的位置上,我将不再基于學校授權和知識、經驗 (年齡?)上的優勢而對你的自由有任何幹擾。除釋出及成績以外,我最後一次行使教師特權: 請問你有什麼要對教師 (我)說的,建議、抱怨、希望……多謝。

  以前從未體驗過這樣的授課方式,一開始的時候确實會因為上課方式的轉變感到不适,習慣了之後覺得這種方式還不錯,老師的授課風格也很好。

總結:

1. 代碼總量:1505

         平均每周代碼量:125

2. 部落格字數總量:8189

         平均每周字數:682

3. 平均每周在本課程中所用時間:18.5小時

4.

起止時間 送出PSP例行報告時總結的知識點 現在回顧該周收獲的知識點
2018.9.12——2018.9.17
2018.9.19——2018.9.24 版本控制 版本控制是要求,對于程式員來說更應該是一種習慣,我們敲打的代碼很可能因為未知的原因丢失或者損壞。而版本控制可以記錄每一段時間的代碼,正是解決代碼丢失問題的好方法。
2018.9.26——2018.10.09 結對程式設計,效能分析,功能測試 結對程式設計是一段難得的經曆。我與隊友互相協作,互相幫助,互相監督完成四則運算作業的過程曆曆在目,有頗多收獲。
2018.10.10——2018.10.16
2018.10.17——2018.10.22
2018.10.23——2018.10.29
2018.11.03——2018.11.04 事後諸葛亮會議 事後諸葛亮會議是對項目目前階段所完成的進度進行剖析總結的會議。
2018.11.14——2018.11.20
2018.11.21——2018.11.27
2018.11.30——2018.12.01 同上
2018.12.05——2018.12.11

時間配置設定堆積柱狀圖:

PSP總結報告