The most important thing is to be clear on what ARIA does (and doesn't do) and know all the ways to avoid needing to use ARIA in the first place. Which is another way of saying you need to understand accessibility principles before ARIA will make a whole lot of sense.
The short version is that ARIA describes what the HTML element is doing, without adding or removing any functionality, which is useful when that element is not doing what it normally does; or would normally be replaced with something else. The classic example is to describe the fact a span is acting like a button. Obviously the simpler way to replicate the various properties of a button is to actually use one - the old "you can't style them" argument is out of date.
To give you something more useful: start with the simple things. Does your app have a lot of elements which get shown and hidden? Migrate them away from direct CSS or commong but non-standard class names like hidden.
Instead use aria-hidden combined with this css:
[aria-hidden="true"] { display: none; }
When your app updates the DOM, set the attribute to true or false and now you have nicely-described behaviour making use of ARIA. The huge upside here on top of accessibility is this gives you an explicit state which is useful in tests. I go a bit deeper into the wider benefits of ARIA in this presso - http://www.slideshare.net/200ok/a11y-camparia
After that, start evaluating your code for elements being used in ways that aren't effectively described to assistive tech; and sparingly add roles where required... and so on.