> > some scaling issues arrive the moment you would like to have two people > work on something
Well, those two people are going to be pair programming, right? ;-P <omg i am winking so hard right now> On Thu, Aug 25, 2016 at 4:52 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > On Aug 25, 2016, at 2:51 PM, Richard Feldman <richard.t.feld...@gmail.com> > wrote: > > Richard's definition of large application (36,000 lines) and my definition >> (Photoshop, Lightroom, ...) are rather different in scale >> > > OP said "If i have a site with lots of features what is the best way to > orgainze everything?" and our code base precisely fits the bill for what he > asked for advice about. :) > > > Point taken. > > However, I fear that your argument to worry about scaling later dances > around the fact that some scaling issues arrive the moment you would like > to have two people work on something. At that point, they can generally > both be more productive if you can subdivide the work, put an API in place > in between, and then let each proceed in a separate file. This avoids lots > of opportunities for toes to get stepped on either in actual coding or in a > source code merge. > > Breaking things out into new utility types and functions is pretty clear, > but what are the useful patterns to take an app and subdivide it so that > two people can work on it at once? What are the API design principles one > should apply? > > Mark > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
