今天我阅读了邹欣老师的《构建之法》从前言到正文的第66页，一些思考和体会如下：
1.前言
从前言可以看出邹欣老师对软件工程课的定位和对这本书作为教材的评价还是很高的。从前言可以知道这本书是邹欣老师结合了在一些高校的软件工程授课经验和自己的心得体验，写出的一本强调通过动手实践学习软件工程的教材。
2.给任课老师和助教的建议
这部分可以看书邹欣老师对同学们的要求很高，预期每个学生需要每周花费8个小时在这门课上。我个人而言，在个人项目和团队项目中每周花费的时间要超过8个小时。在团队项目中如果算上开会讨论等事务的时间，也是超过八个小时的。而在团队项目中，写代码的时间则不是很稳定，有的周超过8个小时，有的周则不够。
面对软件学院老师的抱怨，邹欣老师提出的问题的解决方法是先让同学们维护已有的程序再逐步增量开发的方式。我觉得这种想法很好。当时黄金点游戏我们组得到了第二顺位，挑选项目的优先级还是很高的。当时怀着对已有项目的天真的认可，包括我们的所有顺位靠前的组都选择了对已有项目的迭代开发。但事实证明我们真的是too young to naive，因为拿到手的程序根本不是一个完整的程序，何谈迭代开发？这从很大程度上打消了我的热情，是我有了很强的抵触心理。
邹欣老师对于师生关系的论述罗杰老师在上课也讲到了。教练/学员模型确实很吸引人，但是在实际的开发过程中，我觉得是学员们在独立战斗，从老师那里能够得到的帮助极其有限。
关于邹欣老师给出的1/N打分法和团队贡献分的机制，我觉得前者太残酷而后者太理想化。可能还是社会本来就很现实而作为学生的我还太naive。
3.第一章
第一章主要将了一些概念性的东西。比较重要的可能是几个公式。
一个是我们很早就知道的公式：
程序=算法+数据结构
另外两个我认为是书提醒我们要额外注意的：
软件=程序+软件工程
软件企业=软件+商业模式
对于这三个公式，我有些自己的想法:
程序对人与人关系的涉及最少，软件和软件企业对人和人与人关系的探寻则是越来越多。
看来人还是最根本的。比如邹欣老师在书中提到，很多软件功能相似，但用户体验将他们拉开了巨大的差距。
看来博弈归根到底是人与人的博弈。
4.第二章
第二章讲个人技术和流程，比较实践性的内容包括单元测试和效能分析。
邹欣老师列出的对比大四学生和工作三年的软件工程师在个人项目耗时的对比很有意思。
最明显的对比是SDE比学生多60%的时间在需求分析和测试上而少1/3的时间在编码上。这现实了职业化有一个突出的特点就是规范化。
5.第三章
这一章讲软件工程师的成长，我想每一个学生都会很关心这个话题，我当然也不例外。这一章依然印证了职业化的突出特点是规范化。要成为一个优秀的软件工程师，很多东西不能够再用大概、差不多这种词去描述，而应该用真实记录下来的数据说话。而真实的项目是能力提升的必由之路。
邹欣老师提到的魔方的例子使我印象很深刻。怎么提高技能，邹欣老师给出的答案一针见血：通过不断的练习，把那些低层次的问题都解决了，变成不用经大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。事实上，这种模式正式中学时代的模式：所有的知识点都已经到了滚瓜烂熟的接近本能的程度，然后才能在应付各种题目的过程中天马行空随意施展。
但这可能也是我和我身边的很多同学们面临的最大的问题。又想提起大二下的面向对象课了。面向对象课确实讲了面向对象的思想，也写了很多的代码。但更多的时候我们是在纠结于代码的细节而不是面向对象。能用指定的java语言写出基本满足功能的程序交了作业就已经很纠结了，谁有功夫去管什么对象不对象呢。
现在的软工课，也是这种感觉。这学期的另外一门大作业，数据库，也是这样。
所以虽然编译的课程设计最难，但是做起来最舒服。因为只要想通了，就能写出来，你不会问自己：我的这个设想需要的一些东西语言支持不支持，因为你很清楚，这种语言能做什么，怎么做。
我们确实学了很多语言，必修有c，选修有c++，java，c#，ruby，但用的熟练的确实有限。
可能是我们的努力还不够吧。