Alternate Final Phase: Shutting Down
Long story short, I have a very exciting new job starting three weeks from Monday. Expect a very excited note about that right before it starts, but for now, I’ll talk about the very interesting process of preparing a non-trivial project that I’ve been the sole developer on for a year to be handed off to the team that will be continuing to use it as a foundation for future development.
I’ve spent a full week on it already, with a mix of getting the last big chunk working properly, which involves making the API I wrote return the same values as a set of test data from the existing system. I had hundreds of failures starting on Monday, I plan to be done by close-of-business Friday, and am close to on Track with fifty as of Thursday afternoon.
This also included: getting the person inheriting the Java package up and running with source control and all of the IDE tools for that, and making sure that the person taking on the Objective-C side of development could pull down everything from the Source Control and build properly. I also learned a lot of the little details of things that I’ve done right or wrong as I prep for handoff.
The Good:
- I used source control and configured the repos well enough that aside from some minor permissions tweaks and configuration changes it was trivial for the other developers to pull down a version of the project that would compile and run.
- I documented the tools and structure of most of the project, even the very terse notes that I kept made it significantly easier to expand that out into something that will be useful for the developers inheriting it.
- I tried to keep the code modular, with explicit private and public methods so that learning how to work with a section will require minimal understanding on the internals.
- I followed Style guides, and either automated the formatting or used linters that informed me when I broke the rules. This hopefully will increase code readability long term.
- After I got something working, I refactored and reworked it until the code was also clean and and well structured. It’s by no means perfect, but I did do a lot to reduce repetitive checks in code into functions or blocks whenever possible.
The Bad:
- I got into testing the code very late in the game, and the test suite only covers incredibly specific cases.
- As much as some of the more complex details of my development environment is defined by requirements the multi-OS, multi-language requirements make the whole setup cumbersome to teach to others.
- As much as I have decent documentation on most of the project, more documentation and more detailed documentation would be better.
- Which the project will be at a releasable 1.0 before I leave, there were several sections of the project that I still wanted to rewrite to better deal with features that were added in the second half of development.