《构建之法》第二周---个人技术开发流程，软件工程师的学习

前面章节的的回顾以及第二、三章的学习

第一章中有一段话我觉得我们应该记住：

哲学家的宗旨是：我思，故我在

科学家的宗旨是：我发现，故我在

工程师的宗旨是：我构建，故我在

对于工程，是因为构建所存在的，自顶向下地进行对工程的构建，由浅入深的解决问题。工程有工程理论，质量控制论等的问题。

软件工程的目标—创建“足够好”的软件，世界上并没有完美的的事物，同样的，软件工程也是。所谓好软件，就是软件没有缺陷，所谓软件工程，就是把软件中的bug都消灭掉的过程。Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠度和可维护性。由此发现，bug的影响还是挺大的，虽然它只是小虫子。

第二章讲的主要是个人技术和流程。即单元测试、回归测试、效能分析、个人软件开发流程。

以下简述以下好的单元测试的标准：

1. 单元测试应该在最基本的功能/参数上验证程序的正确性
2. 必须由最熟悉代码的人（程序的作者）来写
3. 测试过后，机器状态保持不变
4. 快
5. 应该产生可重复、一致的结果
6. 该覆盖所有的代码路径，然后，100%的覆盖率并不等同于100%的正确性
7. 应该集成到自动测试的框架中
8. 必须和产品代码一起保存和维护

单元测试可以用VSTS来进行，但是我们并不能一度为了单元测试的正确性而忽略了整个软件开发的完整性、可行性、有用性。单元测试中要注意修改类库中的代码。

在单元测试的基础上，我们就能够建立关于这一模块的回归测试。

在效能分析中，我们可以很清楚地知道哪一个函数占用的空间最大，被调用的次数最多、最频繁。那么影响整个程序时间的八九不离十就是它了，如果我们想让程序运行更快，那么可以对这个程序进行改进，使得它越来越符合我们的需求。例如课本上所举的例子，WordFrep程序处理一个30KB的文本文件时，

WordFrep.Frep.FrepOneword(string)

System.String.EqualsHelper(string,string)

System.Collecting.ArrayList.get_Item(int32)

这三个函数占用程序的时间最多，所以课本上也对这种情况进行了分析，通过进行代码注入的分析，结合实际的代码，可以看到上面那三个函数被调用的次数很多，耗时都很长，所以课本上也是对for（int i=0;i<m_wordList.Count;i++）被调用了1631884次，于是就应该对代码进行修改，改成int count=m_wordList.Count;

               For(int i=0;i<count;i++)

也就是进行“效能测试，分析，改进，再效能测试……”这一循环过程来让代码更加的符合需求。我觉得这也是我们在写程序时发现bug。分析，修改bug的循环过程。

第三章的内容是软件工程师的成长，主要讲述评价软件工程师水平的主要方法以及软件工程师的自我评估。

软件开发流程包块团队和个人的开发流程。软件开发，测试，用户界面设计，管理，交流等工作是被分配到团队中的个人来具体实现的，个人与个人之间是紧密联系的，这样，他们的软件才能实现一个整体。与足球队，篮球队等相比，这些战队之间都是有合作，有阵型，临场应变的，就像我们的软件也有可能会出现一些以前的没有发现的问题，这时候就考量一个软件工程师的实力以及临场应变能力了。每个篮球队员或是足球队员的都有命中率，出场数等属性，我认为软件工程师也有这样类似的属性，比如做过的项目数，解决的bug数和质量等，这些属性也就是可以衡量软件工程师的工作质量。看了课本上的初级软件工程师的成长后，我觉得我对软件工程师成长的理解是，从学习基础知识开始，慢慢地积累到一定程度时可以进行对软件设计思想和软件的结构的分析，从构建开始，而不是直接从代码入手。然后在达到一定程度后，提升职业技能，后面就是自己动手写一个比较实际的程序了。需要说明的是，从学习的第一步开始，就应该时刻不要忘记写代码，看代码，练代码，要把代码当做吃饭一样频繁的去做，要养成习惯，我觉得我现在代码还学不好就是没有养成每天都写代码的习惯，总是记得就写一两句，这是非常不对的。

以上就是我本周学习到的内容，是比较止于平面的，下周开始正式进入有效学习层次。