软工实践——个人技术总结

个人作业——软件工程实践总结&个人技术博客

这个作业属于	2020软工实践W班
这个作业要求在	作业要求
作业目标	个人与团队技术总结
作业正文	如下
其他文献	<《构建之法》>

• deline 2020-06-15 23:00

一.回望

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

• 在开篇博客中，我选择学习的是linux等系统与网络等相关方面知识的学习，在本学期的所学所练中主要是对软件工程的学习以及结对/团队项目的练习开发，采用的主要是java方面的知识，在框架技术与java编程等方面本人技术与理论提升还是显著的，但也因此在日常学习中对最初的系统与网络方面的知识学习较少，不过也有安排时间进行学习，只是进度还未达到之前定下的目标还是需要努力。

你在第一次作业的个人简历中制定的这门课程结束后，你预期你将增长的能力、技术、技能；和你针对你的目标绘制的学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？

• 预期一：提升团队协作能力

  不论是本学习的结对任务还是之后的团队协作开发项目，每一个都是对团队成员的团队协作能力的提升，因此对于团队协作方面，在本学期的锻炼之中还是提升显著的。

• 预期二：加深对linux的开发与运维技术

  对于这个预期，当初指定了相对应的学习计划，但是现今的进度还是与预期有所差距，还处于Linux中级知识（相关文件管理机制，服务器安全策略等）的学习。

请总结这门课程的实践总结和给你带来的提升

统计一下，你在这门软件工程实践中，一共完成了多少行的代码；

• 在软件工程实践中，从刚开始的个人作业，结对原型实现到后来的团队项目开发，总体来说加起来大约也有四千行代码。

软工实践的各次作业分别花了多少时间？（做一个列表）

历次作业	耗时/h
准备篇	3h
热身篇	12h
结对第一次——结对原型设计	5h
团队第一次——种子选拔	3h
结对第二种——疫情可视化实现	16h
团队第二次——团队Git训练	11h
团队第三次——项目需求分析	4h
团队第四次——系统与数据库分析	7h
个人作业——软件评测	5h
团队第五次——站立时会议与alpha冲刺	34h
团队第六次——beta冲刺+事后诸葛亮	28h

哪一次作业让你印象最深刻？为什么？

• 要说哪一次作业对我印象最深我估计是热身篇——疫情统计了，因为那一次作业由自己一人完成，花费时间还算是比较多的了，也算是比较独立的实现一个有用的程序，实现完成后询问周围同学的进度与代码量，惊奇的发现有的同学只用了400行左右的代码，想想自己用了进900行代码才完成，才发现自己的编码能力还是非常欠缺。以及之后在作业成绩发布之后也不尽人意，可能实现完成后没有进行详细的测试存在一些bug导致成绩的不理想，总的来说还是得认真努力与思考啊。

累计花了多少个小时在软工实践上？平均每周花多少个小时？

• 累计加起来花费的时间大概也有128h平均每周7.5h左右

学习和使用的新软件；

• 新软件Git Desktop，IDEA，Xmind，Typora，JProfiler，starUML，墨刀，Axure等。

学习和掌握的新语言、新平台；

• 暂无。

学习和掌握的新方法；

• 包含多种设计模式的方法。

工程能力的提升；

• 在项目系统、数据库设计，java编码，框架开发，代码复审与整合上都有显著的提升。

团队合作上的提升；

• 团队协作上有较大的提升，在团队开发中团队协作的能力得到了充分的锻炼。

其他方面的提升；

• 除了以上的提升外，其他的可能就是学习到了一些工具来协助开发。

二.团队总结

你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？

• 在团队中我主要担任的是后端开发者的角色，总体来说还是完成了该角色的任务，也算较为适合。

如果你是组员，你觉得你的组长分工安排是否合理？你对组长的选举有什么建议？

• 较为合理，选举得话我认为主要要考察三个方面，技术、沟通、与抗压。

你这学期经历过换组吗？你对换组有哪些看法？谈谈你在这个过程中的感受。

• 没有，换组的话感觉是对个人试应能力的一种锻炼，要想在不熟悉的环境下完美完成下发的任务还是需要与其他组员进行充分的沟通，也是对团队协作能力的锻炼。

软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么?

• 目前团队达到了规范得阶段，离创造阶段还有些差距还需继续努力。

