程序员的基本修炼——读《构建之法》

博客地址：http://kbiao.me/wordpress/read-build-to-win/
附带邹欣老师博客地址：http://www.cnblogs.com/xinz/p/4470424.html
学习软件，我一直有个想法就是毕业之后可以带着自己的一个完整的作品去找工作。但是一个完整的作品应该是什么样子的呢？我自己心中的概念也是模棱两可。但是很清楚的一点就是，和我们每个学期完成的大作业是有很大不同的。课上学习的软件工程，一学期下来只是记住了一些高大上的词汇，知识也很难落地。有幸朋友推荐了《构建之法》一书。让我对自己的问题有了一个比较明确的答案。

课堂上的软件工程总是在理论层面探讨设计模式，需求分析，编码实现等等，而现实中往往不是这样。最起码的一点，一个完整可用的软件用户不只是给你打分的老师一人，作者也很少是个人。所以在大作业中积累的经验很难落实到实际的化境中。现实中，往往是有一群水平参差不齐的人组成的团队，要从用户那里，要从生活中，从相关技术进步中，从超前的设想中……挖掘需求，提出需求，解决需求。现代的软件工程已经远远超出了我们大作业般的玩具阶段，而是一个成熟的产业。要想在现实的环境中拿出成绩，必须从根本上树立正确的软件工程的概念。
既然称之为工程，必然不是一个码农安心Coding就够了，如同一栋只有泥瓦匠是不行的。软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。首先提醒我们认识软件要从一个高度上去看，不能只是拘泥于具体代码这个层面。这便是我们学生党的问题所在，经常是没有多少实际经验的情况下去上软件工程相关课程，尽是理论觉得虚无缥缈。记住的一些概念做大作业的用不上，所以学完也就还给老师了。而《构建之法》这本书从一个独特的视角，以我们学生可以明白的方式讲清楚了软件开发的流程，真正启发我们思考，把概念定义理论落实到项目的实践中去。

---

个人技术和流程

书中有个例子给我留下的映像非常深刻，说的是玩魔方。

大概在我小学五年级的时候，大家开始玩魔方，我们家也买了一个。我和几个小孩折腾了一会，没搞出什么名堂。我哥哥却很快弄出一面一样的颜色。后来我也琢磨出来了这一步。再后来我才知道魔方有一些模式和一些口诀，按图索骥，依口诀而行，就会从一面玩到一面再加一层，再到加两层，然后把最上层四个角的颜色搞对，然后再按照一两个口诀翻十几下，六面就做好了！我玩着玩着，就把各种模式和口诀都掌握了。上初中的时候，我还在课间表演过，赢得一些男同学的好评，
女同学似乎对此不感兴趣。要在当时，我的简历一定会在“技能”一栏写上：
“精通玩魔方。”
后来我就不玩魔方了，这样过了好多年。不久前我在一个实习生的桌上又看到了魔方。我拿起来，似乎不用想，当年的口诀就在手上。转啊转，一面，一层，两层，那个男实习生露出崇拜的目光……直到最上一层，嗯，口诀是什么来着？我试了几种可能，好像都不行。我看到周围的女实习生似乎不感兴趣，那就算了吧。
看来我的简历要改写成：
“精通玩魔方，只到第二层。”
后来我想，把第二层拼好，我只知道找到某个模式，按照某个口诀执行即可。但是我并不了解为什么这个口诀能把第二层拼好，同时又不打乱第一层的结果。我更不知道如果在执行中走错了几步，如何随机应变，挽回局面。离开了口诀的话，我只能把魔方的一面拼出来。从这点来看，我的魔方技能应该是：
“能够独立地还原一面，其他看口诀可搞定。”

从这里我开始思考自己的能力以及问题所在。曾经觉得自己会网页制作，还会安卓的移动开发，也写过桌面程序，也玩过嵌入式开发板。但是，真的就是这样么？了解、掌握、精通这几个关键词走到了哪一步？这么多的只是技能都停留在了解的层面的时候还有多少可以值得骄傲的呢？
对于学校的考试来讲，了解足以应付考试。但是作为一个科班出生的软件工程师来讲是远远不够的，我们要经过尝试——了解——入门——熟练——变化——创造，一步步深入技术的核心，真正提高自己的实力以求在技术日新月异的时代扎稳自己的根基，不能坐进观天，自以为是。

两人合作

