Hi guys. The only experience I have, is doing Rails app in which I do everything with templates, so full stack so to speak. This week I have been approach by woman who is designer/frontend and has proposed a collaboration.
Given that I've never worked in pairs, I would appreciate if someone here could give a few tips. For my part it will be a Rails API with all the DB stuff. But, should we place everything in one repo and everyone touch what he/she considers, or should we split something..? How this is usually done?
Hi @juanseb,
It really depends on your preferences, but since this is the first time you collaborate I would keep it simple, without adding unnecessary complexity.
I would keep it in a single repo, with the code in a git repo, using Pull Requests to share code updates with each other.
This way you both can have a look at what the other is doing and learning from each other. Conflicts shouldn’t be a problem, if you’re working mostly on the backend and she’s working on the front end.
You could ideally split the client and server in two separate repositories, using different stacks, but it will add a little more complexity to the build and deploy stage.
It depends a lot also on your cofounder experience: have you already talked with her about this?
This is great advice.
I've lead a lot of teams in the past as a lead engineer in structuring projects and generally speaking, if you're only going to be having 2 people collaborate on a project, one repo is the way.
It makes it a lot easier for devs to keep in touch and know what the other is working on. I also second the pull request approach.
Prematurely splitting into 2 repos this early not only adds deployment and other complexities, it can make regular communication more difficult I've found (it's easy to ignore pull requests from a repo you're not actively involved in).
When you have more than 3 people collaborating, it's generally a good idea to think about separating front end from back end (eg Rails app in its own repo, js/vue/react in its own repo), and to establish code owners, as well as regular syncing.
That said, as you make code and architectural decisions in your one repo, you should have it in the back of your mind that eventually at some point you will need to split the repo into two. That way you don't make a decision that backs you into a corner making it difficult to split the repo up later on.
Thank you very much. It is a good approach to keep in mind. Right now, I am looking for simplicity and get things done.
Yes, I have talked with her. She is basically very very good with Adobe suit and have strong background working with statics such HTML/CSS. Besides, she is (based on other projects) decent at VUE. The only problem is that she also have never done that. All her previous experience is using Firebase or hosting those statics for marketing.