In Feb 2009 I started converting a PHP application over to Python and a framework. Today, I have finished all of the functional code and am at the point where I need to write a number of interfaces to the message daemon (currently a Perl script I wrote after ripping apart a C\/libace daemon we had written).<\/p>\n
The code did work in prior frameworks, I’ve moved to Pyramid, but, now I’m having to figure out why I ever used __init__ with 13 arguments. Of course everything is a wrapper around a wrapper around a single call and nothing is documented other than some sparse comments. Encrypted RPC payloads are sent to the daemon – oops, I also changed the host and key I’m testing from.<\/p>\n
Yes, I actually am using RPC, in production, the right way.<\/p>\n
Total Physical Source Lines of Code (SLOC) = 5,154<\/p>\n
The penultimate 3% has added almost 200 lines of code. I suspect the last 2% adding the interfaces will add another 100 or so lines. Had I written better internal documentation, getting pulled away from the project for weeks or months at a time would have resulted in less ramp-up time when sitting back down to code. There were a few times where it would take me a few hours just to get up to speed with something I had written 18 months ago because I didn’t know what my original intentions were, or, what problem I was fixing.<\/p>\n
Original PHP\/Smarty project:<\/p>\n
Total Physical Source Lines of Code (SLOC) = 45,040<\/p>\n
In 2009, when I started this project, test code written resulted in roughly a 10:1 reduction in the codebase. It isn’t a truly fair comparison — the new code does more, has much better validation checks, and adds a number of features.<\/p>\n
It’s been a long road and I’ve faced a number of challenges along the way. After Coderetreat<\/a>, I’ve attempted to write testing as I’m writing code. That is a habit that I’ll have to reinforce. I don’t know that I’ll actually do Test Driven Development, but, I can see more test code being written during development, rather than sitting down with the project after it is done and writing test code. Additionally, I’m going to use Sphinx<\/a> even for internal documentation.<\/p>\n People might question why I went with Turbogears, Pylons, and ended up with Pyramid<\/a>, but, at the time I evaluated a number of frameworks, Django<\/a>‘s ORM wasn’t powerful enough for some of the things I needed to do and I knew I needed to use SQLAlchemy<\/a>. While Django and SQLAlchemy could be used at the time, I felt TurboGears was a closer match. As it turns out, Pyramid is just about perfect for me. Light enough that it doesn’t get in the way, heavy enough that it contains the hooks that I need to get things done.<\/p>\n If I wrote a framework, and I have considered it, Pyramid is fairly close to what I would end up with.<\/p>\n Lesson learned… document.<\/p>\n Today is going to be a very frustrating day wiring up stuff to classmethods that have very little documentation and buried __init__ blocks. Yes, I’ll be documenting things today.<\/p>\n In Feb 2009 I started converting a PHP application over to Python and a framework. Today, I have finished all of the functional code and am at the point where I need to write a number of interfaces to the message daemon (currently a Perl script I wrote after ripping apart a C\/libace daemon we […]<\/p>\n