- 课程名称： 软件工程1916|W（福州大学）
- 作业要求： 个人作业——软件工程实践总结作业
- 学号： 221600131
- 作业目标：软工实践总结
作业正文
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
"课程实现目标： 希望能从业界的工程师助教那里学到实际项目的开发模式，尝试一些之前没学过的新技术。"
- 这是我在准备篇博客写下的对软工实践课程的目标与期待。而我确实在这门课的过程中查阅学习了很多业界流行的开发规范和开发工具注入整个团队项目之中，提高了团队的配合开发效率。并且我深入学习了之前只是浅尝辄止的Vue框架，最终带领团队开发了组件化开发的单网页富应用web。
- 不足的是其实我更想写后端，因为我有点完美主义写前端会一直调样式，样式优化是很费时间的。并且我之后并不准备从事前端开发，后端开发其实更有助于今后的发展。但是团队里缺乏擅长前端的队员，UI对官网又尤为重要，因此身为队长只能担下这个责任重新去看Vue文档学习。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
- 我们的团队项目前端总共包含了133个.vue文件（不算外部css和js文件），因为客户端还做了对900-1440px与900px以下宽度的两版css适配，所以客户端展示部分的.vue文件的css代码都是1500行起步。保守估计就团队项目部分我应该至少完成3.5w行的代码。
2、软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业名称 | 时间 |
|---|---|
| 第一次作业-准备篇 | 2 |
| 结对作业第一次—原型设计（文献摘要热词统计） | 8 |
| 结对作业第二次—文献摘要热词统计及进阶需求 | 6 |
| 团队作业第一次—团队展示 | 2 |
| 团队作业第二次—项目选题报告 | 6 |
| 团队作业第三次-项目原型设计 | 20 |
| 团队作业第四次-项目需求分析 | 6 |
| 团队作业第五次—项目系统设计与数据库设计 | 8 |
| 团队作业第六次—团队Github实战训练 | 8 |
| 项目Alpha冲刺（团队） | 40 |
| 事后诸葛亮（团队） | 2 |
| 项目Beta冲刺（团队） | 70 |
| Beta阶段团队项目互评 | 1 |
| 个人作业——软件工程实践总结作业 | 2 |
3、哪一次作业让你印象最深刻？为什么？
- Beta冲刺作业。因为短时间内工作量巨大，尽管面临了期末复习、比赛、srtp结题、论文撰写等多重压力，还是将其它暂时搁置专心beta冲刺。
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
- 根据第2个问题的表格统计花费总时间为181小时。按13周计算每周花14小时。
5、学习和使用的新软件和新工具；
- 原型设计： 墨刀
- 单元测试：easy-mock、SwaggerUI
- 版本管理： Gitlab搭建
- 代码规范： ESlint
6、学习和掌握的新语言、新平台
- 前端框架: Vue
7、学习和掌握的新方法；
- 快速搭建单网页富应用web app
- 自动化测试
- 团队配合的git规范
8、其他方面的提升。
- 团队领导能力，协作沟通能力。
- 对软件项目开发的把控能力。
- 多任务并行处理能力及抗压能力。
- 写博客总结学习知识
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 一个人或两个人开发的时候可能不会注意太多，但是多人一起参与开发的时候就要注重很多之前没有注意到的问题。例如代码规范、版本管理、变更管理等项目管理控制的问题。如果在项目前期没有预防，制定好计划，等项目中期可能会消耗大量的时间去调整已写好的代码。
- 例如尽管项目开始前作业含有一项制定代码规范，但到实际开发中很难记得清都有哪些约束。而如果大家都随心所欲，最后整合起来的代码一定是风格迥异，阅读性差。因此我在前端使用ESlint写好代码规范的脚本，若不遵循规范则会报错并指引错误位置，做到了代码规范的统一。
- 最后很开心带领团队中有四人获得了小黄衫。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
- 首先是关于课程调整的建议，当然我知道这个得跟学院沟通，实现难度很大，不行的话就当作吐槽吧。第一点建议课程时间可以放在前面的学期。在当前升学率逐渐升高的背景下，大三下同学们的情况都是保研的准备夏令营，考研准备考研复习，留学的备战雅思托福GRE等。虽然我们都知道多学多得，对自己绝没有坏处。但在大三下这个关键节点往往还要考虑优先级的关系，短时间内什么是最有必要的选择。另一方面如果学生能较早地经过完整项目实践的洗礼，到了大三其实会更清楚地知道自己的不足和兴趣方向在哪里，进而去有针对地发展。第二点是可以提高软工实践的学分。这个工作量巨大的课程只有1.5学分，难免有些人会“战略性”划水，优先保证其它学分更高的课程。这样无法达到软工实践的目的。
- 关于课程开展的建议，我认为助教可以在开发过程中多进行一些技术指导。如果一个团队中没有人完整接触过项目开发，自己短时间摸索出来的作品是很难达到要求的。可能表面看起来能跑，但根本经不起测试，更不用谈及功能的拓展和维护。相对而言，如果在有人引导下经历一段规范的开发流程，短时间内的提升会更大。而需求分析、软件设计、测试等环节在理论课都已经详细介绍，基本不会出现束手无策的情况。
- 关于换队友的建议其实我之前在群里提过。换队友可以模拟企业宣讲、招聘、面试这样的流程。每个团队上台介绍他们的开发项目和招聘岗位（可能前期组队过程中没有考虑到需要某个位置的队员），让其它所有团队都至少出一人来投递简历面试。最后进行一个双向选择的过程。这样双方自愿，才能更好地继续接下来的工作，也更大程度地模拟了现实场景。特别是还能给某些不满足于所在团队现状的人一个跳槽的机会。随机分配就可能会出现想走的走不了，不想走的恋恋不舍的情况。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- 我认为目前团队还未到创造阶段。因为整个软工实践团队开发的时间实在非常有限，我又担负了大量的开发工作，所以主要精力是针对项目制定开发配合的规范。
五、怎样证明你学会了软件工程？
-
不知如何证明，就简单说一下我在团队项目中是如何进行管理的吧。
-
在团队项目中除了我在第二个问题中举的进行代码规范的控制，我对团队配合规范也进行规定。首先为团队制定git配合规范，基于master建立development分支用来开发，基于dev分支建立了各模块的feature分支，这样分支之间几乎没有耦合，不会存在合并冲突的情况。同时基于master建立release分支作为项目发布版本的分支。
-
为了方便前端开发的接口对接，后端将所有接口文档上传至gitlab上的api文件夹，前端开发人员只需在gitlab便可以查看所有后端接口和相应的更新时间。
-
同时为了便捷后期网站维护人员对bug的定位，我对项目的目录框架和命名也进行规范。在views和components文件夹中分别先建立admin（管理端）、client（客户端）、common三个文件夹。common文件夹主要存放对管理员端和客户端共同复用的组件（如下拉框、导航栏等）和页面（如登陆、404、403页面等）；
而在admin、client分别按照网站模块建立文件夹。客户端的views中的目录与components中目录完全相同，管理端同理。
views里的页面文件统一以index命名。
综上，这样有页面出bug后，即使未参与开发的维护人员也能根据目录快速锁定出错文件。 -
在达到代码规范和配合规范的一定要求，团队可以较有效率地进行配合开发之后，我们对代码质量也有要求。项目前后端都是采用MVC架构，大量封装底层代码，从而保证代码的复用性、可维护性、可拓展性。以前端为例，我们在alpha阶段主要对项目所需组件进行整理统计，接着统一开发单文件组件为项目铺好基础，之后在beta阶段只需在页面文件中直接引用组件进行使用，再根据布局修改css样式，而不必关心组件的内部逻辑。这样减少代码冗余的同时，页面出现问题只需找到组件文件修改，而不会影响该页面的其它部分。
七、个性发挥，包括图文、照片和创意等
那周鱼加熊掌兼得。