本博客主要说说关于两人合作在源代码控制及两人合作遇到的问题。
如果想要仅凭自己的力量完成一个软件，其实是比较困难的。特别是当自己是一个“完美主义者”，很可能会发现软件的功能永远不想自己想象的那么完美。一个人的思维不可能是特别全面的，因此需要与他人合作，不同的思维有时会考虑到不同的问题。当两人合作编写源代码时，一般会先商讨需要的函数以及它们如何声明及定义。但是当大家完成自己编写的部分后，组合起来编译，会发现出现不少运行错误。会觉得对方写的函数考虑不够周全，没有应对可能发生的种种情况；也有可能会觉得对方的代码风格规范没有做好，阅读起来不习惯等等。然后，两人就不断地修改、不断地修改，最后发现修改较为满意的版本与之前写的版本其实是有很多改变的。
因此，合作的两人需要在设计代码之前就要有良好的沟通，遵循相同的代码风格规范，编写详细的规格说明，尽心完成自己的任务。在合作中两人难免会有争执的比较厉害的时候，这也不一定是坏事，可以说明大家都想把合作的代码写的更好。建议合作的两人不要总是挑对方的毛病，有些时候还是需要注意方式、方法。学会提供给对方容易接受的反馈。“三明治”方法其实就是缓冲、冲击、缓和三个过程。
问题出现时，大家都是比较苦恼的，先缓和一下彼此的情绪，为说服对方做好铺垫；接下来，围绕错误的行为带来的后果，这个过程并不是“翻旧账”，而是为了进步，大家商讨解决问题的策略；最后，再次以团队的共同目标相互鼓励。在这一过程中，彼此可以由浅及深地接受改变。
软件的分析和设计也是比较考验软件设计者的。当一个团队对用户的需求进行分析之前，用户有时并不清楚自己到底想要什么，只知道想要的结果大概是什么样。团队里的不同成员会有不同的考虑角度，因此，对于用户的需求分析，可以提供不同的见解。思维导图适合团队讨论和理解核心概念，实体关系图可以表达实体之间的关系。尤其是，当UML出现以后，能更好地对一个问题建模。但是我们依旧需要通过代码实现对问题的解决方案。
通过彼此的合作，相互影响也是相互进步的过程。单枪匹马有时并不能很好的解决问题！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
