專案
內容本作業屬於北航軟體工程課程
班級鏈結
作業要求鏈結檢視
作業要求
我在這門課程的目標是
成為乙個具有一定經驗的軟體開發人員
這個作業在哪個具體方面幫助我實現目標
讓我對自己目前的狀況有乙個更加清醒的認識
請點此鏈結檢視
1. 型別繼承是被提倡使用的嗎？
對於這個問題，我認為針對不同的專案有不同的做法。有些專案從一誕生起就注定了將成為乙個中大型專案，僅靠個人的力量無法獨立完成，必須經過多名程式設計師的共同配合才有可能編寫出來。而另一些專案則是典型的小型專案，兩三個人甚至乙個有經驗的程式設計師就可以輕鬆完成，不需要有太多的人員配合。對於前者而言，有必要在需要對開發人員進行約束的地方使用型別繼承，這樣可以將模組的功能限制在乙個確定的範圍之內，有利於程式整體結構的一致性；而對於後者，可以僅在必要的地方使用型別繼承，例如把一系列相似的物件視為同一種物件在不同切面上的投影。以上是我在實踐中確定的思想，我們組的專案後端框架選擇了ruby on rails，一種非常純粹的物件導向語言，而中介軟體則是選擇了python。rails專案相對來說要龐大一些，且這個框架本身就包含了非常多的型別繼承，因此我們也順水推舟地使用了很多態別繼承；python寫的中介軟體則是幾個小品模組的雜糅，為了求快並沒有使用過多的物件導向技術，反而短平快的解決了問題。
2. 角色互換是否是乙個合理的選擇？
我後來發現，結對程式設計與我預先設想的目的並不相同。我原本以為，結對程式設計是為了直接提高程式設計效率而誕生的，但經過一次實踐之後發現並非如此。結對程式設計本質上是犧牲了兩份時間，換取乙份幾乎沒有bug的**，從而間接提高軟體開發的效率（因為後期複審變得容易了）。在這種情況下，由乙個人長時間駕駛而另乙個人長時間領航就勢必會帶來疲勞駕駛的問題，因此經常進行角色互換實際上是乙個合理的選擇。
3. 該怎麼權衡使用者對ui的相反評價？
4. 如何針對具有複雜***的方法設計測試用例？
ruby on rails這個框架教會了我乙個道理：沒有什麼是乙個測試檔案解決不了的，如果有，那就上乙個整合測試。之前我過於拘泥在單元測試的泥潭裡無法自拔了，後來在實踐的過程中我發現，單元測試只是測試的一種手段，在實際的軟體測試中，整合測試才是更好用、價效比更高的測試方法。整合測試把軟體當成乙個黑箱，關心軟體的執行狀態是否達到預期，其測試粒度相比單元測試要大上不少，可以將許多方法及其***包絡起來，從接近使用者的角度去做測試。因此，設計測試用例的時候，遇到那些不好做單元測試的方法，索性就把它們放在整合測試中，一次性全部測完。
5. 如何做好後端專案的可見性？
我現在覺得，這個問題可能有些自私了。之前我的想法是，乙個軟體專案後端團隊和前端團隊是完全分離獨立的，後端只需要做好所有介面就可以完事走人，前端只需要做好所有介面展示工作就可以回家睡覺，其它地方出了問題都可以甩給別人，自己不接這口鍋。但後來我發現，乙個團隊是榮辱與共的，不存在前端和後端可以真正獨立的情況。無論是在專案經理還是投資者視角中，前端和後端都是不存在的，唯一存在的就只有這個專案本身，後端出了問題是整個專案的問題，前端出了問題也還是整個專案的問題，前端後端福禍相依，也唇亡齒寒。因此，後端沒有必要去過多考慮怎樣做好後端模組的可見性，應該把更多的精力放在完善功能和測試上，不成為前端的瓶頸。這樣，當前端完工時，後端的工作也就自然而然地被展示出來了。
所幸，現在沒有了。
我的問題是：怎樣持續控制軟體質量。
乙個團隊中，技術差距是一定會存在的，這個時候往往技術最強的人會挑起大樑，負責他所在部分的**質量審核。但乙個人的能力越強責任就越大，負責的事情也會越多，往往抽不出身去對**做特別細緻的審核。我們組的**質量在一開始是比較高的，但後期下滑嚴重，**量的快速攀公升給審核**的技術人員帶來了很大的壓力，有時為了專案能夠快速部署上線看到效果，往往會有囫圇吞棗式的審核，**質量控制也就成為了乙個流於形式的東西。但**質量又是十分重要的，當幾個人共同向乙個**庫中推送**時，個人糟糕的**風格很快就會如雪崩般放大，進而影響到整個專案。對於小型團隊而言，當**量逐漸變大（大至一萬行左右）時，有什麼更好的控制**質量的方法嗎？
1. 需求分析階段
如何分辨哪些需求是重要的、哪些需求是不重要的：只需要將自己代入進使用者，並結合市面上相似產品的功能，就可以大致做出判斷。
2. 設計階段
前端不是上來就莽的，如果沒有設計圖就直接開工的話，會死得很難看。
3. 實現階段
熟悉乙個專案的最好方式，就是去親自為其實現乙個新的功能。
4. 測試階段
整合測試往往比單元測試價效比更高。
5. 發布階段
使用者所處的環境千奇百怪，許多bug真的是在上線之後才能發現的。
6. 維護階段也因此我意識到，現代軟體工程已經成為了乙個很難靠單槍匹馬就可以完成的任務，只有團隊合作才能給軟體專案注以源源不斷的生命力。我很感謝我的隊友們，和他們在一起的這個學期，我度過得非常愉快。
軟體工程 提問回顧與個人總結
專案 內容這個作業屬於哪個課程 羅傑這個作業的要求在 提問回顧與個人總結 軟體工程 第一次閱讀作業 了解到了只要能有利於程式邏輯的清晰體驗，使用goto語句是完全可以接受的事情。我認為應該在達成共識後，將設計文件的寫作交付給一位成員來完成。個人認為 你 對推銷新的發明的年輕人的恨 如果有的話 個人認...
軟體工程提問回顧與個人總結
傳送門在結對程式設計的模式下，一對程式設計師肩並肩 平等地 互補地進行開發工作。他們併排地坐在一台電腦前，面對同乙個顯示器，使用過同乙個鍵盤 同乙個滑鼠一起工作。回答 親自體會了結對程式設計之後才會真實的體會到，溝通與交流的重要性，這其中主要的一點就是一起程式設計的過程中的交流。當然，在寫 之前的溝...
軟體工程提問回顧與個人總結
專案 內容這個作業屬於哪個課程 羅傑這個作業的要求在 提問回顧與個人總結 軟體工程第一次閱讀作業 1.我了解到結對程式設計中，工程專案完成的方式可以自己調整，選擇最合適的方式來完成工程。2.這個需要自己進行調研以及經驗的積累。3.同上。4.這個需要自己根據自身情況來衡量。5.只要有利於程式邏輯的清晰...