第一章：概论
本章主要是讲了软件工程的基本概念，软件工程的最终目标是创造“足够好”的软件。
提出问题：什么是BUG？（出自1.2.5节）
答：就我个人而言，在许多游戏中也有许多的BUG，BUG这一词在网络游戏中属于高频率的词，中文意思就是“漏洞”，在游戏中这些BUG漏洞往往会带来给玩家很大的伤害，会造成游戏的不公平，游戏也是个大型的软件，所以一个游戏每个星期几乎都会进行维护更新，主要就是修复这些游戏里的BUG。而书中所说，BUG，简单地说是软件的行为和用户的期望值不一样，就叫BUG。通俗易懂，BUG会在一次次测试中出现，一个程序它可能是一个人写出来的，也可能是一个团队，或是更大的团队，即使如此，但当他投入市场给用户使用时，面对的就是更大的群体。人各自有各自的想法，在使用你的软件时就会有不一样的看法，就会产生BUG，所以我们编写软件的人或团队，要虚心地收集用户们的BUG，最后让做的软件更加地接近于用户的满意值，这样的软件才能做的长久。
第二章：个人技术和流程
提出问题：什么是单元测试？（出自2.1.1节）
答：在我看来，测试是一个软件必不可少的环节，而单元测试我初步理解是设置一个适用于“一个问题”的测试方法，即这个方法适用于你输入各种数据，测试是否符合标准。我曾在深圳一家外企“昱科环球”里做过一个多月的暑假工，在里面我是做操作员。这个公司是做计算机硬件的公司，主要是做存储数据的碟片（西部数据），而操作员也有着很多不同的分工，一个空磁片要经过拆封，清洗，润油，打磨，紫外线照射，测试，包装。每个环节都需要学习了相应知识的操作员，而我恰好被分配到了测试的环节，其中测试的环节是最为重要的，这决定了一个磁片是否能达到正常的指标才能包装销售。每个操作员都要经过一个星期的学习进行考核后才能有资格进行操作。在测试环节中是一台台机器在进行测试碟片，整个无尘操作间几乎90%以上是机器在运转，当然机器也是人做的，每台机器都有两台电脑，每个进来的碟片都要进过物理测试（Glad）和性能测试（Mag），符合规定的指标才能出厂。我认为每台机器就像是个单元测试。而我觉得软件的单元测试虽然没有这么大型的机器，但性质是差不多的。
在百度上找到了官方的定义如下:
单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
第三章：软件工程师的成长
提出问题：现在的我具备了一个软件工程师的能力了吗?（出自3.1节）
答：衡量自己的能力是成长非常重要的过程，人要有自知知名“知己知彼方能百战百胜”。现在的我若像书中扭魔方的例子，觉得自己还在第一层，还在基础层，现在的我基础还不是很牢固，所以要更加努力地打好基础，为以后人生的道路做好铺垫。所以，现在的我显然是还不具备一个软件工程师德能力的。
第四章：两人合作
提出问题：如何在两人合作中提高工作效率？（出自4.6节）
答：在练习二中，我与我的小伙伴进行了结对编程，收获了挺多。一开始，两人要提出各自的看法，互相尊重对方的建议，写出初步的方案（像书中的萌芽阶段）；之后在写代码的过程中会出现意见分歧，要控制好自己的情绪，把各自的意见进行比较，或者结合两人的意见提出新的思路（像书中的磨合阶段）。最后在程序敲完之后会要进行测试，一些代码格式的规范，漏洞问题，或是新的idea，都可以在这一阶段加入进去（规范阶段），最后完成程序（创造阶段）。做好这四个环节，我相信能很有效地提高两人合作的工作效率。在两人合作的过程中，我很享受其中的过程，乐在其中。所以，有个好心态去做事情也是不错的。
第五章：团队和流程
提出问题：团队软件开发是用什么模式好呢？（出自5.2节）
答：书中提供了很多模式，有窝蜂模式，主治医师模式，明星模式，社区模式，业余剧团模式，秘密团队，特工团队，交响乐模式，爵士乐模式，功能团队模式，官僚模式等等。那么多的模式让我很困惑，如何选择相应的模式才能使团队开发顺利的进行呢？他们在不同的模式中又是如何分工的呢？