Requesting advice for working on a large node.js application

[Jake]

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

Thanks in advance for your advice and recommendations!

[Bruno Fuster]

The same rules that you follow for other languages, mainly dynamic ones like ruby python groovy.

- separation of concerns

- well structured and small methods, using either OO or a functional style

- a lot of testing, unit, integration, etc

- pair programming 

- learn to not make callback hell, using small functions, async or promises, and take advantage of functions as first class citizens

- the better you plan and design with your team, the less refactors you might need

Cheers

--
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 nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/182298cb-ff3a-4a9d-a76f-b25be5a9e657%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jake]

Thanks Bruno!  A followup question regarding the unit testing:  I like to write lots of unit tests and I like knowing that when another developer changes code that might break something elsewhere in the codebase, a unit test will fail to let them know this happened.  Coming from a statically-typed language background, I am accustomed to using mocks to isolate what I'm trying to test, where if something like a function signature were to change, the test would fail to compile, but in JS (or any other dynamically typed language) the tests continue to pass just fine, since the mock data continues to work just fine.  It seems like a change in my testing strategy is needed.  The obvious solution seems to be to write a lot more integration tests, possibly sometimes in place of unit tests with mocks.  Do you find yourself more often writing a very large number of integration tests and avoiding unit tests with mocks?

[// ravi]

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?

—ravi

[Bruno Fuster]

Yeah that's true, get your team together and choose whatever they feel more comfortable with.

About tests, usually I have more integration/rest tests than unit with mock. 

--
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 nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CBB29D88-C24B-40CB-A61C-BF955CA925F2%40g8o.net.

[Jake]

Thanks Ravi.  Are there any additional things (aside from those you already mentioned) that you have found beneficial to standardize on?  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.

[// ravi]

On May 25, 2014, at 8:17 AM, Jake <jp02...@gmail.com> 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

[Daniel Rinehart]

I also tend to write more automated integration or system tests since I find more issues in the flow of data between various parts of the application than in individual modules. Fowler mentions a technique about a mock that records the results from the real service (http://martinfowler.com/bliki/SelfInitializingFake.html) that can then speed up future tests runs. Outside of unit tests you can replay the saved function calls and ensure you get the same results.

-- Daniel R. <dan...@neophi.com> [http://danielr.neophi.com/]

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/c7aacfca-91d6-44c9-8d65-531d74341cf4%40googlegroups.com.

[Jake]

The self initializing fake sounds like a pretty good idea.  The unit tests would still be vulnerable to a signature change though, with the replay data being old, but this would at least let me easily regenerate the data if I am concerned that something may have changed, and it would be far better than trying to manually re-code all the mocks involved.  Is there a library that you would recommend for doing the recording/playback for a node application?