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

tomvii

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

引

不必太纠结于当下，也不必太忧虑未来，当你经历过一些事情的时候，眼前的风景已经和从前不一样了。

本次作业
从拾起“软工实践”这枚小确幸以来的一个学期可以说是相对充实的一个学期，从开始的懵懂到如今的淡然，一次次在代码的泥潭中埋下脚印，踩过一个个bug走到今天。
私以为软工实践这门课程对大部分人说都是一条收获>付出的捷径,从个人作业到团队作业；从个人能力的体现到团队协作的考察都是这门课程所覆盖到的。~~若做一门课程的“代码覆盖率”，软工实践一定占了100%~~

一、原风景

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

1)对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
经历了4个多月的洗礼，对比当时的期待，我想收获的更多是自己专业技能吧，不过也确实对开发项目的开发流程、合作方式也有更多的了解。
- 刚开始以为自己掌握了不少专业知识，足以完成软工实践，在经历一次次作业的冲击下，也 “真香式” 地开始了学习，可以说之前仅仅是专业技能有个局部理论性质的认识，现在是将其投入到实践中来进行。
- “做中学”这门实践艺术是我在这门课程中达到我预想目标的，最初我是在C++课程中接触过这种思想，较为开发性、也更具挑战性。但是现在才真正了解、理解这样一们实践艺术，也将自己学习的知识应用到我们的团队作业中的一部分——“目标检测”。
- 很遗憾我们整体团队的开发规程没有较好地制定，这也是本次课程中我做的不足之一，可以说我们的PM已经相当负责地定期push进度，但是大家普遍崇尚个人实力主义，不过多注重相对应的软件过程，导致一度的开发进度延期。
- 不过经过大家的协同努力，我们仍是交出了我们最满意的答卷。
2)总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
个人作业完成了923行代码，团队作业中完成了2194行代码，共计3117行代码，其中C++代码占1149行，python代码占1968行。
2、软工实践的各次作业分别花了多少时间？（做一个列表）

软工作业	时间花费(min)
第一次作业——准备	140
第二次作业——个人项目	1210
第三次作业——结对一	940
第四次作业——团队展示	90
第五次作业——结对二	1480
第六次作业——团队选题报告	280
第七次作业——需求分析报告计	620
Alpha1	470
Alpha2	690
Alpha3	130
Alpha4	230
Alpha5	210
Alpha6	250
Alpha7	330
Alpha8	30
Alpha9	210
Alpha10	150
现场编程实战	410
第十一次作业-Alpha事后诸葛亮	120
第十次作业 - 项目测评（团队）	330
Beta1	170
Beta2	250
Beta3	330
Beta4	30
Beta5	30
Beta6	250
Beta7	330
Beta答辩总结	340
总计(min)	10220
总计(h)	170.3

3、哪一次作业让你印象最深刻？为什么？
结对编程第二次作业吧，因为国庆期间忙着比赛deadline提交项目，这份作业几乎没有怎么动，不过庆幸的是我的队友也没怎么动，让我不会过于自责，~~甚至想打他一顿~~，我们俩连续两个通宵到5点把这份作业补全了，真的是刺激加辛苦。不过越是deadline，人的潜能还真的会被激发出来
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

共计花费了170.3小时在软工实践上，平均每周9.4小时，每天也就一个多小时，其实还不及我第一次作业预想的每天两小时计划！不过考量到这中间存在考试周以及作业尚未发布时间，其实纯工时应该是超过了每天两小时的计划的。
5、学习和使用的新软件；
pycharm(IED)
Axure(原型工具)
SmartDraw（绘图工具）
6、学习和使用的新工具；
VS代码覆盖率插件
爬虫工具
islide（PPT插件）
Chrome插件 —— 新浪微博图床

7、学习和掌握的新语言、新平台；
更加深入了Python语言的学习以及对tensorflow深度学习框架有了更深的理解与认识
还有就是协助前端过程中学习一部分安卓开发——具体参考《第一行代码》

8、学习和掌握的新方法；
最主要的方法还是learning by doing,说实话这的确是我收获最大的一种学习方式，通过在实践中学习来完成新的知识的掌握，而不是通过既定教条式的理论来学习，这样的方法更容易Push你完成，也能给予你更大的发挥空间。
在本次软工实践整个流程中，对于做中学该思想，我更加强调做这个模块，不单单只由于实践课程的缘故，而是一种学习理论的贯彻，传统方式是学完再布置作业，而这种方式下，每次作业都是先发布，然后学习后完成。这算是learning by doing的另一种彩蛋式的体现吧。

