提問回顧與個人總結

項目內容

所屬課程	2019春季計算機學院軟件工程(任健)
所屬作業	提問回顧與問題總結
課程目標	理解軟件工程的作用和重要性，提升工程能力，團隊協作能力
作業目標	回顧軟工課程，總結課程的收獲
提問博客	軟工第1次個人作業

一、問題回顧與解答

1. goto語句

函數最好有單一的出口，為了達到這一目的，可以使用goto。只要有助于程序邏輯的清晰體現，什么方法都可以使用，包括goto。——《構建之法》P69 4.3.2

goto語句在c語言中難以操縱，初衷可能是添加一兩個goto為了體現程序邏輯，如書中提到的單一出口設計。但一旦函數的邏輯比較復雜，使用goto是否會反而破壞程序的條理性呢？

不論是使用更便捷的工具還是更復雜的工具，都會為項目帶來很多的弊端和隱患。比如Python語言，在OO編程中就有著種種不利于工程性的一些特性，而更強大的C++卻有著種種技術難題。但技術是人來使用的，只要軟件工程師的使用符合工程標準，就可以使用種種技術。事實上，在我們的開發過程中，往往會使用很多更復雜，更不利于程序條理性的工具，但為了實現需求，我們是可以選擇去挑戰使用這樣的技術的。

2. 全棧工程師

當一個運維工程師在維護一套系統的時候，運維團隊要了解各個模塊的作用、維護知識，以及和硬件、商業模式相關的各種事件的需求。如果這大部分運維工作都是由一個工程師來完成，那么這位工程師的確是“全棧”。P53 3.3

書中文字給人一種現在是個人就敢說自己是全棧工程師的感覺，可能作者對身邊存在的這樣一種浮躁的現象有一些自己的思考和駁斥。

考慮這樣幾種情況：某職工曾在多家互聯網公司任職，在A公司做過后端，在B公司做過前端，在C公司做過服務器維護，在D公司又負責寫算法，所以他在投給E公司的簡歷上寫——我是全棧工程師。

某獨立開發者自己維護了一個開源項目并且有著一些穩定的用戶，這個開源項目部署在了網站上并且該項目的前端后端都是由該開發者自行搭建，并在網站上貼上了自己的支付寶收款碼求各位大爺們救濟。碰巧該開發者看了《構建之法》這一段，于是心里閃過——我是全棧工程師。

請問職工A和開發者B，究竟誰的技術更好？A作為一個有廣泛工作經驗的職工，他可能有著極強的工程能力和編碼能力；而B可能只是一個剛畢業的研究生，有著維護自己開源項目的愛好。

這是否意味著，全棧工程師在不同的情境下有著不同的意味，而不代表著一個技術上更高一層的階級呢？

先說結論，全棧工程師在同一個項目或系統內，代表著一個技術上更高的階級。

在我小組軟工的項目組內，有著一名對項目非常上心的同學。他做過的事情從前端到后端，從Linux Shell到Android，從項目需求定制到日常例會內容制訂都有所涉獵，最終他也獲得了應得的貢獻分數。因此在我們這個項目內，他就是處于一個全棧工程師的地位。即便拋開對開發的熱情，從純技術層面來說，我認為他在我們的項目組，也屬于一個技術上更高一層的階級。這也是我們項目最終能成功完成的主要因素，就是有這樣一位全棧工程師，為各個部分的同學出謀劃策提供建議，甚至親自動手。

當然，他目前的技術可能不足以在企業內擔任全棧工程師，那需要更多的經驗。但在每個項目內，都會有著這樣一位技術上的領頭人物，如果他真的能涉獵到項目的所有部分，那么他在這一場景下就符合全棧工程師的定義了。

3. 軟件測試

我曾經了解到在如今BAT的大部分項目里，也沒有建立良好的Code Review制度，Unit Test也僅僅有重要模塊會做。那么對于這樣大型項目的覆蓋性測試，其花費的人力成本是否會得到相應的回報呢？如果做工程的最終目的是為了盈利的話，軟件測試的全面性在實際應用中是否并不被重視呢，而我們在完成作業時卻還要為邏輯簡單明了但構造測試樣例卻有難度的那些分支去做100%覆蓋，是否是教育的過度形式化的一種體現呢？

關于軟件測試的作用，在我們的項目中，通過單元測試和分支覆蓋來找到的BUG屈指可數。這一點或許是因為我們的業務邏輯較為簡單。對于大型項目，或許合格的單元測試可以在軟件工程中提升效率，即花費部分測試的時間來減少返工修BUG的時間，在項目的敏捷開發中可以節省項目的總體人力成本。而在課程中應用這種形式，并不是為了節省時間和人力成本，也并不是真的要為了修BUG， 更多的是為了讓我們了解軟件工程中測試的重要性，形成軟件測試的潛意識。

4. 人類學調查

我平時接觸的同學都是計算機專業的，……，我從來沒為軟件或服務付過費。——《構建之法》P159

據書中提到，這是某計算機系的同學，這里我要提出一些自己的見解。

