PDA

View Full Version : How does Sencha keep its codebase so clean and organized?



fliptight
4 Feb 2014, 9:51 AM
Well, my only experience with Sencha is really just Ext JS 4.x.x, but I am rather impressed by how clean and well organized the codebase is, specially with all the jsdocs.

What kind of workflow/processes do you guys follow to maintain a codebase like this?

scottmartin
4 Feb 2014, 2:54 PM
JSDuck is what is used to create the docs. It pulls the comments from the code.
https://github.com/senchalabs/jsduck

fliptight
5 Feb 2014, 8:11 AM
Thanks for the reply, but I was hoping for a more in-depth response.

For example, what kind of processes do you guys follow so that everyone on the team produces quality code? Whenever a new feature needs to be written, does an architect lay everything out for the person(s) implementing it? Do you guys do a (group) whiteboarding session? How do you perform code reviews? Etc.

LesJ
5 Feb 2014, 10:13 AM
It really boils down to craftmanship. If you take a look at the nightly builds, they are even better with regard to code cleanliness. For example, a lot attention is paid to white space usage.

scottmartin
5 Feb 2014, 10:22 AM
It really boils down to craftmanship.

That is about it .. a coding style is decided on and adhered to by all.

Teams will use a repository to manage their code. If you have some crap code, and it is added to the main repo, then that falls on the person merging the code.

There are of course scrums for everyone to get together and discuss the new direction.

Scott.

skirtle
5 Feb 2014, 7:21 PM
that falls on the person merging the code.

I think that's the key thing. The GitHub workflow ensures that each pull request gets reviewed by a senior developer before it hits the repo. That way you only need one disciplined reviewer to keep everyone else in check.

fliptight
6 Feb 2014, 10:12 AM
Ah ok. That's an insight I was looking for. You are right, it's impossible to expect all developers to have the same level of discipline.

So a senior developer would review the pull request, and push it back to the developer with some notes if it doesn't meet certain criteria I am assuming?

skirtle
6 Feb 2014, 7:07 PM
Yeah, bouncing it back to the original developer would be the usual approach.

The GitHub workflow is really solid once you get your head around it. It's also pretty easy to work with, the job of merging changes into the master repo is considerably less painful than it would be using branching in a traditional VCS.