Recently I started working on a project where a very old monolithic application is being migrated into microservice-based architecture.
The legacy codebase is very messy ('spaghetti code') and often an apparently-simple function (e.g named as "multiplyValueByTen") later reveals itself as "thousands of lines of validation code involving 10 tables across 3 different schemas".
Now my boss is (rightly) asking me to estimate how long would it take to write feature X in the new architecture. But I'm having difficulties coming up with a realistic estimation; often I hugely underestimate the task due to reasons I've stated above and embarrass myself because I can't finish in time.
The sensible thing might seem to really get into the code, note every branch and calls to other functions and then estimate the time cost. But there is really a minuscule difference between documenting the old code and actually writing down the new version.
How should I approach a scenario like this?
While I perfectly understand how legacy code refactoring works, my question is not about "how to do refactor/rewrite?" but about giving a realistic answer to "how long would it take to refactor/rewrite part X?"