I’m about to start the process of migrating a program from one component to another. Most of the core functionality will be the same but I’ll need to change database calls, etc. I’m sure there will be a few quirks somewhere.
Naturally, there will be many errrrrrors, some of which Ill miss completely. Would it be better to completely scrutinize the code, checking for errors line by line, or to just write the code and see what errors occur?
2
Running the code is the way to go unless for some reason you can only run the code in a production environment.
As for checking for syntax and configuration errors, computer time is very cheap compared to programmer time. Ideally you would have unit and integration tests to run that would check most of the code’s validity for you. If your code is modular enough, try writing tests before making changes to ensure that the code you’re changing will work.
The problem with analysing code line by line is that you may read what you want to see, not what the code really does. It is time consuming to execute all your code on paper to check for validity and you’re likely to make a mistake or two. And eventually you have to run the code anyways which will do a dozen checks for you very quickly.
It would be best to write unit tests defining the required behavior after migration. After all the unit tests pass, then start integration testing. If you find any bugs in integration testing, add a new unit test or modify an existing one to test the newly discovered requirement.
The effort of writing the units tests will insure that you at least define the requirements before proceeding with the migration.
Scrutinize the code. This is your opportunity to understand it, validate it, refactor it and write tests for it. Otherwise, you will be inheriting all of the problems with the original code.
Find a way to automate the search for errors. If you have automated tests, run them. If you know tables or stored procedures that changed, do a textual search for them by name. If the database is completely different, search for every database call. Identify classes of errors and figure out ways to find them.