AtelierClockwork

Now I Must Evaluate the Enemy I’ve Created for Myself

As is often said: Code is the Enemy. I’ve written quite a bit of it in the last six months. Phase 1 of my large project at work weighs in at almost 40,000 lines of code according to some back of the envelope math and help from cloc.

In a bit more depth:

iOS Client: - 12,000 lines of hand written Objective-C
- 8,000 lines of Objective-C generated by the code generator - 35 UI files including storyboards per device/application section and a pile of .xib files for table headers, footers, and custom table view cells that were referenced in multiple views.

Server: - 2,000 lines handwritten Java - 11,000 lines of Java generated by the code generator - 2,900 lines SQL

API Generator:
- 1,100 lines Ruby - 1,300 lines class definition YAML files - 3,300 lines api mapping YAML files

One very interesting metric on that the entire code generator has paid off in a 3:1 ratio of lines of code required for the code generator to number of lines generated, and in real world analysis I’d call it even better as the YAML mappings are often 2 words per line as it’s just key/value pairs.

The Plan:

I’m hoping to reduce the line count for the project by somewhere between 1/8 and 1/4 by some optimizations. I hope to reduce the generated Java by a signifiant amount because I’ve learned a lot about the best practices working with Java and I have other pressing reasons to do some restructuring in that I plan to make all of the database queries thread based and to multithread any operation that I can.

I also want to restructure a lot of how the JSON data is parsed in. Most of the time I have no issues with the speed of parsing in objects, but I have a handful of queries that dump out very large numbers of items, and while the performance isn’t terrible, I think I could do better.

After that, I have some amount of overlapping UI code that I hope to clean up. I also have a laundry list of things to do once iOS8 hits release status, using size traits to simplify multi-device development should save me a good chunk of code.

Even if I manage a 1/4 reduction in volume of current code, the project is going to keep growing. I’m starting to try to plan for how to keep the large volumes of code more manageable. Right now I also am planning to package each section of the app into a separate dynamic library to help break the code into more maintainable chunks with stronger separation of each section. I’m also planning to write some basic unit tests for each library to help prevent issues as more hands start to get directly involved with the code.