2017軟件工程實踐總結做業

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

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

1、請回望暑假時的第一次做業，你對於軟件工程課程的想象

1）對比開篇博客你對課程目標和期待，「但願經過實踐鍛鍊，加強計算機專業的能力和就業競爭力」，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，爲何？
2）總結這門課程的實踐總結和給你帶來的提高，包括如下內容：
一、統計一下，你在這門軟件工程實踐中，完成了多少行的代碼；
二、軟工實踐的各次做業分別花了多少時間？（作一個列表）
三、哪一次做業讓你印象最深入？爲何？
四、累計花了多少個小時在軟工實踐上？平均每週花多少個小時？
五、學習和使用的新軟件；
六、學習和使用的新工具；
七、學習和掌握的新語言、新平臺；
八、學習和掌握的新方法；
九、其餘方面的提高。

首先貼出軟工實踐的第一次做業連接：

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、個人團隊、我本身。
感謝善良的薛美玉老師的支持和反饋。

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

2、寫下屬於本身的人月神話——我的或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析

• 拒絕拖延，立刻行動
  軟工以來，我以爲天天的時間都變短了。一開始我以爲是由於太過充實，然而我開始反思，本身是真的把時間都利用上了嗎。
  其實否則，我發現我這人有個毛病，一旦時間相對充裕了，我就會心理安逸，開始消磨時光，而等到時間來不及時，才悔不當初。
  漸漸地我發現了問題的嚴重性，其一，顧此失彼，我沒有利用好相對空閒的時間去作其餘事情，致使其餘任務的完成也相應地被拖延；其二，本身嚴重低估了項目開發的未知性和debug的耗時，致使遇到難題時解決困難，又缺少對應的應對時間，最後還得「借」時間來處理。如此一來，就影響了項目開發的進度。
  所以，不管在作什麼事情時，能儘快解決掉就不要拖延，你永遠不知道明天和意外哪一個先來。

• 不會就問不可行，不會就google纔是硬道理
  因爲技藝不精，在剛開始編程的過程當中，遇到偏 「底層化」 的問題時，我就會反感和逃避。
  就好比一開始的環境搭建，按照網上的教程一步步執行下去卻遇到了神奇的問題，這時候我就懵逼了，明明同樣的步驟，爲何會這樣？因而我開始了「百度」（點開三四個頁面的那種），嘗試幾回（試了兩三個的那種），發現問題沒解決，因而我煩躁了，以爲本身解決不了，開始抱怨問題的神奇。
  然而我忽略了問題的關鍵所在，問題是無限的，難度和類型也是層出不窮的，不可能遇到什麼問題都是以你如今的知識和能力就可以一下看出要點並立馬解決。之因此須要增長代碼量，就是爲了提升本身的學習能力，不只是學習新技術，最重要是學習解決問題的能力。
  而當初的我並不懂這個道理，百度了幾回後就去問大佬，一次兩次後，大佬開始不耐煩了，而我開始責怪大佬的態度很差了。。如今想一想，換成本身，也會反感吧。
  不過好在爲時不晚。
  （好比alpha階段配置開發環境安裝項目依賴時遇到模塊丟失問題，苦苦查閱了一個多小時的資料才得以解決，附帶連接：http://www.cnblogs.com/How-Come/p/7737928.html）

• 按時彙報真實進度
  這點跟第一點有相關之處，在合做項目中，尤爲是團隊項目中，每一個人的任務都是按時分配的，只有正確的進度反饋和進度實現才能保證整個項目良好而有序地運營下去。
  當由於自身拖延或者遇到問題卡住的時候，不要「爲了面子」向PM彙報虛假進度，這樣只會累了本身，害了團隊。
  不會就是不會。有問題就說出來。（與第二點不矛盾）

• 有效溝通很重要
  由於我是這次項目web端的負責人，一同開發web端的還有一名隊員。在一次任務分配中，由於沒有會議式編程，又github的代碼同步會出現衝突現象，致使對對方的代碼進度和完成狀況不甚瞭解，致使雙方對事先分配的任務的理解起了衝突，最後一方的日工做量表示報廢。
  對於一個合格的負責人或者組員來講，分配清楚任務和理解任務是最基本的要求，當出現疑問時，請進行最直接的溝通。

• 合理安排工做和生活
  熬夜是軟工階段的常態，但顯然每一個人都想極力避免這種現象。
  利弊與否，我以爲今天在微信羣看到的這句話就很犀利。

  「熬夜不必定是好事，由於可能效率並不高，有時候選擇本身有效率的時候作事情，也是一種能力吧。記住，凌晨四點的福大，不是熬到的，而是給本身的計劃，讓本身精力充沛，從4點開始的。熬夜到凌晨，睡到中午的生活，以後渾渾噩噩必定是一件值得稱道的事情嗎？我以爲未必吧。」

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

• 我仍是以爲每一個人在生命的不一樣階段作出的蠢事，都是有他的意義所在。過度地給予所謂的「指點」，反而會下降自我感悟的體驗和價值。既然要給出建議，我想說：
  ① 好好玩吧哈哈哈哈，管他的呢
  ② 若是你按照上一條去作，你之後會打我
  ③ 忽略前兩條
  ④
  追隨本心，作本身想要作的。
  不要懼怕，多去嘗試，早日找到本身的定位。
  多聽學長的話，固然，是優秀學長的話，學姐？沒有學姐。
  多聽棟哥的話。

• 特別地，特別地
  我以爲中途換隊員仍是有必要的。
  可是這個時間點問題……仍是換一下。
  至於爲何，微信羣幾百條信息大戰已經很明確地說明了問題的所在——意義不大，表面工程。
  我理解老師們的想法，想讓咱們體驗一下「現實模擬」中的這麼一個換員環節。然而就我團隊而言，並無看到新成員的突出貢獻（固然不是在吐槽新成員）。時間太短，又要吸納融匯新團隊的內容，學習新知識新技術，是有點蛇吞象的意思。因此我的建議老師將這個環節放在alpha中間階段。

4、分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了「創造」階段了麼？（參考《構建執法》第17章 人、績效和職業道德）

包括萌芽階段、磨合階段、規範階段、創造階段。
創造階段的特色包括：

• 團隊知道爲什麼而戰，並將注意力集中到如何創造、實現目標上。
• 高度自治，再也不須要領導的時時教誨和介入。
• 角色和職責可以根據項目的要求天然地轉換，沒有人爲此擔憂或發牢騷。

個人團隊經歷過以上各個階段，並體現了達到「創造」階段的特色。

5、怎樣證實你學會了軟件工程？

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