軟件工程期中作業（閱讀和提問）

本來打算每篇文獻寫一份讀后感來著，讀了”There is a Silver Bullet”，借鑒其中把模塊的復用作為銀彈的做法，決定把經歷總結和讀后感穿插成一篇去寫。

part1 主要關于經驗總結

在寫這一篇之前，我已經經歷了一次alpha階段的開發（對聯項目），beta階段換了一個組（Julia-AI），此時，beta階段也已經經歷了一半。
在alpha階段的開發中，主要做的是前端的一個demo界面，這里一方面是對前端的工作不熟悉，另一方面是在開發開始的時候就定下來這次的開發是以一個demo界面為主，不太需要考慮之后的發展（也就是篤定了之后要重構的）這樣的念頭，所以基本也沒有做到對原型進行很好的設計

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
  
• Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
• Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
• cited from"Worse is Better"

關于worse is better里面這樣的設計理念，我是覺得很好的。一方面來說，盡量好的設計可以滿足大部分常見情況下的需求，也就是說幾乎可以滿足市場，另一方面，這種做法可以合理的劃分主次，把主要精力放在攻克主要的領域上，同時又足夠的簡單，可以說是在“多快省”這三個方面權衡下的最好設計方式了。但是這種方法會對編程人員的項目經驗和架構能力與洞察力有比較高的要求。在這次10天的alpha沖刺，這個原型的設計確實是被我忽視了的，只做到了足夠的簡單，完成了一個算是完成各項功能模塊的demo，但是正確性和持續性幾乎是完全忽視了的。這也造成了最后的前后端邏輯是一個大泥球。

Therefore, focus first on features and functionality, then focus on architecture and performance
("Big Ball of Mud")

這篇文獻相當于是給出了一個系統變成一個大泥球（一個雜亂無章的系統）和如何進行解決的方法。

反思，在沖刺的過程中做了什么事情讓這個系統變成了泥球了呢？首先像上面引用的那樣，只關注系統的功能，而對架構缺乏設計，這個可以說是最根本的原因了。其次的一些原因，

Therefore, produce, by any means available, simple, expedient, disposable code that adequately addresses just the problem at-hand. “Big Ball of Mud”

開發的時候確實抱著最后再進行整理的心態，但是到了后期整合各個部分的時候，發現由于缺乏前期的整體設計，最后將各個模塊整理到一塊（比如接口調整等）就花費掉了最后的沖刺時間。這就是在時間規劃上出現的問題。做增量式改進的時候，也就是每次對需求作出改進的時候，過于急于看到效果，做的是最不經大腦的修改，沒有考慮到各個模塊之間的解耦和對可擴展性的支持。到了后期增加新的功能往往需要改動的函數就會變得很多。不過beta階段整體架構和代碼都在進行重構，也是符合“Big Ball of Mud”中的重新讓項目有條理的做法的。

在沖刺的過程中，為了提升開發的效率，很多模塊功能的實現并不是依靠自己去認真的翻庫，而是通過尋找功能類似的代碼去進行復用，也就是寄希望于銀彈來提升開發的效率。確實，這樣效率是提高了不少，但是，像這篇“有人負責，才有質量：寫給在集市中迷失的一代”中闡述的那個樣子，現在的開源部分的代碼更多的像是一個大集市，很多代碼的質量是沒有辦法保證的，特別是網上那些發布了代碼但是作者仿佛忘記了自己的賬號密碼的博客中對應的代碼，經?？梢砸姷接腥嗽谙旅嬖u論在運行過程中遇到了什么問題但是并沒有能夠解決，但是往往過了一兩年這樣一條還是了無音信（當然，也和提問的人詢問的方式有關）。然后這些代碼彼此依賴，從一方面來說，給項目的代碼中增加了許許多多沒有必要的冗余代碼，從另一方面，這些代碼（尤其是作者失蹤的）更多的是只是應付在某一種特定情況下的功能，并不會有任何的設計構造或者是異常處理可言，盲目的復用代碼之后使得自己的代碼更加像一個泥球。綜上而言，在實現demo原型的階段，復用是一個很好的提高效率的方式，但是做一個成熟的項目的時候，代碼復用要考慮的事情應當會有很多。包括對于使用的庫函數也應當有合理的挑選，比如之前的圣誕節圖標狗啃事件。如果全部考慮（比如使用限制，應用大小，可擴展性等等），感覺代碼復用并不能夠非常顯著的提高效率？
在利用已經成熟的模塊時候，我遇到的兩個問題：

