2017軟體工程實踐總結作業

2017最後最長的一段話，寫給軟工。

第一次例會合照：（當時的PM頭發還算茂密……）

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

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

2）總結這門課程的實踐總結和給你帶來的提升，包括以下内容：

1、統計一下，你在這門軟體工程實踐中，完成了多少行的代碼；

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

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

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

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

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

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

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

9、其他方面的提升。

首先貼出軟工實踐的第一次作業連結：

http://www.cnblogs.com/How-Come/p/7454844.html

20170830—20171229

這次軟工實踐曆時整整 4 個月，其中的悲喜雜陳，也隻有用心去經曆的人才能真正領悟。

官方地報一下資料：

• 代碼行數：3500 行左右（html+js+css 基于vue.js架構開發）

• 平均每周所花時間：每天平均 4h 來算的話，大概一周 30-40 h（與課程量成反比，周末加倍）

  累計所花時間：根據上面的周時間來算的話，大約為 510-680 h（周數 4*4+1）

• 各次作業耗時清單：

作業名	作業内容	用時/h
第一次作業	閱讀、思考、期望	2-4
第二次作業	生成數獨、PSP、效能分析	20-22
第一次結對作業	部門app NABCD分析、原型模型開發	10-12
第二次結對作業	資料模組化、比對程式	20
α階段	軟工項目開發第一階段	250
β階段	軟工項目開發第二階段	300
γ階段	軟工項目開發完善、推廣階段	50

• 學習和使用的新軟體：Visual Studio Code
• 學習和使用的新工具：Vue.js 開發架構、伺服器
• 學習和掌握的新語言、新平台：github（更深層次使用）
• 學習和掌握的新方法：前端與後端交接（之前沒有接API等與後端溝通的開發經驗）
• 其他方面的提升：忍氣吞聲的能力加強了……覺得自己更菜了……動作更迅速了……學習能力加強一點點……

官方地總結和吐槽：

回頭看了一下軟工實踐的第一次作業，内容是思考當初選擇計算機專業的初衷以及對過去大學兩年的總結和對本課程的期望。

看到部落格發表的日期，第一反應是，哇！過去了這麼久嗎！第二反應是，哇！我怎麼還是那麼菜。當然，比那時候不菜了一點……

要談軟工實踐給我帶來的感想，我想會從以下幾點展開：

時間過的很快，生活單調但充實，睡眠不足是日常，偶爾煩的想打人。
           

• 從 “我以為” 到 “其實是這樣”

  從alpha階段開始，伴随着繁多的課程，我們又多了一項任務，開發一款屬于自己的項目。

  從選題到架構，我們都是充滿興趣和信心的，畢竟讀了計算機專業三年，終于有機會做一款屬于自己的産品了，然而随着開發程序的發展，我還是覺得too naive了。

  現實會告訴你，做産品，光有想法和激情是遠遠不夠的，你還要考慮到時間、能力、其他組員的進度、未知的bug、來自後端的要求、來自PM的督促，現實的環境決定了我們不可能像專職程式員一樣專注于開發，一邊要上課，要寫作業，要金工實習，還要吃飯洗澡睡覺，我甚至覺得打電話都是在浪費時間了。

• 像個程式猿了

  于是我也有了兩三天沒洗澡、一連幾個月一兩點睡、偶爾三四點的習慣，看着鏡子中邋遢的我，我笑了，我終于像個程式員了。

• 與PM做不成朋友了

  當然，最氣的還是PM的深夜di di di——“xxx，今日份代碼敲完沒有，趕緊傳github，close掉issue！” “xxx，我的意思不是這個意思，你快改！” “xxx，下來拍照！”

  上面的情況每個組員都會遇到，然而不幸的是我和PM宿舍在同一層，于是就有，在某個深睡的下午，“xxx，還在睡覺，起床debug啦！”……我？？？？

  附上聊天截圖：

  先來張日常的：

  

  （從中還是能看出PM的用心良苦啊……）

再來張更猛的：

國際慣例之話語一轉：反過來想想，這次實踐的收獲還是很大的。
           

• 首先，代碼量上去了。

  第一次負責一個完整的項目web開發，對架構、互動、js原理、代碼邏輯關系、架構使用的認識有着質的提升。量變産生質變。

• debug能力上去了（或者說被強迫debug的次數增加了）。

  以往的代碼經曆，幾乎都是沒有維護的，僅僅是為了完成任務，過後不會再去看。而在開發項目的過程中顯然不可能是這樣的，随着版本的疊代和功能的完善，需要進行代碼甚至架構的修正，在這個過程中，會改變很多“我以為”的想法，我也漸漸認識到，開發是面向對象的程式設計，很多代碼并不是表面看着AC就可以了，要根據實際的使用情況來判斷是否有bug、是否人性化。

• 項目開發算成功了（起碼功能都實作了）

  我們的項目課題一開始就是為了解決機率論的薛老師使用微信批改圖檔作業的不友善問題而提出的。

  而我們推廣的第一個小目标就是讓薛老師能夠使用我們的項目，并争取獲得她的認可。

  後來我們也确實有一次作業通過我們的項目來送出和批改了。因為項目開發結束時已經接近結課，是以也很遺憾沒能使我們的産品被多次使用。

  結果附上截圖（正經.jpg）：

