markdown guide

I'm going to be super generic.

I assume the system you are working on has extensive tests. I suggest you start from integration / functional level tests: write failing tests regarding the new behavior and then make them not failing :D

Since the system is part of a larger ecosystem you should probably also talk to the teams and agree on data formats and interfaces.

Last but not least, figure out if the new system has to be compatible with the old one. What happens if the system receives in input data created with the old format?

What happens if the consumer of this system has not been upgraded and it expects data in the old format?


Thank you @rhymes , I know this is a trivial question but I needed these affirmations.


It's actually not trivial. You would be surprised how many times integrations don't take into account old systems or retro compatibility. The same goes with APIs (internal or external), there is no standard on how to decide when it's time to break compatibility. Communication is key ✌🏾


Definitely writing test first, if there are already tests for old logic, base on that and write test for new logic, move slowly and as small steps as possible.
In my humble opinion.

Classic DEV Post from Aug 18 '18

What are/were your go to resources for learning Ruby and Rails?

Discussion on great resources to learn Ruby and Rails

raja sudhan profile image

Hey there reader...

Do you prefer sans serif over serif?

You can change your font preferences in the "misc" section of your settings. ❤️