Latest / DevQuestions with Tim Corey / 097 How Do I Organize My Common Libraries Into Projects?

Transcript

097 How Do I Organize My Common Libraries Into Projects? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_01: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_01: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_01: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_01: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:24
  SPEAKER_02: How do I organize my common projects into libraries I can reuse?
• 0:30
  SPEAKER_02: 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?
• 0:37
  SPEAKER_02: Do I put everything in one big project?
• 0:40
  SPEAKER_02: Do I have lots of little projects?
• 0:42
  SPEAKER_02: Are they all in the same solution?
• 0:44
  SPEAKER_02: Do I have separate solutions?
• 0:46
  SPEAKER_02: What do I do?
• 0:46
  SPEAKER_02: What are the best practices around arranging my common code?
• 0:52
  SPEAKER_02: 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.
• 1:03
  SPEAKER_02: Now, first, let's talk about how you want to organize your code.
• 1:07
  SPEAKER_02: 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.
• 1:19
  SPEAKER_02: So you create a little bit of a library that you reuse over and over again.
• 1:25
  SPEAKER_02: And maybe you also have a library that does, I don't know, emailing your code.
• 1:31
  SPEAKER_02: So in your code, you have an email system that you wrote.
• 1:34
  SPEAKER_02: Well, a lot of projects use that.
• 1:36
  SPEAKER_02: So you put it in a library.
• 1:38
  SPEAKER_02: But how do you start organizing these things so it's not just this chaotic mess?
• 1:42
  SPEAKER_02: The first thing I want you to focus on is what goes together.
• 1:48
  SPEAKER_02: 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.
• 1:56
  SPEAKER_02: They should be in the same project and have direct access to each other.
• 2:00
  SPEAKER_02: So that reliance means a coupling.
• 2:03
  SPEAKER_02: Therefore, they should be coupled in code.
• 2:06
  SPEAKER_02: There's no reason to separate them out.
• 2:08
  SPEAKER_02: Next up, if you are always going to install these two libraries in every project, then why aren't they together?
• 2:17
  SPEAKER_02: They probably should be.
• 2:18
  SPEAKER_02: Because the two of them are necessary in your projects.
• 2:22
  SPEAKER_02: There's no reason to keep them apart.
• 2:25
  SPEAKER_02: But if there is no relationship between two different pieces of code, maybe one is for emailing, another is for creating zip files.
• 2:34
  SPEAKER_02: There's not really a relationship there.
• 2:36
  SPEAKER_02: Therefore, put them in different projects.
• 2:39
  SPEAKER_02: Now, should you have all these projects in one solution?
• 2:43
  SPEAKER_02: I would say no.
• 2:45
  SPEAKER_02: I like to have them in separate solutions.
• 2:48
  SPEAKER_02: That way they're totally isolated.
• 2:51
  SPEAKER_02: You can upgrade one and not have to change anything else.
• 2:56
  SPEAKER_02: When you build, you just build that entire solution, not you don't focus on, oh well, this particular library has to be rebuilt.
• 3:05
  SPEAKER_02: So I like to have one solution per project that is a shared library.
• 3:12
  SPEAKER_02: Now, next up, I recommend that you create a NuGet package out of that library.
• 3:18
  SPEAKER_02: Even though you might only ever use this internally, you should still create a NuGet package out of it.
• 3:24
  SPEAKER_02: And the benefit there is if you've ever dealt with DLLs, you know the mess that can cause.
• 3:31
  SPEAKER_02: Do you know what version of that DLL it is?
• 3:33
  SPEAKER_02: Well, maybe not.
• 3:35
  SPEAKER_02: Do you know where that DLL is used?
• 3:38
  SPEAKER_02: Do you know how long it's been since that's been upgraded?
• 3:41
  SPEAKER_02: Do you know what's in that DLL?
• 3:43
  SPEAKER_02: All these things, the answer is I don't know.
• 3:46
  SPEAKER_02: So that's not a great thing.
• 3:48
  SPEAKER_02: Instead, what you want to do is use Nougat packages.
• 3:51
  SPEAKER_02: That way you have a version number in every application.
• 3:56
  SPEAKER_02: You don't have to upgrade every application's NuGet package.
• 4:00
  SPEAKER_02: However, when you do, you know what's in the new versions.
• 4:05
  SPEAKER_02: 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.
• 4:19
  SPEAKER_02: So I would encourage you, every separate library gets its own NuGet package, even if it's only internally.
• 4:28
  SPEAKER_02: So now you have these in separate systems, the things that are together, work together, are in the same library.
• 4:36
  SPEAKER_02: Next, let's talk about repetition.
• 4:38
  SPEAKER_02: This is one that people often misunderstand.
• 4:43
  SPEAKER_02: There is an acronym, DRI, that we use a lot.
• 4:47
  SPEAKER_02: We talk about don't repeat yourself.
• 4:50
  SPEAKER_02: 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.
• 5:00
  SPEAKER_02: And there's a more higher likelihood you'll miss one of those.
