软件工程(GZSD2015) 第二次作业小结

第二次作业，从4月7号开始，陆续开始提交作业。根据同学们提交的作业报告，相比第一次作业，已经有了巨大改变，大家开始有了完整的实践，对那些抽象的名词也开始有了直观的感受，这很好。然后有一些普遍存在的问题，在这里做一下小结，大家可以PK下各自的思考和想法。此处主要从几个方面说：

作业雷同、抄袭问题
排版和代码插入的问题
需求分析和设计太抽象，应该如何理解和实践的建议
手工测试和单元测试的区别，以及单元测试的使用等
作业反馈和迭代改进，做中学。

作业雷同问题

作业雷同的问题。对于作业，我希望大家一定要独立完成。这个独立在不同场合下意义不一样，比如是PSP训练里，那么独立应该是指自己一个人独立完成，如果是结对编程，那么独立应该有两层含义，一方面指代小组相对于其他小组的独立，另一方面指代小组里两个人要各自分工协作，不能编程一个人完全全部，另外一个人啥都没做。所有的作业我们都会看过去，谁在抄袭谁在独自完成，都是能看出来的，这方面请同学们自己注意。

排版和代码插入的问题

首先是排版和代码插入的问题。根据博客园后台编辑器的选择，有些同学使用可视化编辑器，有些同学选择使用MarkDown编辑器。一般来说学会了MarkDown排版的同学，插入代码都是没有问题的，这就是我推荐大家用MarkDown的原因，它既简洁，又排版效果好。而是用可视化编辑器的同学，排版一般也都还可以，只是有些同学可能对如何正确的插入代码不熟悉，所以插入的代码存在排版错乱、没有高亮、缩进不正确等等问题。所以这点上建议大家都改进。学会基本的排版技能对于你们以后的职业生涯都是一个重要的事情。

需求分析和设计太抽象，应该如何理解和实践的建议

其次是需求分析和设计的问题。这两个本身比较抽象，听上去都属于可做可不做的事情，这是神码东西呢:D。什么是需求分析？什么是设计？我想很多同学都是在代码做完了之后，为了写上这么两个环节，而拼凑出内容的。但另一方面，我又看到一些同学在分析和总结里说一开始看不懂题目，在经过A、B、C步骤之后终于搞明白题目要做什么。这个过程本身就是属于需求分析的一部分，软件开发过程中，需求分析是重要的一环，它本身就是要将不明确的、模糊的需求厘清、并写下来的，然后和目标（比如客户）达成一致的一个过程。设计，对于本次作业来说，可能最重要的就是关于代码如何实现的大致划分，比如要不要用函数？如果要，大致有哪些函数，整体又要怎样组合。再一个就是要做单元测试，那么可能首先要根据书上的例子、老师的课堂呈现、以及自己的查阅先搞明白单元测试是什么，有一个直观的认识。然后自己在设计函数、类、模块应该如何设计使得更易于做单元测试。此外，《构建之法》书中的wc程序也是一个很好的从基本需求、扩展需求、到高级需求分析的一个案例，当然这样的过程需要反复训练。

`手工测试`和`单元测试`的区别，以及`单元测试`的使用等

接着还是说测试。大部分同学都做了手工测试，就是把程序跑起来手工输入一个个答案，然后程序都跑对了，就算是做了测试。但这个和真正的单元测试是不一样的，这块希望大家能结合书上的例子，或者http://en.wikipedia.org/wiki/Unit_testing对这个页面的阅读，能有一个自己认识上的改变，可以将自己的理解写下来，写成博客。单元测试的目的是为了对软件的基本单元，比如函数，做各种边界条件测试或者语义测试。语义测试比较高阶，此处单说边界条件测试，很多人的作业里都对除法的被除数为0，或者除不尽的情况没考虑到，但是如有设计单元测试，则单元测试的测试用例就可以故意针对这种边界条件做测试，所以你在设计测试用例的过程中就实际上把问题考虑的更全面。再比如，有的同学用了goto语句，goto在现代结构化编程里是不推荐使用的，至于为什么，使用了goto语句的同学也可以自己把事后的查阅理解写下来，写成博客。我们说，如果你有了单元测试，那么，你在把goto语句去掉的过程中，就可以要求修改后的函数，通过之前设计的测试用例。这就属于回归测试。你也可以理解成回退测试，就是说我的函数的实现改变了，但是依然通过之前设计的那些测试用例。

作业反馈和迭代改进，`做中学`。

然后，我们说下迭代改进的问题。这次作业只有少数几个同学能对点评做反馈改进--意味着更多工作量。为什么应该要迭代改进呢？此处我要表扬下涂江凤同学，她的作业一开始用到了goto，我给了她点评，她就立刻抓紧时间去对代码做了改进，去掉了goto，并且自己去思考为什么不推荐用goto，这样她就从改进做学到了为什么，并且在博客里记录下了改进的结果，以及从中学到的东西，这就符合《构建之法》的核心理念做中学，通过在实践作业中发现问题，进而通过重新理解，重新看书，重新写代码等等过程中，去学到课程真正要传递给你的那些知识或者认知方法。涂同学看到了zhaoxiong关于代码写法改进以及函数注释的反馈后，就立刻对自己的函数做了详细的注释同时改进了自己的代码，排版风格良好，这样她就有了对代码规范和代码风格的一个初步认识，如果她这个时候重新去看《构建之法》里写代码风格和代码规范的章节，那么她就不再是觉的这是很抽象的东西，而是实实在在的切实有用的----写代码的过程中时刻要注意的。涂同学也把每次的修改增加到了PSP耗时统计里，这样她就能看到自己的每次改进的完整记录，包括解决的问题、提出的疑问、以及消耗的时间，这些都可以用在以后的过程中改进自己。这里的核心就是做中学，有迭代改进和无迭代改进，这是一个问题，请同学们也思考下。软件工程里，处处存在人与人之间的沟通和交流，快速的对点评或者建议做反馈，迭代改进，这样的行为它本身就是符合工程思维的，我想在这点上，如果能做到，那么至少是学到了工程的一个小小但非常重要的点。

大概就写这些，大家加油~。