106 reputation
6
bio website
location
age
visits member for 2 years, 11 months
seen Nov 12 at 15:34

Jun
27
awarded  Scholar
Jun
27
accepted How can my team avoid frequent errors after refactoring?
Jun
16
awarded  Supporter
Jun
16
comment How can my team avoid frequent errors after refactoring?
Just calling TDD seems not enough for me. So, besides the splitting of the core suggestion, I like your answer the most. Sadly, the core is not perfectly tested, but that would not solve all our problems. Adding new core features for one customer may seem perfectly fine and even give a green build, for them, because only the core specs are shared between the customers. One does not notice, what happens to every possible customer. So, I like your suggestion to find out the problems and to talk about what caused them.
Jun
16
comment How can my team avoid frequent errors after refactoring?
Before we migrated our product from Java to RoR, we actually did like you suggested. We one had a Java core for all customers, but their requirements 'broke' it one day and we had to split it up. During that situation, we faced problems like: 'Dude, customer Y does have such a nice core feature. Too bad we cant port it to customer Z, because their core is incompatible'. With Rails, we strictly want to go for a 'one core for all' policy. If it has to be, we still offer drastic changes, but those disattach the customer from any further updates.
Jun
12
awarded  Nice Question
Jun
12
awarded  Popular Question
Jun
12
comment How can my team avoid frequent errors after refactoring?
@DocBrown: Okay, maybe our understandings differ. The core features, written by him, are overly complicated to satisfy even the strangest possibilities. Most of them, we never encountered. The complexity slows us down to refactor them, on the other side.
Jun
12
comment How can my team avoid frequent errors after refactoring?
@DocBrown Yes, we learned to use one branch of the core for each customer project. This caused some other problems. For example we don't like to 'touch' already deployed customer systems. As a result, they might encounter several minor version jumps of their used core after each deployment.
Jun
12
comment How can my team avoid frequent errors after refactoring?
We had a "watch dog", since he wrote most of the core. Sadly, he was also responsible for most of the untested parts. He was YAGNI impersonated and has been replaced half a year ago by two other guys. We still struggle to refactore those 'dark parts'.
Jun
12
comment How can my team avoid frequent errors after refactoring?
@DocBrown You are right. Each team may change the core. Of course, those changes are supposed to be beneficial for each project. However, they work on different backlogs. We have one for each customer and one for the core.
Jun
12
comment How can my team avoid frequent errors after refactoring?
@logc May be I wasnt clear, sorry. We dont overwrite a core feature like the filter library itself, but add new filters to the classes we use in our customer projects. One common scenario can be, that changes in the filter library destroy those added filters in the customer project.
Jun
12
awarded  Student
Jun
12
asked How can my team avoid frequent errors after refactoring?
May
9
awarded  Editor