097 How Do I Organize My Common Libraries Into Projects?

What is a good way to organize all of my common libraries? I have multiple reusable libraries that I have built up. What are some best practices around organizing them? How do I maintain them in a logical, easy-to-use manner? These are the questions we are going to answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:24

How do I organize my common projects into libraries I can reuse? How do I make sure that I have one set of libraries I can use for all of my other projects in a way that's logical? Do I put everything in one big project? Do I have lots of little projects? Are they all in the same solution? Do I have separate solutions? What do I do? What are the best practices around arranging my common code? This is a question that was asked on the suggestion site, and it's one I think that interests a lot of people, got a lot of upvotes, and I think that we should answer on today's episode of DevQuesti. Now, first, let's talk about how you want to organize your code. Now, we're talking about code where let's say you work in an organization and you always do data access with Dapper, and you always write a little bit of extra code around that Dapper. So you create a little bit of a library that you reuse over and over again. And maybe you also have a library that does, I don't know, emailing your code. So in your code, you have an email system that you wrote. Well, a lot of projects use that. So you put it in a library. But how do you start organizing these things so it's not just this chaotic mess? The first thing I want you to focus on is what goes together. And the way I tell what goes together is first, if one thing relies on another thing, those two should be in the same library. They should be in the same project and have direct access to each other. So that reliance means a coupling. Therefore, they should be coupled in code. There's no reason to separate them out. Next up, if you are always going to install these two libraries in every project, then why aren't they together? They probably should be. Because the two of them are necessary in your projects. There's no reason to keep them apart. But if there is no relationship between two different pieces of code, maybe one is for emailing, another is for creating zip files. There's not really a relationship there. Therefore, put them in different projects. Now, should you have all these projects in one solution? I would say no. I like to have them in separate solutions. That way they're totally isolated. You can upgrade one and not have to change anything else. When you build, you just build that entire solution, not you don't focus on, oh well, this particular library has to be rebuilt. So I like to have one solution per project that is a shared library. Now, next up, I recommend that you create a NuGet package out of that library. Even though you might only ever use this internally, you should still create a NuGet package out of it. And the benefit there is if you've ever dealt with DLLs, you know the mess that can cause. Do you know what version of that DLL it is? Well, maybe not. Do you know where that DLL is used? Do you know how long it's been since that's been upgraded? Do you know what's in that DLL? All these things, the answer is I don't know. So that's not a great thing. Instead, what you want to do is use Nougat packages. That way you have a version number in every application. You don't have to upgrade every application's NuGet package. However, when you do, you know what's in the new versions. So it allows very easily for you to maintain multiple versions and at the same time have an upgrade path that's very easy for your solutions that are relying on these libraries. So I would encourage you, every separate library gets its own NuGet package, even if it's only internally. So now you have these in separate systems, the things that are together, work together, are in the same library. Next, let's talk about repetition. This is one that people often misunderstand. There is an acronym, DRI, that we use a lot. We talk about don't repeat yourself. And this concept is around the idea of if you write code multiple times and you find a bug in it, well, you have to fix that bug multiple times. And there's a more higher likelihood you'll miss one of those. Therefore, you'll have that bug still in your code, and it's just even more insidious to find. So don't repeat yourself, says write the code once, and everything point back to that and rely on that. And that is a good concept, but it can be taken too far. Don't give in to extremism. When you say everything must be dry, there should be no repetition anywhere, you really make your code worse, not better. There is a value to repetition. So, for example, if you have a extension method for a string that maybe is a couple lines of code that does some tweaking, you're going to do more than once in your application. Maybe you do it in two different projects that are common projects. Don't turn that into its own project. Don't create a a NuGet package or a DLL just for that little bit. Don't put that as a as a dependency in both of your other common projects. Instead, just repeat the code. I know it sounds strange, but by creating that that separate library and depending on it in both sources, you create more of a mess. You create more complexity. Reduce the complexity by increasing a little bit your repetition. So don't go so far down your repetition elimination that you actually make your code more complex. Now that leads us into the third point, which is keep it simple. Focus on what actually needs to be in a library. Focus on what actually needs to be de-duplicated. Not everything needs to be in a library. Not every bit of code needs to be done once and used from everywhere. Sometimes you're gonna write code over again. That's okay. Focus on what should be in a library. And there's a couple different areas that should be in a library. So, first of all, if you do it an awful lot, maybe let's take something that is pretty common. Maybe you have a set of extension methods that you use everywhere. And every application needs these 10 extension methods. Well, since you're using them everywhere, may have a little bit of business logic in them, they're they're very common, then yes, that might be a good case for a separate library. However, again, if you're using a few of them or you sometimes use them, that's not a good case. Next up, if it's a complicated piece of code. Let's say that you have a system that builds out a zip file based upon a number of criteria, and it's a lot of complex logic, and you use it in maybe a few of your applications, that's a good opportunity to create a common library because there's complicated code there. If you have something more complicated, then yes, that's a great opportunity to put it in a library. But again, don't focus so hard on dry that you make your life more complicated. Because if you put everything in a library and you have 30 NuGet packages to depend on, that's too complicated. That makes things hard. Instead, focus on making it three, four, five NuGet packages, maybe at most, that you rely on in your application. Don't go so far down the rabbit hole of trying to make everything a library that you make your dependencies very hard to work with. Imagine for a minute you have a bug in your code. Well, if you have a bunch of NuGet packages and those packages depend on other packages, which depend on other packages, imagine how hard that is to track down where that bug is. It's a whole lot easier if it's right in your code. Now, yes, you have it right in your code. Maybe you're not taking in full advantage of the common library idea. There's a balance there, which is why you need to hit the middle, not either extreme. So focus on keeping it simple. Don't be afraid of repetition and organize your libraries in the way you'll use them. So those are my ideas. There is a lot of different ways to organize your libraries, but I would focus on those. Try to focus in what is going to make your life better, make your life simpler, and make your code simpler. Okay. Great question. I hope that answers the question. If you have a question your own, then go to suggestions.imtimcorey.com, leave that there, mark it as a dev question suggestion. I love to hear your suggestions, and maybe you'll hear the answer to your question on the next episode of DevQuestions. Thanks for watching. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 10:28

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share dev questions. You can also send your questions to questions at iamtimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.