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