jackiw@cs.swarthmore.edu (Nick Jackiw) (02/08/89)
Here's a question for any of you using LSP to work on mid- to large-scale
development projects.
Up til now, I've done most of my applications' development alone, and
consequently haven't had much problem keeping track of what does what
and where its doing it. Browsing over past projects, I see that my
average number of units (source files) per segment is four or five, each
being 3-10K.
Recently, however, I've been working on a project large enough that at
some point my boss plans to hire a programming team to work on it. With
this comes necessarily increased attention to consistent documentation,
intra-team communication, etc. A preliminary analysis of the subsystems
involved in the entire project shows that a lot of small files (on the
order of 1/2K bytes) would be much more manageable ideally, just for
"division of labor" and "separation of functionality" and so-forth.
My question is: has anyone experienced practical drawbacks to having LOTS
of units in a project? And (I guess this is directed to Rich S.), are
their any limitations (absolute or relative) to LSP's internal implementation
of the unit list? More generally, what sort of project fragmentation do
large-scale developers find best suits their needs?
I'm aware of obvious things like the increased file-system interaction
necessary to re-compile 10 small files rather than one large one, of
course. My interface-declarations are sufficiently sacrosanct that most
of my Code-Go-Debug-Go cycles don't trigger cascading recompilation of
dependent units, however.
Any thoughts or general discussion on this topic would be appreciated.
Thanks,
Nick
--
+-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+
| nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet |
+-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+
"I cannot approve thy marriage choices, son."(Samson's dad, _Samson Agonistes_)siegel@endor.harvard.edu (Rich Siegel) (02/08/89)
In article <2406@ilium.cs.swarthmore.edu> jackiw@swatsun.UUCP () writes: > >My question is: has anyone experienced practical drawbacks to having LOTS >of units in a project? And (I guess this is directed to Rich S.), are >their any limitations (absolute or relative) to LSP's internal implementation >of the unit list? More generally, what sort of project fragmentation do >large-scale developers find best suits their needs? The Lightspeed Pascal 2.0 bootstrap contains 111 (one hundred and eleven) files, ranging in size from about 2K to about 70K. One of my projects contains about 90 files, all of which weigh in at under 20K. My preference is towards a larger number of smaller source files, since smaller source files are easier to manage. The increased disk hits aren't really a factor, since they can easily be offset by use of a cache. Full builds where each file uses a number of other units may require a little more memory, but otherwise there's not much to be lost by using smaller files. We're in the process of researching the multi-programmer problem, so that in the future we can come up with a solution for group projects. The "Check-In, Check-Out" paradigm is clunky (in my opinion, anyway), and we have some more streamlined and intuitive solutions in mind. -Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.