Every now and then Liraz and I find ourselves chatting about how much we love Python, but more so the lessons we have learned from coding, and how to apply them to create beautiful Python code. I've tried to refine some of the "lessons" into practical guidelines that I apply religiously to all new code I write, and the refactoring of old code I written. When reading other peoples code it sometimes ties my mind into knots, and on occasions I want to pull my hair out in frustration and disgust. That's not to say I'm perfect, but hopefully these guidelines will benefit others (and indirectly help reduce my hair loss). I couldn't possibly include everything I wanted to in one post, so this will be the first, and more will follow...
#1 - OO structure == Well defined mental conceptsObject Orientated structure should always map to well defined mental concepts in the problem domain. If you don't have a well defined mental model of the problem domain, start with that. Class Responsibility Collaboration (CRC) cards are really useful in this. Basically you need a sketch of the architecture. What parts does your system have, what are their names, what does each part do? What parts is that part made out of? How do the parts interact with each other? You can save quite a bit of effort if you come up with a good architecture up-front, but sometimes it may be easier to start without and figure it out a bit later after you have a bit more knowledge about the problem you are solving. The rule is that the sooner you refine your architecture, the better. It is easy to dig yourself further and further into a complexity hole that makes restructuring very difficult later on. So do that as early as possible. Refining the architecture is part of the "refactor mercilessly" rule. #2 - Leverage built-in Python types
It is often a good idea to build on top of built-in Python types or at least emulate them. Read more: Turnkey
#1 - OO structure == Well defined mental conceptsObject Orientated structure should always map to well defined mental concepts in the problem domain. If you don't have a well defined mental model of the problem domain, start with that. Class Responsibility Collaboration (CRC) cards are really useful in this. Basically you need a sketch of the architecture. What parts does your system have, what are their names, what does each part do? What parts is that part made out of? How do the parts interact with each other? You can save quite a bit of effort if you come up with a good architecture up-front, but sometimes it may be easier to start without and figure it out a bit later after you have a bit more knowledge about the problem you are solving. The rule is that the sooner you refine your architecture, the better. It is easy to dig yourself further and further into a complexity hole that makes restructuring very difficult later on. So do that as early as possible. Refining the architecture is part of the "refactor mercilessly" rule. #2 - Leverage built-in Python types
It is often a good idea to build on top of built-in Python types or at least emulate them. Read more: Turnkey
Posts
0 comments:
Post a Comment