Thanks for the Brandon talk link: I hadn't seen it yet and I'm eager to
see anything new from him.
> Oates
I did embark on the Django refactor, and in my mind it was a success of
sorts. Obviously we didn't derive any immediate business value from that
refactor, but it did demonstrate that the approach was viable, and I
liked the way that the code turned out. I would seriously consider it on
future projects (I'm not doing Django at the moment, and my current
project has a large codebase that I'm not going to try to re-architect.)
There were some sticking points that with hindsight seemed predictable.
I don't know that I can remember them specifically now, but the pattern
seemed to be that it would have been much easier if our code had kept
Django at a bit more of arms-length, rather than wholeheartedly relying
on it for *everything*.
For example, we had used things like Django's magic 'settings' module to
store all sorts of project-wide constants. This caused problems for the
'clean architecture' approach, because it meant that any code which
wanted to access any settings needed to import the Django settings
mechanism. Better, instead, to use Django's settings module to just
store Django configuration options, and store project-wide constants in
more generic place of your own devising.
So, as advertised, it seemed that the 'clean' approach really did make
it more visible when we weren't being very smart about managing our
dependencies, and force us to limit them more than we previously had.
Jonathan
On 13/08/14 11:32, James Broadhead wrote:
On 13 August 2014 08:17, Peter Inglesby <peter.ingle...@gmail.com> wrote:
I'm starting my week-long exercise on trying it out on a slice of our
existing Django monster. I'll report back.
Echoes of Captain Oates here?
Anyway, reviving an old thread: Brandon Rhodes talks provides a
straightforward and accessible summary of "The Clean Architecture" in a
recent talk[0] and it's the least wanky discussion of this kind that I've
come across. His main point is that things with side effects (particularly
calling external services) should be isolated in "procedural glue" code,
while the processing of data -- the business logic -- should happen in pure
functional code. This leads to a better focus on the structure of the data
you're dealing with, which in turn leads to more comprehensible and
maintainable code.
Thoughts?
[0] http://www.pyvideo.org/video/2840/the-clean-architecture-in-python
I'm always reminded of that Rimmer quote about Oates...
I've been doing this recently with Twisted -- separating out async code
that deals with deferred chains from synchronous logic handling the results
of the deferreds.
I'm finding that it's leading to clear, easily tested code -- simple
synchronous tests on real data for the business logic, and stubbed
success/failures to test the various code-paths in the deferred logic.
I came to this variously by tangling too much with mixes of deferred-flows
and business logic while trying to write simple tests and seeing this DAS
talk on Boundaries [1]
d = defer.succeed(foo)
d.addCallback(handle_foo)
d.addCallback(make_request)
d.addErrback(retry, make_request, foo)
d.addCallback(parse_body)
return d
^ code like this is easily tested by stubbing all the callbacks, with the
stubs either succeeding or raising synchronous exceptions.
def parse_body(body):
content = json.parse(body.read())
if not 'username' in content:
raise HttpError(401)
return Response(content)
^ again, really easy to test. No deep nested logic, no need to mock or
stub.
[1] https://www.destroyallsoftware.com/talks/boundaries
_______________________________________________
python-uk mailing list
python-uk@python.org
https://mail.python.org/mailman/listinfo/python-uk
--
Jonathan Hartley tart...@tartley.com http://tartley.com
Made of meat. +44 7737 062 225 twitter/skype: tartley
_______________________________________________
python-uk mailing list
python-uk@python.org
https://mail.python.org/mailman/listinfo/python-uk
