Summary:
component used to work and now doesn't, the regression happened 1+ years ago and we're not sure when, now I'm considering replacing the broken and poorly architected component with a mature library
Background:
I am working on a web application which interacts with a 3rd party API to import and export data. This is an optional feature, which would be used instead of manually inputting data. Two years ago, I implemented an authentication system from scratch that uses basic authentication (i.e. generating basic authentication http header, including it with requests). I then spent two years at another company, but have now returned and am working on the same application again. While I was gone, someone introduced a regression error somewhere in the authentication module: now you can't connect, period. Nada. Zip.
And I don't know when this started because I wasn't here - but if I dug through commit logs I could probably get a rough idea. At some point someone disabled the ability to connect to the 3rd party API because it didn't work (yeah, I know... great solution -_-), so I could use that to get a rough idea of when it happened and possibly get a lead on where the regression error was introduced.
What now:
While investigating this, I have discovered that there is a mature library written for our technology stack for interacting specifically with this 3rd party API. (As an aside, it supports basic authentication and oauth, and we would like to move to oauth if possible - so switching to this library also has nice side-benefits.)
The current plan is to replace the (not functioning) hand-rolled authentication component with the library, which may involve a database schema change, and some non-trivial refactoring.
My question:
is it important to identify the bug in the old authentication component before starting to replace it with the library?
Some thoughts:
- why waste time finding the bug if we're about to replace the component?
- what if somehow replacing the authentication component won't fix the bug - and if I took the time to find the bug in the first place then I would have known that
Other details:
- there is no need to start using the library if the current code works, though the side benefits of the library are nice
- the current authentication code is poorly architected and hard to maintain
The current plan is to replace the (not functioning) hand-rolled authentication component with the library, which may involve a database schema change, and some non-trivial refactoring.
-- Sounds like a good plan.Is it important to identify the bug in the old authentication component before starting to replace it with the library?
-- Will it help you implement the new library? My guess is no, it won't, and it's going to be a lot of research cost for little benefit.