Reminder: Reading for next Tuesday

[Jeremy W. Sherman]

*Read chapter 4 on Seams if you read nothing else!*

Reading for 1st October: (48 pp.)

- Preface: Definition of “legacy code” (5 pages)
- Introduction: “how this book is laid out” (1 page)
- Chapters 2, 3, and 4: Testing and legacy evolution basics (11 pp., 8
pp., 15 pp. => 34 pp.)
- Appendix: Extract Method Refactoring (6 pp.)
- Chapter 14: Dependencies on libraries are killing me (2 pp.) (Graham Lee)

This is all from Michael C. Feathers' /Working Effectively with Legacy Code/.

Thoughts, comments, complaints, send 'em here. You don't have to wait
till Tuesday! We have a lot of folks who can't always make the
meetings but could benefit from your cogitations.
--
Jeremy W. Sherman
+1 (314) 488–0053
Software Engineer
Big Nerd Ranch

bignerdranch.com | twitter.com/bignerdranch | facebook.com/bignerdranch

[Sean McCune]

It looks like I'm going to have to bag the book club today. Furnace fan motor went, laundry tub faucet began leaking badly (down the back onto the floor not down the front into the laundry tub) and the clothes dryer started shaking and making a noise that it ought not to…  Too many things at once.

My quick thoughts: I read all the sections. I really liked them and agreed with them. I have found in the past, working for companies where I was developing products, that it was possible (and necessary) to apply these kinds of principles.  Its a lot harder to do so in a consulting environment. You have an app that was developed 3 years ago, say. The customer comes to you and want  x, y and z features added. That's the hours they want to pay for. They don't want to pay you for doing these kinds of legacy maintenance and upgrades. So you end up not being able to do them until they are absolutely necessary to get features x, y and z done… and you can convince the customer of it.  That's where I think long term maintenance of consultant/contractor-developed codebases on a consulting basis is problematic. I have seen cases where a codebase was developed on a contract basis but was then turned over to customer devs for maintenance and most follow-on work except for major feature or technology/platform upgrades and that worked well. The customer devs more or less did the work needed to keep the "legacy" code in decent shape rather than letting it go until its so rotted and tangled that you just want to throw it all away.

Have fun!

McC

--
- Voting Choices: http://j.mp/bnrbc-texts
- Chat: http://j.mp/bnrbc-chat
- Google Group: http://j.mp/bnr-bookclub
---
You received this message because you are subscribed to the Google Groups "Big Nerd Ranch Book Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bnr-bookclub...@googlegroups.com.
To post to this group, send email to bnr-bo...@googlegroups.com.
Visit this group at http://groups.google.com/group/bnr-bookclub.

--

Sean McCune, Nerd

Big Nerd Ranch

(724) 799-5927

www.bignerdranch.com

[Jeremy W. Sherman]

We'll miss you, but I well understand the joys of maintaining a home.

I actually see the techniques as being very applicable in precisely
that case. It provides a structure for you to pinpoint where exactly
to make the incision (to return to the surgical analogy introduced
early) to slip in the changes the customer wants to pay for, without
breaking the world. Prettying things up, they can pay for later if
n/ever.

--
Jeremy W. Sherman
+1 (314) 488–0053
Software Engineer
Big Nerd Ranch

bignerdranch.com | twitter.com/bignerdranch | facebook.com/bignerdranch

2013/10/1 Sean McCune <se...@bignerdranch.com>:

[Graham Lee]

Sorry I missed out, I blame being a programmer and as a result not understanding time zones.

The important part for me from the first few chapters was just how many places there in code that can be treated as "seams" for testing. I've never really thought about testing code that uses C function interfaces (in the iOS world, I'm thinking of things like the Security framework and Core Graphics) until I read what he said on preprocessor seams and linker seams, and now I can see how to do it. So when people tell me "oh, my app is mostly graphics and you can't test that" I have more reasons to press than just "no, it's probably mostly logic that's tightly coupled to your graphics code" :-).

Speaking of tight coupling, that's why I recommended chapter 14. For those who aren't iOS programmers we have this in-joke (where "joke" is used in its early mediaeval "disappointing reflection of reality" meaning) from https://twitter.com/Colin_Campbell/status/293167951132098560:

> iOS architecture, where MVC stands for Massive View Controller

You often find that everything is just bundled into the view controllers, and that specific frameworks are slathered all over the apps. I think it may be an artefact of a couple of things:

 - the sample code (Apple's, our own, other people's) doesn't make a big deal of architecture, and for brevity and focus follows the Massive View Controller pattern

 - there's a large subset of Cocoa* developers who only consume information if it's in Objective-C, so miss out on OO practices where they were documented in C++, Java or whatever

 - it hasn't really bitten people yet. A handful of developers have the same app on Mac and iOS, but few have a real need for either portability or agility at the moment.

I think this is an opportunity, if for not more than a couple of blog posts, and wanted to put that chapter on the list to raise that point and to find out how relevant it is to other people, what do the Rails, Android, JS and other people among us think?

Thanks,

Graham.

[Brian Hardy]

On Oct 2, 2013, at 8:00 PM, Graham Lee <gra...@bignerdranch.com> wrote:

> I think this is an opportunity, if for not more than a couple of blog posts

Having just led a team down the hole of putting 537 distinct references to a singleton "store" class throughout our huge project, I couldn't agree more.

I have a decent amount of experience now testing Core Data and web service stuff, all in relative isolation. I'd be happy to contribute to a series called "how do I test that?" or something similarly blithe.

/b

[Graham Lee]

> On 2 Oct 2013, at 19:58, Brian Hardy <br...@bignerdranch.com> wrote:
>
> I have a decent amount of experience now testing Core Data and web service stuff, all in relative isolation. I'd be happy to contribute to a series called "how do I test that?" or something similarly blithe.

Will Blithe mind? *rimshot*

I think it's a good idea. I did a video training series for ideveloper (currently MIA, should be made freely available soon) on TDD which was basically that: this episode is table views, that episode is core sat and so on. It's ripe for an updated retelling, with A list actors and better special effects.

Cheers,
Graham.

[Mark Dalrymple]

I think it's a good idea. I did a video training series for ideveloper on TDD 

YOU MAGNIFICENT BASTARD, I WATCHED YOUR VID...  Er, it was quite well done, and I enjoyed it.  If it stays MIA for too long, I have it in my archives.

Cheers,

++md