前言：從手工業到工業的轉換——軟體工程
蒸汽機是革命嗎？大家把蒸汽機當做工業革命的先兆和代表，但是卻少有人注意到蒸汽機隻是技術，而工業化思想才是代表。基于流水線的思想，勞工不用掌握全部的流程技術，而隻要懂得其中一個流程的關節，短期内就能上手實踐，而且熟練操作的成本變的很低。基于元件化的思想，一件成品被拆分層相關性較小的多個部件，一家工廠不用負責生産所有的元件，而可以利用其它公司更先進優良的技術生産的産品，産品的品質提高了，産品的成本降低了，産品的可維護性上升了。等等。
如果隻有蒸汽機，而沒有工業化思想，那麼手工業還是手工業，永遠也不會變成工業，也很難發展壯大。
我們把計算機技術類比蒸汽機，把軟體工程思想類比工業思想，就可以發現這一切是共通的。
現在的軟體行業正處于從手工業到工業的變化之中，大大小小的公司打造了很多可複用的輪子，有很多已經開源，包括大資料平台、人工智能、分布式架構等等。但是我們的軟體開發卻還是做不到像工業化那樣高效率，大量的輪子仍是在每天的編碼中重複制造，人力在軟體開發中隻起到微薄的作用，各大廠還是求賢若渴，對應聘者提出了很高的要求。
究其原因還是軟體工程思想太被忽視，大多數IT公司注重技術實力，而忽略了工程實力。
建構之法是一本很優秀的書，鄒老師把軟體工程的思想用生動、靈活的例子像我們展示出來，極大了降低了我們對工程思想的了解成本，在做中學的思想更是讓人受益頗多。
1、軟體開發的規模和難度是指數關系嗎？
網絡上有人曾說能被一個人清晰了解的代碼規模約莫是1萬行左右。按照一個子產品5個檔案，每個檔案300行代碼計算，這約莫是6到7個子產品。而一個項目如果超過了10個子產品就會顯得很複雜，尤其是子產品之間還存在調用的話。代碼量并不是磚塊的堆砌。對一個子產品還需要進行詳細的測試。對于一個項目，以現有的工程水準，要讓這個項目能被個人了解，最大能接受多大的代碼量？
2、軟體開發的效率能一直用技術來提高嗎？
程式設計語言的進步也象征着IT技術的變化，從不符合人類語言習慣的彙編，到精巧簡練的c，到用面向對象的思想描繪世界的Java、C++，到高度語義化的python。使用這些程式設計語言也确實帶來了客觀上的軟體開發效率提高。比如相似的項目，使用python大約隻需要Java的三分之一代碼量，這其中還有語義化和更簡單的庫使用帶來的程式設計速度的提高。這一切有極限嗎？會一直有更好的語言、更優秀的編譯器在未來出現嗎？就像摩爾定律一樣，我覺得這些事總有極限的。
3、軟體工程有銀彈嗎？未來會有嗎？
軟體工程的思想和技術是相存相依的。我們不能忘記，工程很多時候不一定會帶來個人效率的提高。過于繁雜的理論會壓抑創造力的空間，繁複的步驟也會降低整體的人均效率。代碼的複用性特點導緻人不可能總是在開發代碼。維護代碼和優化代碼這才是我們常做的。對于很多工程理論已經融入到了某一些開源架構裡。軟體工程很難抛開這些架構來談理論。但這些架構顯然不是銀彈。了解架構和使用架構也需要成本。軟體開發既不能像工業流水線那樣重複低門檻，也無法做到真正的技術大衆化。那麼未來會有銀彈嗎？
4、軟體工程實踐中基于項目進度的分工是否應該改為基于團隊人員的分工更為合理？
大學生的軟體工程實踐課程一般的開課周期都是一個學期。每一次項目進度一般是一到兩周，按照需求分析、原型設計、系統設計、實際編碼這樣流程走，雖然能讓所有的同學都能體驗到軟體工程的開發過程，但是帶來的一個問題就是，術業有專攻，有的同學擅長原型設計，有的同學擅長實際編碼。而實際的項目組也是這樣，在某一個階段某個同學承擔了大量的工作，因為他擅長這個。但是每次作業是短期化的，這位同學雖然擅長這個，但是他卻沒有多少時間把它做好，這樣子并不利于效率的提高，能否讓成員進行細緻的分工，貢獻度也按照分工計算？而不是按照某次作業計算？這樣也許更接近實際項目組中的情況。我的想法是，比如讓一位同學是負責原型設計，那麼他理應在整個項目的進行過程中對他的原型設計負責，而在原型設計這次作業中他也應該享有更高的貢獻度。
5、換組是否真的起到作用？
誠然在實際項目團隊裡，成員的突然離開都是很正常的事情，但是作為技術實力和工程實力都一般的學生，而且項目的時間周期短，換組可能很難落實。