Hey been reading a couple of your articles and I'm very interested to hear more from you!
We're struggling with scaling from a < 50 person engineering org to 100+ in a year. Fast start up growth. We already have 2 monoliths and have been talking about splitting things out for a while.
1) As someone who's new to the team and backend development in general, what are some tips for getting a grasp on monoliths, understanding business domains, etc?
2) Can you clarify this line for me? "Don't make cheap code, make code cheap." Maybe an example of two would help.
Hi Daniel! thanks for your feedback 😊. Let me answer your questions:
1) Understanding the business domain through code with lots of technical debt is a challenge that you don't need to face alone. Try to pair or do mob programming with more experienced teammates, make sure that everyone on your team has the same understanding of the business rules (also your PO, don't forget about him/her). Document those rules somewhere.
If you have someone experienced, I would suggest to do several event storming sessions to document and understand business behavior. Usually event storming is used to build new features, but in my experience it works quite well also to share business knowledge.
2) In my experience, one of the biggest issues when refactoring or splitting a code-base is premature code reuse. Most of the times you will be facing code that is reused across components (usually this code is shared through a static method/class, a base class, or utility functions). This means that you need to decouple first from the shared code, and then fix the issue or extract the code to somewhere else.
To avoid this issue, do not refactor to reuse code, refactor to make code safer. Safer means that is easy to change, is observable (good logging, good metrics) and is easy to test (if you do TDD, this will be far easier).
A few recommendations:
Avoid utility classes, if you need to use the same code, use a Value Object. It's cheaper to test and change.
Avoid abstract/generic/reused components. If you are facing that you need to do the same thing (like accessing to the DB) from different several places, find a way to fix the issue with your framework (for example, with Spring, with an ORM or a JDBCTemplate). If it's not possible (most of the times it's possible) create a library that provides this capability and decouple it completely from your business logic. If it's in another deliverable, better, so it's harder to break the boundaries.
Test the application. You don't need automated tests for everything, but at least a test plan. If you can have functional blackbox tests for the happy path, so it's easier to extract, I recommend to write them.
Hope I helped!
Thanks for reading!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey been reading a couple of your articles and I'm very interested to hear more from you!
We're struggling with scaling from a < 50 person engineering org to 100+ in a year. Fast start up growth. We already have 2 monoliths and have been talking about splitting things out for a while.
1) As someone who's new to the team and backend development in general, what are some tips for getting a grasp on monoliths, understanding business domains, etc?
2) Can you clarify this line for me? "Don't make cheap code, make code cheap." Maybe an example of two would help.
Hi Daniel! thanks for your feedback 😊. Let me answer your questions:
1) Understanding the business domain through code with lots of technical debt is a challenge that you don't need to face alone. Try to pair or do mob programming with more experienced teammates, make sure that everyone on your team has the same understanding of the business rules (also your PO, don't forget about him/her). Document those rules somewhere.
If you have someone experienced, I would suggest to do several event storming sessions to document and understand business behavior. Usually event storming is used to build new features, but in my experience it works quite well also to share business knowledge.
2) In my experience, one of the biggest issues when refactoring or splitting a code-base is premature code reuse. Most of the times you will be facing code that is reused across components (usually this code is shared through a static method/class, a base class, or utility functions). This means that you need to decouple first from the shared code, and then fix the issue or extract the code to somewhere else.
To avoid this issue, do not refactor to reuse code, refactor to make code safer. Safer means that is easy to change, is observable (good logging, good metrics) and is easy to test (if you do TDD, this will be far easier).
A few recommendations:
Avoid utility classes, if you need to use the same code, use a Value Object. It's cheaper to test and change.
Avoid abstract/generic/reused components. If you are facing that you need to do the same thing (like accessing to the DB) from different several places, find a way to fix the issue with your framework (for example, with Spring, with an ORM or a JDBCTemplate). If it's not possible (most of the times it's possible) create a library that provides this capability and decouple it completely from your business logic. If it's in another deliverable, better, so it's harder to break the boundaries.
Test the application. You don't need automated tests for everything, but at least a test plan. If you can have functional blackbox tests for the happy path, so it's easier to extract, I recommend to write them.
Hope I helped!
Thanks for reading!