Steve "ardalis" Smith Podcast Image

Steve "ardalis" Smith

Host, Producer & Editor of Weekly Dev Tips
Steve Smith (@ardalis) is an entrepreneur and software developer with a passion for building quality software as effectively as possible. He provides mentoring and training workshops for teams with the desire to improve. Steve has been recognized as a Microsoft MVP for over 10 consecutive years, and is a frequent speaker at software developer conferences and events. He is one of the top contributors to the official documentation on ASP.NET Core and enjoys helpings others write maintainable, testable applications using Microsoft’s developer tools. Connect with Steve at ardalis.com.
Recent episodes featuring Steve "ardalis" Smith
Boundaries with guest James Hickey
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 58, on the concept of boundaries, with guest James Hickey. Boundaries This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Read some of the testimonials on devBetter.com and see if it sounds like it you might be a good fit. This week we have our first returning guest, James Hickey. James was on the show earlier for episode 48 on how to accelerate your career. This week, he's back to talk about boundaries withing software systems. James is a software developer working remotely in eastern Canada. He's recently written a book about keeping your code clean called "Refactoring TypeScript" (https://leanpub.com/refactoringtypescript). He's also the author of an open-source .NET Core library called Coravel, which provides advanced capabilities to web applications. Welcome back, James! Boundaries Hi! I'm James Hickey. I'm a software developer working remotely in eastern Canada. When I started my career as a software developer I was thrust into a large codebase for a SAAS that helped automotive manufacturers perform analytics on their financial data. The way the codebase was organized is probably familiar to most developers - especially those with a background in enterprise-y companies. The solution was organized into 3 main projects: business, DAL (data-access), and "core" (which was just a bunch of classes having no business logic full of public getters and setters). At the end of the day, all the real business logic was mostly found within stored procedures in the database. So, all those layers didn't serve any real purpose. Business-oriented classes would just call a function from the DAL layer, and that method would call a stored procedure. As a fresh-out-of-school developer who's trying to learn "how the pros do it", I didn't question this way of organizing code. Eventually, though, I came to realize that this way of organizing code was terrible. It was hard to find code for specific features. You end up having to switch contexts between multiple projects when working on the same feature. A Better Way I've also been in projects having very different ways of organizing code, yet suffered from the same kinds of issues. Throughout this time, I had a hunch that there was a common issue that was causing these difficulties. It didn't matter how well classes or sub-systems were designed, because, in the grand scheme of things, it was still hard to deal with the codebase as a whole. As I read books and blogs and listened to well-known industry experts share their knowledge about software design, I came across better techniques and patterns for organizing code and designing software well. Then, I discovered domain-driven design. DDD DDD is a pretty huge subject, but at the heart of the entire philosophy is the idea that the most important thing about managing complexity in software is around putting up boundaries. In these other systems I've mentioned, the boundaries were enforced the wrong way. Instead of slicing our solutions by technical concerns (like by data-access, objects, interfaces, etc.), DDD teaches us to slice our solutions by business functionality (like shipping, search, billing, etc.) Since then, I've had the opportunity to learn about other approaches to software design and have formed some opinions around what works well and what generally doesn't work out so well. Out of all of these ideas, the most important one I've learned and have seen the effects of within real software projects is this idea of creating boundaries. Different Boundary Types You might be familiar with the concept called Bounded Contexts. In a nutshell, these are isolated sub-systems or bubbles that you design and build individually. Instead of creating one codebase and shoving all your code into it, you create a codebase or application per specific business feature or area of functionality. Multiple boundaries can communicate with each other, but not by traditional means. In projects like the ones I mentioned at the beginning, if shipping needed information from the payments feature, it would just reach into the database and query the payments table! These more strict boundaries mean you can't just reach into another feature's data or code. This has many benefits. Mainly, it allows the inside of each boundary to attack its core business problem head-on and not worry about secondary concerns like persistence and what other business problems require. And it decouples all your different bubbles or contexts. Inside each bounded context are these other boundaries called aggregates. These are objects that represent transactional boundaries. The details are not important, but what is important is that each aggregate does not directly call another aggregate's methods and grab its data. Usually, aggregates will emit events to communicate with each other. I use domain-driven design as the first example because the idea of boundaries is so fundamental to it. But there are other ways to enforce boundaries. Some prefer to create an isolated component, module, package or assembly (depending on what language you are in) and expose all the functionality of that isolated component as a facade. In this case, you might have one class that has all the publicly accessible behaviours or functions. None of the internal classes are exposed. When looking at architectures like Clean Architecture, all business functionality might be exposed as use cases. Each use case, like "register new user", would be modelled as a single class. This class would not expose any domain objects or objects from modules farther down the chain. It would expose it's own specific models or DTOs. This is a way to enforce a boundary so that the outside world doesn't know about the internal details of specific modules or components. Similarly, if you are building a web API then you might want to enforce boundaries by using view models or DTOs which are used for sending data to your clients. This way, internal details like specific domain classes aren't exposed and you can modify or version each endpoint without affecting the other modules or projects that depend on it. Using specific classes dedicated for use in HTTP POST data binding also helps keep boundaries around each specific end-point. You also get the added security benefit of not "over posting." Duplication? Whenever you share code you are introducing some form of coupling. This, in turn, is the opposite of putting up boundaries. Let's say, for example, I have a User class. This class is used within the user profile logic and the authentication logic for an application. If I need to add new behaviours to the authentication flow, does it make sense that the same functionality is now available for use in the user profile scenario? Since both features are sharing the same class, this is possible. This approach of trying to share as much code as possible throughout our apps is what causes spaghetti code and bugs galore. This is probably the biggest issue I come across in codebases. We think that sharing everything is good. But it's not. It creates a tangled mess of dependencies that, over time, cause businesses who want to be agile to sluggishly attempt to keep up with customer and market needs. Instead, if we isolate each of these features and NOT share that User class, then changes from one feature won't affect the other. Sure, you might end up creating two different user classes that have what look like duplicated fields, but that's OK. You aren't duplicating logic because these classes represent different things. The logic for the user profile screen is going to be different than authentication logic by definition. There is a place for shared behaviour, like sharing how you might display a user's name in your application's UI. But fundamentally, we should seek to create boundaries around the different parts of our codebases. Conclusion Next time you find yourself having to start a new project or product, think about how you can isolate that product or feature from the rest of your codebase. Maybe you want to build it as a completely separate assembly or project? In this case, you could use an event-driven means of communication. Or, maybe expose a public API as a facade. If that doesn't make sense or isn't possible, you can at least create a new folder structure that makes it very clear what business functionality exists in that place. I've written more about this last point over at builtwithdot.net if you are curious. Thanks for listening in! Thanks, James. I've added a link to your blog to the show notes. Listeners interested in learning more about Domain-Driven Design and Clean Architecture will find additional resources in the show notes as well. Show Resources and Links devBetter Changing How Your Code is Organized Could Speed Development Clean Architecture on GitHub DDD Fundamentals That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.
Dependency Inversion Principle
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.This is episode 57, on the Dependency Inversion principle.Dependency Inversion PrincipleThis week's tip is brought to you by devBetter.com.Sponsor - devBetter Group Career Coaching for DevelopersNeed to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Interested? Check it out at devBetter.com.Show Notes / TranscriptOk, now we've reached the last and in my opinion the most important of the SOLID principles, D for Dependency Inversion. The Dependency Inversion Principle, or DIP for short, has a longer definition that most of the other principles and is often conflated with the related coding technique, dependency inversion, or DI. The principle states that High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces or abstract types). and further, Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.Let's look quickly at each of these two parts. The first part talks about high level and low level modules. The "level" of a module has to do with how near or far it is from some kind of I/O device. That could be the user interface or it could be a local file or a database server. Low level modules deal directly with these kinds of I/O devices or destinations. High level modules do not know about or deal with specific kinds of I/O. These are things like business logic classes and behavior that model how a system works. In many systems that don't use abstractions, high level modules depend on low level modules, or the high level logic is mixed in with low level concerns in the same modules. Both of these approaches violate the Dependency Inversion Principle. Instead, these modules should communicate with one another using abstractions like C# or Java interfaces. Both kinds of modules would depend on a common interface, typically with the low level module implementing the interface and the high level module calling it.The second part suggests that abstractions - interfaces typically - should not depend on details. So an example of this would be if you had an interface for fetching information about a customer. One approach would be to write the interface so that it returned a SqlDataReader as its return type, where the data reader had the customer info. This exposes the details of how the data is stored, since you would only use a SqlDataReader to fetch the data from a SQL database. One benefit of following the Dependency Inversion principle is modularity. You could change that interface to return a simple List type and that List could come from any number of storage locations, from databases, to files to in-memory stores or web APIs. So, that covers how abstractions should not depend on details - what about the last bit that says details should depend on abstractions? That's talking about your low-level modules that actually communicate with I/O. These should depend on your interfaces by implementing them.If you're build a system composed of multiple projects it can be extremely difficult to follow the Dependency Inversion principle if you don't structure your project dependencies appropriately. This means ensuring that your abstractions - your interfaces - live in a project alongside your business model entities and that your implementation details live in another project that references this one. I have a GitHub repository and solution template called Clean Architecture that you can use as a starting point for new ASP.NET Core applications that need to follow SOLID principles and use clean architecture. You'll find a link to it in the show notes or just google ardalis clean architecture.A key benefit of Clean Architecture that is enabled by following the Dependency Inversion Principle is that your business model has no dependencies on external infrastructure concerns. These dependencies are a huge part of why legacy codebases are often difficult or impossible to write unit tests for. By keeping these dependencies separate and in their own project that other projects do not depend upon, it makes it much easier to unit test the most important part of your application: its business domain model. I talk more about this in my DDD Fundamentals course with Julie Lerman on Pluralsight if you want to see this in action. You can also check out the eShopOnWeb reference application that I built for Microsoft and its companion book, Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure.Show Resources and LinksdevBetterClean Architecture on GitHubSOLID Principles for C# DevelopersSOLID Principles of Object Oriented Design -and the DRY PrincipleDDD FundamentalseShopOnWeb Reference ApplicationThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.
One Step Build Test Run
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 56, on the importance of having a simple way to build, test, and run your application locally. One Step Build Test Run This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet weekly for group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript I've worked on a lot of projects for a lot of different companies and teams. One thing that dramatically increases the friction of becoming productive on a project is the number of manual and often undocumented steps required to take a new developer on a new machine and get them up and running the application from its source code locally. A lot of the time the developers on the team don't even recognize this as an issue because they've all been there long enough that they've absorbed the knowledge that's been passed down through shared oral history since the ancient times. But new developers, and especially new developers on distributed teams, weren't there last week when someone said "Oh yeah, I changed this thing so now you have to install this tool before you run the app on your machine". They don't just magically know the arcane command line scripts that must be run from 4 different nested subfolders of the application's source code in order to get the system up and running. As soon as you have one new remote team member, it exposes all the implicit knowledge-sharing and manual steps that have taken root in the team's processes and, hopefully, forces the team to make these steps explicit and then to automate them as much as possible. Simple projects don't require much, if any, documentation or automation. If you have an application that is so simple that any new developer can pull it down from source, use the default compilation step for the platform, like dotnet run for .NET Core or F5 for a Visual Studio-based solution, then you may not need any more documentation or automation than that. But when it's not that simple, you'll make everybody's life easier if you document and automate the steps. Documentation should be first, since it just makes the steps explicit, and sometimes automation can be difficult to achieve, especially if you need it to work across different operating systems. This is getting easier, though. Once you have the steps documented, you should strive to automate them to the point where common tasks are a single step. Ideally you want a One Step Build Test Run script that does all of these things: builds the app, runs tests against it, runs the app. But before we get that far, let's talk about how to document the process a bit more. Today, GitHub has become the standard for open source software projects. And GitHub has essentially codified the standard that projects should have README.md files in their root that describe what the project is. Even if you're not hosting your application's code on GitHub, it's a good guess that your dev team has looked at projects on GitHub and is familiar with this convention. Thus, purely from a discoverability standpoint, the best place to put important steps for building and running your app is in its README file in the root of the repo. If you have a lot of repositories that all use the same steps and you don't want that duplication, then put a link to the shared docs into each README. What about wikis? Wikis are less discoverable. They're not right there in your face when you hit the home page of a repo, and they're not right there with your code when you're looking at the source in your favorite editor like a README file is. You can put more detailed documentation and steps into a wiki if you like, but to make it discoverable you should put links to it in the README file. If you use some CMS system or project management system the answer's the same - use the README as the place to include the links to the relevant information so new team members don't have to try and find it themselves. HTML supports hyperlinks for a reason. Probably the worst thing you can do in documenting your local build/test/run process is to start by putting it in the README file and then later decide to put the process in a wiki or another location, but not update the README. This will cause team members to use the README and not discover the new location, wasting lots of their time. Bad information is worse than no information. Put a link to the new process documentation location in the README. Show Resources and Links devBetter Really old blog post on one-click builds That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.
Interface Segregation
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 55, on the Interface Segregation principle. Interface Segregation Principle This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers You can find help and advice all over today, from twitter to Stack Overflow to various Slack communities. These are great, but if you need more, if you need someone you can count on when you reach out for advice on code or your career, check out devBetter.com. Read the testimonials. Join risk free and see if it's for you. Not only will you learn from me, but if you stay for a while you'll grow and begin to be a mentor for others, gaining valuable confidence and experience. I've watched it happen. Show Notes / Transcript Returning back to the next SOLID principle, this week we're on the I as in Interface. Yes, it's the Interface Segregation Principle! Or ISP for short. Let's start by defining what this principle says. ISP states that no client should be forced to depend on methods it does not use. That's it. You can think of ISP as basically suggesting that you should prefer small, cohesive interfaces to large interfaces. In episode 49, which hopefully you already heard because you're listening to these in sequential order, we talked about the Single Responsibility Principle. These two principles are related! If you have classes that have only one responsibility, they're likely to expose a small, cohesive interface. That might be worth diving into a bit more. I'm guessing that when some developers, especially C# or Java developers, hear about ISP, they immediately map the word 'interface' to the interface type and keyword in these languages. That's not wrong, it's just not fully right, either. The public methods and properties a class exposes are its interface, even if it doesn't implement any interface defined separately. And ISP applies to implicit class interfaces just as much as it does to explicit interface definitions declared with the interface type. If you keep this in mind, it may make it easier to see how SRP and ISP relate, since SRP doesn't make any mention of interface types, only classes. The previous principle we discussed, Liskov Substitution, also relates to ISP. If you have a small, cohesive interface on a class, then when you decide to inherit from it you only have a few methods to worry about. If you have a massive number of methods, and your subtype is only concerned with a subset of them, it's much more likely that you won't fully implement all of the class's methods, potentially leaving some methods to throw NotImplementedException. Thus, it's easier to follow LSP if you first follow ISP. What's the point of having a smaller interface instead of a larger one, though? What's the down side to having fewer, larger classes with many methods on them? Certainly there's an argument to be made, and many have, that it makes it easier to find methods when you don't have so many different classes to search through to find them. The goal of ISP is to reduce dependency between types and especially between components in a system. The more types that depend on a particular type, the more difficult that type is to change. The more inertia it has in the system. If you have a class in your application that's used by 100 other classes, how likely are you to make major changes to its design, compared to one that you just wrote that has literally no other classes using it yet? Of course it's easier and WAY less risky to change classes that have few references to them. Let's say you want to change something fundamental about how that class that's used by 100 other classes works. One way you could do that would be to create a new instance of that class's interface or abstract base class, but then you'd have to implement all of its methods. Odds are, there are a bunch of them. That's not going to be easy - so instead you might just add some more conditional logic to some of the methods. Maybe add a few more method parameters to some methods. Maybe add a couple of new method overloads. And guess what? The problem just got bigger. The class just got bigger. The inertia just grew. By having a small interface and being focused on a small set of functionality, ISP-following classes are easier to change an easier to replace. By being small, they're easier to subtype or implement, making it easier to build systems that are modular. You find a class that has two methods and you want to change how it works in some situations? Just write a new class, implement the two methods, and swap it in where appropriate. Prefer writing new code to change legacy systems rather than modifying existing code. By following ISP, it's easier to replace classes with different variants that implement the same interface, which results in more loosely coupled and modular designs. These designs are easier to maintain and easier to test. You can learn more about ISP and the rest of the SOLID principles from my courses on Pluralsight, linked from this episode's show notes on weeklydevtips.com/episodes/55. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring for C# Developers That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.
Customize Key Mappings in Visual Studio with Kendra Havens
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 54, on customizing key bindings in Visual Studio with guest Kendra Havens. Customize Key Mappings with Kendra Havens This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript This week's guest tip is from Kendra Havens. Kendra is a program manager at Microsoft on the .NET and Visual Studio team, where she focuses on the Visual Studio testing experience and productivity tools. She does videos on .NET, VS Code, and Docker and is a frequent conference presenter as well. In fact, we last met up at a recent DevIntersection conference where we were both presenting, and I invited her to share a favorite tip on the podcast. The nature of describing a visual tool in a podcast is challenging, so I have a link to a video in the show notes if you want to follow up afterward. Welcome, Kendra! Thanks, Kendra! I'll post a link to a video showing how to do this in the show notes for anyone that wants to see it. Show Resources and Links devBetter Kendra on Twitter Visual Studio Productivity Tips - Keyboard Command Mapping That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.
Share Profile
Are you ardalis? Verify and edit this page to your liking.
Stats
Birthdate
Nov 8th, 1973
Location
Kent, Ohio, USA
Episode Count
59
Podcast Count
2
Total Airtime
6 hours, 53 minutes