软件工程实践总结
一、请回望暑假时的第一次作业,你对于软件工程课程的想象
1)对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?
创新能力:这一项能力其实是我在课前没有考虑到的。从个人、结对编程作业,到现场编程、团队作业,想出了许多的点子。发现自己还是蛮享受头脑风暴的过程。从个人和结对的创新点构想,到现场编程的新技术应用、团队展示的idea,再到智能分析的数据处理框架,都是头脑风暴的产物。把已有知识加工成新的东西,再把它实现,其实是这门课里最让我兴奋的地方。
文档能力:在团队作业中,作为文档、博客的负责人,和队友们撰写的选题报告达到了五十多页,需求报告达到了八十多页,并且获得了柯老师的认可,两次登上了观光车。可以说,文档能力又上了一个台阶。
编程能力:虽然完成了几次编程作业,也完成了团队作业了一个功能,但是感觉编程能力还是不太够。
2)总结这门课程的实践总结和给你带来的提升,包括以下内容:
1、统计一下,你在这门软件工程实践中,完成了多少行的代码;
完成了以下的编程任务
任务 | 代码数 |
---|---|
个人作业词频统计 | 340 |
结对编程爬虫代码 | 260 |
团队作业智能分析 | 1500 |
总计 | 2100 |
2、软工实践的各次作业分别花了多少时间?(做一个列表)
作业名 | 时间(min) |
---|---|
第一次作业 | 400 |
个人作业词频统计 | 1400 |
结对作业 | 2310 |
团队第一次作业 | 240 |
结对作业二 | 2800 |
团队选题报告 | 1800 |
课堂实战 | 600 |
需求报告 | 1355 |
现场编程 | 1020 |
ALPHA | 700 |
福大助手项目测评 | 420 |
BETA | 1500 |
总计 | 14545 |
3、哪一次作业让你印象最深刻?为什么?
结对编程的作业让我印象最深刻。这次作业,为了解决一个bug,我见到凌晨五点半的福大,然后两个半小时以后我又去上课了。凌晨四点的时候,正巧遇到了问题,打算给助教留个言,没想到雨勤学姐一个秒回。并不是为了赶ddl而熬夜,而是代码正好有了的进展,进着进着就
进到了四点多,吐槽这门课的同时,也不免感叹,有时候还是有点意思的。
4、累计花了多少个小时在软工实践上?平均每周花多少个小时?同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
累计花了 14545分钟,243个小时,相当于不吃不喝做了10天,平均每周808分钟,13.5个小时。
真是触目惊心啊。
当初的回答
我觉得很难用一个具体的时间来说要花多少时间在这门课上,就像说:我要花10个小时在这门课,或者说花30个小时在这门课,有一种空头支票的感觉。在不知道每次作业量大小的情况下,10个小时可能多了,30个小时也可能少了。只能说,我愿意把这门课的优先级尽量往前提,在上面花费我的时间和精力。
我用总时间除以18周,算出是13.5小个小时。平均每周这个尺度其实不太科学,因为有时候每周的工作量会非常大,总之,工作量还是很大的。
5、学习和使用的新软件;
- 墨刀
- Eclipce
- StarUML
- ProcessOn
- Python
6、学习和使用的新工具;
- 墨刀
- Eclipce
- StarUML
- ProcessOn
- Python
- Visual Studio中的性能分析、代码覆盖率、单元测试
7、学习和掌握的新语言、新平台;
- 更加熟悉 C++
- 更加熟悉 Python
- 使用了vs中的性能分析、代码覆盖率的功能,发现十分强大
8、学习和掌握的新方法;
- 单元测试
- 代码覆盖率
- 代码性能分析
- Python爬虫知识
- 将新技术应用于实践
- 有更好的行动力
9、其他方面的提升。
- 个人方面,在文档、设计、展示方面的能力得到锻炼
- 提升了处理大量并行事件的能力。
- 学会了熬夜肝事情,不把事情做完不罢休(希望未来可以保留后半句,减少前半句的的发生)
- 将新技术结合进软件产品,做出优化改进。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
-
时间的安排对我来说是一个永远都需要提升的能力————特别是从理论上可调度的时间已经小于总任务所需时间的时候。
-
无论个人还是团队项目,总是想做得又快又好,虽然快字当前,但每次还是一不小心变成了好字当头,虽当下喜不自胜,但在事情过后,站在其他堆积如山的事情面前,总是不免心生悔意。
-
熬了这么多晚,掉了那么多头发,更光亮的头总是对时间安排多了一些更多的理解。
-
熬夜会猝死,但是早起比较不会,也就有了早上5点多起来做软工的经历。
-
又快又好,在邻近deadline之前完成,可以保证快,但不能保证好,而且有时候快也未必能保证。又好又快,在ddl前多天完成,可以保证好,很多情况下,做得也不慢,也留给自己更多迭代和修改的时间。
-
邻近deadline完成任务是一种突发事件,容易打乱整体的时间安排,而提早多天,便于时间的安排,事实上,也能在合理的安排下做到省时。在一个提前多天的完成任务的团队中,我深深感到提前完成的优势。
三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,对于同期的TA们,对于后来的学弟学妹:
1)你有什么想建议、告知和期许想要告诉他们呢?
不要低估软工实践的作业量,软工实践的作业量有下限,但是无上限。可能会花费大量的时间,但这取决于对这门课的定位。如果定位在绩点上,这两学分的课对绩点的投入产出比实在太小,不值得投入太多的时间去做这门课。但这门课可能是唯一一门如此非传统的课程,如果认真对待,它会极大占用你的时间,但也同时逼会你如何处理大量并行的事情;它会让你长期脱离舒适区,但也从各个角度磨练你的能力。
2)特别地,特别地,下一届要不要中途换队员(强制的、彻底的从一队换到另一队)?
假设依旧是一个90+人数的大班
可以鼓励,但是没必要强制。如果一个组经过较长时间的磨合,氛围很好、干劲很足,很有可能被强制换人打破。
3)身在一个格外大的班级,竞争强劲,你认为一个组的人数应当在多少比较合适?
十人左右。组数太多课上展示时间缩短不易控制质量。人数太少人均工作量太大难以完成,人数多则需要通过合理分工分配任务。实际上,即使是6-7人一组,也出现了只有1-2人几乎完成整个软工的情况。问题的关键是要合理分工。
4)个人/结对/团队作业应该控制在怎样的规模?
不过多地增加额外要求。附加要求要有,但是太多,太频繁的出现,会大量挤占时间,导致课程完成困难,也反作用于软工。
5)这学期下来,你最感谢的人是谁?有什么话想要对TA说呢?
四、分析一下自己所处的团队。
软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第17章 人、绩效和职业道德)
《构建之法》团队发展阶段
-
萌芽阶段:就像小苗破土而出,柔弱但充满希望。团队成员刚刚接触到团队的宗旨,同时很有可能刚刚互相认识。团队的目标没有真正达成一致,而成员则非常依赖于团队领导的指导。
-
萌芽阶段: 应该在讨论需求的时候,是处于萌芽阶段,大家刚刚互相认识,但是还不确定要做什么,所以就靠一次一次的会议推动。
-
磨合阶段:就像一个人的青少年时期,充满了对个人、同伴和团队的疑惑和冲突。团队无论大小都要克服困难,交付结果,大家不得不认真的面对问题,开展讨论了。这些冲突不一定都是技术问题也许是关于角色、职责、相互关系。甚至是各自性格、文化的冲突。不少人都想成为某个领域的“拥有者”(在软件项目中,谁负责哪个方面,每个方面要怎么做,等等)。同时也有一些人会以不同的方式进行挑战。
-
磨合阶段: 偶尔出现摩擦的情况也是存在的,原则就是对事不对人,大家都是明理人,也不会因为一些摩擦而不快。总之只要是为了团队,磨合都不是事。
- 规范阶段:从磨合阶段毕业进入到规范阶段的团队成员们就角色、职责定义和流程都取得了比较一致的意见。这一时期团队具有以下特点。
- 团队的工作流程和工作的方式得到大家的认可。成员之间互相更加了解,欣赏各自能力和经验,工作中相互支持。
- 领导主要扮演促成者和鼓励者的角色,有能力的成员也分担了一定的领导职责,并自然的获得大家的尊重。
- 随着项目的开展,一些成文的或不成文的规则逐步建立起来了。
- 作为一个整体,团队要做什么、不做什么,都更加明确。团队的信心更足,和其他团队打交道更有底气。
- 规范阶段: 后期团队慢慢规范,因为团队内部氛围很好,成员之间互相更加了解,一些成文的或不成文的规则逐步建立起来,所以大家都更加明确,团队的信心更足。虽然不敢说完全规范,但是某些方面还是达到了的。
- 创造阶段:经历以上三阶段后团队可以创造一些有意义的东西,并不是所有团队都能到达这一阶段。拥有以下特点:
- 团队知道为何而战,并将注意力几种到如何创造、实现目标上。
- 高度自治,不再需要领导的时时教诲与介入。不同意见仍会出现,但成员都以一种积极的心态和方式解决。互相支持,互相依赖,并保持各自的灵活性。
- 创造阶段:也许某时候偶尔能达到这个阶段,偶尔能闪现出一些创新的点子,但是没有办法完全达到。
五、怎样证明你学会了软件工程?
通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料
软件一定是可以也需要维护和继续发展,就像软工课本开头写到的硬件软件的损耗模型,软件的理想曲线是到后期损耗越来越少。而实际上,可能会出现剧烈的波动,需要有健全的SCM来做做好更新管理。以一项intel的大型开源软件为例:
到18年为止,有很多的版本更新,已经维护和发展了很久。以下是更新迭代的版本。
并且有大量的文档说明,详细解释。
并且在每个版本,都有详细的更新说明
六*(选做)、阅读软件工程中关于代码质量的的经典论文,从下列文献中选择一篇或若干篇,结合自己的实际做一个阅读笔记(例如,自己写的代码质量如何,是不是一个大泥球,如何衡量自己代码的质量)?从以下参考论文中选择一篇或若干篇:
阅读了
pen Source Software Development Should Strive for EVEN GREATER CODE MAINTAINABILITY
这篇论文是通过对六百万行代码的追踪,记录如何维护和不断迭代开源的代码。
对传统不开源软件和开源软件进行了比较:
随着版本的不断迭代,传统的不开源软件的MI会逐渐降低,并且低于开源软件的MI
并且发现:
- 开源软件的质量有时要比不开源的质量要好
- 后续版本的变化有时对软件的影响很大,要通过一些工具来帮助代码结构分析
- 要对项目可能发生的问题做好预案,因为OSS也会老化,要做好一些预防性的维护。
其实对于我们的软工项目也是如此,如果迭代到深入的阶段,也必须要做好一些预防措施,做好软件监控。如果有更多用户使用了,更需要对一些可能遇到的问题,做好预案,防患于未然。
参考论文文献:
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87