9、其他方面的提升。
演讲能力吧，虽然不是PM，但是之前由于PM身体不适的缘故也临危受命，代替做了一次分享报告。
其次就是团队沟通能力，由于我是喜欢“单打独斗”这种类型的程序猿，团队协作这种工作一开始也是让我十分苦恼，但是后续也是让我慢慢接受了团队协作的高效率开发这一极大优势。
最后就是对计算机视觉方面的学习理解也加深了，自己实现的一个简单的神经风格迁移帮助我在训练目标检测数据集时提供许多遍历，也是我们最后能做出摩尔纹识别效果的一个极大”功臣“
下述是神经风格的迁移的一份雨夜模拟图

还对图像数据的处理方面有了些许心得，如下述的椒盐噪声图像处理。

二、人月神话

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

经验总结

个人部分

首先一个好的代码规范之于项目相当于地基之于房子，没有好的代码规范基本不可能对代码进行修改和维护，除非你的代码简单到可以一次性打完不出任何问题。
然后就是代码规范的延续，别人的规范的确不是最好的，但在工作实践中总结出来的规范能切合实际需求，能让开发快速进行并完成。
兴趣和热情只能让你很执着，但并不一定能让你走好这条路，只有你的能力和你的强项才能让你走好这条路

团队部分

团队开发前需要预先制订好可不需过分详细，但必须要规范的开发文档，这样在中后期开发过程中才有规范开发参考。
团队开发中实际开发成员必须占三分之二以上，否则会大大影响项目进度的开发。

实例/例证的分析

在刚开始选取目标检测模型，我就完全随便选择一个模型，github中载下源码，一运行，感觉不错，过一段时间又继续重复上述操作，没有对模型测试结果进行保留，也毫无对模型的评估，这样重复性的操作大多是无用功。所以我们需要对多次测试结果进行保留和对比以进一步对下一步开发进行修缮。
而软件开发末期则出现了规范问题的情况，我们的接口没法对接，只能重新改写，而这就需要用到了我们的开发规范说明，而这份说明中由于不甚规范的缘故，对于接口部分的叙述不是特别完全，所以我们只能临时重新设计一个解决方案，十分耗费时间。

三、对下一届的建议

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

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

恭喜你们，这是一门必修课程，你们逃也逃不掉啦！
这门课程是一门实践性很强的课程，会在你的技术层面、逻辑层面等甚至是起到综合水平的提升作用。
合理的分组十分重要，每个团队的人数不需要太多，但是也不能够太少，下一届假设如现在一样为90+人数的话，则9人为一小队是较为优秀的安排。
注重每一次alpha冲刺以及Beta冲刺环节，不要将其当成打卡签到，而是要正确完成对应的工作来保证团队项目的流水进行。

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

单次作业的强制换队员是一个十分有趣的做法，可以考验单个人的适应性以及加深外部对团队成员对于自己项目的理解与认识。
而强制、彻底的更好队伍则更需要进行考量，当前我们采取的是让队员自主选择，而若是下一届是强制措施势必会导致些许对接摩擦发生，所以这一点上海市需要慎重慎重！

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

私认为这个不是一个数字能够回答的，是动态的、可扩展的，而是要具体情况具体分析的，不仅与具体小组选择开发什么项目还与整体项目难度系数、工作量相关。不过大致控制在9人上下是一个较优的选择，不过在项目选取上则要多多考虑难度影响，要量力而行。

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

规模这个词用的很好，个人理解为具体的作业工作量*作业难度系数，以10分制来评比。
这样的话，个人作业的话评分应为2，工作量较少，但是难度较大，用于考察个人实力。
结对作业的话评分应为4，工作量较大，但是难度偏中等，用于考察结对编程能力，更多的是工作集的划分。
团队作业的话评分应为10，工作量较大，但是难度较大，用于考察团队协作能力以及综合素养。

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

