Timeline for How can my team avoid frequent errors after refactoring?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2014 at 6:50 | comment | added | SDD64 | 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, 2014 at 6:37 | comment | added | SDD64 | 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 13, 2014 at 17:20 | review | First posts | |||
| Jun 13, 2014 at 23:00 | |||||
| Jun 13, 2014 at 17:04 | history | answered | sdenham | CC BY-SA 3.0 |