Working for the agency I'm currently employed at, I work with Lancaster Bible College and their marketing and digital team. Lancaster Bible College's website is a WordPress site. With their site, I regularly work with legacy code and updating old styles/markup, all the while creating new design styles and markup.
With Lancaster Bible College, the biggest challenge was working with exisiting code while developing new content blocks with brand new stylings. We also don't host this client, so we had limited access to their server. There was a balance that I had to do when it came to developing these new blocks. The challenge came with scoping out these new styles to only the new pages and not have it affect the exisiting codebase. With this, I also had to overrite global styles and mix them in with the new styles and the old styles.
All the while working on a site where the client is constantly updating content, imagery, etc. With this site and its "real-time" build, I had to figure out a way to continue development without putting everything on hold and without overriding the current live database. Taking over legacy code is always challening, but this one was especially challenging with of all these moving parts.
The three magic words. With this moving car of a project, I had to quickly find a way to make all these changes and develop new blocks without slowing down the timeline. To help solve this problem, I had to create two new stylesheets. One that included the new global changes, and one that was scoped to just the new blocks. This way, should anything break, I could easily pinpoint the file of origin and find where those new styles are being applied.
For caching purposes, adding version control to all the stylesheets, scripts, etc. was a MUST. This forces users' browsers to load in the newest version of everything, avoiding seeing any incomplete styles and/or broken code! For tasks that require bigger changes, the only solution was to pull the site down and develop locally.