【软工】终章 提问回顾与个人总结前言

前言

提问回顾

提问博客

软件人体工学

我还是没有清晰地弄明白软件人体工学指的是什么。可能指的是能让程序员舒服工作的设备设施，但这并不是一个重要的问题，我也不打算细究。

下划线的存在意义

下划线用于代替空格进行分割。

结对出默契的两人为何不能继续在团队中默契合作

在课程设计中，这只是一种模拟和规则设定。在团队中当然可能会存在配合默契的两人，但我们的课程就是为了让每个人从零开始进行团队开发。我们需要付出维护团队关系和沟通交流的成本。

团队模式

在课程实践过程中，我们的团队并没有采用原文中所提到的那种方式，我们采用的是PM+前端开发+后端开发的组织模式，测试工作则由每个人自行完成，并由前端、后端组长进行审核。

如何进行绩效评定

我们团队采用的方式是以最终工作结果为凭据，PM对各组员酌情打分的方式。

开发中学到的知识点

需求

只有依据真实用户需求进行功能开发的软件，才能获得真实的预期结果和真实用户。

设计

在设计时应当首要构建完成软件项目的关键路径，明确主体功能，集中力量进行开发，然后进行迭代更新，不能一次性把所有需求要做的工作都大而模糊地设计出来。并且要结合已有的实际框架进行设计。

实现

实现过程中要及时进行团队交流，了解各成员的开发进度和工作范围。

测试

测试最好还是能有人来负责。在团队中，大家的水平良莠不齐，有的成员功力高，开发内容多，如果仍要他仔细地进行测试，那他的工作内容就会更多了，这样的正反馈循环不是很好。

发布

发布时，应当明确软件切中了哪些用户的需求，并在打广告的时候投放出这些必要的信息以吸引用户，而不是盲目地投放广告，求用户来体验和使用。

维护

维护时，应当定时检查软件状态的变化趋势，并及时对软件漏洞进行信息收集和修正。比如当用户越来越多的时候，我们应该考虑如何在服务器端进行优化？

理解心得

我也不知道该说些什么，当我不知道该说什么的时候，我真的很难说出些什么来。我看到了某些组的优秀成品，意识到自己与他们的差距，能否做好一个软件与能否写好一段代码差距太大了。对于一段代码来说，那完全是你个人的事情，你分析出每一步该做什么，遇到了困难就去寻找对应的解决算法，在得出最终的正确答案之后，你最多也就是调整风格，优化算法，顶多再写个思考与总结。只要有足够的时间和智力，Bug就能找到，代码问题就得以解决。但面对一个软件却不一样，它所消耗地不仅仅是时间，更是一个人的热情和心力，你会发现你需要学习大量的新鲜事物，有诸多方向都在向你施压，不断地思考，不断地修正，永远没有一个最优的终点，尽管你拥有队友，他们有时能给你帮助，但有时他们又是你的一份责任和负担。在这样一场实践性的角逐中，我们的团队已然涣散了凝聚的心神，在我眼里，我们的团队无法算上成功······

祝软工课程越来越好吧！