软件工程实践总结

一、请回望暑假时的第一次作业，你对于软件工程课程的想象

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章 人、绩效和职业道德）

《构建之法》团队发展阶段

  • 萌芽阶段：就像小苗破土而出，柔弱但充满希望。团队成员刚刚接触到团队的宗旨，同时很有可能刚刚互相认识。团队的目标没有真正达成一致，而成员则非常依赖于团队领导的指导。

  • 萌芽阶段： 应该在讨论需求的时候，是处于萌芽阶段，大家刚刚互相认识，但是还不确定要做什么，所以就靠一次一次的会议推动。

  • 磨合阶段：就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突。团队无论大小都要克服困难，交付结果，大家不得不认真的面对问题，开展讨论了。这些冲突不一定都是技术问题也许是关于角色、职责、相互关系。甚至是各自性格、文化的冲突。不少人都想成为某个领域的“拥有者”（在软件项目中，谁负责哪个方面，每个方面要怎么做，等等）。同时也有一些人会以不同的方式进行挑战。

  • 磨合阶段： 偶尔出现摩擦的情况也是存在的，原则就是对事不对人，大家都是明理人，也不会因为一些摩擦而不快。总之只要是为了团队，磨合都不是事。

  • 规范阶段：从磨合阶段毕业进入到规范阶段的团队成员们就角色、职责定义和流程都取得了比较一致的意见。这一时期团队具有以下特点。
  1. 团队的工作流程和工作的方式得到大家的认可。成员之间互相更加了解，欣赏各自能力和经验，工作中相互支持。
  2. 领导主要扮演促成者和鼓励者的角色，有能力的成员也分担了一定的领导职责，并自然的获得大家的尊重。
  3. 随着项目的开展，一些成文的或不成文的规则逐步建立起来了。
  4. 作为一个整体，团队要做什么、不做什么，都更加明确。团队的信心更足，和其他团队打交道更有底气。
  • 规范阶段： 后期团队慢慢规范，因为团队内部氛围很好，成员之间互相更加了解，一些成文的或不成文的规则逐步建立起来，所以大家都更加明确，团队的信心更足。虽然不敢说完全规范，但是某些方面还是达到了的。
  • 创造阶段：经历以上三阶段后团队可以创造一些有意义的东西，并不是所有团队都能到达这一阶段。拥有以下特点：
  1. 团队知道为何而战，并将注意力几种到如何创造、实现目标上。
  2. 高度自治，不再需要领导的时时教诲与介入。不同意见仍会出现，但成员都以一种积极的心态和方式解决。互相支持，互相依赖，并保持各自的灵活性。
  • 创造阶段：也许某时候偶尔能达到这个阶段，偶尔能闪现出一些创新的点子，但是没有办法完全达到。

五、怎样证明你学会了软件工程？

通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料

软件一定是可以也需要维护和继续发展，就像软工课本开头写到的硬件软件的损耗模型，软件的理想曲线是到后期损耗越来越少。而实际上，可能会出现剧烈的波动，需要有健全的SCM来做做好更新管理。以一项intel的大型开源软件为例：

https://www.dpdk.org/

到18年为止，有很多的版本更新，已经维护和发展了很久。以下是更新迭代的版本。

并且有大量的文档说明，详细解释。

并且在每个版本，都有详细的更新说明

六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：

阅读了

pen Source Software Development Should Strive for EVEN GREATER CODE MAINTAINABILITY

这篇论文是通过对六百万行代码的追踪，记录如何维护和不断迭代开源的代码。

对传统不开源软件和开源软件进行了比较：

随着版本的不断迭代，传统的不开源软件的MI会逐渐降低，并且低于开源软件的MI

并且发现：

  1. 开源软件的质量有时要比不开源的质量要好
  2. 后续版本的变化有时对软件的影响很大，要通过一些工具来帮助代码结构分析
  3. 要对项目可能发生的问题做好预案，因为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

posted @ 2019-01-08 11:54  范加索尔拉  阅读(269)  评论(2)  编辑  收藏  举报