起因
身为一个计院学生，相必大家都不得不面临团队合作的问题，但是往往会因为这样那样的原因，合作的非常不愉快，所以，本文主要介绍如何成长为一个合适的团队伙伴。当然，对于我个人而言，这篇文章也将是我寻找合作伙伴的唯一标准，除非……你是我的上司，我希望你能够严格执行下面的所有规范。
合作工具类
我个人更倾向于使用github，因为他的平台更大，能够让我们的项目更加有价值，对后人而言也更有参考意义。
当然，在必要时刻，我也接受使用gittee码云和gitlab,但我决不会主动使用。
讲到这些，我希望你能基本了解git工具的使用，只需要会commit,push即可，甚至你只需要使用github desktop这个软件里部分功能即可。
编程规范类
命名规范：文件名优先使用大驼峰，变量名优先使用小驼峰，这一部分主要参考之后的项目规定，而不必执着于我的选择。比如我在安卓开发时，也常常把布局文件写成下划线区分的格式。
但必须严格参照我们定下的命名规则，言之有物，切忌使用adapter1这种沙雕命名法，鬼知道这个1是谁的适配器。
参考：各种命名法:
- 中文：项目适配器
- 大驼峰：ItemAdapter
- 小驼峰：itemAdapter
- 下划线：item_adapter
代码相关
代码注释 我其实不是很看重，但是，你必须要在每个函数前面写清楚这个函数是干啥的，必要时要讲清这是怎么处理的，不求能让别人看懂，至少要让你自己在第二遍看的时候能看懂
代码复用性 一定要把重复的代码写成模块，相同类型的函数可以统一调用的一定要统一调用，格式清晰，代码复用性高，这才是有人性的代码。（满屏幕的重复代码看着不累么）
文件项目结构
一个项目的文件结构必须是规范的，否则，将很难快速的找到对应的文件在哪里，依靠IDE的ctrl搜寻可太慢了，每个项目结构都必须按照项目规定执行。
参考：一个前端项目的目录
1 | frontend |
技术架构
我个人一般倾向于前后端分离的做法，甚至于，将配置也一并分离出来的做法，这样项目的耦合性会大大降低，之间的交流只限于api的获取，你只需要去负责你所负责的代码即可，一旦有新的需求，必须和我沟通之后，由我来修改我的代码（如果我负责的是后端），严禁越过接口修改我的代码（你可以先自己写一个模拟的接口来模拟处理）
总结
- 熟悉git
- 变量命名规范
- 文件组织规范
- 前后端分离，模块化开发，不越界
合作愉快
保持沟通，多提需求，相互学习。严格遵照以上准则，相互监督，相互进步
