Timeline for Migrating legacy solution with 10 sites, to Helix architecture
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2018 at 5:17 | answer | added | Wen | timeline score: 1 | |
| Jan 29, 2018 at 22:40 | answer | added | Ben Lipson | timeline score: 8 | |
| Jan 29, 2018 at 10:14 | history | edited | Mark Cassidy♦ | CC BY-SA 3.0 |
edited title
|
| Jan 29, 2018 at 9:14 | answer | added | Ruud van Falier | timeline score: 2 | |
| S Jan 29, 2018 at 8:13 | history | suggested | saggi | CC BY-SA 3.0 |
improved formatting
|
| Jan 29, 2018 at 6:46 | comment | added | Richard Hauer | It is generally accepted that a project to migrate a codebase from one structure to another, or a project that involves widespread refactoring, is a bad idea. These projects are very risky, expensive, time consuming, and offer little-to- no business value. Instead consider that all new works adhere to Helix principles, and remove legacy components as soon as possible. Over time your codebase will improve, and you will learn good code hygiene habits as you go. (ref softwareengineering.stackexchange.com/questions/122014/…) | |
| Jan 29, 2018 at 6:44 | review | Suggested edits | |||
| S Jan 29, 2018 at 8:13 | |||||
| Jan 29, 2018 at 5:54 | review | First posts | |||
| Jan 29, 2018 at 8:05 | |||||
| Jan 29, 2018 at 5:53 | history | asked | Santosh Parida | CC BY-SA 3.0 |