读小学的时候，老师就告诉我们，每读一篇文章或者一本书都要有自己的感想，要有自己的想法。在这个光怪陆离的社会中，我们总是沉浸于高速的网络信息中，我们总是惊讶于每时每刻的新鲜事物，却忘了最原始的、最正宗的课本。 高尔基曾说：“书是人类进步的阶梯。”。能够在自己有限的时间里学到尽可能多的知识是好事，我们总是抱怨课本上的知识是有限的，企图从其他渠道来获得更多，却往往忘记了最根本的东西。似乎有点偏题了，但我在读书的过程中真的感悟了很多，纸质版的书没有电子版的书携带方便跟环保，但每次看到它的时候总能提醒我看它，它就像一个朋友，每晚在熄灯后还能陪我一起学习。
读第一章的时候，我最先学到的，就是不断地根据需求分析去完善自己的程序。还记得那个时候老师让我们自己注册一个属于自己的博客，然后让我们写一个能够自动生成四则运算的程序。在第一章的1.1.1中，阿超不断地根据“客户”的要求的要求完善自己的程序，我们可以看出，每一个软件服务都是由一个个应用软件扩展而来的，而每一个应用软件都是由一个个简单的小程序组合而成，每一个小程序的根本，就是一行行熟悉的代码。那么，问题来了，既然我们要不断地根据客户的需求来编写程序，那我们平时写的代码在今后如若遇到不同需求的时候几变成了一些废弃的资料，不能再重复使用了吗？那么代码的意义又将失去了，我们创造了它却又抛弃了它，正如抛弃了自己的孩子一般，创造它又有何意义啊？
想到这里，我翻开了第二章。第二章讲的是个人技术和流程，最吸引我的一句话是：“你的RP是由你的程序质量决定的。”这让我发现好的单元测试才能准确、快速地保证程序基本模块的正确性。好的程序总是要在最低的功能上验证程序的正确性，正如很多软件他们的源代码是在最低的版本上编写的，便是为了能够在任意版本上兼容。虽然在功能上可能会比较不方便，但很多地解决了兼容问题，毕竟现在科技高速发展，人们总不能预计信息发展的速率，因此，在最低的功能上验证程序的正确性是最明智的决定。此外，好的单元测试必须由代码作者来写，这样才能够保证程序在测试的过程中有相对性。转而到回归测试，我们在验证心的代码的时候改正了自身的缺陷，同时也需要验证新的代码有没有破坏模块的现有功能。在修复bug的同时，也应当要注意做容错处理，这样才能做出一个好的程序。对于第二章，我没有针对于哪一节的问题，只是觉得整体都是在讲一些很理论很实际的东西，作者用不同的视角来演绎不同的人物性格，告诉我们个人技术和流程应该注意哪些细节，只有不断测试，不断完善，才能做出更好的软件。
之于第三章，我觉得让我感受到的更多的就是要坚持。写代码与唱歌跳舞写作一般，都是一门艺术，都是一门让我们一辈子都可以为之感兴趣的艺术。我在写代码的时候，我总是喜欢根据以前自己在学java或者c的时候积累下来的一些小程序，然后根据自己想实现的功能加以改进，修改成自己想要的那一系列的程序源代码。在我眼里 ，程序都是一样的，都是通用的，没有好程序与坏程序之分。在每一个程序员精心编辑下，每一段程序代码都有它独特的意义。可以说，编程的过程本身就是一门艺术。在3.3中，笔者谈到一个人从五年级到成长后的魔方“技能”的变化，这个例子告诉我们，没有成熟的技术，往往会达不到需求分析，但在3.2中，我们可以看出，一个程序所需要的技能并没有多少，我们何必要浪费那么多的时间去读计算机专业，直接去参加Java编程培训班不是更快，学费与学时都会相应减少，效率说不定还会加倍。所以我觉得，这是一个严肃而又认真的问题，它让我思考为什么要读大学。
转而到第四章。还记得那个时候助教先生给我们出了一个结对编程的题目，让我们跟我们的小伙伴一起结对编写一个带界面的四则运算程序。书上有一句话我记得特别清楚：“没有'我的代码'、'你的代码'或‘他/她的代码'，只有'我们的代码'。”结对编程，让我们变得更加团结。在编写程序的时候，是没有导航员与驾驶员之分的，每个人都可以提出自己的想法，只为能够完成更好的代码。我们在学习正确的给予反馈的过程中，也收获到了最真诚的信息，朋友，总是在最困难的时候出现在你身边帮助你的人。在这一章中我学会到的是如何跟队友合作，在分歧中更快地达到共识，把我们各自的长处集中在一起然后改进其他缺点跟不足。有人说：“选队友是至关重要的。”那我们在选择队友的时候应当要怎么考虑呢？强强联合？还是以优带弱？是否可以详细解说一下应当如何选择自己的队友？
第五章依旧是讲关于“团结”的内容，只是由两个人扩展到一个团队。看完这一章，我得出的结论是：团队跟个人的关系——团队是由个人组成的，个人离不开团队，团队又依赖于个人，个人与团队是相互依存的两个实体。每个人都有每个人的优点，取每个人的长处，改进每个人的短处，这样就可以更快地做出更好的程序了。想到这里，我的嘴角不禁微微一翘，我的队友总是那么的给力，我们之间没有水平上的差异之分，只有越来越勤奋，然后在不断地磨合中一点点的进步。在5.3的开发流程中，我注意到了瀑布模型，这是最原始的编程模式，在最初就确定好需求分析后对于以后的编程就会有一个明确的目标。但是时代在变，信息在变，我们的需求也在变，这个时候我们就由最初的瀑布模型变形发展成了圆形模型，在这个模型中我们可以随时根据客户的要求更改需求分析，并编写出更符合时代需求的程序。但在这里，我有一个疑问，瀑布模型跟圆形模型都有它的特点——瀑布模型需求明确但不实用，圆形模型实用但需求分析不明——我们应当怎样选择不同的开发流程才能开发出适应时代的软件呢？
读完了《现代软件工程——构建之法》的第1~5章后，我有许多感想，笨拙的文笔总是不能很好的诠释内心的想法（请原谅我是理科生），但愿在接下来的时间里，能够在良师益友的支持下学习到更多的知识，开发出更好的软件，做一个合格的程序员。Everybody，come on！