标签：
个人阅读作业3
〇、链接
1.阅读书籍中不理解的问题：http://www.cnblogs.com/baitrsou/p/4025461.html
2.个人阅读作业2:http://www.cnblogs.com/baitrsou/p/4093791.html
一、关于之前遇到的问题：
1. 关于把握发布软件时，如何平衡发布时间与剩余bug的量的问题，经过这一个学期的实践，我的想法如下：
在软件设计的需求分析阶段，就应该根据自己软件的功能、适用人群等，确定一个软件的有效时间，根据这个时间来确定一个最晚的发布时间，即无论软件开发进行到何种程度，都要进行发布，除非这个软件还完全没有实现预期的功能。否则，再晚发布，这个软件的意义就不大了。在我看来，任何存在的bug都不能对功能有很大的影响。对于没有这类bug的软件，则在适当的时间，就可以考虑发布了。这些bug可以在后续通过更新的方式修复。
2.对于测试中的重复测试问题，我还是没有一个很好地理解。我现在的大致想法是可以先进行整体的功能测试，整体测试尽量照顾多的分支。或者从最小的功能模块，如一个函数\方法，或对一个类的功能进行测试，测试完成后，则暂时认为这个方法或类是正确的，在调用他的模块中测试时可以不必考虑这个方法或类的问题。如出现错误，则认为是当前模块的错误，与被调用的模块无关。
3.对于测试中使用随机数的方法，我还是认为使用随机数的测试方式也是可行的，而且，随机数的测试方式可以测试到一些认为构造测试点所难以想到的边界数据，这对于测试中发现软件的bug是很有好处的，只要每次都记录下来测试的数据也可以很好地恢复错误现场。
4.关于如何合理估计每人所需时间的问题，经过团队开发的alpha和beta阶段，我的感想是，每个人之间的能力差异、以及每个人的惰性的确是一个不可忽略的问题。将同一件工作交给不同的人去完成，有的人可能经过几个小时就可能能完成，而有的人所需时间可能是正无穷。而对于每个人而言，对自己能力的估计一般比别人更准确一些，所以，我认为在分配完工作之后，可以让当事人自己估计自己的所需时间，而不是由PM一个人估计所有人的时间。如果PM认为某人的估计时间太离谱，则可以重新估计，或者改变任务分配方式。
5.至于在分工之后，每个人各自实现自己的部分，导致合并代码时难度较大的问题。经过老师的讲解，和开发的实践，我觉得最好的解决方案应该就属scum meeting了。每经过一段时间的开发，就进行一次讨论，以及时发现自己暴露给其他人的接口的问题，并及时修正。不仅如此，PM在分配工作时也应该很好地考虑这个问题，最好能有一个负责搭建软件架构的人，在工程开始时就能确定好每个人的接口，以减少合并代码时的难度。
就用我们组在开发过程中遇到的问题来说。在整个阶段中，我们最大的问题一直是网络连接，之前无论怎么尝试，服务器的返回值永远是403。这导致后台完全不知服务器返回的数据的格式，因而也就更无法确定反馈给前端的数据格式。所以，负责前端的同学只能完全按照自己的想法设计界面，在最后完成了后台的网络连接之后，发现前端需要改动的地方很多，比如当时费了不少劲才做好的注册页面由于移动设备的服务器端根本没有这个接口，所以根本不需要也不可能在自己的程序中实现，而是只能提供一个链接跳转到浏览器注册。
二、遇到的新问题
1．团队人员的积极性问题：作为一个全部由新手组成的开发团队，对于一个项目，所有人都是陌生的，几乎都是从零开始学习。加上成员间的能力不同，可能能力稍微弱一点的成员，就会萌生我不干总会有人干的想法。最终导致好多人的一个项目，只有可能不到一半甚至更少的人在完成。如何能让所有人都动起来，齐心协力去完成是一个很大的问题。
2．关于老师所说的团队离开任何人都必须能继续开展工作，在现实中感觉很困难。鉴于第1个问题所提到的情况，如果是一个对团队贡献度较低的人的离开可能对团队没什么影响，而如果是最主力的成员离开（例如实质上的PM）很可能导致一个项目的彻底失败。因而个人认为如何能让剩下人继续完成工作是一件很难的事。
3．如何能更充分地估计可能遇到的困难？就我们的开发过程而言，在这次的开发过程中，本来觉得只要网络连通，后续问题都好解决。但当我们进行到数据处理以及前后台合并时，又遇到了各种困难，例如起初不知道安卓中调用httpclient等连接网络，必须在一个新的线程中进行；怎样将服务器返回的以String类型存储的数据转换成一个JSON类型数据；如何设置缓存，使得本机的视频播放器能实现从网上直接观看视频，而不需要下载；如何动态在grid布局中的ImageView中动态加载图片等等。我希望知道怎么能在项目开始时，尽可能多的发现或预判可能出现的困难。
三、新的体会
1．对于大泥球问题，我有些新的体会。鉴于我们团队中的每个人都是完全没有开发经验的。对于代码的规范做的很不够，在实现的时候，发现能重用的部分就毫不犹豫的复制粘贴，导致代码中各部分的嵌套层数相当多，当一个人完成自己的代码后，其他人想要对其修改会非常的困难。
2．对于大教堂以及集市的方法，我还是倾向于大教堂方法。因为就我个人而言，在我专心想自己的实现方案时，很不喜欢被人的指手画脚，尤其是被对项目完全不了解的人说三道四，影响自己的思路。所以，我觉得在代码完全完成之后再公开可以很好地保证每个程序员按照各自的思路顺利进行工作，而不会被打断思路。
3．关于瀑布模型，经过这段时间的实践，我认为这种方法是很好的。但是对于一个全新的团队而言，要做到这个多少有些困难。作为新人，要准确的做好制定计划、需求分析、软件设计、程序编写、软件测试和运行维护这六个步骤实在不易。也就是说难以避免回过头来重新执行前一步骤，有点类似一个带回溯的递归下降算法。
4．在开发过程中，经常遇到刚刚解决一个问题，紧接着就又来了一个大麻烦。在这个过程中，难免会感到烦躁，甚至接近于精神崩溃的现象，如何在这个过程中很好地控制自己的情绪显得非常重要。
5．在需求/设计/实现/测试/发布/维护各个阶段的“新知识”：
在需求和设计阶段不能草草了事，我们当时的问题就是所有人都不了解怎么开始工程，自然也没把这个阶段看得太重。对于工作的分配也是简单带过，导致到了实现阶段，仍然完全不知道如何进行，只能走一步看一步。在发布的时候，很难保证自己的程序没有什么bug，所以在维护的过程中，需要不断的发现并修改自己的程序，这就对实现阶段有了要求，即尽量规范代码，不能出现大泥球。否则后续维护会很难，甚至需要全部重新实现。
四、总结
这个学期的软件工程课程，让我度过了好几个“不眠的夜晚”，同样也让我学到了不少知识，对软件工程中的合作等环节有了很深的了解。总之，虽然这门课程的学习过程有些痛苦，但总体而言是值得的。要说以后再也不担心大项目无法下手还为时尚早，但至少不会拿到一个工程之后毫无头绪了。
标签：
原文地址：http://www.cnblogs.com/baitrsou/p/4215188.html
