软件工程课所思所想 &&《移山之道》读后感（第二期）
软件工程课我的观念转变
之前了解到邹欣老师教过的软件工程课都是大四或研究生的课，我还曾抱怨过。
我曾想过大三的代码量还不够很好地学习软件工程，而且以我的理解这门课是将一定数量的程序员很好地融合进同一个工程的学习，类似于“接口的构建”。而现在连类内部的方法（个人对编程语言的掌握）都没搞清楚，我们的数据库等专业课还正在学，要很好地在工程中合作必然阻碍重重。
有一段时间我一直都是这个想法。
其实自第一天学C开始，我就一直听到人们在说像learn by doing这类的话，我还是像对待数学物理那样去学编程必然是行不通的。在无数bug中慢慢提高，这是目前为止我学编程最真切的感受。
关于软件工程课，客观的说应该是在漫长的编程学习过程中一门巩固提高并具启发作用的专业课。我们不能只局限于一个问题的算法实现和最有效率的数据结构的使用，真正能让自己的这一段代码很好地融合进整个大工程，才能真正起到它的作用。所以说个人的修炼自然是需要坚持进行的，而学会真正在工程中与他人合作，更是必不可少的能力（我曾在@我的微博上听说Microsoft的一个牛人David Cutler先生经常一个人高效率写大工程，表示我可不是“操作系统天神”）。
《移山之道》
在这篇博客里我就不班门弄斧地说一些技术上的1234条什么的了，我就只写一些感悟类的东西。《移山之道》是邹欣老师写的一本有关VSTS开发的书，不是严苛的工具书，就像是一篇篇博客的合集。我读后感觉很像是现在本科三年级的我和同学们做编程开发的例子。都是有一定的编程基础，但是对于如何做工程仅仅是一知半解，像书里写的我们的第一个团队项目是“第一个孩子，照书养”，各种小心翼翼，想要完全消除warning并尽量做到在正确前提下速度最快。
然而这是很难实现的。一是我们自身对编程的理解与掌握还有限，再者只要工程稍大点，想要面面俱到就是很难的了。代码的复杂程度绝对不是线性增加的！这点相信能得到广大群众痛心疾首的支持。一旦成千上万行的程序在眼前展开，尤其是其中好多方法还是照着书第一次用的，调试起来真心有如2012来临。然而之前都是自己一个人死死盯着屏幕找BUG，或许一天一夜之后被偶然经过的某人一句不经意的话语点醒，那可真是忽如一夜春风来~现在结对编程能够很好地解决这个问题，至少不用等一天一夜那么久了。
在《移山之道》的结尾，我和参加了Stone项目的阿超、果冻等人一样也做了总结。其实在前进时不必遗憾，若成功了，叫做精彩；就算结果是糟糕的，也称作经历。果冻说“发布才是硬道理”，其实这不仅仅是指拿出一个完成的作品，发布了的RTM软件（其实自Alpha起就已经是了）就要像自己倾注心血的艺术品，我们不满足基本实现了预想的功能。我们要在这个领域内做到极致。正如文无第一武无第二，IT也是赢者通吃的。行业巨头天下皆知，要问第二好的是谁？或许已经倒在前进的道路上了。谈到软件实现的功能与用户需求之间的关系，我想引用@程序员邹欣老师的微博里提到过的一条：
