Then learn an extremely valuable lesson: don't touch code for no reason. You
have not expressed any reason to remove anything. If there is no such
reason, then don't do it!

Very often I'm asked, "what's the best/fastest/best designed way to do x".
My answer is "do it so that it works, then get to work on the next thing".
If it is too slow, that would be a reason to change things. If it needs to
change because it needs to be more general, then that might be a reason to
apply a Design Pattern. If it turns out that it doesn't really work, then
that would be the best reason of all to change things.

But if none of the above apply, then there is usually more code to write,
and you'd be better off spending your time on the other code until a better
reason arises.

John

P.S. When I say "works", I mean that, ideally, all of its automated unit
tests should pass. A good set of automated tests will give you a real,
executable definition of "it works". This is very useful when you go to
improve the performance or the design. It allows you to say, "I improved the
performance/design" and still, "it works".