软件工程--个人总结

本课程对我带来的提升如下：

学习和使用的新软件：

墨刀，git软件，钉钉。

学习使用的新工具：

Markdown排版，coding.

学习和掌握的新平台、新语言：

Myeclipse,SQL.

软件工程实践中，完成的代码行数：

300+

学习和掌握的新方法：

在课堂以及在书本中学到了：单元测试、效能分析、代码规范、代码复审、黑盒测试以及白盒测试等方法；在实际过程中，我负责了单元测试和黑盒测试，主要也是学习了这两个方面。

总结与展望:

经验总结：

团队成员一定要学会团结，你可以求同存异，但不可盲目自信，认为自己的都是对的，还有就是代码的编写中一定要遵循代码规范，这样可以在代码的合并中，节约大量的时间。

对学弟学妹的建议:

在团队合作中，首先要听从组长的建议，然后就是在其他的问题上一定要多讨论，多沟通，三个臭皮匠赛过诸葛亮，所以心中有想法一定要及时说出来和大家讨论，这毕竟是团队项目，而不是个人能力的表演。

团队经历及到达阶段：

因为是才组建的团队，所以出现了很大的摩擦，原因在于我和组长不能很好的求同存异，从而演化成了冲突；但在大部分方面上我们能够很好的分工、以及合作，总之我觉得我们团队已经进入了融合阶段。

对第一次提出的问题进行回答

• 1.我看了软件团队的模式一章，对其中“主治医师模式”和“功能团队模式”这两种团队模式感觉是完全相反的，其中“主治医师模式”因为有首席程序员，所有团队的凝聚力很强，分工明确，却会出现“一个人干活，其他人打酱油”的现象，二“功能团队模式”中，具备不同能力的人平等协作，共同完成一个功能，小组内部的交流很频繁，但是小组之间的交流却很少，小组之间达成一致很不容易，所以我想知道在当下的公司开发环境中，哪种模式更有优势？---《构建之法》（第五章 团队和流程）
• 2.两人合作的开发方式中，首先要注意的便是代码风格规范，只有两人的代码风格一致，才能做到更快的相互理解，在以后的代码合并中亦能更快，但是在代码复审阶段，由于毕竟是两个人，互相提问题时依然不能很快代入对方的想法，从而导致时间的浪费，效率的下降；问：在已有相同代码规范的条件下，怎样能更快的相互理解，加快代码的合并，并尽可能减少分歧？---《构建之法》（第四章 两人合作）
• 3.在需求分析的过程中，软件产品的利益相关者包括用户、顾客、市场分析着、监管机构、系统/应用集成商、软件团队和软件工程师，由于软件开发不可能一次满足所有利益相关者的要求，但是我们我们依然会征询所有相关角色的需求和意见，所以在这些角色中，谁的需求和意见是最需要考虑的，作为软件开发者又将如何调剂这些利益相关者的矛盾的，即优先级是怎么样的？---《构建之法》（第八章 需求分析）
• 4.在需求分析阶段，我们要搞清楚：在问题领域的现实世界中，都有哪些实体，如何抽象出我们真正关心的属性，实体之间的关系是什么，在这个基础上，用户的需求是什么，软件是如何解决用户的需求的，怎样选择软件的侧重点，比如侧重用户，软件对硬件的依赖性，以及PC端还是移动端；那么在以上问题都解决的条件下，软件开发团队需要处理、了解这些信息，如书中所说：如果在处理的过程中有误解和遗失，就会导致开发过程中的问题发生，那么到底怎么表达才能更准确有效的交流？---《构建之法》（第十一章 软件设计与实现）
• 5.开发流程包括写了再改模式（Code-and-Fix）、瀑布模型（Waterfall Model）及其相关变形、统一流程（Rational Unified Process）和老板驱动的流程（Boss-Driven Process）,那么对于如今越来越多的中小型企业来说，哪种开发流程是最适合他们的，能够更少的减少资源的浪费以及尽可能地减少项目所需的时间？---《构建之法》（p.92--5.3 开发流程）

回答

• 1.功能团队模式更有优势，因为每个人都能发挥自己的功能和特长，而且避免出现打酱油的情况。
• 2.两人可以求同存异，并且在分歧的基础上听从能力强的。
• 3.设计问卷调查的形式，主要是客户的需求和自己团队最高能够实现的功能以及利益相关，必要问题上应该寻求所有人员的需求。
• 4.团队在编辑代码及功能实现的过程中应该在一起工作，这样可以有效的减少时间的浪费以及效率的最高化。
• 5.对于中小型企业来说，因为资金的短缺和人才能力的薄弱，所以应该采取写了再改模式（Code-and-Fix）。