请回望第一次作业，你对于软件工程课程的想象
对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”
- 上面那句话引号意思是我对课程的期待？但我没说过这句话，也不是这么希望的
- 达标方面：代码能力，架构能力，移动端开发能力，全栈开发，安全性考虑，吹逼能力，文档瞎逼逼的能力
- 不足：对于随机团队的组织能力和时间进度的把控能力
总结这门课程的实践总结和给你带来的提升
统计一下，你在这门软件工程实践中，完成了多少行的代码
30K+
软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业 | 时间 |
|---|---|
| 第一次博客作业 | 1h |
| 第一次个人编程 | 24h |
| 第一次团队展示 | <1h |
| 第一次结对编程作业 | 8h |
| 团队项目-选题报告 | 10h |
| 第二次结对编程作业 | 30h |
| 团队项目-需求分析报告 | 8h |
| 团队Git现场编程实战 | 4h |
| Alpha冲刺 | 100h |
| Beta冲刺 | 80h |
| 最终展示 | 40h |
| SUM | 305h |
哪一次作业让你印象最深刻？为什么？
团队现场编程
现场3小时做东西，比编程马拉松还刺激。
累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
时间真说不准，受到许多因素的制约。
累计请参阅上面的SUM那一行，但那应该是保守估计，实际应该还大于这个数，软件工程实践19周，平均每周16小时。
学习和使用的新软件
并没有，都是已经会的，用过的
(PS, PR, Axure)
学习和使用的新工具
并没有，都是已经会的，用过的
(IntelliJ IDEA, Android Studio, Visual Studio Code, TMUX, Postman, etc)
学习和掌握的新语言、新平台
并没有，都是已经会的，用过的
(Kotlin, Android, Spring Boot, Office 365, AndroidX, Swagger, etc)
学习和掌握的新方法
倒是有些
- 需求分析的方法
- 文档写法和注意事项
- 吹牛逼的方法
其他方面的提升
说实话，这门课并没有给我任何质的提升，最多多了一些经验，然而还不如我跟一个正常团队去做外包的经验多。
写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 在实现一个需求项之前建议先抽象建模，然后参阅相关的最佳实践，再写代码。这样可以避免写出屎一般的代码。另外做好隔离和解耦，有利于代码复用和故障传播隔离。例子太多了，比如我那个相册选择的代码就是随意嫖的，然后在项目里复制来复制去，导致后面要改这个代码的Bug很难操作。
- 保持知识更新。网上很多博客，或者文章里的实践代码可能已经过时（Deprecated），应该去找官方文档里相应的文档对照一下，当然这也需要一定的辨识能力。
- 定好进度，盯好进度。
这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？
我感谢我的所有队友们，在我这么烂的领导之下，他们居然没有杀了我，没有锤死我，我十分感激。
个性发挥，包括图文、照片和创意等
吐槽
这课槽点和想喷的地方太多了。
首先是关于课程目的方面，前面所说的“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，我不认为这门课很好的达到了这样的目的。主要看想不想做。想做的，想学的，想实践的人，早在这门课之前就已经掌握了相关技能，也有了团队项目实践锻炼相关经验，这门课纯浪费时间，不如去接个外包，有钱又有经验。而对于处在中间的那部分人，这样逼一逼确实能起到效果。对于本身对计算机没兴趣的，不想学的，逼都没用，就算学会了也能很快忘掉，根本起不到提升就业竞争力的作用。如果说可以让简历多个东西，我觉得效果也不是很好，我看了一下这门课各个小组的GitHub的代码，说实话乱的一笔（包括我），甚至还有一些安全隐患和Anti-Pattern，这样的项目写上简历我不认为是一个加分项。针对不同的人群，我认为这门课不能做到因材施教，甚至浪费一部分人的时间，必修很有问题。
其次，对于课程过程来说，课程安排应该充分考虑到我们是学生，不是全职人员，故模仿公司那一套我觉得是很有问题的。学生每个人都有不同的课程和时间安排，只能松散的管理。而且非全职人员也没有那么多时间去走完整个正经的软件过程，包括需求，建模，开发，测试，部署，反馈维护。软件过程中生成了一大堆文档，但开发中遇到了各种问题，需要修改需求，而改了需求有没几个人真正去修正文档的，这样，就造成了文档不一致，不一致的文档跟废纸没什么区别，甚至能起到负向作用。说实话，要体验或者经历这一套过程，并且积累经验不如暑假去找个正经的实习来得靠谱，还有人带，有正经的考核机制。比一堆学生在这个课程上xjb乱搞强多了。
另外，我觉得组队机制上也很有问题。第一堂课就要求尽快完成组队，这实际上我认为是不科学的。这样组成的队伍要么是瞎组的，要么熟人抱团。其实就课程过程体验来讲，要真正让每个人都共同进步，体会到共同进步的乐趣，最好是水平差不多的在一起，即大佬和大佬一起，菜鸟和菜鸟一起。这样组内不会出现知识和认知的断层，沟通上也比较容易，比较不会出现跨服聊天的情况。水平差不多的人在一起，不管是大佬和大佬，还是菜鸟和菜鸟，都可以共同为解决难题贡献力量，不需要花费时间处理知识断层问题。而若是水平参差不齐的人一起，很容易出现工作量倾斜的情况，或者磨合组内水平花费大量时间，降低效率。另外就是大佬对菜鸟的不信任的情况，这也是造成工作量倾斜的一个原因。我认为，出现这些情况，对于双方都是不利的。反倒是水平差不多的人在一起，可以消除一些跨服聊天，大佬共同挑战难题，菜鸟共同学习基础，这样对大家都是有利的。
此外，还有助教和评分问题。这次课程淡化助教，我觉得不是一个很好的实践。让同学们互评，公开透明，问题是公平吗？客观吗？同学之间需要考虑人情，大家都是同学，抬头不见低头见，而且利益相关又易受影响，这样的情况下，能客观评分就出鬼了。最后的结果就是大家分数都差不多，都是接近满分，没什么区分度。甚至有的人不按应遵循的标准打分，而是乱打，或按关系疏近。我不知道最后老师会怎么处理这些分数。如果加入老师或助教主观成分，那么公开透明呢？如果不加入，公平客观呢？这个问题隔壁程永利班的助教统分时已经不止一次找我吐槽了。我认为软工评分还是需要一个利益无关的，联系甚少的第三方，如企业助教，或者直接由权威，如老师，来进行，并且公开评分。这样既公开透明，又公平客观。
还有就是选题，柯老板似乎过度注重创新，并且我们好像都选的To C(Client)的题，没有人去做To B(Business)的项目，我不知道柯老板会不会同意我们选To B的项目。但我认为在软件工程中，To B项目和To C项目是不同的，而且都是重要的。To C的项目是我们自己找客户，所以我们需要揣测客户的需求，才有人用， 而To B的项目是客户找我们做的，肯定有人用，但是要做好也是不容易。但是我觉得我们不应局限于To C，To B项目也要尝试一下。虽然可能没什么创新，但要做到规范也是挺难的。
建议
针对上面的吐槽，对于这门课提出一些建议吧
- 建议推迟组队，到第一次个人编程或第一次结对编程结束后，或更晚的时间组队，这样可以避免一些xjb组队的现象
- 建议柯老板可以给出或建议一些To B的项目选题，让一些同学有实践这类项目的机会
- 我觉得强制换队员这个是可以搞搞，挺刺激的，模拟职场人员流动。另外，建议经常换，而且换核心队员，增强大家处理危机的能力，或者让每个人都有成为核心的机会
- 团队现场编程时间建议延长，这样更能拉大差距，也能做更多工作，出更好更多更有意思的成果
- 建议增加单独的软件测试作业，建议强制测试机制，使用完善的测试报告来体现测试成果，测试也是软工的重要一环
- 西二在线和服务外包建议内部直接抱团，或互相抱团
- 划水建议找上面两个组织的人组队
- 如果可能，建议接一个工期差不多又能过选题的外包，这样，既做外包又完成课程任务，既能拿钱，又收获经验，还完成作业，一举多得。而且这样更有动力，做起来不会那么痛苦
再吐槽
这门课对有的人是真的浪费时间，不知道它必修有什么意义
另外上面有两点说的没学到新东西，是真的