0

there is an app with lets say, 75 years worth of development in it. The frontend is a bit a chaos, there is jquery, there is vuejs (vue 2 of course), there is a lot of server side rendering with over 1200 files.

What process would you consider to moving it to something that does not feel messy and that allows easier global style adjustments? A global rewrite... is out of the question. It would need to be a process that allows to step by step change the app.

UPDATE messiness> it has custom CSS / styling almost on each page. If you reuse something, it will look different on the other page. Then youll get feedback "change the look of this" then you change it, you just created yet another customization of at least styling. Not even talking about functionality yet.

What do we even have at the ready? what can we use? we have a bunch of vue 2 stories, but there is no equivalent for the SSR components (aka twig includes).

it is a good money maker keeping a company of 15ish employees afloat with 6ish developers.

Toskan
  • 280

2 Answers2

9

The important questions you need to answer first:

  • What are the problems with the current system? Just "messy" isn't concrete enough. In what way does the current messiness make your life hard? That defines the goals you want to achieve.

  • What resources do you have available? Elsewhere you vaguely wrote that nothing much has happened with this app in the last decade. If that means nobody has touched the app recently, then would you even get much in terms of manpower to do anything much on the app?

    Consider that it's entirely cromulent to just let legacy apps be, until they're replaced by some other product and/or the last user has jumped ship.

    I.e. does anything actually need to be done here?

  • Where could something be done? That highly depends on the details of the code base. Do you have any mechanisms in place to do anything worthwhile globally that can affect positive change? Or would any change necessitate touching 1200 files manually? Could any of that be reasonably automated? Only you and your team can figure out the details here.

  • Do you have any sort of unit testing/integration tests in place? If not, is there any reasonable way to QA any changes, to ensure you're not breaking anything? Breaking stuff for the end user through changes which only the developer is interested in and which don't introduce any new features or other value propositions usually isn't something that makes end users nor management happy.

Think this over and talk to other team members. Then you can think about a concrete process to actually do something specific.

If this is an app in long-term maintenance mode which won't see any changes beyond minor bug fixes, then there is usually little sense to dump a lot of developer time into it. Yes, you'll need to put on the rubber gloves and hold your nose every time you dive in there, but that's much more sensible than trying to untangle a bunch of spaghetti, and give up on it after 2 months because you can't put it back together the way it was.

If on the other hand this product is an active money maker and will see much development over the coming years, then identify what you want to do and what can be done and do it little by little as you keep developing on it. New components should be written according to your new standards, and old ones can be refactored little by little every time they're being touched anyway. But unless done skillfully, you'll just end up with yet another way to write stuff. Since a complete rewrite is out of the question, you'll never transition everything to The New Way™, so take care you're not ending up with an n + 1 situation compared to the old n. You'll probably mostly want to pick one of the existing technologies, even if that's Vue 2, and write more stuff using just it.

deceze
  • 2,315
4

Deceze's answer is great.

But there's another issue that needs to be addressed here:

Process

You have a small team. Given the right mix of talent, longevity, and coordination it is possible (but by no means guaranteed) for a small team to maintain consistency and cohesion in a codebase over time.

That's not how this has played out at your company.

You have processes in place that have allowed people to put changes where it was most convenient at the time rather than the right place which is hampering your flexibility and consistency. Even if you fix the current problem du jour without fixing the process that let you wind up here you're just going to wind up here again in a couple of years.

It's up to the team how formal you make the process, but you are probably going to have to do some of the things that teams/projects do to maintain consistency: more stringent code reviews, limitations around the introduction of new dependencies (e.g. set a watch on package-lock.json in your CI/CD), creation/adoption and use of a style system as opposed to hand-coding things like colors and sizes, etc.

And, and this is crucial: everyone will have to agree to this.

If these things are a problem to you but not your peers you are not going to be able to move the needle on this. Even if you are their superior unless you plan on turning them all over they will have to be bought in to making these process changes. So you

  1. Get everybody to agree to new/better processes, with or without some expert help.
  2. Use the new processes/guidelines for all new code, and ensure compliance as part of the process itself.
  3. Selectively update the old code to adhere when and where it makes sense to.
Jared Smith
  • 1,935