前言：从手工业到工业的转换——软件工程
蒸汽机是革命吗？大家把蒸汽机当做工业革命的先兆和代表，但是却少有人注意到蒸汽机只是技术，而工业化思想才是代表。基于流水线的思想，工人不用掌握全部的流程技术，而只要懂得其中一个流程的关节，短期内就能上手实践，而且熟练操作的成本变的很低。基于组件化的思想，一件成品被拆分层相关性较小的多个部件，一家工厂不用负责生产所有的组件，而可以利用其它公司更先进优良的技术生产的产品，产品的品质提高了，产品的成本降低了，产品的可维护性上升了。等等。
如果只有蒸汽机，而没有工业化思想，那么手工业还是手工业，永远也不会变成工业，也很难发展壮大。
我们把计算机技术类比蒸汽机，把软件工程思想类比工业思想，就可以发现这一切是共通的。
现在的软件行业正处于从手工业到工业的变化之中，大大小小的公司打造了很多可复用的轮子，有很多已经开源，包括大数据平台、人工智能、分布式框架等等。但是我们的软件开发却还是做不到像工业化那样高效率，大量的轮子仍是在每天的编码中重复制造，人力在软件开发中只起到微薄的作用，各大厂还是求贤若渴，对应聘者提出了很高的要求。
究其原因还是软件工程思想太被忽视，大多数IT公司注重技术实力，而忽略了工程实力。
构建之法是一本很优秀的书，邹老师把软件工程的思想用生动、灵活的例子像我们展示出来，极大了降低了我们对工程思想的理解成本，在做中学的思想更是让人受益颇多。
1、软件开发的规模和难度是指数关系吗？
网络上有人曾说能被一个人清晰理解的代码规模约莫是1万行左右。按照一个模块5个文件，每个文件300行代码计算，这约莫是6到7个模块。而一个项目如果超过了10个模块就会显得很复杂，尤其是模块之间还存在调用的话。代码量并不是砖块的堆砌。对一个模块还需要进行详细的测试。对于一个项目，以现有的工程水平，要让这个项目能被个人理解，最大能接受多大的代码量？
2、软件开发的效率能一直用技术来提高吗？
编程语言的进步也象征着IT技术的变化，从不符合人类语言习惯的汇编，到精巧简练的c，到用面向对象的思想描绘世界的Java、C++，到高度语义化的python。使用这些编程语言也确实带来了客观上的软件开发效率提高。比如相似的项目，使用python大约只需要Java的三分之一代码量，这其中还有语义化和更简单的库使用带来的编程速度的提高。这一切有极限吗？会一直有更好的语言、更优秀的编译器在未来出现吗？就像摩尔定律一样，我觉得这些事总有极限的。
3、软件工程有银弹吗？未来会有吗？
软件工程的思想和技术是相存相依的。我们不能忘记，工程很多时候不一定会带来个人效率的提高。过于繁杂的理论会压抑创造力的空间，繁复的步骤也会降低整体的人均效率。代码的复用性特点导致人不可能总是在开发代码。维护代码和优化代码这才是我们常做的。对于很多工程理论已经融入到了某一些开源框架里。软件工程很难抛开这些框架来谈理论。但这些框架显然不是银弹。理解框架和使用框架也需要成本。软件开发既不能像工业流水线那样重复低门槛，也无法做到真正的技术大众化。那么未来会有银弹吗？
4、软件工程实践中基于项目进度的分工是否应该改为基于团队人员的分工更为合理？
本科生的软件工程实践课程一般的开课周期都是一个学期。每一次项目进度一般是一到两周，按照需求分析、原型设计、系统设计、实际编码这样流程走，虽然能让所有的同学都能体验到软件工程的开发过程，但是带来的一个问题就是，术业有专攻，有的同学擅长原型设计，有的同学擅长实际编码。而实际的项目组也是这样，在某一个阶段某个同学承担了大量的工作，因为他擅长这个。但是每次作业是短期化的，这位同学虽然擅长这个，但是他却没有多少时间把它做好，这样子并不利于效率的提高，能否让成员进行细致的分工，贡献度也按照分工计算？而不是按照某次作业计算？这样也许更接近实际项目组中的情况。我的想法是，比如让一位同学是负责原型设计，那么他理应在整个项目的进行过程中对他的原型设计负责，而在原型设计这次作业中他也应该享有更高的贡献度。
5、换组是否真的起到作用？
诚然在实际项目团队里，成员的突然离开都是很正常的事情，但是作为技术实力和工程实力都一般的学生，而且项目的时间周期短，换组可能很难落实。