第四次作业——个人作业——软件工程实践总结作业
不知不觉大三上就已接近尾声，与我们相伴已久的软工也将画上圆满的句号。
这篇既是作业，也是对自己这学期以来软工的感受和想法。
如下：
ONE
回望开学初对于软件工程课程的想象，回望博客开篇时对于这门课和这学期的期望，1）对比现在的你和开学初博客开篇的课程目标和期待。同时，2）总结这门课程的实践给你带来的提升：包括，1、学习和使用的新软件；2、学习和使用的新工具；3、学习和掌握的新语言、新平台；4、统计一下，你在这门软件工程实践中，完成了多少行的代码；5、学习和掌握的新方法；6、其他的提升
现在回顾过去，我只想对自己说一声：年轻人，你还是太嫩了。
（1）回忆往昔，对比当下
开学初：
对实践项目完成后学习到的能力的预期：
1.能够清楚、完整地了解项目开发的具体流程。
2.自己能够独立实现一个小而完整的项目
3.学会和其他人合作，一起共事的能力
对项目课程的期望：
1.希望能够激发大家的学习热情，毕竟是计算机专业的，不热爱怎么行？
2.希望定期能有总结，还有适当的针对性的辅导
对项目的愿景规划：
1.10月6号前（期间一个月）看完《第一行代码》
2.同步跟进老师的课程且结合网上课堂进行学习
3.每天瞧一瞧、敲一敲代码并记录
此时此刻：
1.课程目标：
- 感觉之前的课程目标写的不够具体，所以到底实现了怎么样了心里也没有底呀，总体来说，一半一半吧
- 在软工实践上切实体会到了团队协作的重要性，有问题一起讨论、一起解决
- 哈哈，自己实现一个小项目可是没有在这么软工之列呀，结果还是没有精力和时间完成
2.期望：
- 这门课的确激发了大家的学习热情哈哈
- 学习到了很多新的东西
（2）千锤百炼，提升自我
1.新软件
- Android studio：谷歌官方出品的针对安卓开发当然是最好用的，想学安卓的少不了这位得力助手！
- 墨刀：安卓原型设计工具，免费的软件，很好用，关键是可以和其他成员同步设计界面，很棒！拥有的素材、动画都很出色。
- Axure RP：原型设计工具，网页或者是手机。
- GitBash：免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
- MarkdownPad：很好用的在windows上的markdown写作工具。
- VIsio：用于绘制流程图、类图、用例图等等。
2.新工具
- Markdown的使用：简洁又实用的排版风格，更专注于你的写作。
- Photoshop和Illustrator的基本使用：在界面设计时会用到，最终的界面效果是什么样的可以用这些设计出来。规范后再进行敲代码就方便多了。
- 屏幕录制与gif制作：有专门的gif制作工具哈哈。在反映Bug时更清楚明了。
3.新语言、新平台
- github：写的代码都在这里托管，团队协作很方便！
- java：java 语法的基本使用，用于安卓的设计开发。
4.多少行代码
- 说到代码其实自己敲得相对其他组员来说比较少，大概只有5~6百行吧。说来惭愧，有空要多敲代码啊！
5.新方法
- 结对编程：我很提倡结对编程，一个人比较容易开小差，两个人一起的话效率会比较高。自己不想做的时候看另外一位伙伴还在努力，你没有理由去偷懒啊，不过很遗憾的是机会都很少。
- NABCD等之前用到的软工方法：学会如何更加全面地看待问题，在历次的作业中都有所体会。
6.其他
TWO
写下属于自己的人月神话——项目实践中的经验总结+实例/例证结合的分析
经验总结：
- 一定要写注释，这很重要！否则你将看不懂或要花更多时间看懂自己之前写过的代码和队友写过的代码。个人觉得注释不要拘泥于中文还是英文，英文不好就不要用英文，好好用中文也不low。
- 在推送之前记得要检查一下代码是否符合要求，提交之后整合再修改很麻烦
- 有功能更变要及时和组员交流沟通，取得一致意见再定夺
- 每天开站立式会议总结昨天或者前天的任务完成情况，讨论并分配接下来要做的任务。
- 自己的任务做完了要是有空可以帮忙其他组员。不仅自己得到提升、学到知识，而且还增进友谊哈哈哈。
- 要很清楚自己接下来要干什么，什么阶段什么时间做完什么事情，不要拖延，不要找借口。
实例/例证结合分析：
- 前天敲完代码，今天拿起来看，头脑里冒出一句：这些代码是我写的吗？实现了啥功能？ 队友敲完push上去，自己pull下来看，没有注释，又要看半天这些代码是什么作用。过程很繁琐。
- 有一次写完一个功能早早推送上去，推送完之后发现弄错了，可是本地的代码已经被我commit了，之前的也没保存，所以无法版本回退。回退到更早的一个状态后再push，发生了很多的冲突，，，还好之前主master还在，无奈之下只好删除dev分支再重建。
- 有时和组长沟通，觉得这块界面需要改改，再增加一个功能，然后我们就确定下来了，可是却没和其他组员说明情况。等到开会时总结的时候才说出来，结果有些界面做的不一致，又要回头重改。
- 站立式会议是栋哥让我们去实践的。几乎是固定的某个时间段的晚上，然后我们聚在一起，站着总结已经做过的事情偶尔用笔简单记录一下。轮流式总结，说明一下你在编程过程中都碰到了哪些问题，要怎么解决，解决不了再和组员协调一下怎么解决。自由式发言，谁有想法有问题就可以提出来，然后我们就一起讨论，比如说有次界面我不是很满意，和预期想的不一样，所以就提出来和他们商讨看看能不能改变设置界面中的布局。
- 毕竟是一个团队，合作共享、相互帮忙是很重要的。我们有位组员做数据库时，其他组员都过来帮忙，最迟的时候一直忙到两三点才回去睡觉。
- 我一度不清楚自己接下来要干啥，不怎么明白小组接下来的进度。觉得时间也很宽裕，可以明天再做的，于是就一拖再拖，然后到要交付功能的时候，组长头很大，咦？怎么还没做出来？然后就赶紧做，时间也很紧张，人就会很烦躁，就更写不下去。所以有问题要及时解决，不要等到后面像滚雪球一样越滚越大，最后把自己压死。
THREE
对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许
To 学弟学妹们：
- 关于选课
哈哈哈，首先将来的你们也会遇到选课的问题，选择栋哥的软工还是其他老师的呢？因为之前上过栋哥教的c++，觉得还不错，感觉轻轻松松，我想这次的软工应该也不会太折磨人吧。
恰恰相反。
这是一把双刃剑。
如果你是只要学分，或者说不想大三太累，选栋哥水水这门课是不建议的。因为强度很大，密度很高，而且下几届的的强度应该会加大，听说从16级开始还要新开课程？选择这门课的实践极有可能会挂，这不是开玩笑。
如果你想得到锻炼，想尝试一下新的东西，觉得自己大一大二过的实在是浑浑噩噩，不清楚目标，手头敲的代码少得可怜，想知道一个软件是怎么被开发出来的，团队协作是什么感觉？那我推荐一下栋哥的软工。客观地讲，很充实，几乎每周都有新的博客作业，包括个人作业和团队作业。写文档也知道目的性，是为了干什么，而不是盲目地堆砌文字。
但不要盲目的热情，要自己冷静分析自己想要的是什么。 - 关于软工
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。说起来有点麻烦，但可以了解到如何将软工的方法应用到你的开发实践中，可能说的方法已经应用但自己却不知道。除了教材，还要推荐一本书《构建之法》。
To 开学初的老师：
第一次写博客还真是太爽，不过很多博文内容也没怎么继续下去了，这是一个遗憾。写博客的好处栋哥已经说过了，希望继续应用到以后的教学中。
我们的微信群似乎不怎么活跃啊。
FOUR
分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么
-
萌芽阶段
万事开头难，我们小组刚刚成立的时候，都是萌新，完全不懂安卓开发。组员虽然都是同班同学，但平常也挺少碰面，开会的时候都很腼腆。
看到栋哥安排下来的任务后，脑子里想着好难啊，我们这几个小菜能完成吗？要怎么分工才合理？记得在第一次开会要确立选题的时候，大家有想法都没怎么说，不过渐渐的都提了一点，没啥冲突，最后投票选了一下选题。 -
磨合阶段
前期还不明确各自要做什么任务，不过后来组长规划后就逐渐清晰。当其他组员推送代码后自己看了感觉和心中想的不一样，然后就和组长讨论要不要这样做，讨论完之后组长再和组员们讲。虽然问题解决，但还是感觉方法不对，其实私下个别讨论一点不足就是不够清楚明确。
开会的时候会遇到意见分歧，不过发生口角冲突、肢体冲突是没有的。你提出来你的想法，我觉得需要这样，或者说再改改，那我就把自己的意见发表出来，看看大家是怎么认为的。解决冲突的方法主要是追求最大和谐哈哈。
不过主要原因还是学生的小团队性质决定了磨合阶段的磨合程度。 -
规范阶段
马马虎虎到了规范阶段，组长的任务安排更加明晰，谁谁谁做什么都很明确。 某个组员做完推送后另外一个组员pull下来就继续做，基本上没什么冲突。有遇到问题时，就跑到隔壁宿舍去一起讨论解决办法。 -
创造阶段
不知道有没有达到创造阶段，最后的B冲刺有点体会，要把这个功能实现出来，小组们人人都不用再催促了，开会时间也越来越短，而是都把时间花在自己的任务上。
FIVE
阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）
参考论文文献：
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J].
阅读笔记
介绍：
开源软件开发:原型在网上发布,其他程序员可以进行自由地读取、修改。该系统演化速度很快，比传统的封闭项目的速度要快得多。
介绍了开源项目的好处：高品质、高产、高效率，迅速发展，对问题能够更快解决。
很多的软件专家和研究人员提出并讨论了开源的利弊。
Bollinger和他的同事指出：
对于开放的源代码的一个重要要求是，它应该是'严格模块化的，自包含的，自我解释的“，以求得更长远的发展。
测量与开源代码的评估：
芬顿等人提出了测试工具，测量每个部件，评估其四项基本标准，包括可测性、简单性、可读性和自描述。
表1. 质量标准和指标的关系
| 标准 | 相关的指标 |
|---|---|
| 可测性 | VG，MAX_LVLS，N_IO |
| 简单性 | VG，N_STMTS，AVG_S |
| 可读性 | VG，PR_LGTH，MAX_LVLS，AVG_S |
| 自我描述性 | COM_R |
| 可测性的计算公式为： | |
| ** testability = 40CVG+40CMAX_LVLS+20*CN_IO ** | |
| Eventually, for each component a final score is calculated, ranging from 0 to 100, based on the four scores obtained for each one of the criteria mentioned above. | |
| 90-100分表示可以接受，30或者更低的分数表示需要重新开始。 | |
| ** 表2. 根据获得的得分组件分类 ** |
| 建议 | MIN | MAX |
|---|---|---|
| accepted | 90 | 100 |
| commit | 80 | 90 |
| inspect | 50 | 80 |
| test | 30 | 50 |
| rewrite | 0 | 30 |
| 表3. 100 Linux应用程序的源代码测量的统计描述（缩写在文中解释） |
| . | 最小值 | 最大值 | 平均值 | SD | 中位数 |
|---|---|---|---|---|---|
| N_STMTS | 3.00 | 92.00 | 23.43 | 12.25 | 21.65 |
| VG | 1.00 | 35.00 | 7.70 | 4.28 | 7.58 |
| MAX_LVLS | 1.00 | 8.00 | 2.99 | 0.81 | 2.94 |
| N_PATHS | 1.00 | 32767.00 | 1266.34 | 3317.85 | 704.96 |
| UNCOND_J | 0.00 | 1.96 | 0.14 | 0.30 | 0.00 |
| COM_R | 0.00 | 1.32 | 0.11 | 0.15 | 0.08 |
| VOC_F | 1.50 | 9.90 | 2.75 | 0.93 | 2.67 |
| PR_LGTH | 18.00 | 516.00 | 133.68 | 73.17 | 122.82 |
| AVG_S | 3.68 | 14.96 | 6.35 | 1.58 | 5.96 |
| N_IO | 2.00 | 6.03 | 2.92 | 0.77 | 2.80 |
| 表4. 五个推荐类中根据LOGISCOPE组件分配的统计描述®行业标准 |
| . | 最小值 | 最大值 | 平均值 | SD | 中位数 |
|---|---|---|---|---|---|
| ACCEPT（％） | 0.00 | 100.00 | 50.18 | 18.65 | 48.37 |
| COMMENT（％） | 0.00 | 66.66 | 30.95 | 14.09 | 31.83 |
| INSPEC（％） | 0.00 | 50.00 | 50.00 | 8.55 | 8.50 |
| TEST（％） | 0.00 | 16.00 | 4.31 | 4.14 | 3.55 |
| REWRIT（％） | 0.00 | 100.00 | 5.57 | 10.73 | 3.20 |
| UNDEFI（％） | 0.00 | 7.69 | 0.42 | 1.29 | 0.00 |
组件的尺寸和用户满意度：
用户满意度评级：
A 用户体验几乎察觉不到错误。
B 主要程序功能正常运行，但有一个小的功能有错误或者被禁用。
C 至少有一个主要的功能有错误或者被禁用。
# 程序无法运行。
指标结果：
（其中纵坐标N_STMTS表示程序语句数目，横坐标USRSAT表示用户满意度）
（其中纵坐标PR_LGTH表示节目长度，横坐标USRSAT表示用户满意度）
讨论：
工业标准LOGSCOPE的比较结果：
1.构造代码质量的Linux应用程序提供的结果高于期望值，开发过程中一直遵循着有限的控制。
2.Linux应用程序的结构代码质量提供的结果低于标准所隐含的质量。
第一个结果有利于开源的开发，而第二个不利于开源开发。
有助于实现高质量代码的三个不同做法：
1.当干预代码时，可以要求程序员考虑结构代码的质量。
2.项目统筹能够评估根据预定标准由程序员返回的代码的质量。这意味着，某些组件，不符合标准被改为符合标准，可能会被拒绝即使他们提供正确的bug修复和新功能。
3.每当项目似乎遇到严重问题，项目协调员可以采取适当的代码重新设计决策。
结论与未来研究：
无。
自我代码评估
我喜欢简单易懂的代码，至少自己理解上不会出现差错，所以写代码的时候都力求简洁，另一方面也是自己的水平很菜，写不出高大上的代码。
写代码习惯注释，没有注释回头再看代码很痛苦，不能立即在大脑里反应出这段代码实现了什么，所以我每写完一小段代码都带上一点注释，以备查询。自我来说可读性一般般。
大泥球是肯定有的，多敲代码多看书得到改善吧！
SIX
怎样证明你学会了软件工程？
研发出符合用户需求的软件
通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
并且通过数据展现软件是可以维护和继续发展的
- 我们开发的软件是一款名叫松鼠摘的记事类软件，目前还不是很完善，在个别机子中的兼容性很低，也就在自己周边同学的机上运行使用过，还没有推广开。
- 项目规划/需求/设计/实现等等请参考我们的团队博客：（博客地址）。情况有好有坏吧，有时候大家可以顺利写完，有时候又要加班加点熬夜赶制。
- 教材说写代码的时候只占整个过程的20%，可是自己感觉下来大部分时间都是在写代码，写功能，改bug。软件的是可维护的在我的阅读笔记中第一段有所体现，这点很重要。我们自己写的代码没有太按照规格说明书中的代码规范，这是一大缺憾。
SEVEN
写一段话，介绍下你自己吧
我是来自计算机4班的李陈辉，很高兴认识大家。
从c++选课的时候认识的张栋老师，不过在上课之前就见过面了。那时候他刚刚当上我们实验班的班主任，临时要开一次实验班班会。他站在讲台上， 在玩手机陆陆续续看同学们走近教室。对老师的初次印象就是他有点紧张，可能是被选为班主任有点激动吧。。。
我这样写，老师可能就会记得我：噢，这个同学是第一个说我上课有点紧张的人。
我写博客一般简洁，符合markdown精神，就不装饰了哈哈哈哈哈哈
以上。