三.人月神话

怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？请在随笔中用数据证明上述内容或侧重选择之一。

• 我们的团队项目是可以维护和继续发展的，我们的项目都有上传到github上，属于一项开源项目，同时我们的系统与数据库设计文档也有上传到github，同时我们的项目编码风格统一，制定有相关代码规范，对于代码也有详细的注释说明，以及我们的接口文档清晰易懂可以对于后续开发人员非常友好。

  项目github地址

写下属于你自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析，文字部分字数要求在100字以上，可以使用你自己喜欢的方式表达（如图文结合、视频）..

• 刚开始看到《人月神话》还不知道这是啥，百度了解了下感觉书中的一些内容说的真的很不错，以下先引用书中的名句再结合自己的项目阐述

乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误”

• 首先不得不说近乎所有人在开发的时候包括我自己总是秉持着一颗乐观的心态，就如书中所说，在系统测试或者bug修复过程中我们总是觉得自己的操作已经很完美了，但是有时候结果往往还是与期待不符。在团队项目中有一次在交付接口代码时，前端进行测试获取数据出错，那时候审视了好几次代码，修复了一些潜在的bug总以为应该可以了，然而事实证明墨菲定律是正确的，该发生的还是会发生，盲目的乐观并不能改变什么，当然菜是原罪。现在想想还是bug调试经验不足，没法准确的定位哪里出的错误。现在想想我们都没办法保证写出的代码没有一点bug，因此我们不能盲目的认为这个bug修复完了就完美了，盲目的乐观只能让我们失去应持有的严谨，修复bug后正确的做法不是就万事大吉了，更应该应该做出记录和总结防止再犯。

人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。

• 这句话给我的感触也很深，在团队开发过程中很多时候的确并不是人越多做的越快，人多了意味着通讯耗时也增加了，如果任务没有清楚的下发，那所耗的时间往往会更甚与人少之时，不仅如此还增加了人力资源的损耗。

为变更计划系统 变更的阶段化是一种必要技术。每个产品都应该有相应的数字版本号

• 这一点主要是体现在我们项目接口设计中，我们都知道没有一种设计一开始就是完美的不需要变更的，我们项目接口都有相应的数字版本号，来表示接口的变更，也方便了后期接口的整合。

前进一步，后退两步 程序维护中的一个问题﹣缺陷修复总会以固定（20%~50%）的几率引入新的bug

• 确实bug的修复有时候会产生新的bug，这就像一个连锁反应，每个功能模块之间相关联，你修改这个模块就有可能影响那个模块，最后导致bug的不断产生。这也充分说明了前期设计的重要性，一个好的设计能够让一个项目做到高内聚低耦合的程度，功能模块之间独立了，彼此产生的影响才能缩减到最小。

在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。

• 我们团队的进度安排较为合理，所以可能没有体会到不合理的时间进度会产生什么影响。但是我知道没有合理的时间规划，合理的进度安排，对一个项目来说简直是致命的。时间安排长了，后续可能时间不足，项目后滞，安排短了，就可能出现大幅减低项目质量来追求开发速度的现象，因此项目开发前最为重要的工作之一无疑是总体进度的安排。

四.建议

对下一届同学的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？请写下你对后来人的期许。

• 对于下一届得同学的建议大概就是基础功要打好，可以多去拓广自己的知识层面，尽早发现自己感兴趣的今后想发展的方向，然后向那个方面努力，同时呢也可以多向优秀的学长学姐们交流，请教经验也可以少走很多弯路。

对于软工实践课程，你有哪些建议？

• 软件工程实践课程到现在为止总体来说我认为还是挺完善的，老师布置的任务都很能锻炼我们各方面的能力，同时还能加深理论课方面知识的实际应用学习。

对于助教工作，你有哪些建议？

• 本学期的助教我认为也很棒，会给学弟学妹们分享相关的经验，建议的话暂时没有（可能因为工作做的太好了）

对于自己今后，你有哪些建言？

• 继续努力吧，不要懈怠。

五.个人技术总结

技术概述：说起来也不算什么技术，主要是Linux学习过程中偶然发现的实用性小玩意，基于Linux发行版本Ubuntu安装配置Nextcloud可以作为一个实用性的私人网盘。

博客链接：基于Ubuntu系统下的Nextcloud手动安装