We all know what is a dystopian world -- A world of Chaos or Injustice, for developer Antipattern, is the dystopian world but surprisingly willingly or unwillingly developers love to live in a dystopian world.
Jokes apart, but this is the ground reality for most of the Legacy or old projects, common experience for developers are they change in one place, it breaks in another place. This has happened due to three major factors.
Tight coupling and complex codebase.
Multiple God Objects are driving Business Logic.
Inexperienced coder and tight timeline.
I have discussed enough on Tight coupling, SRP, KISS, Law of Demeter all these, these are the basic stuff must-have in the developer toolbox irrespective of experience.
Ironically we assume junior developers(Not all Juniors some are very good) may not have this knowledge, only Core Java knowledge is sufficient for them, and in the selection process we omit those questions or in their syllabus, we will not include them. Anyway, I am not going to discuss that this is a different topic and different countries have different selection processes or syllabus.
My take on coding is if from the beginning you do not know basic design principles, you can’t build a good code, which impacted other project members in long run, implementing a business logic according to acceptance criteria is just the tip of Iceberg, handling negative scenario and modularizing and packaging would be your main focus.
In Agile for a 5 pointers development story(not counting QA), i like (2 + 1+1+1) split,
2 for designing and packaging higher component(Top-down approach)
1 for Building logic,
1 for handling error handling
1 for Unit Testing.
If you are not maintaining design and packaging you will end up with multiple God objects, let discuss what do we mean by God Objects?
God Object/Monster Object ::
In a simple term, God objects are something that is doing everything or knows about everything. That Uncle who pokes his nose in everywhere.
Want to trace your project’s God objects footprint? Check your last two months' commit history and plot a graph and find out which are classes modified most.
You will observe a few classes will change often, those are your projects God Objects- who controlling your projects. In a classical word a Feature Envy class.
I always wonder what makes God Objects?
so, I try to see the commit history of the God object and found one use case that in the first place a developer creates objects which hold few important business responsibilities, the intention was to create a Mediator type of object which has reference to multiple other important objects to reduce the coupling and accomplish more business logic with a small line of codes. To know how Mediator reduces coupling you can check the Mediator pattern.
Then over time developers are adding logic on top as this class acts as one shop for all. Blindly developers put logic there as it has already all-important objects references !!!!!.
it grows over time until you get a big escalation and your project managers mandate no one touch this class!!!!
So, If we restrict ourselves in the first place we can reduce the probability of God Object, Once Mediator object grows it will turn into God objects-- A obvious booby trap, Once God Objects are created I think at that point in the Agile era refactoring a God object is very tough and should be avoided.
On the contrary, during each sprint, at the end of the development phase you need to pay attention to Modularizing and refactoring your code a must-do activity in Sprint, to accomplish it, take a blanket story for all development work, Sprint goal is not to only focus on MVP also it needs to focus on Technical quality, but the second one is missing most of the cases, As, Business or Scrum Master doesn't want to give importance on code quality, peer review. I am open to hearing various perspectives on the strategy,
How to maintain good code quality in Sprint?
God objects are bad for your code, it's a booby trap which brings unwanted side effects. Often your Mediator Objects turned in into God object, Pay attention to Mediator Objects after each sprint and refactor it when necessary, Restricting it in the first place will be the best protection not to refactor after it turned into God Objects.
Posts
Post a Comment