软件工程实践总结&个人技术博客
软件工程实践总结&个人技术博客
| 这个作业属于哪个课程 | 2021春软件工程实践|S班 |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 实践总结 |
| 其他参考文献 | 无 |
第一部分：课程回顾与总结
给课程起一个有意义的名字：以梦为马,不负韶华
问题回顾：软工实践寒假作业（2/2）
对之前问题的解答
1.创新者与先行者
p351页写到：
大家听了很多创新者的故事，有些人想，他们真了不起，第一个想出了这些美妙的想法，要是我早生几十年，也第一个实现那些想法就好了。其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。又如 Apple的音乐播放器iPod，发布于2001年10月23日，在它之前市面上已经有很多同类产品了.
论及市场竞争时，人们喜欢用下面这样一些词汇:。
先行者（ First Mover )、先发优势（First Mover Advantage，FMA )·
后起者( Second Mover )，后发优势( Second Mover Advantage，SMA)
这是sma的定义：后动优势(late-mover advantage；Second-mover advantage；又称为次动优势、后发优势、先动劣势)是指相对于行业的先进入企业，后进入者由于较晚进入行业而获得的较先动企业不具有的竞争优势，通过观察先动者的行动及效果来减少自身面临的不确定性而采取相应行动，获得更多的市场份额。
实际上，搜索了一下SMA的定义后，我觉得一些成功的后发者凭借的并不是后发优势，如微信打败米聊更多的是因为QQ庞大的用户基数可以使微信迅速发展用户流量罢了.同样ie超过mosaic更多的应该是商业策略的原因.
2.事后诸葛亮会议
p339页：
一个里程碑结束了，接下来怎么办?团队有什么经验教训?产品怎么才能做得更好?我们常说“软件的生命周期”—这个软件开发的周期结束了，生命也结束了。我们能不能像医学的尸体解剖一样，把这个软件开发的流程解剖一下?解剖的过程可以叫:Postmortem,Retrospective"，Review，事后诸葛亮会议，等等……大多数学校里的软件工程项目结束后大家一哄而散，一些诺言像“我一定会补上文档的”、“我们还会继续开发的”……成了撤退时的疑兵之计，等烟尘散去，同学们早跑没影了。
产品发布了，大家松了一口气。阿超建议大家开一个总结会议，就是事后诸葛亮会议。会议请公司的秘书小芳主持并作记录。为了让大家能畅所欲言，阿超和大牛没有参加会议。为了活跃气氛,小芳还买了零食、饮料、河曲啤酒等。
事后诸葛亮会议是对整个项目的回顾，总结经验教训，但是一些公司里人员流动大，去去留留一个项目能换几茬人，那么事后诸葛亮会议还有意义吗？会不会变成甩锅大会呢？
思考以后觉得个人对参与项目的自我反思还是相当重要的，事后诸葛亮会议要不要成为团队的常设项目还是要因具体情况而定吧
当然，后面实践以后，发现事后诸葛亮会议还是非常有必要的，至少对于一个随机组队的团队来说，队员们相互之间不熟悉，很多时候也有沟通的各种各样的问题，事后诸葛亮会议能帮助我们更好的纠错改正。
3.qa和test
p316页：
从上面的叙述中不难看出，软件的质量保障(QA)和软件测试(Test)是有很大区别的。然而,当前IT业界经常混用QA和Test这两个名词，很多团队的QA/Test工作是在较低水平上重复。一位曾在微软和雅虎工作过的程序员，有这么一个论断:大多数的开发团队并不需要一个独立的测试角色°。这引起了中国IT业界的热烈讨论，其中一篇影响较大的文章是“我们需要专职的QA吗?”
我了解了QA与TEST的具体信息与区别
| 相同点 | 不同点 | ||
|---|---|---|---|
| QA | TEST | QA | TEST |
| 保证和提高产品质量 | 关注过程SQA 重点是对软件开发过程进行监督管理、控制 | 关注产品TESTER 重点是对软件开发的成果进行检查、控制 | |
| 以组织标准过程和项目已定义过程为依据 | 以产品需求为依据 | ||
| 以评审和审计为主要手段 | 以模拟各种场景的实际使用为手段 | ||
| 重在发现和提出过程存在的问题 | 重在发现产品存在的缺陷 | ||
| 重在预防 | 重在发现和纠正 |
我的理解是test就是QA的子集，软件测试只是QA的一部分，QA的权限也比test大许多，对于大部分公司来说，职位并不是严格的，很多人可能是一职多能，即是QA也是开发.看了一些回答把国内的测试称作顶着QA头衔的test
就实践来说其实我们组内也是没有严格的划分，因为没有评审和审计之类的工作我是没对此有什么心得。
4.结对编程
p85：在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
结对编程的好处书中已经详细描述了，那结对编程的不足之处呢？结对编程在现实生活中国内的公司似乎很少采用，是有什么局限吗？
我发现知乎有一个相似的提问：国内为何很少有人做结对编程呢？是确实不好还是属于中国特色
阅读了他们的回答以后，我总结了一些看法：
1、一些内向的程序员不太喜欢在编程中与他人频繁交流
2、管理者怀疑结对编程的产出比不上两个人以传统方式进行开发
3、有些工作不适合结对，结对的人有明显的思维趋同性，可能范一样的错误
实际上，到目前为止，我的感受就是互相沟通一起完成工作确实会比单干少放错、进度快，但是会快多少就不清楚了。
5.典型用户
p218：
定义了最初的典型用户之后，是不是就可以开始写程序了?不，典型用户只是我们的设想，这些都是纸上谈兵，我们还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户。于是，移山公司的员工和实习生花了几天时间，做了不少用户调查，搞了不少头脑风暴，画了无数草图。
小李：(回来报告）除了进一步了解用户的需求，细化了一些功能的设想外，我们还有一个重大发现，我们的第一个典型用户，吴石头，好像不喜欢上网，他事实上不太会用电脑，也搞不懂如何上传照片。凡是和网络相关的事情，都交给了他的儿子。所以我们不得不把吴石头从典型用户中删除。
典型用户是指，按不同维度来区分用户的过程中，在每个维度中能代表目标用户的那类群体。比如，按人数多少来划分的，能代表最多用户特征的群体；按盈利来划分，能代表带来最多盈利价值特征的群体。
但是典型用户的定义和删除让我觉得非常奇怪，典型用户在何种情况下需要进行删除呢？
现在看来，典型用户的定义与删除不是那么死板的过程，因为用户的需求不是一成不变的，用户需求也存在因为调查不充分被误解的情况，如果用户需求和产品相差实在太大的话就只能删掉了。
是否原来的问题还不明白？如果有，请分析。
暂无
是否产生了新的问题？如果有，请提出。
其实就目前来说个人觉得软工实践和软件工程完全是不相干的两门课程，软工实践的课程只有中间的寥寥几次让我觉得与理论内容有些相关，大部分时间内都是在学技术写文档，总觉得怪怪的。
在项目的需求/设计/实现/测试/发布阶段（一共5个阶段）中，每个阶段收获最大的知识或能力
需求阶段：需求因为助教和老师给的比较全，所以没有碰到什么问题，收获最大的知识或能力应该是团队沟通与协作能力
设计阶段：设计阶段负责的是数据库和权限方面的部分内容，收获最多的方面的话，数据库的设计最好从最开始就定义好，并且最好要考虑一下冗余，中间改设计的时候改数据库是非常痛苦的事情，权限没有划分的话就会出现一些哭笑不得的问题，比如游客都能随便更改数据库内容。
实现阶段：在alpha和beta阶段中我们使用了leangoo这一敏捷开发工具，每天的站立式会议也能保证大家对进度有大概的认识，也学会了一些安卓开发的知识
测试阶段：学了一些例如Jmeter，Junit之类的插件用法，也体会到了测试对项目质量保证的作用
发布阶段：发布阶段其实没帮上什么忙，做了调查问卷和项目总结之类的，体会到了项目是要及时和用户沟通完善的
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
个人项目的话，感觉还是作业时间有点短，词频统计功能不算难但是总会出奇奇怪怪的问题，像github以及黑盒白盒都是之前很少使用的东西，做的也不算完善，还是有些遗憾，如果时间延长一两天或许就能做完全部。
结对编程中，队友是个自制力很强，技术也很强的人，他的后端实现的非常快，前端的后面一些功能都是我们一起实现的，学的比较多的应该是echarts各类图表的使用，数据的统计之类的。结对作业让我收获很多，体会到了合作的快乐
团队项目中，虽然我们是随机组成的团队，但是团队没有因此成为一团散沙，队友之间也没有产生隔阂，alpha冲刺是我第一次参与到一个比较大的团队协作中去，团队之间的成员沟通尤为重要，alpha冲刺可以因为大家回家的原因感觉团队之间的合作还是不够密切，很多时候前端和后端可以说是背道而驰向两个不同的方向各做各的，beta冲刺我们总结教训之后就好多了，组内大家都能比较好的沟通交流，大家各自尽自己的力量完成工作，项目进度也比较快。
