【个人阅读】软件工程M1/M2阶段总结
? ? ? 這次作業是好久以前布置的,由于學期末課程設計任務比較重,我在完善M2階段的代碼的同時又忙于數據庫的實現和編譯器的實現,一度感覺忙得透不過氣來。。。。到這些都基本完成的時候,會看自己以前的閱讀心得,覺得經過了M1/M2階段自己第一次接觸android代碼開發的一無所知到后面通過合作編程以及不斷的查找資料和測試代碼下,我對結對編程以及軟件開發又有了一些個人的理解和建議,正好發現還有一次閱讀作業,就順便我的想法都記下來。。。
? ? ? 還是從學期開始來說吧,第一次是個人統計詞頻的項目,這次作業還沒有納入團隊編程的范圍之中,我感覺應該是準備工作吧。詞頻統計程序不是很難,所以用基本的語法,很快的完成了代碼的編寫,調試階段還是花了一點功夫,主要是之前寫的代碼冗余太大,篇幅太長,看的時候有點眼花(就1詞 2詞 3詞的檢索代碼基本都差不多),而且自己寫代碼的時候分號不對齊,喜歡把簡單正確的一部分代碼合在一行寫。結果當邏輯出現問題的時候(多跳了一次光標)等,感覺看自己的代碼越看越惡心。所以從頭到尾優化了一下代碼風格,把檢索寫成了一個模塊,用正則表達式來進行檢索(之前不懂這個概念,因為和同學討論時同學都說正則表達式好用,我就上網學了挺久時間才弄懂),最后調試運行終于成功了,感覺還可以,不過速度還是有點慢。。。
? ? ? 結對項目實現電梯調度算法的設計,每個電梯屬性都不一樣,最初我和同學討論的時候,設計了一種誰來搭誰的很簡便的算法,后面發現這種算法在人少的時候比較合理,但是在人多的極端情況下,比入300人一起在1樓等的情況,這個算法還沒有傻瓜調度快,所以后面我們綜合了幾種極端情況結合助教的代碼終于設計出了一個比較合理的算法,拿了50分。
? ? ? 之后就來到了M1階段,由于黃金點游戲的排名比較靠后,我們是作為自選題目小組選擇了開發一個android運用。我分配的任務是實現一個底層頁面的設計,展示出一道菜的制作過程。對于android,之前沒有一點基礎,所以我也特地花時間在android頁面開發的學習上。但是在實現的時候也遇到額很多問題,第2周和第三周的時間我都在上網或者問同學來解決這些問題,開始對于json數組及json的分析提取及封裝等過程比較迷茫,和隊長討論的時候,隊長建議我去網上找一個關于json解析運用的實例代碼去看一下會比較好。我同意這個看法,就去網上隨便找了個(真的是隨便找的么。。)結果看了個逼格比較高的代碼,看了半天硬是沒看懂,就老老實實去圖書館借了本開發實例結合語法學習才一步一步知道。之后在頁面布局的設計階段,我使用listiew的時候發現listview套用圖片文字會使圖片顯示不出來,看來了半天也不知道為何(其實很多時候我都覺得一些錯誤我怎么看都看不懂。。包括解釋。。),后面查詢資料才知道,得改寫其中的方法,弄了半天才把基礎的M1版本寫完。。感覺雖然很累但是真正學到了很多有用的東西。
? ? ? M2階段,由于各種課程設計的壓力,我一度忽略了軟工作業。。。不過對于團隊作業,自己的部分還是應該在規定的時間內要完成對應的目標,不然會影響進度和隊長的工作,所以在M1的基礎上我明確了自己的目標,花了一下午和隊長討論了界面的優化方案,最后確定后我有通過對頁面結構的學習為listiew添加了headeview以及一些相對布局的實現,順利完成了要求。
? ? ? 雖然自己的工作是完成了,但是得到的成績并不理想,我簡單的回顧了一下自己的開發代碼以及之前閱讀作業的感想,發現了幾個比較大的問題。
? ? ? 1.對于自己的代碼,我們不止應該去完成它,還要想辦法去找它的bug并解決它,對于M1/M2階段的開發,我是鑒于學習的基礎上做出來的,原則上還有很多可以優化的地方,在測試階段對軟件的使用時我們也發現關于我頁面的一些問題,如果在自己完成代碼優化時多考慮一些問題,就能避免這樣的尷尬,也能加快團隊的開發進度。。。
? ? ? 2. 在閱讀作業中我也明白了團隊項目的開發最重要的不僅僅是個人部分的開發的晚上,更重要的事團隊之間協商的代碼的連接架構以及全局解決方案和各種情況下軟件實現方面問題引申到每個人的代碼的問題,要寫好團隊項目,就必須及時和正確的和隊員溝通,無論是困難的解決以及接口的規范或者是代碼連結的調試,都能及時發現問題,提高效率。
? ? ? 在自己的開發階段,我曾經想通過自學自己干來“獨立”完成代碼編寫,事實發現這樣的想法是不成熟的。遇到的問題應該多多結合和隊員的交流討論,并且在代碼功能及結構的設計層次上,自己在設計時由于沒有和隊長進行完全的溝通,導致開發時的接口以及參數引用不正確,自討苦吃。。
? ? ? 不過,自己也在后兩次階段實現時收獲了很多的感悟
? ? ? ?首先,1+1>2,在我實現json的解析與展示的時候遇到的問題在和相關開發任務的同學經過交流,一起解決困難,這樣比兩個人分開解決好多了,并且我們也互相借鑒了對方的開發方法和部分開發風格,都得到了代碼的優化。
? ? ? 由于自己的組織能力不是很強,所以沒有選擇當隊長,后面我認為,隊長不僅要負責協商團隊編程的進度,也得承擔代碼連結方面的工作,強度可見一斑。。。對于每一位隊員來說,應該服從隊長的安排,最規定的時間完成目標,有什么結構問題優先找隊長協商,而不是找其他隊員私下決定。我在和隊長交談算法和處理問題的時候也交流了許多界面以及功能結構方面的知識,也漸漸對自己的部分有了全局的理解,這對于自己的開發也大有好處。
? ? ? 對于代碼強度來說,我覺得還吃得消,雖然之前沒有接觸,在實現代碼的時候在優化算法方面以及功能設計方面也會有很多的不足,但是至少前面的空白自己都硬著頭皮一點一點學來了,后面的高級部分我們也應該抱有信心和熱情,努力克服困難。
? ? ? 關于個人的建議,其實我不太建議選學長代碼的完善,我更傾向于選一個新的問題從頭做起,這樣我能夠從頭到尾經歷一次比較完整的開發過程,才能真正體會到團隊項目的特點和交流,整合以及優化測試的重要性,這樣也讓我認識到了大工程不僅僅要重視算法,更要重視架構上和變化上對軟件目標實現的綜合整合。
? ? ? ?唯一很遺憾的就是,對于《構建之法》的理解不是很深入,其實軟工的東西基本都是從這本書上整合來的。。遺憾自己沒時間更加深入android開發的一些優化算法,對自己的頁面不太滿意,對其他的大作業花了比較多的心思,軟工沒有投入更多的時間去做也是自己的問題。。。
? ? ? 此時我又想到編譯老師和計組老師說過,大作業雖然會累得讓你喘不過氣,但是你付出的越多,收獲的也會越多,所以我們也沒有必要去抱怨什么,軟工也是如此,團隊的工程,多學多實踐,多多交流,尋找好的方法和途徑,從頭開始雖然很痛苦,但是我也學到了團隊開發的基本過程,如何去解決問題(問同學,上網差書籍,學習別人的代碼也是一種很好的方式,但也要找一個比較合適的代碼。。),總能寫出點什么好東西來的!
? ? ? ?之前閱讀博客鏈接
? ? ? ?http://www.cnblogs.com/12061174lj/p/4027885.html
? ? ? ?http://www.cnblogs.com/12061174lj/p/4072310.html
轉載于:https://www.cnblogs.com/12061174lj/p/4213789.html
總結
以上是生活随笔為你收集整理的【个人阅读】软件工程M1/M2阶段总结的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【树莓派学习笔记】七、(免费)内网穿透将
- 下一篇: uniapp中引入colorUI