练习3——读《构建之法》1-5章

拜读完《构建之法》第一至五章，我了解了软件工程的重要性，它就像是一栋房屋的建设，是一项大工程，必须有工具，有能力，有计划才有可能实现这么一个工程。对于那些生硬的概念，书中举了形象生动的例子，很多都能让我们联想到自己日常生活，能很好的记忆和理解其中的奥妙。

第一章：概论

1)  在读此书之前，我一直以为当一个团队确定了负责一个项目之后，他们的成员不会再有所修改，会对所负责的项目负责到底。但实际上，软件团队是会流动的。为什么要有人员的流动呢？是出现了现有团队解决不了的技术困难，需要新技术新知识的支持，还是现有团队身担多职，需要人手帮忙？另外，不止是软件程序会有bug，团队也会有bug。处理好bug是创造“足够好”的软件的基础，但在校园学习过程中，我们常常会忽视bug，甚至把它留在最后处理。

 

2)  用户体验，很多时候我们会在软件商店下载各种功能相似的应用，比如，我们曾经下载过无数个背英语单词的app,而能留到最后的只有“百词斩”。软件的用户体验的好坏就在于他是否与同类型的软件比起来更好用。用户体验对一款软件的考验很大，市场上也有许多新开发的软件，这些软件有的一夜之间下载量飙升，有的却不了了之，也有的在一段时间内飙升后再被淘汰。比如像素鸟，前段时间很风靡，现在也逐渐退去光环。我觉得这也和用户体验有密切相关的关系，作为一款游戏，前一段时间因为游戏有难度而风靡，而后来听说有些大神通了关，但我相信大部分人都是没过几根柱子就game over了的。这样没有奖励又屡战屡败的游戏，用户大概也不太想要坚持玩下去。但游戏的有创意又容易上手，就是太容易game over。

 

3) ＡＰＩ到底是什么，和ｊａｖａ的ＡＰＩ一个意思吗？

百度百科解析：API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

 

4) “没有银弹”论断？

互动百科：没有银弹--是Fred Brooks在1987年所发表的一篇关于软件工程的经典论文。该论述中强调真正的银弹并不存在，而所谓的银弹则是指没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。

 

5) 书上提到了三种学院，讲解了计算机科学和软件工程的区别及其互助性，那软件学院和软件工程学院所学的是否有区别呢。

 

第二章：个人技术和流程

1) 个人编写模块时要有单元测试，毕竟最后的软件是由多人合作完成的。我们要确保我们所写的模块能被他人调用，并且代码清晰易懂，不影响其他模块。用vsts写单元测试我们没有接触过，看着书也印象不太深，它是否能测试所有的计算机语言呢。希望有时间实践操作一下。另外，对于单元测试自动化，什么是单元自动化，要怎么做呢。百度了也很晕。以及GitHub之前觉得它的图标很可爱，有去了解过，但是没看懂它能干嘛。

 

2) 原来使用for循环调用a.lenght;这些调用的获取数组长度的方法会增大时间复杂度。

 

第三章：软件工程师的成长

1) 对于一个软件工程师，个人能力尤为重要，如果能力不足，那么做什么都无从下手，甚至还会有负面影响。我一直以来都觉得现在所学的专业，出去工作顶多是个程序员，或者至少也要干几年才能是工程师，但看了课本，我觉得我们似乎可以成为一个初、中级的软件工程师。程序员与软件工程师之间有很大的区别，有人说，这种关系就像是民工和包工头的关系。程序员被指挥，工程师当指挥。也有人说只是名字好听点而已。我觉得，程序员主要就是负责成天按照上级发的任务编程，软件工程师呢，在一个项目里会有大量的建模、构思和设计。

 

2) 在学校，我们需要学的知识，语言太多了。往往给我们一种杂而不精的感觉，但是平时在校期间几乎是没有多余的时间去将所学知识学精的。这个时候，我们该怎么办？坐等毕业之后就职公司给我们培训吗？我觉得，参加比赛是对付学而不精的好方法，比赛会让你控制好你的每分每秒，也可以以比赛的形式逼着自己去学一些东西，若是得了奖，可以丰富简历，若是没得奖，那我们也从中学到了很多。重在参与。

 

3) 确实，像书上52页所描述。我们在平时的作业里，很多都是通过上网找资料得来的。因为有上网这个“好东西”，我们也没有体会到要去记牢一些最基本的事情。所以此后，我们也养成了习惯，一碰到不会的，马上百度，却从来不记住。当下次再遇到同样的问题时，我们可能还会再一次向百度伸出请求援助之手。此时，我也意识到问题的严重性了。某些低级的问题确实不值得我们一而再再而三地百度，这些最基本的东西本就该稳稳地沉淀在脑海里面，可以不经大脑就自然一气呵成。否则，你所精通的，其实都是别人的。

 

第四章：两人合作

1）在合作里面，代码风格要规范，命名，缩进等更不用说。看了这一章，我才知道一个注释要如何写才能让人通熟易懂。在平常的编程里，我的注释大多都是在变量名的后面，标注了该变量是什么。突然觉得这样的做法很傻逼逼，一个变量，其实要是命名得好，那么一眼就知道这个变量做了什么，根本无需注释。

 

2） p63--断言是什么？

百度曰：  编写代码时，我们总是会做出一些假设，断言就是用于在代码中捕捉这些假设。断言表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新启用断言。使用断言可以创建更稳定、品质更好且 不易于出错的代码。当需要在一个值为FALSE时中断当前操作的话，可以使用断言。单元测试必须使用断言（Junit/JunitX）。

我并不怎么明白，对于没有实践过，只有理论的新事物，我们通常都很迷糊，似懂非懂。当我们真正运用到了，再回去看这些概念，可能一切才恍然大悟。真的，我们需要学的“新”事物实在太多了。

 

3）在上一篇博客中，我们便是做了结对编程。感觉两个人做起事情来还是要比一个人轻松的，无论是编程上还是气氛上。但是我却无法想象，要是三个人，四个人…一个团队的人该如何合作。（也就是第五章的团队合作。）

 

第五章：团队和流程

1）看了很多软件团队的模式，有主治医生模式，明星模式，社区模式等等。以及功能团队模式，有官僚模式。开发流程有写了再改模式等。但是，可能是我拜读不深吧，看完还是么能理清团队如何合作，团队里的每一个人负责什么。要一起写需求设计吗？还是一部分人负责？有没有具体的例子可以帮助理解呢。一个公司开发一个大项目，要如何才能让一个软件团队有条不紊等工作，他们之间如何分工，如何把所有人所负责的部分整合成一个项目？