tag:blogger.com,1999:blog-4273255328290947077.post7106596185582872624..comments2023-05-17T10:04:02.732-06:00Comments on Being Cellfish: Abstracting vs Isolating dependenciescellfishhttp://www.blogger.com/profile/12888771675677858223noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-4273255328290947077.post-26090730386153346042014-05-04T08:35:43.855-06:002014-05-04T08:35:43.855-06:00I think it's a repeated pattern in discussions...I think it's a repeated pattern in discussions, and I also think it's almost always pointless to discuss. Because what we (almost) always lack is context. All the techniques and ways to split projects etc. are centering around simple questions. how big is your codebase, did you reach the "painlevel" for the next scaleout move. That could be introduction of IOC container, intrduction of verticval slices in the architecture (reducing build time by strongly reducing the longest path in the build dependency tree), introdcution of more sophisticated spectests , etc. pp. There is never a right or wrong, just the righ or wrong chouice in relation to some metrics of a codebase, and as long as we don't define those metrics and simplify to a shared mental "map", we will always stumble in the dark.<br />To be more specific: in your case, the codebase was sophisticate enough, so that the overhead of the added project easily trumped the problem with updating the 3rd party reference. "Sophisticated" in that case means a higher score in soem kind of "3rd party change frequency vs code read frequency" metric. In addition, technology (a.k.a tooling) always removes the overhead, so having an alternative build tool which doesn't rely on VS (in fact inside my company I'm writing one right now) and completely derives the build tree from conventions, makes the extra project a nonissue.<br /><br />Sorry for the long post, but it was just something on my mind, should probably start blogging as I see that pattern in discussion all over the place.Anonymoushttps://www.blogger.com/profile/15557998819642909832noreply@blogger.comtag:blogger.com,1999:blog-4273255328290947077.post-46065778992597483942014-05-02T09:55:03.298-06:002014-05-02T09:55:03.298-06:00@Daniel Fisher: I do not completely agree with the...@Daniel Fisher: I do not completely agree with the article you referenced since it seems to imply that if you have a large project you always compile everything. For a large project I do not think I would ever want to compile everything at once, ever. I think you want to separate your project into smaller pieces that are built separately and then shared in binary form. Either by using a private NuGet server or a binary drop folder. The referenced article kind of implies that since it mentions building all projects into a common bin folder.<br />On the projects I have worked on putting everything into one single assembly would not have made it possible for me to compile in a short enough time for me to be happy when I need to make a change.<br />This does not mean that the article is giving bad advice. I agree some people create way more projects than they need and that is bad. I even said above that physical separation is something you can do on demand to save yourself some work since I described what I hope is a very rare scenario. The key point is to show that abstraction of dependencies is not always enough - isolation is the only way to be sure. But like they say in the movie Aliens; "let's nuke it from orbit, it is the only way to be sure" - the solution that solves all your problems is not going to be the best solution for all your problems.cellfishhttps://www.blogger.com/profile/12888771675677858223noreply@blogger.comtag:blogger.com,1999:blog-4273255328290947077.post-49155779929526931522014-05-02T03:47:29.295-06:002014-05-02T03:47:29.295-06:00Dear Cellfish,
I don't think that more comple...Dear Cellfish,<br /><br />I don't think that more complexity, more compile time, more deployment, more IO, etc... is a fair price for handling dependency changes gracefully.<br /><br />Further read: https://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/<br /><br />Best regards,<br />DanielAnonymoushttps://www.blogger.com/profile/04402842196319115917noreply@blogger.com