該同學覺得自己每天FQ上外網看quora，表姐父母卻天天hao123，QQ秀，話語中體現出自己比海量的中國用戶不知高到哪里去了。

如果他覺得站在墻外就更懂計算機，我還可以理解，但是他認為自己從來沒為軟件或服務付過費是一種很hacker的行為我就很奇怪了。上百度搜個注冊機破解碼就覺得自己比那些不愿意花錢干等著的人高半頭？作為計算機未來的從業者，自己想用軟件不花錢，自己寫軟件的時候你也別想著賺別人的錢啊？如果可以培養一些高素質人群的付費使用習慣，我認為這是可以促進現有軟件工程的質量的。如果大家都想不花錢用，那軟件提供商就只能在軟件上掛廣告，大家都不舒服，何必呢？

這只是一個和書中所選的某位同學的觀點不合的一些看法，并沒有構成提問。原書只是想借用這一例子來說明用戶需求調查中，人類學調查的重要性，即世界上存在大量為使用便捷，或者Geek眼里的懶惰付錢的人。

Geek自然有資格評價他人的懶惰，但Geek卻不應為自己會使用搜索引擎尋找破解軟件而自豪。這不是Geek，這只是聰明的窮鬼而已。

5. 大馬哈魚洄游模型

P416

書中提到了一些軟件工程課的一些現象，看起來軟件工程這門課似乎并不完善，這似乎主要是因為同學們的水平比較低（上課睡覺），還有一些課程安排方面過于高屋建瓴，沒有落實到地。

比如本次博客作業，要大家在比較短時間內瀏覽完鄒欣老師的《構建之法》這本書，這一看，上周課上的PPT基本上就是構建之法的掃描件嘛。書中安排了健身學員的身份給大家，你讀完，你就是很想提高自己，你不想讀，就是想把健身卡墊桌腳。那既然我們大家都讀完構建之法了，是不是我們就已經大致了解軟件工程理論，只需要等著編碼實踐了呢？那么如果未來的課程還只是構建之法的掃描縮印，那理論課的課程內容在第一次博客作業時就已經學習完畢了，理論課的內容是否顯得空虛了一些呢？如果課程設計時知道大家在這很短的時間內看不明白構建之法的軟工精髓，那么留本次博客作業讓大家看完這本書是否合理，又是否自相矛盾呢？

如果不能解決上述問題，就盲目地認為是因為學生沒有學好軟工就是因為用健身卡墊桌腳了，是不是有些不妥呢？

私以為《構建之法》是一本很好的書，深入淺出而生動獨特。軟工課程是想以課程中所介紹的方法和實際的項目開發相結合，從而讓學生更好地理解軟工的精髓。但是在實際操作上卻仍然有著一些不足之處。這樣的不足之處，可以通過學生的熱情和主觀能動性來彌補。軟工課程中介紹的理論和軟工項目的開發在實際環境中脫節嚴重，至少在我身邊的數個小組是這樣的。當然，學生可以通過不懈的努力和主動去嘗試學習來親身實踐，但更好的課程制度應該是去建立一個良好的學習體系，并以此聯系理論和實踐。這一點我認為軟工課程還需要改進，但我個人沒有很好的建議，因為這確實是一件很困難的事情，因為在我看來，很多軟工的理論都是難以在課程項目這個級別就輕松實現的。

---

二、知識點總結

• 需求：用戶的需求是推動項目功能設計的關鍵因素，因此用戶調查是非常重要的
• 設計：在軟件的功能設計上，應均衡考慮功能的效果及功能本身實現的難度等多方面
• 實現：實現時應盡量選用較為成熟的框架或工具，這樣有詳盡的文檔和大量的社區貢獻者所提供的資料
• 測試：測試工程師需要對項目所使用的的技術較為熟悉，并對項目的結構和每個函數的作用有著具體的了解才能更好地完成測試。
• 發布：App的發布需要考慮到很多因素，如安全因素，使用代碼的開源許可等等。因此App的發布需要提前調研，防止由于應用市場的政策導致App發布的延期。
• 維護：對功能主要集中在本地的App的維護主要體現在日常反饋Bug的修復和新功能的跟進，新系統的適配等等。其次要對App使用的一些在線服務進行維護，保證其可用性，比如Bug反饋服務和軟件檢查更新服務。

三、理解和心得

對軟工的課程項目，我認為在其中團隊的協作和溝通是極為重要的，對項目的熱情也是必不可少的。而每個人的技術實力應該是一個團隊成功的主要因素，輔以軟件工程方法的優秀應用，才可以成就一個更好的項目。

對此，我可以理解課程為什么會有大量的博客來進行展示，或許是課程更重視一個項目開發中軟件工程方法的應用。對項目本身，更注重其功能的全面性，以及其功能和需求的切合度，能自圓其說便可。而項目的實現難度和技術的優秀與否，在課程的構建中并不是最重要的部分。雖然事實上很多成功的應用或許不會使用十分先進的技術，而是其抓住了市場的需求和痛點，但是對于程序員本身來說，對技術的追求應該是永不停歇的。

轉載于:https://www.cnblogs.com/SephyFine/p/11102831.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的[BUAA软工]提问回顾与个人总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。