软工实践总结
| 这个作业属于哪个课程 | 班级 |
|---|---|
| 这个作业要求在哪里 | 个人总结 |
| 这个作业的目标 | 课程回顾与个人技术总结 |
提问博客链接
问题解决
- 问题一 团队合作的代码规范的商定
在实践的第一次冲刺初期，我们团队的后端组参照普遍的规范制定了golang的代码规范和GitHub的说明规范，并且经过了所有人的审核和同意 - 问题二 个人发展过程中如何兼顾技术和产品理解能力
这个问题只是理解了一些，技术和产品是密不可分的，对技术的革新也是对产品的展望，其实更别致的idea或者迭代都可以从技术层面出发，对于技术之外来说，阅读更多的社科类书籍大有裨益 - 问题三 MSF过程模型运用于实践存在的问题解决思路或主次
依据产品的需求决定主次，快速上线型产品和长期迭代型产品，可以调整不同的比重进行模型运用，目前看存在的问题并不严重，并且多是沟通问题 - 问题四 如何权衡面向未来功能和面向当下功能在软件中的比重，在何种比例对软件的用户迎合度有促进作用
提这个问题的时候有点想当然了，因为不会存在功能黄金比的，所以pass - 问题五 我看了代码规范里的“这是移山公司的一家之言，如果碰到争执，关键是要本着‘保持简明，让代码更容易读’的原则”，有这个问题（旧的代码如何在适应新的代码规范中进行维护，还是直接重构）。我查了资料，了解到模块解耦的代码对于这个问题可以对新旧代码进行分开维护，我的实践项目体量都比较小，因此还存在对大项目的代码更新规范的疑惑
更加理解了更容易读的思想了，一套明确的代码规范大概可以解决很多问题，剩下的折磨和重构暂时也不知道怎么解决 - 问题六 我看了结对编程里的“在结对编程中，任何一段代码都至少被两双眼睛看过，两个脑袋思考过。代码被不断地复审，这样可以避免牛仔式的编程。同时，结对编程避免了‘我的代码’还是‘他的代码’的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。”，有这个问题（个人英雄主义在某些方面可以提高完成效率的上限，如何在结对编程中与团队效率结合）。根据我的实践，组队编程的顺利程度取决于天花板。 因此对结对编程还存在以上的困惑
个人英雄主义只适合解决难题，并不适合构建结对代码，代码的稳定和可靠，也是一种上限，缩短定位错误（发现bug）的时间，是个人英雄主义的完美结合 - 问题七 读到“软件开发的工作量和质量怎么衡量”，有一个疑惑是如何在短时间内衡量代码的可拓展性和兼容性，如果是由外包团队完成的代码，后期维护或者重构的成本肯定更高。资料都是抽象的描述，并未查到实际的举例说明
还是没能找到这个解决办法，因为实践过程中的衡量对成本的考虑太少了，可拓展性和兼容性在已有框架的基础上已经满足目前需求了 - 问题八 读到结对编程时想到，仅把结对编程运用到关键代码的实现上（重要算法或者逻辑链），会不会提高结对编程的效率，这个问题留到实践时验证
关键代码反倒不会出错，其他细节反倒成为调试改错的地方hhh
在实践中学习
- 需求 同步信息和高效交流的方式（信息的粒度决定信息的发布范围）
- 设计 命名的规范
- 实现 遵循代码规约和github规则
- 测试 自动化测试工具
- 发布 对反馈的讨论
理解或心得
这次的软工实践，确实是对身心的考验，但是也有一些不合理的地方（在问卷中说明了），更多理解了设计初期的重要性吧，也接受到了一些教训，也学习到了一些沟通的新方式
技术总结
学习进度:还在跑模型。。。
前后端结合实现实时人脸检测
概述：需要一个方法来解决调用同步视频流并检测视频内容的过程
（葡萄牙出局了，我的欧洲杯结束了）
