個人作業——軟體工程實踐總結作業

• 一、請回望暑假時的第一次作業，你對于軟體工程課程的想象

  • 1）對比開篇部落格你對課程目标和期待，“希望通過實踐鍛煉，增強計算機專業的能力和就業競争力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目标，哪些方面還存在哪些不足，為什麼？

    在經過了一個學期的努力之後，真的花了很多時間來做軟工實踐啊，有時候想了想為啥自己當時來找虐呢，但是自己後來在上台講我們自己的實驗成果的時候，無論好壞，自己都充滿自豪感。我覺得至少我通過一次次的部落格，通過一次次建構之法的閱讀和對于隊員們的溝通以及自己做決定的一些事故，像極了以後工作中的各種狀況。我覺得自己可能不适合程式設計，但是我發現了自己很适合做一個産品經理或者項目經理，至少在我如果考研失敗，那麼我還可以去應聘這方面的類似的職位，我一開始覺得可能産品經理對于整個以後的現實中的團隊來說可能會沒那麼重要，至少從工資上可能差不少，但是經過了實踐和一次次的和助教老師們的溝通，我知道了并不是這樣的。收獲很多。我覺得最大的收獲就是讓我自己找到了一個可能适合自己的方向，這讓我以後可能會少走很多的彎路。讓我自己去強化類似的技能和其他方面的知識。不足的話，對于每一個計算機專業的人來說，當然是希望自己的代碼能力非常強。我這方面真的太欠缺了。自己也努力過，但是就是不開竅，我覺得自己找好方向萬一以後這條路走不通還是得走程式員的老路。路在人走在人為，一切的一切，感謝隊友感謝助教感謝老師，軟工實踐，受益匪淺。指引了我的方向，讓我給自己的路有了個思考，至少我會朝着類似的方向努力。自己的缺點代碼能力上多學習吧。長路漫漫。

    今天聽了老師講的項目管理的課感覺受益匪淺。項目管理中的第一階段還是要當程式員。統稱。萬變不離其宗，在35 歲的時候還是要當上管理層的。就算現在不會變成也要學會看代碼。還要豐富需求分析，原型設計，協調整個團隊的能力。就像老師說的你如何在給你的人不是那麼理想情況下完成任務，我覺得這是需要去哦好好考慮的并且需要更多地鍛煉。但是我覺得自己感興趣這方面也沒用。感覺競争還是蠻大的。雖然感覺挺簡單但是感覺還是沒有程式員有含量。裝B還是得程式員。而且現在有技術有能力有情商的太多了。是以自己還是要多多努力。

  • 2）總結這門課程的實踐總結和給你帶來的提升，包括以下内容：
    • 1、統計一下，你在這門軟體工程實踐中，完成了多少行的代碼；

      

      整個的阿爾法階段和貝塔階段的代碼可能有3000-5000多行，我如果算上測試學習神馬的應該有10000行了吧。因為在阿爾法階段都是我自己在上傳Git，是以這個資料并不準确。但是也差不多。但是和别人真的比不了。人家認真的有技術的都是十幾萬行的。這就看出來差距了。

    • 2、軟工實踐的各次作業分别花了多少時間？（做一個清單）

      見文章末尾 時間圖表

    • 3、哪一次作業讓你印象最深刻？為什麼？

      阿爾法階段驗收的作業 啊。那次上台真的是太尴尬了，沒完成也要去講。那種心情真的不是滋味。人家都完成了美滋滋的去上面講。我自己在上面尴尬的展示，給自己一首我們不一樣。哈哈。真的是上了軟工實踐，神馬不要臉的事情都搞過了，以後HR面試的時候問我問題我也能很好的回答，問我的經曆問我的故事，那我就有的聊了，軟工實踐我能講上三天三夜。

    • 4、累計花了多少個小時在軟工實踐上？平均每周花多少個小時？

      10月，11月，12月，每天晚上花幾個小時學程式設計，沖刺階段每天還要開會寫部落格，周六周日還要做周六的準備。可能這也算提前适應程式員的生活。平均每天3個小時，有的不是為了敲代碼，一周20個小時，一共三個月240個小時吧。我的組員可能更多。緻敬。

    • 5、學習和使用的新軟體；

      AS，Git，idea，apache。

    • 6、學習和使用的新工具；

      Git，碼雲，markdown

    • 7、學習和掌握的新語言、新平台；

      Java，Android，還會寫部落格了。

    • 8、學習和掌握的新方法；

      最重要的軟工流程。開發模式，從需求分析到原型設計到實際編碼沖刺再到最後的成品成功，雖然我們感覺還是不太成功，但是至少我對于整個流程都有了一個直接的認識。雖然感覺還是失敗了，但是學到的還是很多。但是肯定是沒有那些做的好的感悟的多得。

    • 9、其他方面的提升。

      人際交往關系，了解了開發模式，知道了Android的原理，離自己并不遙遠。最重要的是認識了一大堆的人。助教老師隊友，開拓了眼界。知道了自己喜歡和各種各樣的人交流協調進度喜歡認識各種人，喜歡最後團隊做出完美産品的時候在上級面前的自豪感。也算發現了自己的特點吧。臉皮也變得更加厚了。（偷笑這個不算）

