maiden speech - maintainable javascript code

[Todd Sedano]

Short version: what would you tell someone who was trying to improve at ______ ? (see last sentence of email)

This last fall at SCNA in Chicago, I presented findings from my class "The Craft of Software Development" where each master student studying software engineering created a learning plan designed to work on an area of known weakness to further themselves in our craft. I appreciated the community's feedback about my class. (If you don't remember me, we also did some dancing at the start of my session. You were magnificant.) 

This year, I'm asking for your input on my students' learning plans. If you have personal experience in one of these learning areas (or have guided an apprentice), I'd love to get your input. 

What is something that has worked for you to become more of an expert in the named area? 

(I've debated how to present this request to this group. There are eight topics. Perhaps it is better to have one email with everyone replying to it. Perhaps it is better to have eight email threads where people who only care about TDD can just offer advice on how to get better at TDD. Because there hasn't been a lot of traffic on this mailing list recently, I've decided to post four emails today and four emails tomorrow. If this was a colossal lack of judgement on my part, please mute any thread that you aren't interested in. And I'm sorry.) 

I really appreciate your time and input, 

Todd Sedano
Director of Software Engineering
Carnegie Mellon University
Silicon Valley Campus
Developing Software Leaders (TM)
T: 650-335-2812

For me Software Craftsmanship includes the notion of maintainable code. I want to get better at writing maintainable javascript code specially in heavy-browser web game. What does the community think will help me improve?

[Doug Bradbury]

The best way to learn to write maintainable code (in general) is to have to change it.  Give a project where the requirements are leaked over a period of time.  Just when the student has a working system, change it in some way that throws them for a loop and make them re-factor their code.

We often do this in the apprenticeship with Tic Tac Toe.  (Ok, now make it play on the web, make it 4x4, make it so either player can go first, etc.)

Doug

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

[Raoul Duke]

On Fri, Mar 23, 2012 at 4:47 PM, Doug Bradbury <bradbu...@gmail.com> wrote:
> The best way to learn to write maintainable code (in general) is to have to
> change it.  Give a project where the requirements are leaked over a period
> of time.  Just when the student has a working system, change it in some way
> that throws them for a loop and make them re-factor their code.

and hopefully make the point that there is a distinction to be made
between code that is maintainable, and code that has been make overly
super generic. people might tend to do the latter whenever they think
that things will change, rather than the former.

[Sidu Ponnappa]

JS code is code. Treat it like a first class citizen. It deserves all
the respect your regular codebases do, like a decent object model,
TDD, CI etc. It also deserves a developer willing to take the time to
understand how a prototype based language is different from a class
based one, and how JS is different from other prototype based
languages.

Since the fact of the matter is that js is largely used to build rich
UIs these day, some study of thick client UI paradigms is often very
useful. At the least, how the observer pattern works, and how one
makes single threaded thick clients responsive. Also, implementation
patterns from AWT, Swing, Winforms and Cocoa are worth studying and
contrasting. Rich clients aren't new, they're basically a new avatar
of the good old client server architecture that's been around for
ages. There's no need to repeat the same mistakes all over again just
because you've never built one yourself.

Best,
Sidu.
http://rubymonk.com
http://twitter.com/ponnappa