クラス：ソフトウェア工学1916 | W
操作：個々の割り当て-ソフトウェア工学の実践は、ジョブに
学生番号：221 600 420
ジョブの目標：自分の柔らかい労働慣行を要約します
まず、最初の夏の仕事を振り返ってください、あなたはソフトウェア工学コースのための想像します
1）コントラスト開口ブログあなたのコースの目標や期待、どのようなアップあなたの期待と目標にして得られる電流を学び、練習に比べて、「私はコンピュータ専門的スキルと雇用と競争力を強化するために、練習や訓練を通じてことを願っています」、そのそこに尊敬の何不足、なぜ？
で、冒頭、私は私の目標を述べたとことを楽しみにして：
コースに合格することができ、全体のプロセスは、実際のプロジェクトを完了し、独自のコードのスキル、チームワークのスキルを高めています。
全体的に、到達するための目標はありますが、改善の余地がコーディネートチームの面で依然として存在しています
2）コースの実践の概要をまとめたもので、あなたをもたらすためにアップグレードし、以下を含む：
ドアであなたについて1.統計そのソフトウェアエンジニアリングの実践、完成したコードの行数;
によるとcloc、統計、ファイルの総数66（42 JSファイルを含む、サス20ファイル）、行の合計数は、（JSコードの2979行とコードサスの725本のラインを含む）3818本のラインである
：参照コードの量CLOC統計を使用します
2.各タイムの仕事労働慣行は、ソフトに多くの時間を費やしたのですか？（リストを作成します）
| いいえ。 | 仕事 | 時間 |
|---|---|---|
| 1 | 初めての個人的な仕事 - 論文を準備します | 3 |
| 2 | 初めてペアの仕事 - プロトタイピング（ホット言葉の統計情報を抽象化） | 14 |
| 3 | ペアジョブ二度目 - 抄録熱い言葉の統計情報と高度な需要 | 17 |
| 4 | 最初のチームワーク - チームショー | 1 |
| 5 | 第二チームワーク - プロジェクト選択レポート | 10 |
| 6 | 第三チームワーク - プロジェクトプロトタイピング | 12 |
| 7 | 第四チームワーク - プロジェクトは、分析を必要とします | 8 |
| 8 | 第五チームワーク - プロジェクトシステム設計やデータベース設計 | 10 |
| 9 | 第六チームワーク - 戦闘訓練チームのGithub | 9 |
| 10 | チームワークセブンス - プロジェクトアルファスプリント | 30 |
| 11 | 第八チームワーク - 後知恵 | 2 |
| 12 | 团队作业第九次—项目Beta冲刺 | 21 |
| 13 | 团队作业第十次—Beta阶段团队项目互评 | 5 |
| 14 | 个人作业第二次—软件工程实践总结作业 | 3 |
| 总计 | 145 |
3. 哪一次作业让你印象最深刻？为什么？
【团队作业第六次—团队Github实战训练】的印象最深。
当时由于自己有点其他的事，然后这个作业的时间又比较赶。原本以为自己一天应该能够完美搞定这个作业，但是实践后才知道bug多多，不断踩坑，最终还是熬夜加班才把bug改完并部署。也算作是alpha冲刺前的一次练兵，对alpha冲刺也有一定的帮助。
4. 累计花了多少个小时在软工实践上？平均每周花多少个小时？
总的大致应该有145+小时（包含问题2中列出的时间及答辩等时间），平均每周大概有12+小时
5. 学习和使用的新软件&新工具；
VS Code、墨刀、GitHub
6. 学习和掌握的新语言、新平台；
React框架、Taro框架
7. 学习和掌握的新方法；
前端UI组件的单元测试方法
8. 其他方面的提升。
对于团队的协调及管理
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
团队成员如果没有一开始就定义好相关的文档、接口等，会在后面不断的掉坑里，尤其是在某一个成员改动了某一块内容后，如果没有及时通知到相关成员身上，可能会引起不必要的争执...
比如在beta阶段，甲同学改动某功能后，觉得得把数据库中的字段A改成字段A'，所以他就改了。到后面另外一个同学发现突然出了个数据库报错，才发现数据库已经被改掉了，这个时候，两个人开始了balabala...，最终结果是甲同学屈服了，把数据库改了回来...
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
告知： 这是一门挺辛苦的课，得花费挺多时间（相比于其他同学分的课而言），但是只要认真付出了，就一定会有收获的。刚开始可能会觉得，怎么还没开学就开始布置作业了？这课是要累死的节奏啊？但是反过来看，这样的节奏正好是恰到好处的，在学期初，其他课程时间较为宽松的时候完成了大部分任务，等到期末，当其他人还在准备期末考的时候还得敲软工实践的代码，而你只要认认真真去复习考试科目就行的时候，你就会觉得，真棒！
关于是否要换队员：换是可以的，但是换的方式可以更加优化一些。比如设置一个类似于人才市场，有一个双选的机制，同学可以自行决定去留，而接收的组也可以考虑是否接收等，而不是强制说甲组的A同学必须去乙组，乙组的B同学必须去丙组。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建之法》第17章 人、绩效和职业道德）
萌芽阶段
选题由队内成员提出，经过讨论就这样确定了下来。大家根据各自情况分配了任务并开始相关学习。磨合阶段
每次作业分配任务后各位成员都很认真地完成了任务，进展也比较顺利。规范阶段
通过两次冲刺，整个团队目前开发规范性得到了很明显的提高，主要体现在前后端接口以及各自的代码上。创造阶段
还没有达到
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
所在的团队通过beta冲刺后，项目的累计用户量及访问人数如下：
（数据来源：微信官方小程序 - 小程序数据助手）
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
团队在一开始就定下了项目的大致计划，也具体到了每个人的工作上。项目进度也都在计划之内，没有出现延迟等现象。
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
项目的源码都可以在github上找到，同时也有编译的说明文档，接口而言也有详细的markdown文档。