• 二、寫下屬于自己的人月神話——個人或結對或團隊項目實踐中的經驗總結+執行個體/例證結合的分析

  作為後來的臨時PM自己的不足太多了。在我心裡的配置，一個團隊的頂配是一到兩個大神，兩個可帶的人，加上一個組長就能完成任務了。對于特别的強的組對于我們來說就是一個Android一個iOS一個後端兼職組長，期末考的學長就是這樣的配置。真的大神。

  經驗總結來說，最開始的計劃階段就要選擇對于整個組有利的方向。如果是剛才的那種配置的隊伍那麼都可以，因為那樣的隊伍有組長給你配置設定明确的任務，有大神帶你那樣你會有一個明确的思路知道你要去做那一塊。不會去徒勞的做其他的事情。你自己也要做好準備。然而肯定也會有各種隊伍，就比如我們隊，如果急真的攤上了這樣的隊伍，一定要努力積極地溝通，去整合一切的力量，因為這時候我們的目的就變了，據說下個學年軟工實踐是必修，那麼大神的隊伍可以浪可以有各種天馬行空的創意但是人家做的完。我們的話，自己就要知道我們是為了不挂科的基礎上來做這件事。對于我們最後一屆的我們隊伍裡，我們後來的目的就是單純的搞好不去搞砸。不像其他組各種蒂花之秀。但是如果我手下有的不是一些新手而是理想配置，那麼我想我會更多的去發揮自己的想象力，讓整個團隊變得更好，是以在什麼樣的環境做什麼樣的事，不讓結局更壞，抱着重在參與的心态積極地參加，當然這個心态也要天時地利人和，有時候總會有其他的阻力，那麼就順其自然。

  還有就是一定要遵循每一個階段的規範，即使沒有規範那也要自己心裡有一杆秤。告訴自己要到截止日期了抓緊。還有如果隊友是那種很努力的很努力的那麼請珍惜，和他們合作你遲早成功。遵循Git規範每天完成任務積極上傳做好組長配置設定給你的任務，那麼軟工實踐就沒白上。我真的是想說的太多了。

• 三、對下一屆實踐的建議，或者對于開學初的你，對于大一的你，對于開學初的我，你有什麼想建議和告知的呢？對于後來人的期許。 特别地，特别地，下一屆要不要中途換隊員？

  我覺得在你決定要選擇軟工實踐的時候那麼你就要找好你的隊伍，别等到别人都組好隊了剩下一群沒組織的人去再組一個菜雞隊。組長特别重要，給不給你配置設定任務至關重要，沒有人給你配置設定任務那麼你就是一群烏合之衆。漫無目的毫無效率可言。組裡最好還有一到兩個大神你不能之靠大神大神的目的是在你有疑問的時候解決你的疑問，讓你更好地去學習改進，跟上項目進度。你自己也要積極地去了解。去在大二暑假的時候盡可能的去掌握Java，Android或者iOS後端森馬的。在别人一教你你就會學的事半功倍。而且你要去學會你自己擅長什麼。這樣對你未來的一年很有好處。軟工實踐可以說是整個大學不可多得的實踐課。讓你了解整個軟體的開發過程，了解整個團隊的構成，以及各種的工具各種的新知識，以及發現你自己的優點和不足。還有盡量選擇同一個宿舍樓的不一定是同一個宿舍的組隊，這樣好交流。

  對于換人這塊，我們組沒什麼感受，但是對于我自己來說還是都可以的，換人是公司裡常有的。而且老師這麼安排肯定有他的道理。我覺得聽老師的話是有好處的。但是我覺得應該鼓勵而不是強制。這樣應該效果會更好。

