-
May 31st, 2009
On the Challenge of Developing JavaScript Within a Team
I find one of the most challenging aspects of developing JavaScript in a team environment is cracking open someone else’s code and being able to work with it as if it was my own. Within the scope of a programming language we tend, often subconsciously, to define our own dialect to describe the things we build. This dialect is expressed in the names we give to the classes, functions and variables within our applications. The position of an underscore, the use of verbs, nouns and adjectives, whether something is singular or plural — all of these things (and so much more) affect our understanding of the intent of the original developer.
There can be vast differences between the dialects of two JavaScript developers on a single project, which is only amplified with each additional developer. Put together a team of five developers each working on different portions of the same application, or ten developers all working on various projects together, and without a set of coding standards and naming conventions, code quality and developer efficiency will quickly go down, replaced with a tangle of conflicting approaches that serve to undermine overall cohesion as developers inject their own dialect into the structures written in the dialects of other developers.
As JavaScript is a dynamic language, naming conventions become even more important as almost everything can become anything else at any time; this means that part of our job as developers within a team is to encourage the correct use of what we create through the subtleties of naming conventions and standards.
Aside: My biggest pet peeve is finding that a developer has named something “foo” in their application. Foo, an utterly meaningless word, describes nothing, and gives others absolutely no hint as to the purpose of that thing. The only way to figure out what “foo” might refer to is to follow that name back through the code, reading every single line, incrementally gaining insight into the intent of the original developer. Everything given a name should be named to expose the intent of that thing.
Over the next week or so I’ll be sifting through my code in an attempt to codify my dialect of JavaScript. I hope to better understand my current approach and illuminate any shortcomings and inconsistencies. I’ll post an overview of what I find, along with code samples for illustration.
Jonathan Arkell | June 1, 2009 4:00 pm
This is further amplified by the fact that Javascript can be used procedurally, functionally or object oriented. Even in its OO, it is natively prototype based, but there earen’t that many (it seems) who know how to work with prototype OO.
JS provides the rope…
Dan Dean | June 1, 2009 5:58 pm
I’ve been thinking about this too. This is one of the unfortunate consequences of JavaScript typically being the secondary discipline of the author. People tend to be either server-side devs then JS devs, or html/css devs then JS devs. Our approach to JavaScript is then highly influenced by where our primary interests lie. This makes for an interesting (if sometimes galling) experience for those of us whose primary interest is in JavaScript.
Kris | June 8, 2009 4:21 pm
I’m curious to read your findings, and your current approach. I always get a little self-conscious when I think about my coding style — I tend to change my mind (and my style) a lot, which is not a good thing. I’ve written a lot of Actionscript lately which has definitely altered the way I write JavaScript, which in turn has changed the way I write PHP. For better or worse.
Radoslav Stankov | July 14, 2009 11:54 am
I haven’t work with more than 2 js developers. But I think that conventions and frameworks should be decided in the beginning. That using tools like sprockets for managing dependencies and sub-libs like my CD3Widgets Behaviors ( https://github.com/RStankov/controldepo-3-widgets ) will help a lot.
I think for the js work we should learn form the frameworks in the manner of managing work / code / responsibilities. And still serious js development is still in yearly stages.