On May 25, 2014, at 8:17 AM, Jake <[email protected]> wrote:
> Thanks Ravi. Are there any additional things (aside from those you already
> mentioned) that you have found beneficial to standardize on?
Well there are the standard and general issues: tabs vs spaces :-), indentation
size, variable/function/object/etc naming conventions, comments and inline
documentation... there are other coding style guides and "best practices" out
there: use of ===, avoid variable hoisting confusion by declaring variables at
the top (of the function). Then there are issues relevant to file structure.
E.g: how do programs find modules? Do you want to allow relative paths in
require()s?
I am listing mostly low level stuff here. There are higher level considerations
that are application and design/architecture specific as well. Do you have a
REST API for a server? What convention should be used for URLs? What parameters
belong in the URL vs what (if any) should go in a message body? Will it help to
"version" the API? Etc. But some of these, as noted, are application specific.
> There is certainly benefit to doing so, but I still like for a team of
> developers to have a lot of freedom to choose things as the project moves
> along, so it would be good to know which things are worth standardizing on
> and which don't really matter if they differ.
I would argue that you can give developers freedom to choose, but at the same
time, once a rational choice is made, then it be adopted team-wide (which does
not mean it cannot be changed upon later review). After all, you never know who
is going to work on a piece of code 2 months down the line. So, while it is
obvious that interfaces be consistent (e.g: when using callbacks, everyone
follows the Node convention of args: err, response), it is likely also going to
prove true that you want internals/implementation of each component to be
consistent with other components. The things that, without doubt, should be
left to the individual, are choices such as programming editors.
All IMHO of course :-).
--ravi
>
> On Saturday, May 24, 2014 11:45:42 PM UTC-5, // ravi wrote:
> On May 24, 2014, at 8:55 AM, Jake <[email protected]> wrote:
>> In discussions at my company about adopting node.js one concern that tends
>> to come up is about managing the codebase of a large project where about 10
>> developers are working on it concurrently.
>>
>> I would like to get some suggestions, techniques, best practices, and advice
>> from the group here for:
>>
>> 1. maintaining a clean codebase for a large node.js web application
>> 2. refactoring in a large node.js project (probably tied to #1)
>> 3. having a team of about 10 developers working on the same node.js
>> application
>> 4. quickly ramping up new developers (that already know JS well) on a large
>> node.js application
>>
>
> I have but one suggestion: choose one style of JS programming for the team
> and stick to it. Are you going to mimic or emulate classic OO with classes,
> prototypes, inheritance, etc? Are you going to use IIFEs for encapsulation?
> Are you going to use callbacks, or promises, or some other "flattening"
> library?
--
Job board: http://jobs.nodejs.org/
New group rules:
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/nodejs/48A05F2E-2CF6-4D4E-9EB7-FE8B7B80703F%40g8o.net.
For more options, visit https://groups.google.com/d/optout.
