Why we’re here

1. Under the Microscope: Evaluating Existing Django Code When Onboarding a New ClientBrian Moloney, Joe JasinskiImaginary Landscape, LLCChicago, Illinois

2. Why we’re here General web development shop, that just happens to use Python (since 1999) and Django (since 2006)

4. Why we’re here Transitioned to a Django-only developer – loudly and proudly. More Django-specific inquiries.

6. Why they call • In house staff can’t handle the load (increase in load or decrease in staff) • Developer has become slow/unresponsive • Sometimes amicable, often not • Whatever the underlying cause, the pain remains the same • “We can’t get things done.”

7. When they call • A wide array of scenarios • Caller may or may not have technical knowledge • Immediately begin triage • Describe where it hurts • Give a sense of pricing

8. When they call • Do you know where the site is hosted? • Do you know if the code is in a repository? • “No, I said RE-pository” • How accessible is the current developer? • You don’t need to be a programmer to get a feel where on the continuum this site falls.

9. Request (and test) access

10. Where to begin?

11. Code Review • Standardize the questions to ask • Provides a place to document • Enables comparison between clients • Documents new technologies that clients use • Gives a sense of effort involved

12. General Orientation • Find the code • Make note of any “important” directories • Find manage.py and settings.py • Identify if the app is using any sort of local settings • Lookup urls.py to identify url space

13. Checklist

14. Code Review: Question 1 • List any system services that the site appears to use. • What webserver? • Django version? • Check settings.py • Check INSTALLED_APPS • ID external services (RDBMS, caching, NoSQL, Queue, APIs, etc) • Using Staticfiles? (Django 1.3+) • Using Django Logging (Django 1.3+)

15. Code Review: Question 1 (Continued) • If the server is a working environment • WARNING: make your presence "read only" • Activate the virtualenv and do a pip freeze • Identify key processes with ps (Nginx, Apache, Django, Postgres, Supervisor, etc.) • Identify application UNIX user (if applicable) • Any cron jobs? • Browse the site and Django admin

16. Code Review: Question 2 • What kind of version control do they use? • Git, Subversion, Mercurial, etc. • Are the using it? • How are they using it? • Basic usage or something more?

17. Code Review: Question 3 • Are they using Django best-practices for their site setup (Yes | No)? • Requirements File included? • Django Tests? • Use of Django South for migrations? • Evidence of virtualenv? • Configuration separate from code? • Fabric for configuration? • Use of Django logging? • Use of Django static files?

18. Code Review: Question 4 • How well is the code and setup documented? • (scale of 1 – 10 ) • README? • Inline documentation? • Did client provide other documentation? • Is there documentation in the version history? • Comment as needed

19. Code Review: Question 5 • Overall opinion, can we work with this? • (scale of 1 – 10 ) • Basic sanity check question • Indicate effort needed for transition

20. Code Review: Question 6 • Identify possible on-boarding issues • e.g. “they need a dev site” or “unfamiliar APIs” • Anticipate problems to migrate • Document unknowns • Helps management communicate probable setup issues to client

21. Code Review: Take Notes • Record basic path locations • Note key findings not previously documented • “What will help me when I come back to it?”

22. Spaghetti Code

23. Examples “All files owned by root.”   “Upload directory in htdocs has 777 permissions set.” “Python, html and css files are marked as executable currently.”

24. Examples “In views.py, imports are done at the top of each view function.”   “All models, forms, and urls in a one file.  Not very modular by function. Models.py at project root.” 

25. Examples “Template directory has weird lock (LCK) files all over the place.  i.e. /usr/local/src/client/web/templates/file.html.LCK.  Are these dreamweaver lock files?” “Methods in models.py is returning html markup.  Email markup is hard-coded into the model.  Seems like there could be a better separation between data and presentation.”

26. As a reviewer… • Keep an open mind • Determine if something was done for a reason • Research the client a bit • Self-document as you review

27. As a coder… • Follow the basic Python philosophy when coding • Project setup documentation very clear and easy to find • Define a configuration strategy • Work towards a one-step setup • Easy to acquire project dependencies • Use maintained packages (if possible)

28. parting thoughts • Assume your code will outlast the sun going nova • Code as though the members of the Django Core Development team will be reviewing • Resist the gravitational pull for speed – from your boss, from your client – it can never be satisfied • Exercise your right to say “No”

29. parting thoughts • You’re a professional – act accordingly • Write it down • Return the call/email, even if there is nothing to report or the news is bad • Take the time to be great • Bad coders hurt good coders • The halo affect of bad code hurts Django • It’s your reputation

31. thank youPresentation materials:chicagodjango.com/djangocon2012 @Brian_Moloney Imaginary Landscape chicagodjango.com@JoeJJasinski @iscapechicago 877.275.9144