跟軟工實踐say byebye
| 這個作業屬於哪個課程 | 2021春軟體工程實踐|W班(福州大學) |
|---|---|
| 這個作業要求在哪裡 | 軟體工程實踐總結&個人技術部落格 |
| 這個作業的目標 | 1.課程回顧總結 2.個人技術總結 |
| 其他參考文獻 |
課程回顧與總結
寒假作業二
新的解答
問題1：re-work
問題來源：
“有人試圖用“re-work”來表示質量，那麼改動少的程式碼最初質量高，因為re-work的次數少。筆者認為，re-work只是表明在軟體開發過程中花費的時間，re-work的多寡並不跟最終的質量成正比。”
我的疑惑：
那軟體質量與哪些因素有關？re-work次數主要反映了什麼？
新的思考：結合複習軟體質量和測試的筆記，裡面寫道軟體質量的因素有需求分析、軟體設計、編寫程式碼、軟體測試、規格模式、軟體文件。結合本次團隊開發的經歷，在進行軟體開發的前期，我們經過了需求分析、原型設計、資料庫設計和系統設計，並且書寫了相關的文件，方便開發過程檢視，這些前期的工作每一項都必不可少，如果沒有做某一項，勢必會造成一定數量的re-work。當然開發過程也很重要，所以我覺得re-work次數反映了前期準備的到不到位和開發過程的細緻細心程度。
問題2：goto語句
問題來源：
“函式最好有單一出口，為了達到這一目的，可以使用goto。只要有助於函式邏輯的清晰體現，什麼方法都可以使用，包括goto。”
我的疑惑：
“goto語句在我的印象裡，老師一般都不太提倡使用，因為可能會使程式難以理解，難以查錯，並且可以使用其他語句來代替。所以goto語句是否應該被使用，其存在的合理性是什麼？
新的思考：
整個軟工實踐過程中，我主要是負責前端開發，沒有使用過goto語句，加上並不太擅長一些後端的開發語言，所以對此還是沒有太多新的認知，還是維持原思考。即：在不具備垃圾回收機制的語言中，使用goto語句是合理的，使用其可以簡化程式，也不容易忘記釋放資源。
問題3：結對程式設計
問題來源：
“結對程式設計中駕駛員和領航員的角色要經常互換，避免長時間緊張工作而導致觀察力和判斷力的下降。”
我的疑惑：
我一直以為結對程式設計甚至團隊程式設計時，是大家主要負責自己更擅長的事情。這種經常互換角色的操作，其實會不會不利於程式設計？因為可能互換後我對這一部分的工作並沒有那麼熟悉，反而做的更不好。
新的思考：
結合我與隊友結對程式設計的實踐經歷來說，首先我要肯定結對程式設計的好處，它確實是一個很棒的開發方式，之前我會覺得應該做各自擅長的事情，但結對程式設計的過程中，我和我的隊友其實並沒有這麼做，並且做到了角色的互換，儘管我們對於對方的任務領域並不擅長，但我們仍然可以和對方進行討論，檢查對方所負責的任務，提出相應的改進建議。這提高了我們的效率，並且不至於後期脫離原本的目標而導致大改。
問題4：迷思之三：好的想法會贏
問題來源：
“原始佈局設計的優點失去了原有的價值，反而變成了弱點。但是，長期以來，人們已經習慣了QWERTY鍵盤，所謂先入為主。”
作者觀點：
好的想法不一定會贏。
新的觀點：
之前我的觀點是好的想法會贏，只是可能時機未到，或者沒有堅持或者改變的決心。現在我認為好的想法會不會贏，要看後期投入如何，還要看時機。比如本次團隊開發，有些小組的想法確實很新穎很棒，但是他們可能後期存在一些工作的到位或者其他原因，最終得分並不高。又或者拿我們組舉例，假設我們的Fidle也是一個好的想法，β後期我們的投入與產出比也不錯，但是卻無法上線，因為涉及到資訊釋出的問題，所以這其實也沒有贏。
問題5：迷思之五：要成為領域的專家，才能創新
問題來源：
“研究表明，70%的創新者說，他們最成功的創新，是在他們拿手領域之外發現的。”
我的疑惑：
我一直以為，創新的基礎，是要他已經掌握了這項技能或者知識。正如作者在第三章技能的反面那裡說的魔方的技能層次6——能夠設計出新型的魔方，但這個層次6之前的層次5是要求已經對魔方玩法的掌握達到了頂尖水平，甚至可以說是該領域的專家？但為什麼在拿手之外領域，更容易創新呢？
新的思考：
拿我自己來講，我很害怕在意的事情（比如期末考試）被自己搞砸，所以每次我都會按部就班複習，刷題，而不會說是這個題很難我很感興趣但是老師說不考我還去在考前研究它。但對於自己不太在意的事我就可以放心大膽的去做，不會特別在意結果有沒有達到自己的預期。所以代入此情景，既然可以稱之為某領域的專家，此領域的成果對他們一定很重要，而其他自己不太擅長的領域相對也就不那麼重要，所以他們可以放心大膽地去做，去創新。就算搞砸還可以來一句：“我本來就不擅長這個領域欸”。
做中學
需求階段
我的工作：需求討論、功能結構圖繪製、部落格撰寫
具體討論內容：在需求階段，我們將全組人員劃分為需求小組和原型小組，一起討論但又各司其職。需求討論我們主要是確定產品的定位，同時參考其他相關軟體所具備的功能，進行適當篩選，最終通過釋出問卷的方式，明確使用者需求，真正抓住痛點。
我的收穫：在此階段，我學到了需求分析的相關內容，對NABCD各自的定義有了更明確的理解，意識到使用者意見的重要性。同時學會了提煉產品功能，並使用XMind繪製功能結構圖。
設計階段
我的工作：原型討論、前臺和後臺的原型設計和修改、功能模組層次圖、會議記錄、部落格撰寫、評審表製作、學習新技術
具體：原型討論我們主要確認整個產品的配色和風格以及大致的佈局，方便之後對於原型的製作。
我的收穫：在此階段，我熟悉了Mocking bot的使用，掌握了母版的使用，學會了製作輪播圖，發掘了許多有關UI設計的網站。同時學習了對產品功能進行模組劃分及功能模組層次圖的製作。
實現階段
我的工作：前臺我的二手、任務、活動部分以及舉報功能的實現，其中任務和活動只負責了結構和佈局，互動由其他同學來寫。後臺axios跨域問題的解決以及部分部落格的撰寫和PPT製作。
我的收穫：在此階段，我將小程式的開發從文件落實到實戰，學習了小程式的開發，加強了對生命週期函式的理解。還有第一次使用了Vant-weapp元件，減輕了不少的工作量。β階段也對vue開發有了更深入的理解，尤其是跨域問題的解決（後面會附部落格）。最重要的是前後端及時的溝通很！重！要！，因為你可能很久沒解決的問題，可能只是資料庫為空，或者不是你這邊的問題。
測試階段
我的工作：對自己負責的部分進行介面測試；在專案基本完工後對整個產品進行功能測試。
我的收穫：在此階段，我意識到測試的重要性，之前一直沒有重視測試，最終導致α階段的產品存在許多意想不到的bug。在β階段的時候，我們吸取了這個教訓，預留了時間來進行測試來發現bug並改正。
釋出階段
我的工作：對小程式程式碼進行上傳和釋出。協助組員進行問卷調查。（主要因為我是小程式的管理員，而體驗小程式需要我的同意）
我的收穫：上傳很容易，但想要釋出卻很難。α階段時我們稽核通過卻沒有https開始的介面，β階段我們擁有https，微信公眾平臺卻稽核不通過了（好苦）。導致最終只能使用體驗版進行問卷調查。還有就是團隊合作真的很重要！！！我們的問卷得來全靠組內成員的共同努力！！最重要的是開發一個產品或許不太難，但維護一定很難，需要定時收集意見進行產品更新維護，這樣才會有人繼續使用的吧。
理解和心得
個人專案
通過閱讀《構建之法》對軟體工程這門課有了一個初步的理解。通過個人程式設計的WordCount專案，讓我意識到自己對java的掌握真的很差（還好不打算做後端開發），這次作業多虧了和朋友一起使用測試用例進行測試，發掘了一些本來覺得不會出錯的地方，比如正則表示式判斷的書寫。可惜的是最終寫的程式並不能測試過大的檔案（比如150MB的）。而軟體評測作業中，我最終選擇對三個IT問答網站進行評測，發掘各自優缺點和bug，並提出自己的相應意見。這個過程中，我認識到想要之後從事軟體測試相關的工作的話，要具備耐心和細心的特質，不然的話很難發現bug。
結對程式設計
結對程式設計的初體驗，首先讓我意識到溝通的重要性。得意於我跟隊友的不斷溝通所以我們不管是需求分析、原型設計、還是之後的開發過程，都覺得少了很多的麻煩，有人陪你做同一件事，並可以幫你解決疑惑並提出建議，真的很棒。結對程式設計前我不懂為什麼要結對程式設計，結對程式設計後我真的感受到這種開發方式存在的合理性，在實踐中體會到什麼叫1+1>2。
團隊專案
團隊專案中，因為我本身是組長。首先要對所涉及的任務有個全面的瞭解和大致的估計，方便之後的工作劃分。其次要對整個作業進度有個全域性的掌握，進行適時的調整，防止最後時間太緊而出問題（比如α階段，時間安排不合理導致後期趕工且沒有能進行充分測試）。
在這個專案中，我同時也是前端開發。開發的過程中，僅僅書寫好自己部分的程式碼是不夠的，還要考慮與其他部分的跳轉，互動。測試的時候也要記得真機除錯，很多問題只有在真機除錯才會暴露。
個人技術總結
vue-cli3開發解決axios跨域問題
概述：本篇技術部落格是針對我們使用vue-cli3進行後臺開發過程中使用axios進行互動時遇到的一些問題總結，主要是跨域問題的解決。