[buaa-SE-2017]个人作业-回顾

个人作业-回顾

提问题的博客：[buaa-SE-2017]个人作业-Week1

Part1: 问题的解答和分析

1.1

问题：根据书中“除了前20的学校之外，计科和软工没有区别”所以计算机科学这个专业也许在我们学校是和软件工程有区别的，但是可以料想的是大多数人将来都会是码农，那么我们专业和其他学软件工程的人相比有什么优势呢？

现在仍然不清楚，因为每个人的情况不同，也许是我们基础好一点吧？实践出真知，以后工作之后也许会知道。

1.2

问题：既然用户的需求是不断变化的，那么如何才能在设计过程中最大限度地使得软件易于扩展？另一方面，如果这样考虑会不会又进入了过早优化的思维误区呢？

设计一个健康的系统结构，让软件变得易于扩展是必须的，但是过早的预测用户需求的变化是不需要并且多余的，真正需要的是保持和用户的频繁接触，有更短的迭代周期和更频繁的反馈，简而言之，保持敏捷。

1.3

项目经理看起来是一个需要具有多领域知识的人（管理、营销、计算机），但大多数人都不会在大学毕业时就具备这些知识，那么如果将来想成为项目经理，现在可以做什么准备呢？各个部分的知识需要掌握多少？

这个问题现在看起来最好的解决方法除了多积累知识以外最重要的还是去公司实习，参与到实际的项目中，毕竟就算从书本中获得再多的东西，不能在实际中运用还是没有用的。

1.4

团队开发中一个比较困难的问题是，团队成员之间如何更有效地沟通？特别是在学校的时候我们除了软工以外还有很多课程，平时也很忙，这样成员之间的沟通就非常困难了。

这次团队项目虽然有的时候后端会出现问题，但是一些简单的问题我可以自己修复，同时大问题PM会解决，所以一天一次的scrum对我来说已经足够，不过不知道当项目规模变大这种问题会不会出现。

1.5

第四章中提到，变量命名的时候需要避免不必要的修饰词，判断必要或者不必要的方法是问自己，但是这种方法是否太过武断？毕竟看程序的都不是写程序的，对自己易懂，对别人就一定易懂吗？

现在我认为命名太长或是太短都是不好的，如何命名每个人应该都有自己的方法，但关键并不在这里，而是个人应该有统一的命名风格，如果是团队也是一样的。

1.6

16章中讨论了技术创新的问题，并用金钱和知识的转换过程来阐明科研和创新之间的关系，但是科研和创新是否真的是对立的过程？Viterbi创造的Viterbi算法让无数人受益，也让他获得了名誉和金钱，所以这两者之间也许并非是对立的，毕竟工业界的要求是要work，科研需要的东西也包括这一点。

创新和科研是不同的过程，发现知识的人也可以是创新的人，没有新知识的驱动创新也很难发生，而创新通常也会激发对新知识的探索，它们之间相互促进，两者是不同的概念，不过并不对立。

Part2: 知识点的总结

2.1 需求阶段

我们在需求分析阶段采用了调查问卷的方式来了解需求，这个调查问卷得到的结果和我们讨论的并不一样，比如我们最初希望项目的核心功能是对课程的评价功能，不过问卷的结果显示用户最需要的是下载课件资源的功能，还有一个当时我觉得基本不怎么起眼的自定义课表的功能也得到了很多票，所以说个人的需求和整体的需求是会有很多偏差的，真正的需求还应该从用户那里得到。

同时现在回顾一下我认为我们当时还应该有一个进行深入面谈或是组建焦点小组的需求分析的过程，因为调查问卷只是用户对问题的直觉上的回答，用户很可能没有深入想过这些问题，同时他们的需求可能和他们表达出来的并不一样。

2.2 设计阶段

我们的架构基本实现了前后端的分离，所以设计起来基本没有困难。不过Ui界面的设计和后台系统结构的设计完全是两回事，在Ui界面设计的时候，你需要为了一个分割线的颜色考虑很多，比如这个颜色是否过于醒目，是否会干扰用户的体验，你还需要不停地调整字体的大小和颜色，同时你也需要考虑元素之间的间隔，界面设计通常需要不断地打磨。

