How can my team avoid frequent errors after refactoring?
Posted
by
SDD64
on Programmers
See other posts from Programmers
or by SDD64
Published on 2014-06-12T06:41:14Z
Indexed on
2014/06/12
9:39 UTC
Read the original article
Hit count: 219
to give you a little background: I work for a company with roughly twelve Ruby on Rails developers (+/- interns). Remote work is common. Our product is made out of two parts: a rather fat core, and thin up to big customer projects built upon it. Customer projects usually expand the core. Overwriting of key features does not happen. I might add that the core has some rather bad parts that are in urgent need of refactorings. There are specs, but mostly for the customer projects. The worst part of the core are untested (as it should be...).
The developers are split into two teams, working with one or two PO for each sprint.
Usually, one customer project is strictly associated with one of the teams and POs.
Now our problem: Rather frequently, we break each others stuff. Some one from Team A expands or refactors the core feature Y, causing unexpected errors for one of Team B's customer projects. Mostly, the changes are not announced over the teams, so the bugs hit almost always unexpected. Team B, including the PO, thought about feature Y to be stable and did not test it before releasing, unaware of the changes.
How to get rid of those problems? What kind of 'announcement technique' can you recommend me?
© Programmers or respective owner