閱讀後感

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

原本打算每篇文獻寫一份讀後感來着，讀了」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」中的從新讓項目有條理的作法的。

在衝刺的過程當中，爲了提高開發的效率，不少模塊功能的實現並非依靠本身去認真的翻庫，而是經過尋找功能相似的代碼去進行復用，也就是寄但願於銀彈來提高開發的效率。確實，這樣效率是提升了很多，可是，像這篇「有人負責，纔有質量：寫給在集市中迷失的一代」中闡述的那個樣子，如今的開源部分的代碼更多的像是一個大集市，不少代碼的質量是沒有辦法保證的，特別是網上那些發佈了代碼可是做者彷彿忘記了本身的帳號密碼的博客中對應的代碼，常常能夠見到有人在下面評論在運行過程當中遇到了什麼問題可是並無可以解決，可是每每過了一兩年這樣一條仍是了無音信（固然，也和提問的人詢問的方式有關）。而後這些代碼彼此依賴，從一方面來講，給項目的代碼中增長了許許多多沒有必要的冗餘代碼，從另外一方面，這些代碼（尤爲是做者失蹤的）更多的是隻是應付在某一種特定狀況下的功能，並不會有任何的設計構造或者是異常處理可言，盲目的複用代碼以後使得本身的代碼更加像一個泥球。綜上而言，在實現demo原型的階段，複用是一個很好的提升效率的方式，可是作一個成熟的項目的時候，代碼複用要考慮的事情應當會有不少。包括對於使用的庫函數也應當有合理的挑選，好比以前的聖誕節圖標狗啃事件。若是所有考慮（好比使用限制，應用大小，可擴展性等等），感受代碼複用並不可以很是顯著的提升效率？
在利用已經成熟的模塊時候，我遇到的兩個問題：

1. 雖然僅僅須要其中的一小部分功能，可是爲了使用這個模塊有的時候不得不將模塊總體包含在項目文件內，致使項目總體體積偏大，運行效率可能比較慢，然而查不清楚具體緣由
2. 藉助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 如何學習軟件工程

一點牢騷

這個方面，我想更多的聚焦於學校裏的軟件工程課。由於各類緣由，我是本身上過一節軟件工程課，同時經過聽同窗吐槽的方式旁觀了第二學期的軟件工程課。這門課裏我聽到最多的吐槽是哪幾個呢？回想起來，是

1. 這個做業ddl的時候立刻就要考試了，哪有時間來應付這個
2. 忽然要求幹XXX，這個東西根本沒有接觸過啊
3. 團隊裏XXX是個大腿，只要他幹活就好了
4. 課程上得很是無聊，老師也不介紹編程技巧。。。
   爲何計算機系的老師教很差軟件工程水平的編程這樣一篇文章裏，做者吐槽了軟件工程這門課沒啥鍛鍊的東西，老師教學彷彿是一種應付差事。這篇文章裏，有這麼一句話

就咱們系來講，在學習軟件工程這麼課以前，好像一直都處於理論學習的階段，平時的做業都只是一些簡單的練習。甚至有些課程，如今都還不知道本身該在什麼地方去應用它們，感受真是白學了。

在某些程度上，這句話彷佛能夠解釋一下你們會以爲軟件工程這門課無聊的緣由。由於課程上不少東西是從理論的角度出發的或者是方法論同樣的東西，而這兩個東西，理論的東西須要大量實踐的驗證，方法論的共鳴也是須要不少實踐，經驗同樣的東西才能夠有同感。在缺少共鳴的時候就像是給原始人講流水線生產是多麼高效同樣。在這篇博客中，團隊成員對於如何學好programming摘出了幾個意見：

1. 請企業中的開發者參與programming的教學
2. 學生本身應該有自我發現的能力，you develop software on your own，teacher give you time to develop your skills semi—autonomously
3. 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等方式去聽成熟地軟件工程師對一個實際項目地看法，考慮的方方面面的要素，在本身工做的過程當中去詢問學習的方式，會更快的去領會該如何去真正的開發一個軟件。作中學的方式，而不是開發一個玩具去自娛自樂的方式，更容易讓人在這樣一個偏工程的學科中得到成長。