个人作业——软件工程实践总结&个人技术博客
| 这个作业属于哪个课程 | 班级链接 |
|---|---|
| 这个作业要求在哪里 | 作业链接 |
| 这个作业的目标 | 总结 |
| 作业正文 | 链接 |
一、回望
（1）对比
对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强软件工程专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
课程刚开始时并没有什么特别的期待和目标，心里想着是：不就是写代码、做项目嘛，又不是没做过。但当时没想到的是，团队作业由我担任组长，要管理整个小组。团队作业结束后，在管理队伍这方面超出了我预期，这个任务确实不是那么简单，也存在不少不足，比如在追踪组员进度上并没有做的很好，导致了整体进度的滞后，整体的分工规划并不是特别完美等等。不过好在beta阶段也算是顺利完成，给这次的团队任务画上了个不错的句号。
（2）检验
你在第一次作业的个人简历中制定的这门课程结束后，你预期你将增长的能力、技术、技能；和你针对你的目标绘制的学习路线图。对比当前你的所学所得，你达到了当时的预期值吗？
学习路线虽然并没有严格按照当初绘制的执行，但基本上还是有覆盖到大部分，虽然学到的东西都没有用在这次的课程中，但也算是符合预期了。
（3）总结
i. 统计
统计一下，你在这门软件工程实践中，一共完成了多少行的代码；
软工实践的各次作业分别花了多少时间？（做一个列表）
累计花了多少个小时在软工实践上？平均每周花多少个小时？
| 作业名 | 代码行数 | 时间 |
|---|---|---|
| 个人作业——疫情统计 | 500 | 10-15h |
| 个人作业——软件评测 | 12h | |
| 结对作业——疫情统计可视化 | 1400 | 15-20h |
| 结对作业——原型设计 | 10h | |
| 团队作业——Github实战训练 | 800 | 12h |
| 团队作业——需求分析 | 10h | |
| 团队作业——项目系统设计与数据库设计 | 15h | |
| 团队作业——alpha冲刺 | 1700 | 25h+ |
| 团队作业——beta冲刺 | 后端：2300 前端：800 | 20h+ |
| 总计 | 7500 | 130+h |
ii. 印象最深刻的作业
哪一次作业让你印象最深刻？为什么？
github实战训练， 要求一天之内完成一个项目是我没想到的，而且那天刚开始时还不知道deadline就一天，上午还在干其他事情。最后应该算是完成的不错了，虽然还有着不少的bug，但这次作业的体验确实不错。
iii. 学会的东西
学习和使用的新软件；
学习和使用的新工具；
学习和掌握的新语言、新平台；
学习和掌握的新方法；
工程能力的提升；
团队合作上的提升；
其他方面的提升；
技术上学到的新东西不多，大部分都是啃老本。
团队合作上确实学到了不少东西，比如处理合作中出现的各种问题，分配任务，规划日程等都有或多或少学到点新东西。
二、团队总结
软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
你在团队中担任了什么角色？你是否完成了该角色的任务？现在你觉得你适合该角色吗？
1、 如果你是组长，你觉得你有哪些地方做的不够好的？有哪些地方做的好的？你觉得该怎么改进？（详细描述）
2、 如果你是组员，你觉得你的组长分工安排是否合理？你对组长的选举有什么建议？
3、 你这学期经历过换组吗？你对换组有哪些看法？谈谈你在这个过程中的感受。
4、 分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建之法》第17章 人、绩效和职业道德）
1. 团队角色
作为组长，我觉得我在安排日程上不够好。比如在alpha冲刺阶段任务发布时，因为个人原因（懒），拖了几天才开始规划安排，以至于冲刺开始和结束都比较晚，也导致了alpha阶段后续没有足够的缓冲时间，未能完成所有任务。所以在beta阶段我提早了开始时间，留下较多的缓冲时间去收尾。
2. 换组
换组的话我最早是没什么想法的，只要我和前端的负责人没被换掉，怎么换都不会影响太多。换组时有组员和其他组商量了后，表示可以互相换组，看到都没有什么意见后，后续也没管太多，想着beta开始前看情况分配点任务就好了，没想到新来的组员开始时并没有回复我们的询问，直到beta冲刺开始后才回话，可这时能分配的任务都分配出去了，没有多余的任务可以分配了，只好让她熟悉下我们的产品，给出点用户反馈。
至于换组这个做法我并不是很看好，按照助教博客里提到的原因，是想模拟真实的人员流动。但是想还原的情景大都是人员为了自己主动提出想要离职，而在课程中的换组被换的人或多或少都带有点被迫、不得已、为了作业能顺利进行的心情去交换的，这无论是对小组还是被换的人都不是什么很好的体验。
3. 分析
我觉得团队大概处在磨合期。现在是大三下学期，大家都很忙，每个人都有着考研or工作的目标，并没有多少时间来优化团队运作。
三、人月神话
1. 软件工程
1、怎样证明你学会了软件工程？以下要求你们的团队达到了哪几个？请在随笔中用数据证明上述内容或侧重选择之一。
（1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
（2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
（3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
后端开发时全程使用git进行版本控制，每一个功能的更新都有相应的commit记录
接口在开发过程中同时编写接口文档，每个接口都有着详细地说明，保证前端在调用时可以正确的使用，也保证了后端重构接口时不会设置与原先不一样的接口
同时在接口文档完成后，每次更新接口也都会写上相应的更新内容，确保前端及时发现更新点并进行更新
2. 我的人月神话
2、写下属于你自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析，文字部分字数要求在100字以上，可以使用你自己喜欢的方式表达（如图文结合、视频）..
"Make it work, make it right, make it fast."
这是我非常喜欢的一句话。道理很简单，就是先让程序能够跑起来。早期我写代码时很容易陷入“这种写法肯定不是最简单的写法，我应该去优化——优化的方式太复杂了，我需要点时间去研究——研究不出来，我写不下去了”这种状态，这也导致了我经常写些小玩意儿会半途而废。所以我经常会把这句话念叨在嘴边，提醒自己不要想复杂。
开发项目也可以符合这一做法。过早地使用大量设计模式，甚至为了设计模式而设计模式，做出来的程序往往复杂而臃肿，甚至运行不起来。所以可以最低限度地做出满足项目需求的程序，将初步结果拿出来演示，根据反馈快速调整，之后再适当重构优化，使得其易于维护和扩张，最后再对其性能进行优化。
四、建议
对下一届同学的建议。
提前做好准备，确保自己有一定的技术力来参与课程。
对于软工实践课程，你有哪些建议？
强烈建议这门课移到大三上学期。无论是对要秋招还是考研的人来说，大三下学期太重要了。
对于助教工作，你有哪些建议？
希望能多分享点项目开发的经验。
对于自己今后，你有哪些建言？
加油吧！