雖然僅僅需要其中的一小部分功能，但是為了使用這個模塊有的時候不得不將模塊整體包含在項目文件內，導致項目整體體積偏大，運行效率可能比較慢，然而查不清楚具體原因

借助Web App實現部署的時候，需要將項目代碼打包成規定的格式，所以導致部署的代碼和github上的代碼結構不同，同時由于運行環境不同等進行路徑問題等的修改也花費了大量時間，對于Web App模塊本身的運行邏輯不了解也增加了調試的困難，雖然部署方便了很多。

此外，

And for us who are concerned with the success of object-oriented programming, this is chilling—the future will be in the hands of the worst of our fruits. "Is worse really better"

簡單的，考慮的情況比較少但是又相對足夠全面的代碼相對于設計實現復雜，為了一個很少用到的功能而大費周章去設計的代碼來說應當是更容易被閱讀和理解的，也就是更容易被入門的人去接受閱讀的，也就是受眾是更廣的。（這里沒有什么依據，只是看到之前資料收集的時候，看到大家對一個功能的實現，互相轉載的博客中更多的是實現方法比較簡單的做法而做出了的一個假設。）那么相對而言，加上軟件工程的教育和練習在初學者中普及不充分這樣一個情況，更多的項目容易陷入一個泥團的局面。

part2 如何學習軟件工程

一點牢騷

這個方面，我想更多的聚焦于學校里的軟件工程課。因為各種原因，我是自己上過一節軟件工程課，同時通過聽同學吐槽的方式旁觀了第二學期的軟件工程課。這門課里我聽到最多的吐槽是哪幾個呢？回想起來，是

這個作業ddl的時候馬上就要考試了，哪有時間來應付這個

突然要求干XXX，這個東西根本沒有接觸過啊

團隊里XXX是個大腿，只要他干活就行了

課程上得非常無聊，老師也不介紹編程技巧。。。
為什么計算機系的老師教不好軟件工程水平的編程這樣一篇文章里，作者吐槽了軟件工程這門課沒啥鍛煉的東西，老師教學仿佛是一種應付差事。這篇文章里，有這么一句話

就我們系來說，在學習軟件工程這么課之前，好像一直都處于理論學習的階段，平時的作業都只是一些簡單的練習。甚至有些課程，現在都還不知道自己該在什么地方去應用它們，感覺真是白學了。

在某些程度上，這句話似乎可以解釋一下大家會覺得軟件工程這門課無聊的原因。因為課程上很多東西是從理論的角度出發的或者是方法論一樣的東西，而這兩個東西，理論的東西需要大量實踐的驗證，方法論的共鳴也是需要很多實踐，經驗一樣的東西才可以有同感。在缺乏共鳴的時候就像是給原始人講流水線生產是多么高效一樣。在這篇博客中，團隊成員對于如何學好programming摘出了幾個意見：

請企業中的開發者參與programming的教學

學生自己應該有自我發現的能力，you develop software on your own，teacher give you time to develop your skills semi—autonomously

programming更需要在實際的工作經驗中學習

這三個方面的建議都是很有道理的，但是如果按照重要性排序的話可能我會選擇2，3，1這樣的順序。經驗豐富的開發者開設的programming課程，如果針對的還是第一篇博客中提到了“感覺自己白學了“這樣的同學，可能純理論的東西又會被抱怨無聊，做偏工程的項目又會被抱怨課程難度大。這是一個兩難的局面。從自身出發來說，軟件工程的困境一方面是來自于可能部分老師脫離工業環境，導致某些方面讓人感覺說服力不強，另一方面（更大的方面）是來自于學生本身的矛盾性。這個矛盾性主要是體現在所有的課程要求的結題項目更多的是demo性質的而非一個真正的有要求的軟件工程，而被突然施加了很多要求的軟件工程無疑是走出舒適區；另一方面就是傳統的浮躁，想要短期內提高軟件能力而又缺乏足夠的自覺動手能力。

軟件工程教學最好的方式應該還是做中學，兼顧基礎好和不好的兩種情況（關于ddl重疊這種情況，按照道理來說并不應當成為一個顧慮，但是這個顧慮往往是真實存在的，尤其是在看重績點的地方），以下的思考是建立在不存在ddl重疊并且大家真實想學不依賴大腿的情況下。

軟件工程和計算機科學的gap在哪里？

