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

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

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

答：对比目前所学所练所得，达到我对课程目标和期待的有：在本学期的软工实践，在小组中担任开发组的成员，所以对于coding能力肯定有所提升，所以计算机的专业技能、专业能力有一定的提升，回顾我对这门课程的期望，当初想通过这门课程接触一些新的开发工具，学习一些新的东西，这些还是达到了我的预期。另外本门课程更侧重于软件工程的学习，通过一学期的实践，也提升了自己对于这方面的理解，除了协作能力的提升外，本学期在要求之下，规范的按照软件工程的理念开发了我们小组的项目。也算是一次成功的项目经历。对于软件产品开发的流程有更深的理解。这些都是计算机专业能力和就业竞争力的增强。但是多多少少也存在一些不足之处。在本学期的软件工程实践中，虽说软件开发中的规范性学习到了很多，但自己在开发软件的过程中，bug不断，在解决这些bug时花费了大量时间，从这方面也看出了对于软件测试的缺漏。以及一些软件功能的砍去对于技术风险的分析不到位。自己作为开发组成员对于开发过程中成员之间交流也存在欠缺。

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

• 统计一下，你在这门软件工程实践中，完成了多少行的代码；
• 软工实践的各次作业分别花了多少时间？（做一个列表）
• 哪一次作业让你印象最深刻？为什么？
• 累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
• 学习和使用的新软件；
• 学习和使用的新工具；
• 学习和掌握的新语言、新平台；
• 学习和掌握的新方法；
• 其他方面的提升。

答：

• 这门软件工程实践中共完成了大约四千多行的代码

作业	时间 /分钟
第一次作业 - 准备之——自我介绍	5
第一次作业	240
第二次作业 - 个人项目	1200
第三次作业 - 结对项目1	500
第四次作业 - 团队展示	10
第五次作业 - 结对作业2	3150
第七次作业 - 需求分析报告	160
第八次作业 - 课堂实战 - 项目UML设计	600
团队现场编程实战（抽奖系统）
Alpha 冲刺	3000
第十次作业 - 项目测评	380
第十一次作业 - Alpha 事后诸葛亮	330
BETA 版冲刺前准备
Beta 冲刺	680
第十二次作业 - Beta答辩总结	400
最终作业 - 软件工程实践总结	200

• 第二次结对作业让我印象最深刻,在第一次结对作业原型设计后，第二次结对作业实现了第一次立下的大部分flag，第二次结对作业的时间充足，和队友下了很多的功夫，从分工到代码规范的制定，实现工具、数据结构的抉择，到测试样例的编写，都是在大量讨论下的结果，是本学期软工实践首次非常规范地完成一个项目，虽然是一个小项目，但是完成的时候成就感还是很满足的。
• 大约累计花了一百九十小时在软工上，平均每周应该有十四个小时
• 第一次作业的回答：

答：对于本门课程，首先这一定是一门实践性很强的课程，需要付出很多的努力，我的期待是从这门课程的学习之后，自己的专业技能素养能有较大的提升。平均每周拿出十几个小时来用在这门课程上。博客A[1]的作者说到学长给的建议，“把每天把要做的事情分成ABCD四类：A-紧迫且重要；B-重要不紧迫；C-紧迫不重要；D-不重要不紧迫。”，我赞同他的观点，这挺适合于强迫症，但是我有困惑，这样方案的实行真的利于坚持吗？在我实践中，我还是觉得最适合自己的方法一定要自己不断调整才行。我相信自己的目标一定会实现的。

• 学习和使用的新软件：Android Studio、墨刀原型开发工具、Qt、eclipse等
• 学习使用的新工具：阿里巴巴矢量图标库、福步取色器、Snipaste、process on等
• 学习和掌握的新语言、新平台：java 、python
• 学习和掌握的新方法:NABCD竞争性需求分析框架、SWOT框架分析、原型开发、软件测试策略等
• 其他方面的提升:coding能力，文档撰写能力，软件需求分析、软件测试等等方面的能力

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

个人作业：

• 这次软工个人作业的项目是写一个词频统计，自己在写的过程中bug不断，往往调试的时间是写完代码的好几倍，思路构思不清晰急于快速完成导致了这样的结果，所以个人作业是对于个人实战能力的一个测试，能发现自己的很多不足，在动手敲代码之前，先完成好整体的框架构思，再动手。ps：写个词频统计还是很有用的

团队项目：

• 沟通胜过一个人盲干，有时候一个下午解决不了的问题，请教一下队友几分钟就解决了，对于安卓自定义相机拍照卡顿的问题，在队友的帮助下很快就解决了（当然不建议不断地请教队友，还是要注重自己的思考）
• 合理的分工能发挥每个人的最大能力，所以在刚刚定分工的时候应思考是否真的适合自己，或者自己想学哪些方面。例如：这次软工实践自己主动选择了开发的工作，也学到很多，锻炼到很多。
• 文档的重要性。这次软工实践，我们团队刚开始没用很重视这些，尤其是到后面的开发，很多都要去翻阅前面的文档。

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