• 四、分析一下自己所處的團隊。軟體工程實踐是大學裡少有的認真的團隊協作經驗。《建構之法》上說團隊的發展有幾個階段，你的團隊都經曆過麼，最後到達了“創造”階段了麼？（參考《建構執法》第17章 人、績效和職業道德）

  我們的團隊就是假團隊的狀态，但是這幾個階段大緻都經曆過，從最初的萌芽期，大家都互相阿不認識，去摸索去了解去完成前期的任務，瓶頸就是磨合期，看清了誰是豬誰是雞誰是鹦鹉，誰是想好好幹的誰是來水的。到現在團隊裡面還有很大的問題，這個問題是多方面的，是各種因素導緻的。也不去過多的深究。反正我們幾個互相信任了，我們團隊的績效成績拿不出手，那我就自己去抗，總要有一個人去負責的。但是過了這個階段到了貝塔階段，我們就到了規範期和創造期了，雖然沒有其他組的好，但是我們确實規範的遵循了阿爾法階段沒有遵循的規則。并且最終達到了創造一些有意義的事情的地步，我覺得在最後我們算是勉強合格了吧。當然了對于所有的人我心裡當然有一杆秤，差別對待那是肯定的。真想團隊裡面都是P1的就像晨瑤他們組。最後我都想把自己交換出去了。

  我們的團隊我一開始就分析了，第一一開始沒有好的上司者，當然我也不是一個合格的上司者，我多得隻是比前任多了個歸屬感，多了個擔當而已。第二團隊中沒有一個技術核心也就是老師上課所說的主程式員。當然現實中沒那麼理想就是了。第三我自己也是一開始混亂，我現在這個狀态說是組長還不是，自封的組長，說是吧還沒有和舊的組長交流過。反正我就稀裡糊塗的當了臨時PM。但是我一開始就是想當PM的但是自己實在沒有什麼賣點，感覺自己沒什麼能服衆的。現在也是，我群組員之間也沒有什麼PM不PM之分，就是他們每天和我講一下計劃，我陪他們熬夜，給他們鼓勵，我覺得這份情誼很珍貴吧。還有我覺得在中期的時候我們也實行了分隔，但是我們這個的原因有地理原因，有交流原因等等。反正最後确定是5-6個真正的team。老師今天一講我覺得太像了。我的實踐課不失敗也不成功。所有的隊員你有能力我願意交流或者大家都願意交流，那我們就在一起為了一個目标拼搏。good feel。

• 五、怎樣證明你學會了軟體工程？

  我覺得除了一下幾點最重要的一點就是以瀑布模型為理論基礎的整個軟體工程實踐過程。如果連這個都不知道那麼所有的都是空談。

  • 1）研發出符合使用者需求的軟體

    必須公開釋出，有實際的使用者，一定的使用者量和持續使用量 （3 天後能保持10 - 100個使用者）；而不是: 做沒有使用者使用的軟體

  • 2）通過一系列工具，流程，團隊合作，能夠在預計的時間内釋出 “足夠好” 的軟體

    有項目規劃/需求/設計/實作/釋出/維護，有定時的進度釋出 ； 而不是: 通過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲傳遞等方式糊弄

  • 3）并且通過資料展現軟體是可以維護和繼續發展的。

    而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料

    請在随筆中用資料證明上述内容或側重選擇之一。

    對于第二點我覺得我們團隊失敗的主要原因就是做好了原型設計原組長沒有計劃的對我們每個人做什麼搞不清不配置設定，而且我們也有原因就是中期的時候不溝通。各種原因。導緻延遲傳遞，誰都想搞出好的軟體産品，可有時候自身和環境各方面的因素導緻想做好一件事無能為力。這是最要命的。我們阿爾法階段隻有我一個人上傳Git，一人代勞，敷衍了事。而在貝塔階段我們每個人都有明确的分工，每個人每天按時上傳Git。做出來的app不知道好了A階段幾百倍。

• 六*（選做）、閱讀軟體工程中關于代碼品質的的經典論文，從下列文獻中選擇一篇或若幹篇，結合自己的實際做一個閱讀筆記（例如，自己寫的代碼品質如何，是不是一個大泥球，如何衡量自己代碼的品質）？從以下參考論文中選擇一篇或若幹篇：

  參考論文文獻：

[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605

[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87

對于這裡我自己的代碼基礎不是很好，但是每一個PM都要對隊員的代碼品質把關，我覺得這方面是我要更多地要去學習的。對于隊員的品質把控，合格才是merge。

• 七、個性發揮，包括圖文、照片和創意等

  聽說有人十八門課的同時軟工實踐，我二十門笑笑不說話。天秀，陳獨秀。

  

時間圖表

作業名稱	花費時間	總計
第一次随筆	三天	大約40天
第一次結對作業	兩天
第二次結對作業
第二次個人作業
團隊第一次作業	半天
團隊第二次作業
團隊作業--規格需求說明書	一天
團隊作業--系統設計
團隊作業--預則立他山之石
UML設計
Alpha階段第一天到第十二天沖刺	十二天
Alpha階段團隊項目課堂展示
随堂小測--同學錄	四天
個人技術部落格之1,2
事後諸葛亮
個人作業之軟體産品分析	兩個晚上
Beta階段第一天到第五天沖刺	五天
Beta階段團隊課堂展示
個人作業軟工實踐總結作業	一晚上
團隊作業——項目驗收與總結部落格