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?




On Saturday, May 24, 2014 2:13:01 PM UTC-5, Bruno Fuster wrote:
>
> 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
>
> On May 24, 2014, at 5:55 AM, Jake <[email protected] <javascript:>> 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
>
> Thanks in advance for your advice and recommendations!
>
> -- 
> 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] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/nodejs/182298cb-ff3a-4a9d-a76f-b25be5a9e657%40googlegroups.com<https://groups.google.com/d/msgid/nodejs/182298cb-ff3a-4a9d-a76f-b25be5a9e657%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/c7aacfca-91d6-44c9-8d65-531d74341cf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to