預培訓-閱讀-快速閱讀並提問

前言：從手工業到工業的轉換——軟件工程

蒸汽機是革命嗎？你們把蒸汽機當作工業革命的先兆和表明，可是卻少有人注意到蒸汽機只是技術，而工業化思想纔是表明。基於流水線的思想，工人不用掌握所有的流程技術，而只要懂得其中一個流程的關節，短時間內就能上手實踐，並且熟練操做的成本變的很低。基於組件化的思想，一件成品被拆分層相關性較小的多個部件，一家工廠不用負責生產全部的組件，而能夠利用其它公司更先進優良的技術生產的產品，產品的品質提升了，產品的成本下降了，產品的可維護性上升了。等等。

若是隻有蒸汽機，而沒有工業化思想，那麼手工業仍是手工業，永遠也不會變成工業，也很難發展壯大。

咱們把計算機技術類比蒸汽機，把軟件工程思想類比工業思想，就能夠發現這一切是共通的。

如今的軟件行業正處於從手工業到工業的變化之中，大大小小的公司打造了不少可複用的輪子，有不少已經開源，包括大數據平臺、人工智能、分佈式框架等等。可是咱們的軟件開發卻仍是作不到像工業化那樣高效率，大量的輪子還是在天天的編碼中重複製造，人力在軟件開發中只起到微薄的做用，各大廠仍是求賢若渴，對應聘者提出了很高的要求。

究其緣由仍是軟件工程思想太被忽視，大多數IT公司注重技術實力，而忽略了工程實力。

構建之法是一本很優秀的書，鄒老師把軟件工程的思想用生動、靈活的例子像咱們展現出來，極大了下降了咱們對工程思想的理解成本，在作中學的思想更是讓人受益頗多。

一、軟件開發的規模和難度是指數關係嗎？

網絡上有人曾說能被一我的清晰理解的代碼規模約莫是1萬行左右。按照一個模塊5個文件，每一個文件300行代碼計算，這約莫是6到7個模塊。而一個項目若是超過了10個模塊就會顯得很複雜，尤爲是模塊之間還存在調用的話。代碼量並非磚塊的堆砌。對一個模塊還須要進行詳細的測試。對於一個項目，以現有的工程水平，要讓這個項目能被我的理解，最大能接受多大的代碼量？

二、軟件開發的效率能一直用技術來提升嗎？

編程語言的進步也象徵着IT技術的變化，從不符合人類語言習慣的彙編，到精巧簡練的c，到用面向對象的思想描繪世界的Java、C++，到高度語義化的python。使用這些編程語言也確實帶來了客觀上的軟件開發效率提升。好比類似的項目，使用python大約只須要Java的三分之一代碼量，這其中還有語義化和更簡單的庫使用帶來的編程速度的提升。這一切有極限嗎？會一直有更好的語言、更優秀的編譯器在將來出現嗎？就像摩爾定律同樣，我以爲這些事總有極限的。

三、軟件工程有銀彈嗎？將來會有嗎？

軟件工程的思想和技術是相存相依的。咱們不能忘記，工程不少時候不必定會帶來我的效率的提升。過於繁雜的理論會壓抑創造力的空間，繁複的步驟也會下降總體的人均效率。代碼的複用性特色致使人不可能老是在開發代碼。維護代碼和優化代碼這纔是咱們常作的。對於不少工程理論已經融入到了某一些開源框架裏。軟件工程很難拋開這些框架來談理論。但這些框架顯然不是銀彈。理解框架和使用框架也須要成本。軟件開發既不能像工業流水線那樣重複低門檻，也沒法作到真正的技術大衆化。那麼將來會有銀彈嗎？

四、軟件工程實踐中基於項目進度的分工是否應該改成基於團隊人員的分工更爲合理？

本科生的軟件工程實踐課程通常的開課週期都是一個學期。每一次項目進度通常是一到兩週，按照需求分析、原型設計、系統設計、實際編碼這樣流程走，雖然能讓全部的同窗都能體驗到軟件工程的開發過程，可是帶來的一個問題就是，術業有專攻，有的同窗擅長原型設計，有的同窗擅長實際編碼。而實際的項目組也是這樣，在某一個階段某個同窗承擔了大量的工做，由於他擅長這個。可是每次做業是短時間化的，這位同窗雖然擅長這個，可是他卻沒有多少時間把它作好，這樣子並不利於效率的提升，可否讓成員進行細緻的分工，貢獻度也按照分工計算？而不是按照某次做業計算？這樣也許更接近實際項目組中的狀況。個人想法是，好比讓一位同窗是負責原型設計，那麼他理應在整個項目的進行過程當中對他的原型設計負責，而在原型設計此次做業中他也應該享有更高的貢獻度。

五、換組是否真的起到做用？

誠然在實際項目團隊裏，成員的忽然離開都是很正常的事情，可是做爲技術實力和工程實力都通常的學生，並且項目的時間週期短，換組可能很難落實。