• 對團隊精神的了解更深了。

  如果說之前組隊任務給我的感覺是有另一個人幫忙分擔的話，那麼團隊任務讓我覺得自己是一輛車的某個部件，PM則類似于中控。

  一輛車之是以能跑起來，發動機、底盤、車身、電氣裝置……每個部件都不可或缺，而在造車的過程中，每個部門不能隻管着造自己的部件，要不時地根據協作部門的進度和要求來更改自己的稿紙和制作程序、制作方式，以達到各元件完美契合運作的目的。

  既然是一個命運相關的整體，在開發過程中自然也會遇到個人開發所沒有遇到過的問題。最大的差別就是時間不再單純地屬于自己，而是屬于團隊。按照以往我的習慣，大多數情況我都是趕在deadline前一陣子才會完成（得改！），然而在這階段中，已然不可能存在這樣的情況，自己的進度沒有及時完成，往往會導緻其他組員的任務無法開展，因為自己也遇到過自身進度被隊友所拖延的情況，是以也表示對這種态度深惡痛絕（對！）。推己及人，便會要求自己用最高的效率和最誠懇的态度面對自己的任務，因為實際開發時間和面臨的難題往往大于自己的想象，不能說明天晚上的deadline，我覺得明天中午開始做還來得及，最後往往地求着PM說“哥，我錯了”（這是日常……）。你以為終究是你以為，沒有實際去操作去踩坑，往往不知道坑有多深，時間有多緊。現實始終是那個最愛打你臉的人。拒絕拖延，拒絕優柔寡斷。

• 對專業的興趣和了解更深了。

  如同第一次作業所講的，當初選擇計算機專業的目的就是想做自己喜歡的事情，起初是偏向于遊戲開發及設計類。後來進了大學發現教學形式與想象中大不相同，再後來接觸了前端後，覺得相對而言較符合“設計類”的風格，興趣便是建立在那個時候。如果要對當時的期望交個差，那麼我覺得“希望通過實踐鍛煉，增強計算機專業的能力和就業競争力”這個目标，每個人都是達成的，差别隻是在于與自己定的level的差距。就我個人而言，對于軟工實踐這門課程，總體是滿意的。

期待就是讓自己感受到前所未有的對于計算機新的認知和激情，然後能夠從中學到真正有價值的東西、增強自己的專業能力和知識，并認識一群同甘共苦的好夥伴，也為日後的考研方向有一個大體的定位和強心劑。

• 這是當時寫給自己和課程的期望，現在看來，貌似都實作了，然而對自我能力還是不夠滿意的，當然，這是下個階段需要去努力的事情，至少在這個階段，問心無愧了。

  寫到這裡，忽然想起前階段 @周筠老師 在微信群裡分享的一段話，引用至下面：

  #不要一開始就試圖找到你的激情所在#

凱文·凱利給了那些有抱負的大學生一個建議：不要一開始就試圖找到你的激情所在，也沒必要一開始就非要做你感興趣的事情，而是熟練掌握那些别人覺得有價值的技能或知識。你不必喜歡上它，你隻需要做到最好就行。一旦你在這個領域成為大師，就會發現有很多機會可以去做你喜歡的事情。如果你持續完善你的技能，總有一天你會發現你的激情所在。反過來倒不一定能行。

• 這段話對迷茫期的我來說簡直是醍醐灌頂，不同于其他的雞湯文，他讓我認識到，現在的迷茫、不之所措，是有意義的，是為了以後的爆發做積攢，讓我感到放松，感到有希望，讓我積極樂觀地去探索未知和未來，使我相信我能找到我的興趣、我的夢想。當然，不是說一直處在迷茫期就好，還是要趕緊明确自己的方向的。

  說到這裡，不禁讓我深深感悟到，軟工實踐這門課，不僅僅隻是在開發技術、軟體工程、環境模拟這些“物質”層面上給予我們“招式”。在課堂上、微信群中、與老師的日常對話中，彼此分享的心得和心路曆程，才是更加彌足珍貴的“心法”。“招式”再繁雜，也要有足夠深厚的“心法”來輔佐，而這些“心法”，在日後的學習、工作、生活上，将使我們受益無窮。我想，或許這才是這門課的真谛和初心吧。

最後，感謝棟哥，感謝鄒欣老師、周筠老師以及各位助教、我的PM、我的團隊、我自己。

感謝善良的薛美玉老師的支援和回報。

代碼敲多了，說話程式設計化了，文筆變差了，以上。

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

