时至今日，我已经读完了《构建之法》这本书，当然对于软件工程方面也有了更深的了解，邹欣老师这本书，真的给我带来了不一样的感受与收获，邹欣老师的书写的并不像一般课本那样死板，不想大多数的软件工程的书那样只有一夜夜的空洞概念和一段段无味的文字，《构建之法》这书打破了常规，将软件工程的知识与有趣的实例很好的相结合。书的内容从介绍“软件=程序+软件工程”开始，先是个人编程再到两人合作及团队合作。也讲了软件工程的方方面面，如需求分析、设计实现、测试等。其中给我印象最深刻的便是关于代码规范那一章节的阅读学习，因为这点是我们总在使用，总在犯错误，而不曾注意到的地方。软件发展产生的过程离不开人，程序员及用户是这过程中重要的参与者。我们要好哈的学习软件工程。
最后，在阅读计划中我曾提出如下问题：http://www.cnblogs.com/qizhonh/p/5246742.html
1.Github是如何运行供我们使用的？
所以不是程序猿可以用这个来做什么呢？Do whatever you want.
②写文档神器 身为科研狗、产品狗、射鸡湿的你，是不是经常写文档？一个成熟的文档可能会有好几个版本，需要不断地迭代，然后不断提交给老板看哪里需要修改。在不同版本间自如切换就要用到git branch和git rebase了。 想想看，用 git 的分支管理不比拷贝粘贴更方便吗？
③健身 有个哥们为了激励自己健身把每日计划都放上去了，还可以邀请其他人一起来相互监督！（我才不会说我自己也开了一个呢哈哈哈） hoosin/EveryDaySport · GitHub
④找男票 没错，看这个项目！利用众包的形式一起罗列男友条件的 list 然后试图自己开发出一个男票233333 YixuanFranco/YourBoyfriend · GitHub 有人评论问我用这个找到男票了吗？ 统一回复： 并！没！有！
⑤用GitHub搭建博客、个人网站或者公司官网
一个有自己域名的独立博客，是不是很帅？！
GitHub本身提供免费的托管服务，又提供了贴心的 Pages 功能，可以绑定你自己的域名，免费、高效、不限流量，做一个个人页面绰绰有余。
Jekyll 的教程和我自己的博客会稍后放出。。（先给自己挖个坑）
⑥用GitHub协作翻译
苹果官方发布的各种官方手册，比如最近开源的 Swift numbbbbb/the-swift-programming-language-in-chinese · GitHub 就是国内一个自发组织起来的团队，30多个人用9天时间即将翻译和校对工作全部完成，他们每人都还有自己的事情，上班、上线、创业，这么大的工作量在以往简直是不可能完成的任务！
⑦项目管理
GitHub最初是为了开发的管理而生，当然也就具备了项目管理的潜质，特别是与开发密切联系的项目中，它的优势尽显。比如这篇文章介绍了如何使用GitHub结合 Trello 等其它工具进行项目管理：使用GitHub进行团队合作。当然，GitHub还是很偏重开发的管理，一般的项目管理还是适合使用 wortile 之类的产品。
⑧ 府文件？ 之前看到一个知乎回答说：日本政府把宪法放上去了，德国政府也做过类似的事：German Federal Law Now on GitHub。除了德日之外，英美在 GitHub 上也有很多公众服务：英国政府多达 10 页的项目目录：Government Digital Service · GitHub 其中很多是政府项目的源代码或者设计原则之类。芝加哥的公开地理信息：Forking your CityNew York Open City： City of New York 路 （原谅我找不到这个回答了，欢迎补充）⑨科研项目及数据 较早的arXiv、PLoS之外，较有气象的可以推荐mendeley、开放期刊目录 教育方面： ⑩个人简历
GitHub上的代码无法造假，也容易通过你关注的项目来了解你的知识面的宽度与深度。现在越来越多知名公司活跃在GitHub，发布开源库并招募各类人才，例如：Facebook、Twitter、Yahoo ...
开始有了第三方网站提供基于GitHub的人才招聘服务，例如：
- GitHire:通过它，可以找出你所在地区的程序员。
- Gitalytics.com：通过它，能评估某位程序员在GitHub、LinkedIn、StackOverflow、hackernews等多个网站的影响力。
⑪设计资源库（重点来了！！！） 做 ppt 不知道到哪里去找高质量美图？ 最近半年初入设计圈，收集了不少 bookmark 想在年底来一个总结。 于是自己创建了这个Design- Resource List 项目，旨在让更多的设计师找资源变得有章可循。
2.如何理解源代码不是软件本身？
完整的计算机系统由两部分组成，即计算机的硬件系统和软件系统。
计算机软件(computer software)指计算机系统中除硬件以外的所有事物，一般包括计算机程序、程序说明以及其他资料等。
软件的正确含义应该是:
(1)运行时，能够提供所要求功能和性能的指令或计算机程序集合。
(2)程序能够满意地处理信息的数据结构。
(3)描述程序功能需求以及程序如何操作和使用所要求的文档。
软件具有与硬件不同的特点:
(1)表现形式不同
硬件有形，有色，有味，看得见，摸得着，闻得到。而软件无形，无色，无味，看不见，摸不着，闻不到。软件大多存在人们的脑袋里或纸面上，它的正确与否，是好是坏，一直要到程序在机器上运行才能知道。这就给设计、生产和管理带来许多困难。
(2)生产方式不同
软件是开发，是人的智力的高度发挥，不是传统意义上的硬件制造。尽管软件开发与硬件制造之间有许多共同点，但这两种活动是根本不同的。
(3)要求不同
硬件产品允许有误差，而软件产品却不允许有误差。
(4)维护不同
硬件是要用旧用坏的，在理论上，软件是不会用旧用坏的，但在实际上，软件也会变旧变坏。因为在软件的整个生存期中，一直处于改变(维护)状态。
所以软件不仅仅指的就是源代码。
3.响应变化是否真的比遵循计划重要？
响应变化当然要比遵循计划要重要。
进行过敏捷的团队都了解用户故事，用户故事是在迭代计划中团队承诺的 feature，并会对用户故事进行故事拆分和工时评估。并且，Scrum 迭代规定 Sprint 冲刺中不要打断或更改团队冲刺的故事。
但是，大多数团队在进行中很快就变成是小迭代中的小瀑布！团队在计划会议中被要求完成多少个故事，大多数情况缺少前期调研和整理，任务拆分不是按照过程拆分（调研、设计、开发、测试），就是纵向拆分（页面开发、逻辑层开发、接口开发）等。基本感觉就是要完成这些故事，了解个大基本，很多细节还要到迭代中进行梳理和整理。
这时，如果你面临的第一个问题就是，如何保证在迭代内完成承诺的用户故事？
如果你是这样做的：为了保证完成，开始制定计划时间表和里程碑，为了在开始在迭代前梳理清楚需求，要求有 PRD，并在迭代中规定不要轻易改变迭代内容等，那么，你就真的将敏捷变成了小瀑布了。也许你会说，故事拆分就是为了定义边界，让我们知道在迭代中做什么故事。还有燃尽图，就是要按照计划的速度进行开发。
这样做，你就真的理解错了敏捷的含义！你做的就真的不是敏捷！
4.MVP与MBP各有优劣，为何不将二者结合着来？
他们能互相弥补，各有不同的优势和劣势，但是所存在的环境是不同的。
5.书中写到应该不断的修改维护重构，可是这样加大的风险和工作量要如何解决？
首先不断地修改维护重构，而加大的风险和工作量是不可避免，我既然要开发出一款合乎用户心意并且适应当时社会发展等的软件，就一定会经历不断地修改，不停的维护，一次又一次的重构，而我们能做到的就是把损失最小化，利益最大化。