| 这个作业属于哪个课程 | 构建之法-2021秋-福州大学软件工程 |
|---|---|
| 这个作业要求在哪里 | 2021秋季软件工程实践总结 |
| 团队名称 | 摸鱼买菜必涨价 |
| 这个作业目标 | 完成对本学期该课程的总结，提出建议，完成读书笔记 |
| 作业正文 | 2021秋季软件工程实践总结 |
一、个人总结
1）达到的期待和目标，存在的不足
学期初的期待是——参与一个项目的开发，学习掌握相关的流程和必要的知识，收获一次开发的体验；作为一个全程的，投入的参与者，成为团队中被需要的一员。
由于认真地参与了程序的开发流程，从选题需求分析到编码最后的打包上线，在开发一款软件的需要的技能方面从零到有，得到了不小的提升。这是达到的目标，也是仍旧存在不足的地方。在技术方面还未能达到比较强的能力，从想法到实现经常舍近求远，选择了麻烦的方式。目前仅仅处于“会”的状态，将要朝着“通”的方向在加把劲。
2）总结这门课程的实践总结和给个人带来的提升
1、统计在软件工程实践中，完成了多少行的代码
| 作业 | 代码量/行 |
|---|---|
| 个人编程 | 670 |
| 结对作业 | 1500 |
| 团队编程 | 2050 |
| 合计 | 4250 |
2、软工实践的各次作业花费时间
| 作业 | 花费时间/min |
|---|---|
| 个人作业一 | 60 |
| 个人编程 | 1750 |
| 第一次结对作业 | 764 |
| 第二次结对作业 | 2410 |
| 现场编程 | 360 |
| 团队作业 | 2280 |
3、哪一次作业印象最深刻？为什么？
第二次结对作业印象最为深刻，这算是头一次将一个蛮算的上是一个将小项目的付之于代码实现，有很对地方不同于之前的作业。
一是真正能用所知所学来完成一个能分享出去，让大家也参与进来的作品，而非自娱自乐，是一次全新的体验，而且也是为之后的团队项目蓄力，故而开始的情绪很高涨，作业一发布就找来队友着手准备工作。
二是遇到的迷茫和知识的空缺和前面的作业不是一个量级上。一有时间就拼命学，拼命码，最后一天就是用博客展示下这一周以来的工作都花费了不老少时间。
三是把作业演示视频发布到B站上面，居然还有弹幕和投币什么的耶，超级惊喜。
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
| 花费时间/h | 平均每周时间/h |
|---|---|
| 126.2 | 9.7 |
5、学习和使用的新软件；
- HbuilderX
- 微信开发者工具
- 墨刀
6、学习和使用的新工具；
- Cutest
- Intel VTune Profiler
- QUnit
- ProcessOn
- ShowDoc
- Typora
7、学习和掌握的新语言、新平台；
- JavaScript
- HTML
- CSS
- python
- GitHub
- 优快云
8、学习和掌握的新方法
- 代码单元测试
- git协作开发
- 结对编程
- vue框架
- 团队编程
- 接口使用
9、其他方面的提升
- 团队协作的能力
- 快速学习的能力
- 有效沟通的能力
- 时间安排的能力
二、团队总结
-
有效地分配时间，是可以杜绝DDL成为第一生产力的。个人作业的一点感悟，编程的作业容易遇到意想不到的问题导致无法在预期的时间内完成，有效时间难以准确估计，需要更加认真地安排合理的分配时间，增加容错的程度。
这样才不会和其他课程作业的时间打架的问题，遇事也不慌乱，编程作业就完全没有出现突击赶工的情况。 -
沟通交流真的真的非常重要，不论是个人作业还是结对，团队作业，在与人的交流之中，能够发现很对新点子，少走一些弯路。结对作业的时候，我们在考虑做什么样的游戏出来，由于对游戏需要的技术不是很了解，查阅资料之后，就直接定下了感觉我们两个人可以胜任的工作。但是在以后偶然和其他队伍谈论到如何实现的问题的时候，我们才发现我们过于乐观的分析了实现的难度。
个人的力量是有限的，但是沟通起来的团体能量就是无穷的。 -
理智的目标选择获得及时的正面反馈。一开始初生牛犊不怕虎，在结对作业上有一个很宏伟的梦想，但是尝试实现后，那段时间可谓是毫无进展，逐渐怠惰。后来改变方向，分解大的目标成为跳起来或者垫垫脚能实现的小目标，成就感也是无形的动力。
三、提出建议
致老师和助教：每一次的作业在我看来都是新颖特别的，同时每次的作业又都能为下一次的作业打下一点基础，认真地完成就能减少下一次作业的负担，能感觉到老师和助教在出题时候的用心良苦。建议在下一次的开课，也有这样有水准的作业布置。希望大作业之前可以有更加细化的可选择的小作业，帮助和引导基础比较薄弱的同学快速入门。
致未来的软工实践学员：对这门课的评价或许总是带有熬夜，通宵，崩溃等负面的关键词，但是，一定不要带着抵触的情绪接触它。不妨转换心态，怀着求知若渴的心情，去接触去体会，才能汲取这门课程带来的远高于其本身要求的收获，才算不辜负一个学期的时光。倘若能在闲暇的时间，提前接触相关的知识，武装自己，那么在课程中无疑能够有更多的选择和发挥，希望大家都能在课程实践中做闪闪发光的自己。
四、团队分析
萌芽阶段，很快就结束了，队员之间绝大部分都是相互认识熟悉的，提出观点看法，给出建议的时候，基本能够畅所欲言，让任务进行下去的阻力不那么大。而且虽然大家是头一次组成团队进行项目的开发，但是之前课程的作业已经带领大家初步地接触了课程的内容，不会太过于生疏。在组成队伍的一开始，迅速进行了框架的选择，带队人员的确定。
完成现场编程还有之后的alpha冲刺等等作业的时候，是我们团队从磨合阶段迈向规范阶段，大家各司其职，能力比较强的人分担了领导责任。相互信任，需要提交的任务不太需要催促，能按时地完成提交。
五、软件要求
六*关于代码质量的阅读笔记
参考论文文献： 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
文章中认为可维护性是OSS开发的核心问题，需要关注。该案例研究检查了开源开发提供的源代码的可维护性。现代软件工程中一个众所周知的猜想是，外部质量特征与内部质量特征相关。源代码的测量，在一定程度上预测了外部系统的质量特征，例如可维护性。
典型的软件指标是代码的大小（以代码行数、语句数等形式测量）和代码复杂度（通过循环复杂度等复杂度数进行度量）。文章采用的标准如下：
• 代码行数 （LOC）:测量程序代码的物理大小，不包括空行和注释。
• 注释行相对于代码行数的百分比（PerCM）:描述了代码的自我描述性。
• 霍尔斯特德体积 （V ）
Halstead 定义了四个可以从程序源代码中测量的指标：
n1（不同运算符的数量）、n2（不同操作数的数量）、N1（运算符的总数）和 N2（操作数的总数）。
基于此定义了程序词汇 n = n1 + n2 和程序长度N = N1 + N2。定义了体积 V = N * （LOG2 n）
• 环复杂度 V（g）。该指标计算程序组件的控制流图中独立路径的数量。其值取决于由条件语句（if-then-else）引起的分支数。它测量组件的结构复杂性。
可维护性指数MI 遵循以下公式：
其中avgV代表"每个模块的平均霍尔斯特德体积"，avgV （g）、avgLOC 和 avgPerCM 以类似的方式定义。
MI 通过考虑代码的大小、复杂性和自我描述性来衡量可维护性。MI 可能会更改，因为由于错误修复或其他纠正措施，将新代码添加到现有源代码中。但是，由于 MI 基于平均值，因此它相对独立于这些变化的绝对大小，并可用于比较不同大小的系统。高 MI 值表示高可维护性。
七、一些话
我时常畅想，如果这门课要是能独占一段学习时间该多好~（突然想到了占据我大一寒假绝大部分时间的寒假作业特别是我罗斯方块）但实际上，能有完整拥有一段时间心无旁骛地只专注一件事不仅仅是在课程的安排上非常不现实，在往后的工作学习甚至生活中也不太容易实现，可以说是奢侈的。总是面对措手不及，常常需要有三头六臂并发处理很多事情。也算是摸索出一条“为学无间断，如流水行云，日进而不已”的道路。
扫一扫
1804
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
