[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"。

不过从另外一方面说，咱们组的组员都很给力，你们都认真负责为了项目全力以赴，虽然可能有一点小瑕疵，可是我认为咱们已经尽力作到了最好。