一、软工初印象
-
期待、目标和不足
- 期待：坦诚的说，一开始没有很多期望，想着组队水一水，过了就行了，在组队后却成了队长，就期望着能和大家一起做东西出来，能让每个人得到不错的分数，以及有好的收获。
- 不足：没有负责项目的代码部分，是很可惜的一点，但也是自己的选择，会利用寒假的时间去弥补这样的遗憾。
- 目标：希望能在寒假完善好小二结账的商家端，也通过这个过程，弥补下在软工实践中缺失的部分。
-
提升总结
-
代码行数
- 软工实践的代码大量集中在团队项目中，而我本身在团队项目中不主要负责代码部分，所以个人主要代码分布在个人项目和结对项目的代码，以及部分团队项目中的代码，一共只有只有1140行左右
-
作业时间列表
作业名称 耗时(h) 任务 软工实践第一次作业 2 跟随问题引导，反思自己，做出预期 个人作业-词频统计 15 复习c++，学习github使用 第三次作业-结对作业（原型设计） 2 接触墨刀，尝试原型设计 第四次作业 - 团队展示 5 设计团队头像，确定项目，开会讨论并拍照 第五次作业 - 结对作业2 10 负责文本处理部分的代码 第六次作业 - 团队答辩 10 开会确定团队的分配和管理，书写博客，ppt制作演讲 项目UML设计 3 开了临时会议，紧急分配任务，并去别组制作UML图 需求分析报告 10 项目logo设计，思维导图制作，博客整理 团队现场编程实战（抽奖系统） 8 进度协调，需求分析，博客、文案撰写，演示视频制作 Alpha 冲刺 50 机动+任务分配+答辩准备+美工设计+答辩准备+博客整理+拍摄演示视频 Alpha 事后诸葛亮 1 博客整理，alpha反思，beta 计划 项目测评（团队） 6 任务分配，ppt制作，演讲，博客整理 BETA 版冲刺前准备（团队） 1 组织会议，反思总结，分配任务，博客撰写 Beta 冲刺 30 机动+任务分配+答辩准备+美工设计+答辩准备+博客整理+拍摄演示视频 本次作业 3 反思总结，博客撰写 总计 221 -
印象最深刻的作业
- 现场编程实战作业
- 我们在头一天的熬夜开会做了准备，提前配置好了了编程环境，在第二天拿到题目后，从一开始的懵逼，到冷静下来后的分析、分配和构建，到紧张编程到最后没有做出东西，再到任务的重新分配，以及之后一个下午+一个晚上的团队编程，最后终于成功做出东西并提交github。经历了一个软件完整的构建过程，有deadline的刺激、有团队的协作，有失败、有反思、有调整，最终也有了一个好的结果。是很棒、很难忘的经历！
-
累计时长
- 累计大约花了221个小时，按15周次来算，平均每周14个小时
-
-
学习和使用的新软件
- typora可以编辑markdown
- 有道云笔记可以做笔记
- 墨刀可以做原型设计
- powerpoint的功能非常丰富且强大
- 格式工厂对文件格式转换的处理很棒
-
学习和掌握的新语言、新平台
- 小程序开发平台
- 学习了部分小程序的开发语言
-
学习和掌握的新方法
- markdown语法排版简洁明了
- 创客贴和千图网都是很棒的素材网站
- 阿里巴巴矢量图库有很多矢量素材，可以做ppt
-
其他方面的提升
- 做了三次ppt答辩，演讲方面得到了锻炼，提升空间很大
- 做了四次ppt，收集了很多素材，也多了些设计思路
- 博客整理，让我做笔记的整理更简洁、明了
- 有道云笔记很好用，多端同步，很方便
二、人月神话
个人作业
个人作业难度是经过老师和助教讨论过控制在合理范围内的，对这个难度我觉得是，班上绝大部分同学自身通过花费时间学习，就可以完成地不错，但结果并不是绝大部分同学都能完成地很好，包括我自己也一样，排除个人能力的差异以外，更多的还是态度差异，有的人“想着怎么去完成作业”，有的人“想着怎么完成好作业”，类似于这样的态度差异，也决定了最终结果上的差异。
团队作业
在团队作业中当了小组长，所以对团队领导者的角色有了新的认识，作为一个好的团队领导者应该有两个基本的品质：一个是团队中必要且领先的个人能力，另一个是足够的个人魅力。
作为我自己来说，在整个过程中，因为没有参与代码编写部分，在后期会感觉到与团队脱节，而作为队长又会大概率承担一些与项目无关的以外的事情，花费了很多时间，但却对自己的所需要的能力的成长帮助不大。所以我自己以后不会像这次软工一样，在没有相关能力和好的考虑情况下，草率地担任一个团队的领导者，那样对自己和对团队都不能够很好地担负责任，可能作为一个组员在团队中工作，提高自己的核心业务能力，同时向好的领导者学习管理经验，会是一个更好的选择。
三、前车之鉴
-
建议、告知和期许
- 期许：希望他们对自己想做的东西，能有更创新有趣的想法，也希望他们能收获自己想要的东西。
- 建议：建议每个人都要参与代码的编程，不要留下和我一样的遗憾。
- 告知：少熬夜！少熬夜！少熬夜！
-
跳槽建议
交换队员，更建议采取自愿，强制换队本意是好的，但这种骚操作很难把控利弊，容易翻车，造成不好的结果。
-
人数
人数在6-7人比较合适，任务量、沟通交流、团队协作都比较有利。
-
作业规模
- 个人作业：难度上，希望能让多数同学通过查询和学习能独立完成；任务量上，希望平均能在10h左右完成比较好。
- 结对作业：难度上，还是要能让大多数人通过努力做出来，任务量上平坦下来，平均每个人在7-8h左右比较好。
- 团队作业：团队项目因为是各组自定、老师审核，所以觉得提醒同学们，按自己的实际情况去自己选择项目的难度即可，作业量的话希望能简化一些内容，比如：每天的冲刺博客这种，虽然是课程要求，但做到最后反而成了负担，没有了促进作用。
-
感谢的人
感谢刘浩同学，从结对作业到团队作业都给了我很多的帮助，也向他学习了很多东西，具体不想谈，放在心里就好。
四、团队分析
回想起来，我们小组一路走过来还是很不容易。最初组建时候，人员配置缺少大佬和有开发经验的同学，队内其实有一种不够自信的因素在其中；到第一次答辩的项目选题答辩的时候，尽管答辩成绩还不错，但答辩结束后却又两位同学选择跳槽，成为全班唯二的跳槽同学。整个小组就显得有些出师不利、摇摇欲坠的感觉；然后，随着时间的推移，和不断的调整和努力，团队在一次又一次答辩中取得了不错的成绩，整个团队信心也越来越足，技术上也越来越成熟，不断遇到新的问题，不断解决新的问题；最后完成了完整的项目，也取得了不错的成绩，大家都收获很多，非常感谢这段经历！
五、软件工程
怎么证明你学会了软件工程？哈哈，对我而言这是个伪命题，当然是无法证明的。用一个学期的时间在课程要求的引导下，经历了一个完整的软件工程，用期末的三天时间粗读了软工的理论，所以不敢说自己学会了软件工程，只能是对整个软件工程的过程有所体悟，也在整个过程中有了新的收获。
对于项目的发布其实是比较可惜的一点，因为我们项目是基于微信平台的小程序，又涉及到支付的功能，所以本身具有很大的资质限制性，尽管我们已经尽最大努力去达成小程序的发布，但最终还是因为一个无法搞定的资质证书，宣告发布失败。但尽管如此，我们对项目自身的需求和可用性来讲都很有信心，作为一个软件也实现了完整的功能和交互。
六、阅读笔记
参考文献：
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
这篇论文主要介绍了关于开源软件的开发。开源项目的代码需要是”严格模块化，自包含，自我解释“，由于其它程序员可以自由读取、修改，加快了系统的演化速度，而审核代码质量的关键在于带啊吗是否有注释，编码是否贵伐以及代码的可扩展性和移植性。
七、个性发挥
- 个人很喜欢自己为项目设计的宣传海报，所以最后的最后附在这里
