We had a situation in which a senior developer decided to change some code thinking it would be for the best, which it is, but we still had some problems during that period. Some functionalities broke (no unit tests), but the changes did make sense.What I'm looking for now is to avoid this happening again and also improve developer interaction with each other. I'm thinking some kind of policy or process to achieve this. I wanted to ask what you have experience doing and see if we can apply it for our team. Currently, what I have is peer reviews, and also before implementing something new, to have a meeting with the seniors (at least 2 seniors) on how to implement that functionality as having more set of eyes (and brain) can help something to be implemented better.
What processes/activities will improve developer interaction and stop breakages?
development process;teamwork;collaboration
First you need good unit tests.I say first because if you focus on 'developer interactions' before doing this you will be introducing a lot of process and overhead that supports doing the wrong thing or at the very least will be unnecessary when you then have automated tests.  Also resources and enthusiasm for change are limited.  Start changing the worst thing first.  Developer interactions are critical but unit tests are even more criticial.So use your time to take the first step of writing unit tests.  tomorrow.  If folks don't know how to or the framework to use etc, make training and education tomorrow's activity and start writing the tests next week.  Make sure that folks know that this will be hard, will have a steep learning curve, and even when up to speed will often mean taking more than twice as long as just writing tests.  This is an investment.  You can build a house without a foundation more quickly but it will then have issues during use (based on the expected 100 year timeframe it should last).  If a framework or getting started seems intimidating write a piece of code that calls one of your functions (methods, etc.) passing in appropriate parameters and checks the return value to see if it is what is expected. boom.  you have a unit test.  repeat.Start with requiring unit tests for new functionality.  Over time the coverage will grow.  Use a tool to measure code coverage over time so you can see this.Champion the idea that unit tests are the only practical way to ensure that new changes don't break exiting functionality for todays development world.  Relying on manual testing changes the code change cycle from minutes to days.If you are doing Agile development talk about the Unit, Functional, Stress and Exploratory testing that you should consider.  Unit testing is just one of these quadrants.  It's the one area that I consider non-optional and unit tests should be written in concert with the code.  Ideally ahead, step by step, but in practice you may in some cases write the code then the test and in others the test then the code.  On a small scale the details of which you do first don't matter as much (there are differences though) as making sure that you end up with code and tests that support it.  If you do write the tests first though you will generally find that the code ends up being better and more testable!.How will these new processes/activities improve developer interaction?Having a solid reliable comprehensive set of unit tests will help people feel ok about changing code, ok about quick fixes or bug fixes.  I know Joe won't break Mary's code because the good unit tests are there to tell me if I do.  Otherwise days are filled with various developers breaking various other developers code, not realizing it and introducing bugs constantly.  Been there, done that, not fun.  It's hard to have a fun, relaxed friendly environment when all this is going on.   On the other hand an environment where we are all protected from this by tests can be more relaxed and less stressful in my experience.I have worked at several companies at different points on the spectrum of having good test suites and have seen the above play out at them.  Don't rely on a second set of eyes for breaking existing functionality when automated tests can do it for you.  Retain the second of set of eyes for higher level activities surrounding well-crafted code that computers can't do well.yet.One more point - also use linters for your code to check format for html, css, ruby, javascript, python, etc.  This is another way to help stop code reviews becoming personal and heated (thus degrading those developer interactions you are asking about).  You make decisions on code standards and capture those in your linter configuration files.  This also lets you talk about higher level stuff and not be arguing on indent spaces, etc.p.s. this is all new to me.  When I wrote code 20 years ago, manual testing was the only option.