福大软工 · 最终作业 - 软件工程实践总结（个人）

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

1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

• 对比目前的所学所练所得，在coding能力上达到了你的期待和目标，在表达能力上，还存在不足。因为本次软工实践，我被分配到开发组。负责的工作便是代码以及相关文档的编写，没有上台演讲的机会，故在语言表达方面缺少锻炼。

2）总结这门课程的实践总结和给你带来的提升，包括以下内容：

1、统计一下，你在这门软件工程实践中，完成了多少行的代码；

• 通过自己编写简易的代码统计工具，统计出本次软件工程实践过程中，共编写了4000+行代码。

2、软工实践的各次作业分别花了多少时间？（做一个列表）

作业名称	花费时间（分钟）
第一次作业 - 准备之——自我介绍	5
第一次作业	200
第二次作业 - 个人项目	1200
第三次作业 - 结对项目1	500
第四次作业 - 团队展示	5
第五次作业 - 结对作业2	3160
第六次作业 - 团队选题报告	0
第七次作业 - 需求分析报告	150
第八次作业 - 课堂实战 - 项目UML设计	620
团队现场编程实战（抽奖系统）	600
Alpha 冲刺 1 2 3 4 5 6 7 8 9 10	2960
第十次作业 - 项目测评	385
第十一次作业 - Alpha 事后诸葛亮	335
BETA 版冲刺前准备	10
Beta 冲刺 1 2 3 4 5 6 7	700
第十二次作业 - Beta答辩总结	420
最终作业 - 软件工程实践总结	200

3、哪一次作业让你印象最深刻？为什么？

• Beta最后一次冲刺让我印象最深刻。最后一天晚上全组挤在一间宿舍，肝到凌晨3点半（说好的不熬夜呢？？？）。说实话，最后一天肝到凌晨3点半的原因是平时大家都没有紧迫感，到了快到截至时间时候，只能熬夜赶进度。正如柯老板所说：“Deadline是第一生产力。”

4、累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

• 本学期，我累计花了191个小时在软工实践上。

• （四个月）平均每周花12小时在软工实践上（几乎所有的周末空闲了）。

• 开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答：“平均花多少时间现在还说不好，因为还没有正式开始上课，不知道需要做什么。要等具体的任务出了才好决定。暂定10小时吧。到时候会视具体情况调整。”

• 原先的预测还是比较准的。软工实在是一门耗时间的课（但是也能学到很多）。

5、学习和使用的新软件；

• Android Studio、
  Github Desktop、
  墨刀、
  石墨

6、学习和使用的新工具；

• ProcessOn、
  Iconfont-阿里巴巴矢量图标库

7、学习和掌握的新语言、新平台；

• 1.利用C++ + Qt 进行Windows桌面应用开发
• 2.利用Java + Android Studio进行安卓开发
• 3.利用Python PyQt5库进行Windows桌面应用开发

8、学习和掌握的新方法；

• 利用Git进行项目进度同步与管理

9、其他方面的提升。

• 1.团队协作能力得到提升
• 2.沟通能力得到提升
• 3.抗压能力得到提升
• 4.熬夜能力

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

• 1.沟通很重要。不管是结对还是团队项目，充分的沟通使得我对于队友的想法有了更深入的了解，方便了开发。

• 2.不要找借口。不要给自己找借口，什么没空啊，有考试啊，作业多啊的。只要想做，总是有时间的。我晚上每天挤出一个小时用来学习新技术或进行开发。

• 3.不要责备他人。人非圣贤孰能无过？开发的软件出现Bug很正常。当问题出现时，首先不应当是去责备开发者，而应该着眼于问题本身，找出发生问题的原因，从根本上解决问题。 在开发过程中我们也遇到了很多问题，我的队友都很好，遇到问题都是一起想办法解决问题。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：

1）你有什么想建议、告知和期许想要告诉他们呢？

• 1.选择软工要慎重考虑，软工是一门很花时间的课，但是如果肯认认真真学，是能学到很多的，在将来的就业上或许会不少有帮助。
• 2.提前做好规划，安排好每个阶段要做什么。
• 3.要严格按照计划，不要将今天的事情留到明天。谁知道明天又会有什么新的作业。

2）特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？

假设依旧是一个90+人数的大班

• 不要！不要！不要！（重要的事情说三遍）
• 被换的队员往往得分很低，这对他们来说比较不公平。

3）身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？

• 一个组的人数应当在3到5人比较合适，不应该太多。这样可以比较合理地分工，确保每个人都有事情做，减少划水现象发生。

4）个人/结对/团队作业应该控制在怎样的规模？

• 我认为本学期的作业量偏多，代码部分还可以接受，主要是博客部分花了太多的时间。我们常说博客写地比代码多。我认为个人/结对/团队作业量应控制在本学期作业量的80%比较合适，同时应该放松对于博客的要求。

5）这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

• 你最感谢的人是柯老板。感谢不杀之恩（hhh~ 开玩笑~）。柯老师教会了我们不少东西，这些东西在将来我们毕业走上工作岗位时都会排上用场。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）

• 《构建执法》第17章 人、绩效和职业道德中提到，团队的合作分为这几个阶段：萌芽阶段、磨合阶段、规范阶段、创造阶段。

• 萌芽阶段我们团队也经历过。刚开始并不是所有团队成员都互相认识，大家都比较有礼貌，都比较拘谨。

