How Do We Break Up Code Between Multiple Developers?
It's quite common that while developing a Sitecore site, you get provided a tight timeline with a complex design — requiring you to split the work for one component between multiple developers. The most common example of this would be splitting up the front-end and Sitecore components between your React developers and Sitecore developers; however, you can take it one step further!
This article's goal is to get you thinking about how you can divide the work of one front-end component among multiple front-end developers. We will talk about the division between your front-end developers and your Sitecore developers and what they will need to succeed, how to architect and plan the layout of complex components to easily allow multiple people to work simultaneously, and the important things that each developer will need to ensure they can work uninterrupted.
Table of Contents:
- When Should We Break Up Code Between Front-End Developers
- Sitecore vs Front-End Development – Prioritize the Back-End
- Advanced Planning — The Key to Simultaneous Development
- Common Things That Will Cause Development Delays
- The Important Takeaways
When Should We Break Up Code Between Front-End Developers
Any complex component is a good contender for dividing between multiple developers. Complex multistepforms are a great example of what could be split between developers — you can easily assign each step to an individual developer, or if you have a long one-page form, you could start dissecting each part into isolated area’s that could be individually worked on by one developer per component.
Here is an example of a Rendering Component that will have multiple layers of child components, with each section broken up to allow an individual developer to work on each section:
- Red = Shared container component.
- Touched by multiple developers at the same time
- Used to hold the child components that have an individual developer working on them.
- Green = An Individual (or Shared) component.
- Only touched by one developer at a time, unless it contains a child component
- Isolated functionality and code
- Blue = An individual grandchild component
- Only touched by one developer at a time
- Its parent will become a shared component
Source: Helena Lozano on Dribbble
You want to think about isolating functionality. Anything that doesn’t need to share state
with another component is a great potential child component. Not only does it reduce the amount of
useState, useEffect & useMemo’s per component, but also allows for
multiple developers to work together to complete an individual Sitecore Rendering.
Sitecore vs Front-End Development – Prioritize the Back-End
As we all know, there is a natural division between front-end and back-end work. However, with the release of XM Cloud and Sitecore JSS components, this barrier has closed substantially — your developers no longer need to be C# masters to work on the back-end since the majority of the work can be completed directly inside Sitecore. Because of this, many front-end developers can easily pick up rendering creation inside Sitecore. This is great when you’re not under a tight timeline, but sometimes you just don’t have the time to let one person build the entire component, Sitecore and all.
When under a tight timeline, it makes more sense to split the work between a front-end and a back-end developer. Allow the back-end developer to work ahead and create the renderings for all the upcoming components. This lets your front-end developers power through the front end as soon as they start on the component. The important part is that it allows your back-end developer to work ahead — they can be working on the second component in the queue while the front-end developers are still working on the first.
There will be a clear disconnect when your back-end and front-end work is split between two developers. As with everything, communication is key. Your front-end and back-end developers should meet and discuss how the Sitecore renderings should be made, what type each field is going to be, etc. The final step is handing over all the types for the Sitecore fields to your front-end developer. The back-end developer should be able to create the TypeScript types based on the fields they created and provide those directly to the front-end developer. This should help create a smooth transition between the end of the Sitecore work and the start of the front-end work.
Working on the Back-End & Front-End Simultaneously
Wouldn't it be perfect to be able to split up the front and back-end work? Sadly, it doesn't always work like that. So, how can front-end and back-end developers work on the same component simultaneously? Your front-end developers can work in Storybook! Storybook is an isolated area for front-end React developers to construct individual components. Getting started with Storybook & Sitecore is pretty simple, and you can learn more about how to get started in this video.
If your front-end and back-end developers are going to be working simultaneously, it’s important that you define all the types & field names before you start coding. The biggest challenge in this approach is ensuring the Storybook component can easily be inserted into the front-end once the development is complete. There are two main approaches to developing this way:
- Develop everything in Storybook
- Develop everything except the Sitecore fields in Storybook
Developing everything inside Storybook requires some advanced planning for the field names and types. Your front-end and back-end developers should get in a meeting and plan out what each of the field names will be prior to starting development. Then, your front-end developers can create mock Sitecore data. This should help reduce any negative impact from the simultaneous development.
Excluding the development of Sitecore fields while developing in Storybook is an attempt to have the best of both worlds — your front-end and back-end developers can still work simultaneously, and layout/design and back-end can be completed at a similar time, allowing the front-end developer to add the fields after their creation in Sitecore. This is a powerful approach if you have enough back-end developers to ensure the work is completed at the same time. If you don't, you could end up with a plethora of components that are 50% complete and some front-end developers twiddling their thumbs waiting for the solo back-end developer to catch up.
Advanced Planning — The Key to Simultaneous Development
Advanced planning is extremely important at every stage of your project. It doesn't matter if you have a long or short timeline; good or bad planning can easily make or break the project. Because of this, it's imperative that you do a good job leading the initial discovery sessions.
However, the main point in this article is using good planning skills to allow your developers to work simultaneously on one individual component. Once you get the design, you should immediately be thinking about how you would implement it. This doesn't mean you should hijack the design handoff meeting with long explanations on how you would handle each section; as the UI/UX team is explaining the functionality, you should make some general notes. Here are some points that will help you know when to make notes:
- Which areas interact with each other
- Where pieces of data are reused
- Which areas are more/less complicated
Planning the Layout & Architect the Components
After all the handoff meetings, you'll eventually get the chance to start directly planning the layout of each component. One of the most important things to remember when architecting the components is that more than one person will be working on each section. Because of this, it's very important to create organized and reusable files.
Multiple smaller files are significantly better than one larger file.
You want to prioritize creating smaller .tsx files. Not only will this make your code easier to read and
understand, but it also helps create the simultaneous workflow we are looking for. A key rule of thumb is, "Only one
developer can work in a single .tsx file at a time." This is the most common practice for obvious
reasons, but by splitting our code into smaller .tsx files, we can still follow this rule. Every time
you create a new child .tsx file, it can be assigned to a new developer.
For example, if we have one large form.tsx file that contains two distinct pages, we can split each page
into its own .tsx file (StepOne.tsx and StepTwo.tsx), while still maintaining
one Sitecore Rendering. This would create one shared file between both developers (form.tsx) and two
individual files that can be isolated from other developers. Each step file could easily be assigned to an individual
developer, allowing two developers to work together on one large form.
If we want to take it a step further, we can isolate the code in each Step.tsx into its own
sub-components (StepOneChild.tsx and StepTwoChild.tsx). This will turn
StepOne.tsx and StepTwo.tsx into "shared" files, allowing developers to work individually
on the Grandchild components.
Handling Interactions Between Sub-Components
Splitting our code into smaller sub-components is great, but what about scenarios where those two smaller sub-components need to interact with each other? That's a great question!
For this example, let's assume we are working on a complex form. We have split the current part of the form into two
smaller .tsx files (let's call them step 1 and step 2) to allow both our FE developers to work
on it at the same time. The extra complexity: the choices the user makes in step 1 impact which fields appear in step
2. This is a pretty common scenario (although our example is simpler than the average use case to make it easier
to explain) and something that's easy to work around.
Whenever data from one .tsx file will impact another file, you need to predefine what that data will
look like and create a simple mockData object. Using our example above, let's assume the user needs to
pick a “location” in step 1, and each location object contains an array of event objects. We know that we
will pass a location object into step 2, so we can create types for both step 1 and step 2 before anyone starts
developing. This way, we can define exactly what the data will look like between the steps.
type incomingStepOneData = {
location: {
name: string;
events: EventType[];
};
};
Organizing Pull Requests
One of the biggest drawbacks of having large, complex components is doing a pull request review when it’s time to merge into the “master” branch. To make the final review process much easier, you can create a “new” master branch for each component.
Having a new master branch for each component allows your developers to create PRs for each of their smaller
.tsx files as work progresses. This enables everyone to review each other's code as it gets added to the
new master branch, ensuring everyone is on the same page. This also ensures that only the final finished product is
merged into your QA or production branch, preventing unfinished code from accidentally breaking your build process.
The Importance of Whiteboarding
This bleeds directly into the first point of Advanced Planning; ensuring everyone is on the same page and understands the structure is extremely important. Getting all your developers together for a meeting prior to them coding will improve the flow substantially help reduce any misalignment.
Some of the main objectives of the Whiteboarding Meeting should be to:
- Discuss the file structure (file & folders names)
- Define all needed types
- Define all sub-component files
Its important that everyone understand the code structure before they start coding, and whiteboarding is a great way to achieve that. You want to provide a visual representation of what the the file structure and sub-comonents will look like. If you’re all working in-office, then you could use an actual whiteboard - or if you’re working virtual then using a google doc would work just fine. Simply start writing pseudo code, and explain the logic as you go.
Here is a very rough example of what an online whiteboard session might look like. Just a simple outline of what the code structure will look like.
“Manage Account - step 1”
Note: until we have API details, we could use static data
<ManageAccountStepOne />
Inside <ManageAccountStepOne />
<MAStepOneLeft />
inside <MAStepOneLeft />
disclaimer RichTextField
‘List Products’ section
<MAStepOneRight />
inside <MAStepOneRight />
Heading, Body
<plan summary> “recycle plan.tsx from past component”
“Manage Account - Step 2”
<ManageAccountStepTwo />
Inside <ManageAccountStepTwo />
<MAStepTwoLeft />
inside <MAStepTwoLeft />
disclaimer RichTextField
‘Selected Products’ section
<MAStepTwoRight />
inside <MAStepOneRight />
<service details>
<account details>
<payment options>
Common Things That Will Cause Development Delays
It's important to think about the things that will cause issues prior to development starting. Consider areas of your design that are going to be complex and spend extra time defining the requirements for those areas. However, this section is about creating a seamless workflow for your developers to minimize common issues that might come up!
Not Understanding the File Structure
This goes hand in hand with the whiteboarding sessions I mentioned above. You need to make sure everyone fully understands the desired structure. I’ve had issues in the past where I explained the architectural structure of a Sitecore Rendering and its components, and every developer said they understood. Then, during development, we realized one person was struggling to grasp the concepts. This set the project back over a week! And this was on a project with a tight timeline.
It's super important to ensure everyone understands the concepts. A visual representation should help a lot with this, but remember to ask if anyone has any questions – make it apparent that if they don't understand, it's because you failed at explaining it to them. I've found this approach helps encourage people who don't understand to voice their thoughts.
Another good tip is to leave longer-than-expected pauses after you ask if anyone has a question. Some of the quieter developers might have a great idea or a misunderstanding; I've found that leaving that borderline awkward pause gives them enough time to make sure no one else is going to talk before they raise their opinion.
Not Having Strongly Defined Types Before Starting Development
This is another super important point that I mentioned above. It's important that each developer knows what data is
going in and coming out of their component. This can be achieved by defining the types in all the .tsx
files before starting the development of the logic.
Lack of Communication Between Developers
I get it, not everyone likes frequently talking to the other developers; most developers hate standup! But the point here isn't to just say what you're working on, it's to ensure the developers are communicating frequently and discussing the implementations.
This can be as simple as hopping in a Slack huddle or Teams call at the end/start of the day to go over what they did that day. If you have four developers working on the project, you don't need all four in the same meeting; you want smaller 1:1 meetings between the developers working closely in the same areas. If two developers are working on “Step 2,” then they should be in constant communication and frequently reviewing each other's code.
One of the benefits of a daily meeting about progress is how it allows developers to do quick, in-call reviews of each other's code. They can immediately highlight potential issues that deviate from the original plan or discuss a better way to approach the problem! This is one of the best parts about a daily/every-other-day meeting with a developer you're working on the same component with.
Merge Conflicts!
These are the worst, especially when someone accidentally deletes someone else’s work without realizing it. There is nothing worse than being confused when you pull down recent changes to find your code has pulled a Houdini.
Not communicating and flagging when you're working in a shared file that could have potential merge conflicts is a big problem. If someone is working on a shared file, they should let everyone who might be making small 1-2 line changes know that they are making some major changes. Merge conflicts suck, and we want to try to minimize them as much as possible. When working in a shared file, you should PR that change into the main branch immediately so everyone can update their personal branches with the new shared code.
The Important Takeaways
The two most important parts are breaking down the design and requirements into manageable chunks that allow multiple developers to work at the same time, and ensuring those developers are communicating effectively. By dividing the project into smaller, well-defined tasks, you enable developers to focus on specific components without overlapping efforts, which increases productivity and reduces confusion. Its also important to foster a culture of open and frequent communication to help catch potential issues early, facilitates knowledge sharing, and ensures everyone is aligned with the project's goals.
