个人阅读作业——软件工程M1/M2的总结

临近学期末，本学期的软件工程课也已经结束了，在此我对软件工程课中，我们团队M1和M2开发阶段中，我做的工作做一个总结

我是DEV，主要工作是等着上级给我分配任务，但是很多时候如果这个活我不干，其他人就干了，导致我的贡献分就危险了，所以多数时候需要抢活干，主动点才有饭吃。

在M1阶段，我们多次开会，重点讨论了究竟要加什么功能。这是一个非常艰难的过程，因为爬虫软件的功能很明确就是爬取链接及其所有子链接，而这个功能已经被实现了，所以我们讨论的重点就是如何花式爬取网页。最后我们定下来，要实现多种爬取方式，比如关键字爬取等，同时还要对爬取到的各种数据做好管理工作，比如按热度排序等。

当然我们这个阶段犯了一个比较大的错误，由于我们的用户——下一个小组没有找我们强调他们的需求，导致我们蹭蹭蹭做出来之后，我们唯一的用户表示这东西不好用啊，我们还要爬ppt啊。虽然他们没说，但是应该做好用户需求分析的应该是我们，用户才是上帝，所以我们默默把这个锅接了。

具体的程序编写，我负责的模块还是比较顺利的，并且同时我也发现了链接传递时存在中文会变成乱码的问题，最后使用统一的UT8编码解决了这个问题。由于不太信任我们的TEST，所以我自己也对我自己的模块做了许多测试，确保基本功能无误才嵌入了代码。

M1阶段完成后，我们的爬虫软件也算功能众多了，看着我们做出来的软件，心里还是有点小激动的，尤其还是得到了老师的赞许。

在M2阶段，我们吸取了许多教训，比如提前询问了我们唯一的用户的需求，再三确认后才开始工作，确保完成我们唯一的上帝的要求。

M2阶段我主要负责修改网页的储存方式，因为之前是直接把文件命名为其uri的，这样存在许多问题，比如文件名过长无法在本地储存，存入数据库时会造成乱码等等。我一开始想通过将文件名做HASH函数处理后再储存的问题，后来放弃了这个想法，直接给每个网页分配一个唯一的ID，使用这个ID号作为文件名，很好地解决了这个问题。

同时我还协助修改了许多bug。

 

http://www.cnblogs.com/wyjbjl/p/4028189.html

这是以前提出问题的博客链接。

1.像这一类书籍，怎么阅读才更有效？

以我这几年看编程书籍的经验来说吧，我第一次看C++教程时，基本只是通读了全书。真正到要写代码时，还是没有什么概念。但是比如作
业要求我写具有某个功能的程序时，我再去翻编程书，这时边看边写，就基本可以记得下来。很多时候，当自己亲自去从头写程序时才会

2.命名规范为什么是加前缀？

其实现在我还是习惯于加后缀，比如tableA，它的数量我就喜欢命名为tableA_num，因为在使用CB,VS一些编程软件的时候，打出前缀就可
以自动找到对应的变量。加后缀时的逻辑一般是这样的，先是这个变量的“名字”，再是相应的“成员”，比如“tableA_num”表示的就是
“tableA”的“数量”，由于我喜欢先搞清楚这个东西“是谁的”，再搞清楚这个东西“是什么”，因此我喜欢使用加后缀的命名方式。
前缀表示的逻辑是这样的，先是这个变量的“成员”，再是相应的“变量”，比如“num_tableA”表示也是“tableA”的“数量”。这种命
名方式先搞清这个“是什么”，再搞清楚这个“是谁的”。这样做的好处就是，起码不会搞错这个变量的类型，后缀命名就比较容易随手一
点，点错了类型。（说的好像前缀不容易写错一样。。。算了相对不容易一些），我觉得这种命名规范在合作编程的时候只要约定一下不要
搞混了，都是可以的。

3.对于一个已经有一定规模的软件，增加功能重要还是精简功能重要?

在做过我们团队的项目后，我对这个问题也有了自己的体会，我们拿到学长的程序功能非常简单，就是一个网页爬虫，给链接，就会循环爬
取其所有子链接。这当然不能算一个有一定规模的软件，因此增加其可用性是非常重要的，我们加入了许多新功能，比如关键字爬取等等，
同时也砍掉了学长的许多功能，因为他们根本就没有被实现。如果一个模块无法完全实现既定的功能，那么容易造成冗余，还是去掉比较好
。

4.程序质量控制的重要性？

就我本人而言，我还是非常重视程序质量的控制的。由于本人比较粗心，每写完一段，我都喜欢再看上一遍，确保没有问题。但是同时来说
，过于重视程序的质量，容易失去编程的敏捷性。我个人是程序质量优于敏捷性的，程序当场写当场debug比较好，因为刚写出的代码自己
比较熟悉，也比较好改，时间久了就不好说了。

5.DEV要不要TEST自己的代码?还是一直专注于写?让专门的TEST来做?

最熟悉自己程序的肯定是编写者，当程序比较大时，比如这次的电梯程序，涉及到许多类之间的协调，那么测试者就会十分痛苦，因为他要
先搞清楚程序的运行机理，那我才能给出比较好的测试用例，出现bug时，debug人员也要先搞清楚程序的机理才能debug。如果是编写者，
输出的数据发生异常时，他比其他人更容易想到这个错误的原因，那么是不是当程序比较复杂不好测试不好debug时，由编写者自己来做一
部分测试工作？

上面是当时自己得出的答案，经过项目的开发后，我又有了一些新的体会。毕竟做项目是有工期的，如果时间比较充裕，为了减小工作量，
DEV大可不必进行TEST工作，而专门交给TEST去做，出了问题再解决。这样的好处就是每个人的工作量都比较小，毕竟人还是要休息的。但
是如果工期比较紧的话，那DEV还是要做一些基本的TEST的，毕竟最熟悉自己代码的肯定是自己，自己TEST肯定效率是最高的。

产生的新的问题：

由于我们的用户就是下一个小组，因此我们主要要满足他们的需求。而他们的需求是会变的，比如我们写好了这个功能给他们，他们用着用着发现需要的东西又多了出来，这时候又要找我们重新加功能。也就是说，用户的需求不固定。但是各个小组间的沟通又不够，再时间不够的情况下，容易产生下一组怪我们没有提供足够的功能，而我们又怪他们不早讲，这种情况。

需求/设计/实现/测试/发布/维护
需求阶段：需求是来自用户的，了解好用户才是需求阶段最重要的任务，需求分析及其重要！否则做完了东西发现功能不能满足用户的需求，那是要返工的。
设计阶段：我们是在学长的代码基础上进行修改的，学长没有提供文档，因此应该读代码，确定软件各个组成部分内的算法以及各部分的内部数据组织。
实现阶段：实现主要指编码实现，编码是我们的老本行了，要说学到了什么，主要是编码时要写好文档，注意规格吧。
测试阶段：测试应该做好单元测试，写好测试用例，保证覆盖到尽可能多的情况。
发布阶段：发布前要再三检查，确保万无一失再进行发布，再发布一次可是很伤的。
维护阶段：一个模块出了问题或是进行更新时，修改的时候要注意和他有关系的模块，注意是不是要同时修改。