CS != SE，這應該是一個公認的道理，相對而言，計算機科學更偏向于理論，而軟件工程更偏向于更稱，軟件工程的東西相對而言更和人相關，沒有一些很嚴謹的研究方式。在閱讀這篇博客的過程中，作者對計算機科學和軟件工程的區別有著更明確的定義，計算機科學嚴謹，并且各種理論相對比較固定，算法有著嚴格的分析，而軟件工程中的各種不確定性大大增加，而且缺乏明確的定義。理論更新換代速度很快，需要人不斷的根據實踐去調整理論分析的方法，軟件工程是一種將計算機科學的相關成果轉換成為人類可以使用的軟件的一種粘合劑，也就是說，軟件工程是直接和人所打交道的。是一種和人類相關的，包括創意人文等多學科的綜合系統，而非傳統的軟件工程。這篇文章解釋了一個長久以來的疑惑，為什么大學里很多學習的材料都是一些比較老舊的東西，比如知乎經常吐槽的一個問題，為什么大學的C語言教學還在使用VC6.0這樣一個過時的編譯器。因為大學更多的偏向于一些理論知識的教學，大學內的教學包括實驗部分，更多的是注重于促進對計算機科學的理解，比如可計算性，編譯原理，計算算法的復雜度等等，所以，從工業的角度來看，大學里面的很多東西是非常過時落后的，而且學生受到的訓練是可以忽略不計的，也就是“動手能力極差“。這些東西都是不涉及人的，甚至可能不涉及團隊合作的有關內容（不過很多時候大學的團隊合作更多的也都是一人帶飛一對人），也就是和人打交道的部分形同虛設。哪怕是大作業，也就是開發一個軟件項目，更多的也都是小打小鬧性質，沒有達到一定的規模，不需要軟件工程相關的理論指導，不需要考慮軟件的架構等等。那么，如何去準備軟件工程的有關內容呢？計算機科學的內容，教學安排都是顯然地顯示在教學大綱上的，比如密碼學圖論等等。如果想成為一個軟件開發者應該去培養學習啥技能嘞？

軟件工程應該教什么？

"What Should We Teach New Software Developers? Why?"闡述了軟件工程和正常教學之間存在的問題，分析了學術和工業之間存在的gap，指出學術界更關心一些計算機科學的核心理論知識點，工業界則更希望一些有經驗的開發者，理論和實踐之間如何取得一種平衡是教學過程中需要關注的重點。關于教學的方案，針對教授的四年本科時間僅僅只夠教完計算機科學的理論知識點，目標是軟件工程師的人應該需要一個master學位而有志于計算機科學研究的人則應該去學習一個PHD。但是計算機科學的最終目標是進行得到一個更好的系統，所以編程的技能是無論從事學術研究還是工業開發都不可或缺的。關于如何培養一個軟件工程師，我覺得這篇參考文章的闡述更加的詳細一些，也更有一些共鳴。也就是，用工作室的方式來進行學習，換成現在常見的做法，也就是實習這樣一種方式來參與實踐。在這篇文章里，作者指出軟件工程是一種可以通過實踐加反思來自我感悟自我提高的學科。通過工作室的方式參與實踐，學習軟件開發過程中架構設計，與團隊成員溝通等多方面的技能，在經驗豐富的工程師引導下對自己的軟件開發流程進行反思，通過接觸新的項目，考慮很多實際的問題，同時錘煉與人合作的技能等，在這樣一個邊學邊反思的過程中，可以讓人一步步的脫離舒適區，通過一種百煉自得地方式獲取軟件工程所需要地各項技能。軟件工程應當是與建筑等學科無異的一樣的實踐方式。從個人地角度來說，在學校中所做地項目一方面更像是展示自己所學地demo，也就是所謂地三無產品，無用戶，無反饋，無維護。做完就丟掉，也不需要管運行速度之類地東西。然而在實習地過程中，通過scrum等方式去聽成熟地軟件工程師對一個實際項目地見解，考慮的方方面面的要素，在自己工作的過程中去詢問學習的方式，會更快的去領會該如何去真正的開發一個軟件。做中學的方式，而不是開發一個玩具去自娛自樂的方式，更容易讓人在這樣一個偏工程的學科中獲得成長。

轉載于:https://www.cnblogs.com/Annbless/p/10205937.html

總結

以上是生活随笔為你收集整理的阅读后感的全部內容，希望文章能夠幫你解決所遇到的問題。

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