2.3 实现阶段

一个好的设计是好的实现的前提，通常如果你在实现过程中感到举步维艰，只要不是因为你对技术的了解太少，那肯定是设计出了问题，同理如果你在设计的时候感到头昏脑胀，也许你还没搞清楚需求（这是从另一个项目得来的经验= =）。

2.4 测试阶段

由于前端基本可以实现毫秒级别的反馈，所以测试非常方便，不过应该尽早编译代码在服务器上运行，因为实际的界面效果和在开发时候的也许会有不同。
测试一定不是在完成全部编码工作之后再做的，而是随着代码的增加而不断进行的，发现bug的时间越早就越容易修复。

2.5 发布阶段

像上一节提到的，程序实际在服务器上运行的时候的效果和在开发时候的效果有些不同，所以在发布阶段之前为测试预留充分的时间是很有必要的。

2.6 维护阶段

因为我们维护工作没有很多，所以并没有太多的经验，不过及时修复bug肯定是需要的，发现一些影像功能的bug之后应该在24小时之内修复。

Part3: 个人角度看团队事后分析

昨天PM发布了Beta阶段的时候分析，仔细看了之后发现有很多感慨和之前没有注意到的地方，在这里想针对这篇事后分析谈谈自己的体会。

下面所有的引用都来自我们团队的Beta阶段事后分析。

3.1 关于宣传

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
尽早宣传，由于我们宣传得比较晚，导致最终的用户量和汇报时用户量相差比较大。应该把反馈功能尽早衔接到网站上，而不是依赖于用户群。

关于宣传的晚这一点，我深有同感，我们在开发阶段和用户的接触太少了，更理想的做法是在每开发一个新功能之后就及时和用户进行沟通，从而有一个更快的响应速度。

3.2 关于进度估计

我们达到目标了么?
基本达到了目标。但是计划实现的功能太多了，最终只实现了大多数功能，一些非核心功能就被弃掉了。

我认为对项目整体进度的估计不足也是我们beta阶段的一个不足，我认为这其中主要的原因就在于我们对进度估计的不重视，实际上我们没有理由不重视估计这一步骤，因为如果由于估计不准而导致核心功能实现不足，那可能就意味着整个项目的失败，何况我们也没有用于防止这种情况发生的缓冲区。当然实际我们所面临的情况并不是那么糟，至少我们已经实现了大部分的核心功能。

必须要承认的是我的经验并不是很充足，如果还有下一次，也许可以用相关模型或是公式估计一个粗略的时间，最好能把任务尽可能地分解，从而实现细粒度的估计。

3.3 关于bug

博文功能Bug最多，这里主要是前端，一是人手不足，二是bug不太好解决，本身实现难度也比较大。

由于我是前端，所以这里还是要检讨一下自己。前端bug多的原因，一方面就像引文中提到的那样，由于前端都由我一个人搞定，一人难扮多角，所以测试的时候基本都只是测一些基本的功能场景，而不会进行全面的测试；另一方如果不考虑粗心大意这样的情况，这次前端整体的架构也是不够健壮的，整体的结构存在很多问题，这样很容易出现bug，关于这一点我需要反省。

3.4 关于质量保障

我们在这一阶段太过注重功能的实现了，时间又紧，人力资源又少，一直处于一个很紧张的状态。如果重来一遍我们会放弃一部分功能，将更多的时间用在代码管理上，> 保证软件工程的质量。

这一点我也有同感，我们确实没有在工程质量上下太多功夫，人数不够加上初期对功能的重视都导致了这一点，比较好的一点的是我们采用的前后端分离的模式大大降低了整个系统的复杂度，某种程度上避免了整个项目变成一个"Big Ball of mad"。

不过从另一方面说，我们组的组员都很给力，大家都认真负责为了项目尽心尽力，虽然可能有一点小瑕疵，但是我认为我们已经尽力做到了最好。