• 磨合阶段：可能是由于大家素质都比较高，人都比较好，磨合阶段我们并没有发生什么冲突，这个阶段就这么平稳地度过了。通过这个阶段地磨合，团队成员之间更加熟悉了，偶尔还互相开开玩笑，有时候PM还请大家喝奶茶。

• 规范阶段：这个阶段我们团队的每个成员都逐渐清楚自己该做什么。通过聆听、讨论，成员互相之间更加了解，认识并欣赏各自的能力和经验，在开发工作中互相支持。

• 创造阶段：这也是我们团队最终也达到的阶段。大家将注意力集中到如何开发创造，实现共同目标上。不在需要PM的频繁督促，大家都自觉地完成被分配的任务，并且在完成自己的任务后，主动帮助队友。团队士气高涨，为共同的目标奋斗。

• 上述几个阶段我的团队都经历过，最后也成功到达了“创造”阶段。

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

1）研发出符合用户需求的软件

• 我们团队最终研发出了“吃喝玩乐遍福州”这款软件，并且成功通过Alpha、Beta阶段的答辩，最终进行课堂演示，取得成功。根据答辩时老师同学提供的建议和意见，改进我们的算法，取得更高的精度。

• 遗憾的是，由于资金原因，我们的软件没有上架。对我们这款软件有兴趣的同学可以私底下找我们进行体验。

2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

• 我们有对项目进行需求分析，编写需求分析报告。

• 我们利用Git进行代码版本管理。(项目Github链接)

• 我们有明确的分工，并且撰写博客，有定时的进度发布（详见Alpha、Bata冲刺的各次博客）。

分工

工作流程

• 虽然最后几天我们有熬夜，但那是对项目进行最后的优化与测试，并不是临时抱佛脚，胡乱拼凑完成项目。

3）并且通过数据展现软件是可以维护和继续发展的。

• 在Github上可以找到我们项目的源码。

• AR扫描的准确率经我们测试（在数据库内）无遮挡的情况下可以99%，人为故意遮挡（遮挡40%一下）的情况下准确率可以达到90%。

• 简单给出几个测试样例如下所示：

针对于模糊图片也能较好地识别出来

遮挡图片也能识别

4）对着检查表检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。

• 我查看上面所说的检查表，我尝试对里面的问题进行逐一回答。
• 在回答的过程中，我发现，对于一些较为简单的问题，还能较好地回答，但是对于一些涉及到细节的问题，尤其是涉及底层实现的问题，就完全没有头绪。
• 我意识到，我对于编程语言的掌握还很片面，与真正的大牛相比，还有一定的距离。在今后编程时，我将不再仅仅停留在表面的“怎么用”上，而是会进一步深入探究编程语言，理解它的底层实现，这样才能真正地掌握一门语言。

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

• 我选择阅读论文：《Open source software development should strive for even greater code maintainability》

• 该论文给出几种代码质量的评价标准：
  • 1.代码行数(LOC)度量程序代码的物理大小，不包括空行和注释
  • 2.相对于代码行数的注释行百分比(PerCM)描述了代码的自描述性
  • 3.霍尔斯特德体积(V)。霍尔斯特德定义了四个可以从程序源代码中测量的指标：n1(不同运算符的数量)，n2(不同操作数的数量)，N1
    (运算符总数)和N2(操作数总数)。在此基础上，他定义了程序词汇表n(由n = n1 + n2给出)和程序长度N(由N = N1 + N2给出)。
    最后，他定义了体积，一个由公式V = N * (log2n)给出的复合度量
    Volume为程序的大小提供了另一种度量方法。
  • 4.圈复杂度V (g)。由McCabe提出，该指标计算程序组件的控制流图中独立路径的数量。它的值取决于由条件语句(if-then-else)引起的分支数量。它度量组件的结构复杂性。
  • 5.可维护性指数(MI)，被SEI选为最适合测量具有高质量需求的系统的可维护性的工具。MI公式如下:
  • avgV表示“每个模块的平均霍尔斯特德体积”，avgV(g)、avgLOC和avgPerCM以相似的方式定义。
  • MI通过考虑代码的大小、复杂性和自描述性来度量可维护性。MI可能会因为添加到现有源代码中的新代码(由于错误修复或其他纠正措施)而改变。然而，由于MI是基于平均值的，它相对独立于这些变化的绝对值，可以用来比较不同大小的系统。阿曼在休莱特帕卡德维护的各种软件系统上校准了MI公式的系数，MI的支持者证实，这种形式的MI方程一般适用于其他工业规模的软件系统。高MI值表示高可维护性。

• 我的代码质量属于一般水平。在平时写代码时候，我也会注意命名规范和注释的编写，但是，有时候为了方便也会小小偷懒一下，不写注释，命名也不按照规范，导致我的代码质量时高时低，总的来看应该处于平均水平。

七、个性发挥，包括图文、照片和创意等

• 附上我们的团队合照

• 附上69元买的《构建之法》（没有白买，让我受益匪浅）

• 最后，我要感谢《构建之法》的作者邹欣老师写出这本好书；感谢柯逍老师一个学期来对我们的悉心教导；当然，也要感谢两位助教学姐雨勤未晴丶和苏木木木一次次耐心回答我们提出的问题，一次次熬夜批改我们的作业。同时，我也在这提前祝你们新年快乐！