3 ms·

>Splitting up the code into multiple files enabled us to scale the project. I really don't get this at all. More files == more scalable? Someone more knowledge

>Splitting up the code into multiple files enabled us to scale the project. I really don't get this at all. More files == more scalable? Someone more knowledgeable about ... whatever topic is relevant here care to explain this to me?

dougabug 14y ago
Because a hundred files must be worth ten times as much as ten files. Maybe he gets paid by the file.
kevincennis 14y ago
I tend to like having discrete modules of code split up into separate files when I'm building large JavaScript apps (which is really all I do). It helps keep me organized. And I think it also makes version control run more smoothly. Generally, I'll write a little build script in Node that concatenates and minifies all my JS and CSS before actually deploying to production to keep the number of HTTP requests down.
bitcrusher 14y ago
He means "scale the number of people working on the project at one time." He's basically saying that if you have 10 files and 2 developers the chances of collision (or merging issues) is small, but having 20 developers working from 10 files makes things more sticky. To some degree, he's not incorrect, in that over time, you'll spend more time managing the merging and conflict process than you will writing code. Obviously, there are modern tools that will help alleviate this problem, but the deeper you go, the worse it is. This was the reason that "old" VCS had exclusive locks.
- artsrc 14y ago
  If you change an interface, and someone else adds a new client to the interface locking does not help. So file based locking does not guarantee that merge conflicts won't occur. Managing essential merge issues relates to success at dividing work up into highly cohesive, loosely coupled units. The accidental merge issues are not a big deal in good environments.

3 ms·

>Splitting up the code into multiple files enabled us to scale the project. I really don't get this at all. More files == more scalable? Someone more knowledge

by mattdeboard 14y ago

dougabug 14y ago
Because a hundred files must be worth ten times as much as ten files. Maybe he gets paid by the file.
kevincennis 14y ago
I tend to like having discrete modules of code split up into separate files when I'm building large JavaScript apps (which is really all I do). It helps keep me organized. And I think it also makes version control run more smoothly. Generally, I'll write a little build script in Node that concatenates and minifies all my JS and CSS before actually deploying to production to keep the number of HTTP requests down.
bitcrusher 14y ago
He means "scale the number of people working on the project at one time." He's basically saying that if you have 10 files and 2 developers the chances of collision (or merging issues) is small, but having 20 developers working from 10 files makes things more sticky. To some degree, he's not incorrect, in that over time, you'll spend more time managing the merging and conflict process than you will writing code. Obviously, there are modern tools that will help alleviate this problem, but the deeper you go, the worse it is. This was the reason that "old" VCS had exclusive locks.
- artsrc 14y ago
  If you change an interface, and someone else adds a new client to the interface locking does not help. So file based locking does not guarantee that merge conflicts won't occur. Managing essential merge issues relates to success at dividing work up into highly cohesive, loosely coupled units. The accidental merge issues are not a big deal in good environments.