当我们在自己一个人完成大作业的时候，不用说代码规范，基本的面向对象的思想不遵守也是没有大问题的。公有私有受保护的属性方法，都是我自己写成的，自己知道即可，自己写的程序里一般是出不了乱子的。然而当我们进入公司，几乎不可能由我们独自开启一个新项目。大部分工作是从维护别人的代码开始。当我们有阅读别人代码需要时候就会理解代码规范，代码风格并不是教科书的教条主义，而是有切实的价值。曾经有段时间为了参加一个比赛便和我的小伙伴有过一段两人合作的经历，不算很成功但是积累了很多重要的经验。从交流，磨合到一步步规范代码，最终完成需求，这个过程需要的不单单是编码的基本功，还需要沟通交流的技巧。这本书的部分段落里我看到我了我在工商管理课上组织行为学的身影。两人合作的过程对自己的提高是非常明显的，两人互相约束共同进步，最后作品的质量也会高于一人单打独斗的结果。

团队

两人合作之后，随着项目升级，我们有可能要进入团队的合作模式。我当过班长，做过学生工作，也看过爸爸管理公司团队，接触过不同的团队之后对书中的团队章节感触很深。不同的团队有不同的合作模式，都是基于团队成员的实际情况去规划部署，没有哪个万能的团队方案可以保证结果。有了团队之后，才可以涉及团队流程。也正是因为我们学生往往只有大作业的经验，在老师谈瀑布模型，敏捷流程等的时候才会无感。 当我们真正身处一个团队项目中时，自己当初不在意的问题往往就成了阻碍项目进度的关键。这本书的五、六、七三章提到了多种团队项目的协作方案和理论，让我也逐渐理解放假前不到两周的实习中遇到的种种问题。

其他

书中强调一个“做中学”的理念，与我的想法非常接近。我曾在大一学完了C就开始接触安卓开发。按照学校的，或者惯常的学习路径一定要从JAVA开始，然后学习很多相关知识，逐步进入安卓的世界。但是想着这一套流程下来我也就得毕业了。事实证明，带着目的性驱动学习往往更加高效。开始一定会有各种奇奇怪怪的问题，因为学习的跨度有些大。但是正是这些问题驱动自己去探索发现，自己总结出来的经验比树上直接给出的定义能让自己理解的更加深刻。边做边学，问题驱动。能让自己学的更扎实也更快。当然学习了一段时间安卓后我还是退回去老老实实的扎实JAVA基础，但是回过头来看的时候书上讲的概念定义就很顺理成章，每个知识点都会有种醍醐灌顶的感觉。软件工程本就是工科，强调动手，这些理论知识也是时间经验的积累，所以边做边学，不断去尝试更大的项目，获取更多的理解。有了一定的高度再去回望一路踩过的坑，会有不一样的体会。

---

我理解的软件工程是：利用合适的工具、手段、方法快速、高质量地完成软件开发的过程。而我们学过的软件工程都是自顶向下的，从需求分析、设计、开发、测试到最后的交付。当年在学习软件工程这门课的时候，根本就没有任何编程经验，所以那些理论知识很难理解的很透彻。在《构建之法》中恰恰是按照最容易理解的步骤，从开发测试、开发人员成长、团队管理一直讲到需求分析、设计以及用户体验等。先让我们知道开发为何物，每个人都有了编码实践的经验后再一步步到需求分析、设计就会理解的更透彻。一本好书除了本身的内容外，还需要能引发读者思考，能够学习到更多的扩展知识。记得之前网上有人回答怎样找到一本好的技术书时说过：
“在一本经典的书籍上找找所参考的书籍或引用的书籍，大致都还不错。”我认为还是挺有道理的。《构建之法》的正文以及练习与讨论中有大量有价值的引用，这些内容可以让我们了解更多更广的知识，练习中大量的习题如果都能够独立思考并想办法解决的话，对我们的实际动手能力会有很大提升。

这是一本产生于实践并应用于实践的好书，书中后一半详细的讲解了软件的需求分析，项目管理，设计实现，测试等全面的内容。把软件放在市场竞争环境下去衡量，这才是我所期待的一个“完整的项目”的意义所在。我相信在新的学期里我逐步有能力一点点实现自己的梦想，感谢这本书让我看到了通向自己梦想的道路。
好书，值得每个软件工程的学生常伴手边细读。