Friday, January 6, 2012

Dependency Graph Tool for iOS Projects

One of the tools, which I used to use with Symbian C++ projects, was an automated dependency graph generator. Can't recall the name, had totally forgotten anything like it ever existed. Totally happy in my ignorance. Blissful happy-go-lucky cowboy coding.

Until I found this tool: objc_dep.py at GitHub by nst, which does "Graph the import dependancies in an Objective-C project".

Oh the memories! Oh the horrow, when I checked my current projects...

First things first: this is not a real class inheritance and module dependency tool. It's simple, it's fast and it's reliable (as far as you remember what it's doing: track user header includes). When you look at the 195 lines of python code, remember this: do not fix what ain't broken. As long as you have about one class in one file and filename matches class name, it is Good Enough. Got that?

So naturally I did a few fixes, available at my Jomnius/objc_dep github fork. First I automated a recommended manual step to remove categories and then I added support to handle all C language based projects e.g. plain ANSI C and Symbian C++. Did a bit Symbian C++ in between iOS projects, wanted to check how did I manage. Not bad, Symbian does get deep into a person...

Is the tool useful? I would say yes, from maintenance and future-proofness point of views. Let's check my FontType application before and after the tool:


First (spiderweb) is FontType 1.0 with about 2000 lines of code. Second (tree) is refactored FontType 1.1 with about 2007 lines of code, no bug fixes or additional features at all (v1.0 was pretty much perfect). Refactoring took several evenings, functionality didn't change, created and fixed a few nasty new bugs. Good learning experience in many ways. Also got ideas what to add into v1.2 release.

Advantages of dependency graph:
  • Instant overview about current situation
  • Context-switch time gets shorter, since there is less to recall
  • Refactoring is easier, if you know what it should look like: cycle bad, tree good, spiderweb bad, blobs good
  • Adding new features is easier with real app architecture vs. plans
  • Easier to demonstrate and discuss about the app design with other people

FontType is a toy application. Does the tool help with larger projects?

I checked my last two classified business iOS app projects, both client-server systems dealing with file upload/downloads at background, asynchronious operations, handling multimedia data, integrated to email / facebook / map / camera etc. By coincident both had about 3 iOS developers for 6+ months. Requirements kept changing if not weekly, at least monthly. A pretty normal mid-size real-life project.

The dependency graph tool clearly hilighted very unclear dependencies and would have initiated immediate major refactoring all over the app. Can't show any of those charts, but I have seen a similar scale dependency graph for open source mobbler application (link to tweet). Warning: the referenced image here is 14059 x 2172 pizels, 5.37 MB.

Please do REALIZE that Mobbler is a large (~38 kLOC) quality application, depeloped by several multi-site persons over about 4 years - supporting several not-very-compatible Symbian OS versions. It is a complicated application for good valid reasons and part of the graph complexity can be attributed to the limitations of the tool. Still, objc_dep does give an idea about app architecture.

Use it, when it works for you, but don't swear by it. It's a tool. Tool.

...oh, one more thing: how did I count that Lines Of Code? Another tool:
find ./Fonte_4a7938f4fd96 -type f -name *.[hm] -exec wc -l {} \; | awk '{total += $1} END{print total}'
2000
find ../git-jom/Fonte -type f -name *.[hm] -exec wc -l {} \; | awk '{total += $1} END{print total}'
2007

2 comments:

  1. i keep getting the error when i try to run the tool :
    [Errno 2] No such file or directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdint.h'

    any help would be appreciated

    ReplyDelete
  2. Never seen that before, but I'll write it down to be checked! There's another "problem" with headers included by headers being ignored - because I haven't written such code myself. Maintenance of other ppl's code does bring nice surprises :)

    ReplyDelete