1. 你有什么想建议、告知和期许想要告诉他们呢？
2. 特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？假设依旧是一个90+人数的大班
3. 身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？
4. 个人/结对/团队作业应该控制在怎样的规模？
5. 这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

答：（对于下一届的建议）

• 在软工开始的招募阶段，选择自己感兴趣或者有涉及自己想学习的方面的队伍。希望你们都能度过一个愉快充实的软工实践。（这也是很总要的一个项目经历）
• 不要中途换队员，我觉得自己付出就要坚持下去，对于所有人都一样，毕竟以后出去工作，也不是事事都能顺心，每个项目都按照自己的期许推进，所以要坚持，坚持下去一定有收获的，做好自己应该做的事。
• 人数不能过多，也不能太少，太少的话每个人的工作量太大，如果人太多的话，相应的也增加了沟通的成本（时间资源）
• 个人作业最好能在小一点的规模又不失实用性。，团队作业最好不要弄太大规模，量力而行，牛不要吹太大了。
• 本学期软工最该感谢柯逍老师，在这么多次实践中给我们组提了很多实用的建议和不足之处。

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

• 萌芽阶段：团队刚刚确立，队员之间还需要磨合，各自的职责基本确定，对其他成员的长处还有很多不了解的。沟通交流确定主题。有些仓促。
• 磨合阶段：沟通逐渐增加，对彼此有了更多了解，沟通交流更多了。
• 规范阶段：确立了编码规范（有了良好统一的编码规范之后的合作还是比较顺畅的）
• 创造阶段：目标明确，为之努力，创造出真正像样的产品，（虽然和理想还是有很大的差距的），但是大家好像还是很满足的。

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

1. 研发出符合用户需求的软件必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
2. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好”的软件有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3. 并且通过数据展现软件是可以维护和继续发展的。而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
4. 对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试 ，这些常见的问题是否都能回答，并在此总结。

这是我们组的软件产品：

• 

我们的产品有公布公开，但是由于资金的缺乏（需要一个云服务器），所以并没有持续的用户使用量。

• 

  

  

• • 有规范的文档（软件规格需求说明书）
• • 有项目的管理（Github仓库）
• • 合理的分工合作

    

• • 有定期的进度发布，和团队之间的沟通交流
• • 虽然我们有在deadline前熬夜，但是如柯老板说的“deadline是第一生产力”，我们的产品不是熬夜胡乱拼凑出来的，是在团队充分沟通合作的前提下制作的。
• 源代码
• 高正确率：深度学习店铺识别算法结合我们软件的AR功能，是经过我们大量测试的前提下的，正确率在（在数据库内）无遮挡的情况下可以99%，人为故意遮挡（遮挡40%一下）的情况下准确率可以达到90%。
• 基础、进阶、应用开发拓展、安全基础、性能基础。涵盖了很多方面。对于一些问题自己感觉还是没有问题的，但是真真的项目工作需要的优秀的开发人员，要具备的不仅仅是coding能力，对于一些应用开发拓展、安全、性能等方面也要有充分的认识，在我看来，自己还有许多不能回答或者不能很好地回答，所以在接下来的时间还要好好地锻炼自己，朝着优秀开发人员的方向努力。工程的思维是很重要的。严谨求实，加强自己的专业素养。理论知识，更全面的看问题。

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

一个优秀的开发人员的coding能力的衡量很大一部分取决于他的代码质量。现代软件工程中的一个著名猜想是外部质量特征与内部质量特征相关。源代码的度量为评估其质量提供了有用的信息，在一定程度上可以预测外部系统质量特征，如可维护性、可靠性、可扩展性和可移植性。

开源项目应该该努力提高代码的可维护性

• 像柯老板说的一样，好的项目才开源，所以开源项目对软件代码质量是很注重的。
• 开源软件开发的缺点包括缺乏完整的文档或技术支持
• 开源软件的代码维护性会随时间的恶化
• 代码行数(LOC)可以度量程序代码的物理大小，不包括空行和注释
• MI公式的系数：MI通过考虑代码的大小、复杂性和自描述性来度量可维护性。MI可能会因为添加到现有源代码中的新代码(由于错误修复或其他纠正措施)而改变。然而，由于MI是基于平均值的，它相对独立于这些变化的绝对值，可以用来比较不同大小的系统
• 将开源的可维护性度量与闭源软件的可维护性度量进行比较，或者只是观察这些度量的趋势，并对代码质量的改善或恶化进行推测。因为从许多不同的度量标准中获得关于可维护性的单一描述是很困难的。考虑代码的大小、复杂性和自描述性来度量可维护性。
• 代码质量需要监控和改进
• 提升自我：定期传代码到github上，在每一次项目开始前先建好项目仓库，制定好代码规范，保证高代码质量的前提下进行开发，而不是一个大泥球。监控和改进自己的代码质量，通过一系列的评价指标分析的自己代码存在的质量问题，增强软件的可维护性、可靠性、可扩展性和可移植性等等。

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

• 帅气的摩尔纹解决：

  

• 9个人的夜我的心应该放在哪里？

  

参考文献：

[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