• 拒絕拖延，馬上行動

  軟工以來，我覺得每天的時間都變短了。一開始我覺得是因為太過充實，然而我開始反思，自己是真的把時間都利用上了嗎。

  其實不然，我發現我這人有個毛病，一旦時間相對充裕了，我就會心理安逸，開始消磨時光，而等到時間來不及時，才悔不當初。

  漸漸地我發現了問題的嚴重性，其一，顧此失彼，我沒有利用好相對空閑的時間去做其他事情，導緻其他任務的完成也相應地被拖延；其二，自己嚴重低估了項目開發的未知性和debug的耗時，導緻遇到難題時解決困難，又缺乏對應的應對時間，最後還得“借”時間來處理。如此一來，就影響了項目開發的進度。

  是以，無論在做什麼事情時，能盡快解決掉就不要拖延，你永遠不知道明天和意外哪個先來。

• 不會就問不可行，不會就google才是硬道理

  由于技藝不精，在剛開始程式設計的過程中，遇到偏 “底層化” 的問題時，我就會反感和逃避。

  就比如一開始的環境搭建，按照網上的教程一步步執行下去卻遇到了神奇的問題，這時候我就懵逼了，明明一樣的步驟，為什麼會這樣？于是我開始了“百度”（點開三四個頁面的那種），嘗試幾次（試了兩三個的那種），發現問題沒解決，于是我煩躁了，覺得自己解決不了，開始抱怨問題的神奇。

  然而我忽略了問題的關鍵所在，問題是無限的，難度和類型也是層出不窮的，不可能遇到什麼問題都是以你現在的知識和能力就能夠一下看出要點并立馬解決。之是以需要增加代碼量，就是為了提高自己的學習能力，不僅是學習新技術，最重要是學習解決問題的能力。

  而當初的我并不懂這個道理，百度了幾次後就去問大佬，一次兩次後，大佬開始不耐煩了，而我開始責怪大佬的态度不好了。。現在想想，換成自己，也會反感吧。

  不過好在為時不晚。

  （比如alpha階段配置開發環境安裝項目依賴時遇到子產品丢失問題，苦苦查閱了一個多小時的資料才得以解決，附帶連結：http://www.cnblogs.com/How-Come/p/7737928.html）

• 按時彙報真實進度

  這點跟第一點有相關之處，在合作項目中，尤其是團隊項目中，每個人的任務都是按時配置設定的，隻有正确的進度回報和進度實作才能保證整個項目良好而有序地營運下去。

  當因為自身拖延或者遇到問題卡住的時候，不要“為了面子”向PM彙報虛假進度，這樣隻會累了自己，害了團隊。

  不會就是不會。有問題就說出來。（與第二點不沖突）

• 有效溝通很重要

  因為我是此次項目web端的負責人，一同開發web端的還有一名隊員。在一次任務配置設定中，因為沒有會議式程式設計，又github的代碼同步會出現沖突現象，導緻對對方的代碼進度和完成情況不甚了解，導緻雙方對事先配置設定的任務的了解起了沖突，最後一方的日工作量表示報廢。

  對于一個合格的負責人或者組員來說，配置設定清楚任務和了解任務是最基本的要求，當出現疑問時，請進行最直接的溝通。

• 合理安排工作和生活

  熬夜是軟工階段的常态，但顯然每個人都想極力避免這種現象。

  利弊與否，我覺得今天在微信群看到的這句話就很犀利。

“熬夜不一定是好事，因為可能效率并不高，有時候選擇自己有效率的時候做事情，也是一種能力吧。記住，淩晨四點的福大，不是熬到的，而是給自己的計劃，讓自己精力充沛，從4點開始的。熬夜到淩晨，睡到中午的生活，之後渾渾噩噩一定是一件值得稱道的事情嗎？我覺得未必吧。”

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

• 我還是覺得每個人在生命的不同階段做出的蠢事，都是有他的意義所在。過分地給予所謂的“指點”，反而會降低自我感悟的體驗和價值。既然要給出建議，我想說：

  ① 好好玩吧哈哈哈哈，管他的呢

  ② 如果你按照上一條去做，你以後會打我

  ③ 忽略前兩條

  ④

  追随本心，做自己想要做的。

  不要害怕，多去嘗試，早日找到自己的定位。

  多聽學長的話，當然，是優秀學長的話，學姐？沒有學姐。

  多聽棟哥的話。

• 特别地，特别地

  我覺得中途換隊員還是有必要的。

  但是這個時間點問題……還是換一下。

  至于為什麼，微信群幾百條資訊大戰已經很明确地說明了問題的所在——意義不大，表面工程。

  我了解老師們的想法，想讓我們體驗一下“現實模拟”中的這麼一個換員環節。然而就我團隊而言，并沒有看到新成員的突出貢獻（當然不是在吐槽新成員）。時間過短，又要吸納融彙新團隊的内容，學習新知識新技術，是有點蛇吞象的意思。是以個人建議老師将這個環節放在alpha中間階段。

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

包括萌芽階段、磨合階段、規範階段、創造階段。

創造階段的特點包括：

• 團隊知道為何而戰，并将注意力集中到如何創造、實作目标上。
• 高度自治，不再需要上司的時時教誨和介入。
• 角色和職責能夠根據項目的要求自然地轉換，沒有人為此擔心或發牢騷。

我的團隊經曆過以上各個階段，并展現了達到“創造”階段的特點。

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

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

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

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

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

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

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

satisfy and achieve

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

參考論文文獻：

[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