《构建之法》读书笔记

应该是从上周六开始看这本书，起因是其他人发的一张书中内容截图。作者讲到技能的反面中的总结部分——如何考察一个人是否精通魔方：a.给面试者一个各面打乱颜色的魔方;b.要求他把六面还原;c.如果还原了，要求他把魔方恢复成我最初给他的那个混乱的局面，必须一模一样。

 

看到这些，最近自己也在思考这个问题，自己学习一样东西如何才是真正的掌握了？本书作者是微软员工，也是一名比较有名的程序员，这种检测是否精通魔方的方法给我耳目一新，接下来的学习中可以这样去思考问题。

 

本书名叫《构建之法》，其实是讲述软件工程课程的教材。自己应该在大三也会有这一门课，不知道会上成什么样……前面几个章节看的比较仔细，团队运作模式之类的只是翻过一遍而已。现在对于这些不是很感兴趣。

 

总体来说，收获还是比较大的，也更新了自己的某些观念。比如作者在书中提出1/N的打分体系，第一档满分，第二档的一半，第三档得三分之一。

 

可以让想学习的学生知道如何努力，想混的也知道怎样才能混过去，不想上的也会知难而退。现在学校的打分体系确实差劲，很需要往这方面靠近。更重要的是给学生Natural critical learning environment，当然对自己学校来讲，要求有点过了。还有评价人的三种层次：行为和后果、习惯和动机、本质和固有性。

 

接下来是对编程的一些帮助，最重要的是“代码写出来是给人看的，而不是机器”。所以有了代码风格规范和代码设计规范。对于我自己来讲，体现在编程时的格式和变量名，格式可以靠自动对齐，和将复杂的功能用函数来实现，变量名可以采用英文缩写之类的，最重要不要出现什么拼音说些。代码设计规范怎是考验编程能力了，这需要多写。最后是注释的原则，解释程序做什么和为什么这样做以及特别注意的地方。当然错误的注释比没有注释更麻烦。

 

最后是团队模式，现在自己学校里要求团队合作时，真心觉得还是自己一个人做方便，很难找到已经合适的人，自己又不喜欢协调沟通。不过书中讲的那么多规则，映象最深的是团队合作项目转组活动，这点目前没有经历过。其次是修改或维护前几届项目的原则，现在自己的作业，很多连样例都没有给你展示，更别说修改了，每次都要自己重新开始做。这也无可厚非吧。书中还讲到，结对编程，自己目前的体会是，几个人交流可以相互学习和传递经验，分享知识，不过某种程度也减少了探索的乐趣。书中补充了，带来更多满足感，更好的设计质量和代码质量之类的优势。

 

彩蛋：It's not a bug .it's a feature.

 

本书适合高年级之后，再来仔细研读。