• 5:04
  SPEAKER_02: Therefore, you'll have that bug still in your code, and it's just even more insidious to find.
• 5:10
  SPEAKER_02: So don't repeat yourself, says write the code once, and everything point back to that and rely on that.
• 5:16
  SPEAKER_02: And that is a good concept, but it can be taken too far.
• 5:23
  SPEAKER_02: Don't give in to extremism.
• 5:26
  SPEAKER_02: When you say everything must be dry, there should be no repetition anywhere, you really make your code worse, not better.
• 5:36
  SPEAKER_02: There is a value to repetition.
• 5:39
  SPEAKER_02: 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.
• 5:52
  SPEAKER_02: Maybe you do it in two different projects that are common projects.
• 5:57
  SPEAKER_02: Don't turn that into its own project.
• 6:01
  SPEAKER_02: Don't create a a NuGet package or a DLL just for that little bit.
• 6:06
  SPEAKER_02: Don't put that as a as a dependency in both of your other common projects.
• 6:13
  SPEAKER_02: Instead, just repeat the code.
• 6:17
  SPEAKER_02: 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.
• 6:27
  SPEAKER_02: You create more complexity.
• 6:29
  SPEAKER_02: Reduce the complexity by increasing a little bit your repetition.
• 6:35
  SPEAKER_02: So don't go so far down your repetition elimination that you actually make your code more complex.
• 6:42
  SPEAKER_02: Now that leads us into the third point, which is keep it simple.
• 6:47
  SPEAKER_02: Focus on what actually needs to be in a library.
• 6:51
  SPEAKER_02: Focus on what actually needs to be de-duplicated.
• 6:56
  SPEAKER_02: Not everything needs to be in a library.
• 6:59
  SPEAKER_02: Not every bit of code needs to be done once and used from everywhere.
• 7:05
  SPEAKER_02: Sometimes you're gonna write code over again.
• 7:07
  SPEAKER_02: That's okay.
• 7:09
  SPEAKER_02: Focus on what should be in a library.
• 7:12
  SPEAKER_02: And there's a couple different areas that should be in a library.
• 7:15
  SPEAKER_02: So, first of all, if you do it an awful lot, maybe let's take something that is pretty common.
• 7:23
  SPEAKER_02: Maybe you have a set of extension methods that you use everywhere.
• 7:30
  SPEAKER_02: And every application needs these 10 extension methods.
• 7:34
  SPEAKER_02: 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.
• 7:46
  SPEAKER_02: However, again, if you're using a few of them or you sometimes use them, that's not a good case.
• 7:52
  SPEAKER_02: Next up, if it's a complicated piece of code.
• 7:57
  SPEAKER_02: 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.
• 8:29
  SPEAKER_02: If you have something more complicated, then yes, that's a great opportunity to put it in a library.
• 8:34
  SPEAKER_02: But again, don't focus so hard on dry that you make your life more complicated.
• 8:40
  SPEAKER_02: Because if you put everything in a library and you have 30 NuGet packages to depend on, that's too complicated.
• 8:48
  SPEAKER_02: That makes things hard.
• 8:50
  SPEAKER_02: Instead, focus on making it three, four, five NuGet packages, maybe at most, that you rely on in your application.
• 8:59
  SPEAKER_02: 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.
• 9:09
  SPEAKER_02: Imagine for a minute you have a bug in your code.
• 9:12
  SPEAKER_02: 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.
• 9:24
  SPEAKER_02: It's a whole lot easier if it's right in your code.
• 9:27
  SPEAKER_02: Now, yes, you have it right in your code.
• 9:29
  SPEAKER_02: Maybe you're not taking in full advantage of the common library idea.
• 9:34
  SPEAKER_02: There's a balance there, which is why you need to hit the middle, not either extreme.
• 9:40
  SPEAKER_02: So focus on keeping it simple.
• 9:43
  SPEAKER_02: Don't be afraid of repetition and organize your libraries in the way you'll use them.
• 9:49
  SPEAKER_02: So those are my ideas.
• 9:51
  SPEAKER_02: There is a lot of different ways to organize your libraries, but I would focus on those.
• 9:57
  SPEAKER_02: Try to focus in what is going to make your life better, make your life simpler, and make your code simpler.
• 10:04
  SPEAKER_02: Okay.
• 10:05
  SPEAKER_02: Great question.
• 10:06
  SPEAKER_02: I hope that answers the question.
• 10:07
  SPEAKER_02: If you have a question your own, then go to suggestions.imtimcorey.com, leave that there, mark it as a dev question suggestion.
• 10:16
  SPEAKER_02: I love to hear your suggestions, and maybe you'll hear the answer to your question on the next episode of DevQuestions.
• 10:23
  SPEAKER_02: Thanks for watching.
• 10:24
  SPEAKER_02: Thanks for listening.
• 10:25
  SPEAKER_02: And as always, I am Tim Corey.
• 10:28
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 10:31
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 10:34
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share dev questions.
• 10:41
  SPEAKER_00: You can also send your questions to questions at iamtimcorey.com.
• 10:47
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 10:54
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.