1、請回望暑假時的第一次做業,你對於軟件工程課程的想象
1)對比開篇博客你對課程目標和期待,「但願經過實踐鍛鍊,加強計算機專業的能力和就業競爭力」,對比目前的所學所練所得,在哪些方面達到了你的期待和目標,哪些方面還存在哪些不足,爲何?
回想第一次做業時對軟工實踐的期待,想必大多數人和我同樣都是抱着「參與第一」的態度,也會躍躍欲試,但也不奢求會作出怎麼樣了不得的軟件,整體來講軟工實踐基本符合開學初本人對其的期待------一次接近業界真實流程的開發體驗。在這其中,有守得雲開見月明的欣喜,也有揮散不去的怨聲載道,我想這偏偏是這個實踐最真實的意義。python
- 滿意的方面:在本次軟工實踐方面,本人被分配在了算法組,負責識別算法的神經網絡部分。以前雖然有一些在這方面的基礎,可是並無親自參與設計和調試模型,因此在此次的任務對我來講也是一次全新而艱鉅的任務。識別模型到最後順利地完成了,也作到了本身滿意的正確度。經過此次的經歷,最大的收穫是對模型的認識更加宏觀,可以以更高的角度來看待問題。
不足的方面:,雖然在這其中因爲硬件條件不足的客觀緣由,最後的結果和最初的設想存在誤差,最直接具體的表現就是本來打算使用的近九十萬張圖的關於3755個字的訓練集在實際訓練過程當中因爲本機性能不夠只能不斷簡略,最後只能選擇生活中使用頻率最高的500個字。最初時忽略了硬件條件的限制,是一大疏忽,也是一大收穫,對之後的相關的開發提早上了一課。再則是對服務器的架設,因爲對服務器的不瞭解和神經網絡自己對環境極嚴格的特色,致使到最後把原來在本機訓練好的模型架設在服務器上時遇到困難重重,這是在實際開發過程當中的一大教訓-------要充分了解開發平臺和架設平臺的異同和軟件的兼容性。git
2)總結這門課程的實踐總結和給你帶來的提高:
一、統計一下,你在這門軟件工程實踐中,完成了多少行的代碼;程序員
千行左右,這並很少,也和個人部分的特色有關,主要的調參和訓練要花去大部分時間。
做業 | 時長 |
---|---|
軟件工程實踐2017第一次做業 | 3 |
軟件工程實踐2017第二次做業 | 4 |
結隊項目——第一次做業 | 7 |
團隊第一次做業——團隊展現 | 0.05 |
結對項目——第二次做業 | 15 |
團隊做業—選題報告 | 2 |
我的技術博客(α) | 4 |
團隊做業—需求規格說明書 | 3 |
團隊做業—預則立&&他山之石 | 1 |
團隊做業——系統設計 | 4.5 |
團隊做業——UML設計 | 3 |
團隊做業——隨堂小測(同窗錄) | 8 |
我的做業——軟件產品案例分析 | 7 |
團隊項目課堂展現 | 0.5 |
團隊項目測試報告與用戶反饋 | 1 |
團隊Alpha博客連接目錄 | 0.05 |
團隊過後諸葛亮博客 | 2 |
Beta衝刺博客集合貼 | 3 |
我的做業——軟件工程實踐總結做業 | 4 |
Alpha和beta階段代碼 | 100 |
三、哪一次做業讓你印象最深入?爲何?github
最深入的要數α衝刺,感覺到被deadline支配的恐懼和無能爲力,天天在課業和deadline之間徘徊往回,固然還有和團隊隊友的交流協做。五、學習和使用的新軟件;算法
openCV,tessract,墨刀服務器
python相關包如tensorflow ,keras,theano
github,墨刀網絡
都是在以前學習的基礎上(python , IDE:spyder),沒有新語言和平臺工具
閱讀論文來提高模型的性能;在stackflow上尋找解決方案。性能
經驗總結:最大的經驗就是必定要在項目開始前就對項目的各方各面盡力作最全面最細節的分析和安排,修正錯誤的成本隨着項目進度的推動不斷提升,與其在後期花大量時間彌補初始的疏忽,不如在最初作最好的安排,但變動也是沒法避免,從容應對也是必修課
好比在團隊項目最初的設想中,咱們並無打算設立服務器,打算將模型直接嵌套進安卓中,一時的想固然致使了這樣荒謬的錯誤,如今想來直以爲難以想象,在後期安卓和算法組結合時才發現行不通,大大滯後了項目的進度,不得不在本就緊張的安排中,花費時間和人力去架設服務器,對整個團隊形成巨大的不良影響。
3、對下一屆實踐的建議,或者對於開學初的你,對於大一的你,對於開學初的我,你有什麼想建議和告知的呢?對於後來人的期許。 特別地,特別地,下一屆要不要中途換隊員?
---學習
若是你沒時間或者目標研究生甚至出國,不要選實踐;若是你不想從事開發相關的職業,不要選實踐;若是你想高績點,不要選實踐。最後,必修讓上面這些話毫無心義。
可是認真地說,軟工實踐給予了同窗們一個全新的機會去看待本身正在學習的學科,個人建議是去嘗試,只要經歷了才知道適合和不適合,才能瞭解這個行業最核心的人員------程序員是什麼樣的工做節奏。這門課是好是壞,也許見仁見智,可是鼓勵的是必定要去嘗試。
對於中途換隊員這種事,仍是不要換的好,雖然能夠理解老師想讓咱們體驗職場的不測風雲,可是一個初步成型的團隊這樣的變更無疑是巨大的,對學生來講只會徒增對項目的負擔,更甚是對課的抵觸。退一步來講,這樣的體驗對之後的職場生活並沒有益處,試想,一個剛入職場的程序員,是否會由於有這樣的一個經歷而能更好地應對突如其來的變故?面對這樣的事,還能想起以前軟工實踐中的小小的體會?再退一步,這樣的變化和實際上變故一比,實在是小巫見大巫,不值一提。綜上所述,我以爲中途換隊員的好處和帶來的負面影響相比,實在得不償失。。
構建之法中提到的團隊發展有4個階段,分別是萌芽階段,磨合階段,規範階段和創造階段。我以爲最後咱們的團隊到達了「創造階段」。從最開始的組隊,到初步的協做討論,再到熟悉磨合,到如今,存在了幾個問題:
在Alpha階段的時候,咱們已經把咱們的軟件推薦給咱們班的人使用了,並積極收集bug反饋和建議