I'm finding I do some of my best work and learning the most when I a problem is sort of nebulous and I have some time to experiment - people aren't dependent upon the work. I'm getting to play with some features of Java that I was previously unaware of (and haven't seen used on my project yet), dealing with concurrency and how to debug those issues, better ways to unit test my code so that shyts not a surprise, finding ways to design my module so that it's understandable and extensible (it's an open source module you could actually go find right now).
It's a refactoring effort I decided to pursue on my own because there has been talk of changing our application architecture, so I wanted to preempt the work that was going to have to happen in several months anyway. The module is an API that acts as a utility for the application and the current code is pretty rigid. I operate on a lot of assumptions that normally need a perfect world to function. Any deviation renders it useless. On top of that, the performance isn't great.
The refactor pulls out the API logic and breaks it up into architecture-centric classes. I have an abstract class that stubs some important methods, and then I systematically went through and created subclasses that define the appropriate behavior. This setup let's the next person come through and create their own class to implement behaviors while the API stays the same. What's more, I found out how to let a user specify which class they want to use in a property file, so they can basically hot swap as necessary with a simple restart (I actually might write another API that let's them change at runtime...). I even have a fallback system in place that will do a cursory check of your architecture and dynamically create the set of behaviors I wrote that should be sufficient for your needs if you don't specify your own.
As far as performance, the current API is all sequential, and a lot of REST calls and JSON parsing is happening. Most of the operations are idempotent, so I made them concurrent using Streams. This led to some errors I'd never seen before, but are to be expected with concurrency. Through the process I even learned a little bit more about how the application handles requests.
For unit testing it's kinda hard, as the module lives in and must be ran by the application, so a shyt load of mocking needs to happen. My current approach has been mock some class dependencies, but expect failures for REST API calls the module makes against the application. I had to revisit how to mock those calls and found a solution that sets up a test web server I can target for the lifetime of the unit tests. So now I want to go back and start creating test cases that are meaningful and will legitimately ensure my code is robust.
Last thing I'm going to do is touch up my readme.md and then write some useful javadocs, then release it into the wild. I'm targeting midweek next week, then that's getting put on my resume, along with a company recognition award I got recently for my contributions to the discipline
.
but front end devs don't understand and management doesn't care.
.
such a flex
status as it's so easy to forget to do this incase you are busy with other stuff or you get into a couple of meetings.
yeah this aint for me 