本来说感谢柯老师的，但是考虑到我是一个不甚喜欢跟风从众的人，我还是决定感谢一下柯大魔王，柯大魔王不去教哲学可惜了，推荐的水饺真的挺好吃的，不过我还是喜欢玉米猪肉口味的！柯大魔王在Alpha冲刺前期给我提供了一个十分可行的一个方案，以单纯的目标检测来代替文字识别，虽然这个方案后续没有用上，但是我后续的改进思路也是大大受其启发而成的，在正面照片识别的正确率上表现极佳。
太过肉麻的话感觉说出大出来，总之，您辛苦了！
感谢一下助教学姐们一整个学期对我们的照顾！Thanks♪(･ω･)ﾉ)

四、团队发展

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

萌芽

萌芽阶段就像小苗破图而出，柔弱但充满希望。团队成员刚刚接触到团队的宗旨，同时很有可能刚刚互相认识。
比方说我们这个项目都是大家一拍大腿——piapiapia的几声就定下来的，也都是因为新奇和对算法端已经完成的满满自信就定下来的——自然场景下的文本识别相关的内容。

磨合

磨合这一阶段则是我们各自完成对应工作，最终定时对接
通过一次次的会议加深各自的认识。

规范

规范上，我们有完成一份组内共享的技术文档，同时也做了一份个人的技术文档，以供后续查阅资料用。
在代码规范上，我们也在设计说明书中详细定义了部分内容。

创造

最有创造的时刻总是在凌晨！
我们团队在凌晨、午夜的工作效率可以说是整个软工实践团队最高的！试问您见过1个通宵完成前后端所有接口包括服务器对接吗，我们团队就做到了！不过这的确不是一个很好的行为，凡事还是不要拖到Deadline前完成。

五、学会软件工程

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

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

很遗憾我们最终完成的功能是几乎被删的残枝败叶的几部分功能，不过我们的核心功能——AR扫描商铺智能返回商铺信息这个功能超乎我们的想象地完成了，用户不仅能扫描现实场景商铺，还能通过电脑扫描带有摩尔纹的图片的商铺。
总的来说，我们的前端UI均是按照规范原型设计完成的，我们的后端算法也均实现了原计划功能，虽然服务器是搭建在本地的 (能跑起算法的云服务器太贵了！！) ，但是我们仍是模拟了一个很好的场景APP。

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

我们的产品按照预定的时间发布，并且按软件流程逐次分层迭代完成，按照作业的进度，我们每次展示总能发布拿得出手的产品。实地（永嘉天地）识别店铺招牌成功率可以达到80%。
而遇到角度***钻甚至是高度模糊遮挡的图片，识别准确率也能达到63%

通过数据展现软件是可以维护和继续发展的

下图是我们组内技术文档以及我的个人技术文档代码规范

六、软工经典论文阅读

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

论文——Quantitative evaluation of software quality
论文链接

本文的研究建立了一个概念框架及关键步骤、结果，用以分析软件质量的特点。其主要结果和结论如下：关注软件质量特性可以显着节约软件生命周期成本。当前最先进的软件对我们自动、定量评估软件质量的能力施加了一定的限制。开发了明确的、有区别的软件质量特征的层次结构。其更高层次的结构反映了软件质量评估的实际用途;其较低级别的特征与可以执行的实际软件度量评估密切相关。我们可以根据潜在的收益，可量化和自动化的简易性，定义，分类和评估了大量软件质量评估指标。在已经确定了特定的软件生命周期活动，这些活动对软件质量具有重要影响。最重要的是，我们认为本文中报告的研究首次通过一致且相互支持的定义，区别，指南和引用的经验。这个框架当然不完整，但它已经足以成为未来改进和扩展的可行基础。

上述为本论文的摘要简介。
可以容易看出软件的质量特性可以大大节省软件生命周期的成本，而软件质量的高低很大程度上取决于代码质量的高低，我们在进行团队作业之前，我们团队的编码规范不是太过于详细，大部分人仅仅凭借各自对于接口模糊的意识来编码，而最终我们也是因为这一点吃了大亏，所以代码质量不仅仅取决于编程人员的素质，也取决于团队合作中是否能够很好的制定编码规范以及是否能够很好的遵循规范进行开发。
软件接口是实现一个系统跟另外系统进行信息交互的桥梁，在不同的系统之间，根据系统的关联程度的不同存在紧耦合和松耦合两种：紧耦合要求接口响应反应快，消息不能阻塞；松耦合对响应反应要求比较低。而我们大多数用的则是紧密耦合，我们需要软件的紧密耦合相连来完成我们对应信息的传递。