On 21 Jan 2013, at 17:41, Francis Fish <[email protected]> wrote:
> Sounds like a bad case of premature optimisation to me. There are some gems > knocking around where you can record and replay responses from external API > calls (not used them in an age so ... guys?) that may help you write some > tests. Yup, vcr is helping us out in a few key areas. We've been doing a lot of work with this to help with CI which is overall in good shape but lacking coverage in a few areas because devs hadn't got vcr plugged in previously and therefore putting any tests in place that Jenkins would want to run would cause us all sorts of issues. > You could also look at folding it all back in but using the Rails 3 > middleware stack. That might be less up front rewriting - but without seeing > the app it's hard to say if it would be worth the hassle. I think that's definitely an option, and I believe some parts of the app have already been done that way - there's some legacy here originally developed in 2.x that has been pushed up to 3.x by the looks of it, but I think time ran out on pushing through the re-factoring to the fullest extent. As to whether it would be worth the hassle, it's all about finding balance I think. If the end result is "we can ship new features quicker" or "the platform will be more stable", it's easy to justify. If it's "I sense we could use this funky stuff here because it's cool" or "I feel like this is technical debt but I'm not sure", it probably isn't. :-) > I was listening to the Ruby Rogues Sandi Metz episode and she was saying that > you can do things like identify the piece you need to change, turn off the > old code, and do a functional replacement. As in, don't rewrite, but write it > for the functionality revealed by the working app, using it as a spec. Yes, that's an approach I was considering, and coupled with comprehensive Cucumber tests, I'm thinking we might have quite high confidence in going for that style of refactoring. In essence if we have not just happy paths but unhappy paths all covered and we keep an eye on carefully moving views and assets into the new structure mostly untouched at this stage, we could be quite brutal with what is going on in terms of refactoring behind the scenes. > I did a lot of SOA work when it was new 10 or so years ago and it always > seemed more trouble than it was worth, but we are talking Java/Oracle land > where doing anything was pretty hard. When you need to scale, then you need > to consider SOA. I wonder if it was cast that way for resilience? As in, you > can gracefully replace failed pieces with sensible defaults and the site > stays up, plus allow graceful degradation of service? Problem is, I'm not 100% certain we have that resilience benefit here, as deploying more servers within a given tier/function is currently a little problematic, but that's a separate issue relating to underlying metal than it is SOA. We're working on fixing that now as a separate activity, but my gut instinct is telling me this is a premature optimisation. > There's also the 5 9's problem - the whole system's reliability becomes the > product of the probability of failure for each component instead of just the > most vulnerable piece and without that resilience architecture in place it > hurts even more. Indeed. I think we have some quite brittle couplings in here - there is one key component that shouldn't be key to everything but is elevated to a lofty status of determining if the entire app runs or not through our current setup, so if it goes down the entire app basically grinds, opposed to my preference of a bunch of controllers simply shouting out exceptions in a little-visited corner leaving the rest of the architecture up. > Not sure if my rambling's been any help, but I'd rewrite or recast it all. > You don't know where the pain is until you feel the pain. Before that it's > mere speculation. On the development front, there is pain right now. I thought about whether this pain is my unfamiliarity with the code base, but I am increasingly convinced that SOA is hard to develop tests for quickly, which means it is hard to add features for quickly, it's hard to refactor quickly and it's hard to bug fix quickly. When it's hard to be agile, when it's hard to push BDD, when it's hard to fix issues, there's probably something wrong somewhere. I'm currently debating whether the difficulty I'm stood in front if simply a small bump or a wall, and I'll let you know what we end up doing I'm sure, preferably over a pint in a pub that serves beer with a decent head as opposed to the flat muck we get down here... Paul -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
