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
Test All The Things with Guest Corey Weathers
Episode of
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 50 with some guest tips on Testing All The Things! Test All The Things This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript I'm glad to have a new guest offering some tips. Corey Weathers of Twilio is going to offer his perspective on the importance of software testing. Corey loves .NET and has worked for companies including Microsoft and the US federal government before joining Twilio as a developer evangelist. He works to inspire and equip .NET developer, underrepresented developers, and the Twitch community of developers with the tools they need to build the future of communications. Welcome, Corey! My name is Corey Weathers and I have the privilege and pleasure of being a .NET developer evangelist for a great company named Twilio. I’d like to start this week by saying a big thank you to Steve for inviting me on the Weekly Dev Tips podcast. This week I’d like to talk about something very near and dear to my heart as a developer – software testing. WHY TEST Now you may be wondering why testing. After being a developer for a number of years, I have found the following things to happen pretty consistently – someone usually has a problem and says “hey a developer can fix that”. Hopefully they’ve checked in with a software developer before making that assumption, but that’s not often the case. It’s usually problems like these that turn into use cases, user stories, or requirements. As product development happens, it can also be the case that these stories become more specific, nuanced, and refined in scope. When that happens, it’s not unusual to see more user stories created to cover the new scope that was removed from existing stories. What you end up with is one problem that a developer can fix turning into an ever-expanding list of user stories that become very complicated. Now when we start writing the code for one use case, and more show up, we continue writing more and more code to meet the ever expanding list of requirements and after this, we miss the opportunities to validate the code that we’re building. WHAT DOES TESTING DO So one of the first mantras to remember here is – TEST EARLY. Why? Because when you start early, you get to check one box that is super important – that is, you’re making sure that you’re building the right thing. This allows you to clarify your assumptions and confirm the suspicions you may have but that haven’t already been identified and figured out. Which leads me to the second mantra – TEST OFTEN. If Test Early ensures that you’re building the right thing, Test Often makes sure that you’re building the thing right. By making your code testable, you’ve added so much to your code base: maintainability, a measure of quality, and confidence in that things will work as you’ve both built and expected them to. WHERE DO I START At this point you may be wondering, ok well where do I start? And I realize a number of you may be coming from different starting points. Some of you may be at the very beginning and haven’t written a single line of code; whereas others of you may have an application deploying into a production environment that has poor test coverage. I know that it can be tough to get started. Hopefully this piece of advice should be relevant for you no matter where you’re starting from. My third and final mantra is START SIMPLE Let’s use an example here. For our conversation – let’s assume we have an application that has a user interface, and this user interfaces connects to an API that takes some data and saves it in a database. Assuming everything works as expected, you can start by writing a test for each part of this sequence. So one test can reproduce what happens when you click on the button when rendering the UI; a second test can simulate what happens when the UI calls the API; a third test can confirm that the database actually saved the data; and a final test can simulate all of the steps here by testing this one action with an API and database that looks close to what it will be in the real world. We could probably have an entire conversation as well about making sure you test setting up your application, but if you’re just getting started with testing there’s no need to start there. WHAT DO I DO WITH ALL OF THE TESTS With this suite of tests, you now have 4 tests that you can very easily expand on. You’ve started by testing the simplest path forward and can now add different modifications to this path, like what happens when my computer isn’t connected to the internet and my UI can’t talk to the API. Now here’s where we reach the inevitable – well if I’m just starting out with writing tests and something doesn’t pass as I expect it to, what do I do? Here is where I usually say – this is a good thing. Your test is starting to work. Think about it for a second. If you start writing tests and they start making you ask questions about how your test is working, then you’ll probably end up changing your test a bit so that this question focuses more on your application. This is a win because you’ll learn how to write better tests in the process. Alternatively, if you start writing tests and they make you question how your application is working, this is a win because it’s forcing you to make sure your application is meeting its intended need AND is testable as it is doing so. So write more tests, look for their results, and respond when the results don’t match what you expect. CALL TO ACTION That’s it from me this week friends. Remember TEST EARLY, TEST OFTEN, AND START SIMPLE. If you are interested in following up on testing, take a look at the Art of Unit Testing, written by Roy Osherove. He’s built an amazing body of content to help describe some of the why and how to begin testing. If you’d like to follow up with me, feel free to email me at corey@twilio.com. That’s C-O-R-E-Y@T-W-I-L-I-O.COM. That’s it from me this week. I’ll pass it back to Steve. Great stuff, Corey! Thanks for sharing with everyone. Art of Unit Testing is definitely a good book - I'll post a link in the show notes. Show Resources and Links devBetter Art of Unit Testing by Roy Osherove 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.
Single Responsibility Principle
Episode of
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 49 on the Single Responsibility Principle. Single Responsibility This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript The Single Responsibility Principle, or SRP, is the S in the SOLID principles macronym. The short version of it is that a class should have only one reason to change. Specifically, the reason referred to here is tied to the application's requirements. Each class should only be required to change in response to a single change in the application's requirements. These requirements typically correspond to real world things. For example, let's say the application needs to display a report for quarterly sales performance. The system's requirements might be that the report be rendered in a browser, that it include all sales for a given quarter grouped by individual sales representative. Either of these requirements might change in the future. Perhaps the reports need to be emailed as PDFs. Perhaps they need to be calculated monthly instead of quarterly or rolled up by sales region. Ideally, the format of the report and the details of how it is calculated should be separate responsibilities of separate classes. Why is SRP important? Back in episode 15, Maintain Legacy Code with New Code, I explain one reason. Every time you change a class, you risk breaking classes that work with it. When a class has multiple responsibilities, it will likely need to change more often. Also, it's likely these responsibilities will be tightly coupled together by the class, making it harder to change them independently and further increasing the inherent risk of changing them. Let's say you have to fix a bug in an application. Would you rather have to work in a single class that literally only does the thing that has the bug in it, or would you prefer to work in a 2000 line long class that does 10 different things, all of which are intermixed in the class's 50 methods and properties? I know which one I prefer. Too often, developers new to SOLID will hear about SRP and misunderstand a bit what a responsibility really is. They might have a class they've carved out from the rest of the application. Something like CustomerManager. They'll happily explain how CustomerManager is only responsible for Customers in the application, and thus is following SRP. But upon reviewing the code, it's clear that CustomerManager is responsible for Customer validation, Customer persistence, and Customer formatting for various user interfaces. It's responsible for notifying Customers when they place orders and oh yeah, it also is responsible for Customers placing orders, as well as managing their orders and their payment providers and their account history. But don't worry - CustomerManager only has one responsibility: Customers! Although I said responsibilities typically map to business requirements, they don't typically map to entities like customers or orders or policies. This is because these entities will often have a lot of rich behavior that can be isolated into separate responsibilities, often with cross-cutting concerns within the application. For instance, how a customer is validated will likely be very similar to how an order is validated. The same goes for persistence and UI formatting and a host of other activities. Each of these is a responsibility, and should be isolated in its own class. Now, it might seem like breaking up big classes into small ones is going to result in a lot more code, but often just the opposite occurs. As you pull cross-cutting concerns like validation, persistence, logging, notifications, formatting, etc. into their own classes, you'll often find ways to standardize the codebase and reuse these classes. A common way to achieve this reuse is through the strategy pattern, which I discuss in episode episode 19. The Strategy pattern lets you move responsibilities out of a class by delegating to other classes, which are often defined as fields or properties on the original class. These fields or properties have their instances set by having them passed in through the constructor, in what's commonly called dependency injection. Dependency injection and the strategy design pattern go hand-in-hand, and are my favorite way to refactor to achieve SRP in classes that I find have too many responsibilities. If you'd like to learn more about SRP and SOLID, check out my newly revised course, SOLID Principles for C# Developers, on Pluralsight. It's a complete update of my original SOLID Principles of Object Oriented Design course that has been in the top 100 for Pluralsight since it was published in 2010. The new one is shorter and streamlined, though it doesn't cover some topics the original course has. The new course also uses Visual Studio 2019 and has all of its course samples on GitHub. Check both of them out and let me know what you think. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring 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.
Effective Ways to Accelerate Your Career
Episode of
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 48 on Effective Ways to Accelerate Your Career, with guest James Hickey. Effective Ways to Accelerate Your Career This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript This week's tip is brought to you by guest James Hickey. James is a software developer working remotely in eastern Canada. James helps software developers gain traction in their careers with his free email newsletter, "Navigating Your Software Development Career", which I link to in the show notes. He's also the author of an open source .NET Core library called Coravel, which provides advanced capabilities to web applications. James is going to share some tips on accelerating your career. Welcome to Weekly Dev Tips, James! Hi! I'm James Hickey. I'm a senior .NET developer and consultant based in eastern Canada. I'm also the author of an open source .NET Core library you might be familiar with called Coravel. One of the big realizations I had early on in my career was that doing a good job and doing what I was told to do would actually not lead to: Promotions, recognition, becoming really skilled at my craft, and opening up more opportunities. Many developers find themselves comfortable with having an easy and carefree job with minimal responsibilities. Other developers, like myself, have an inner drive, ambition, and passion to be the best that we can be. We recognize that having options means we can support our families better, have more money and resources to help our friends when in need, have the ability to create new businesses that solve important problems in our world, and know that we can inspire others to conquer obstacles in their own lives. Are you one of these developers? Here are some tips for you to accelerate a bit faster in your career! Find Gaps Here's my first tip. Early in my own career, there were times when I would solve a problem and developers who were more senior than I would ask, "How did you that?" One example was when I worked on a large database migration project. My colleagues were building various scripts that could take days to run. When I started building my own scripts, I started using regular expressions in SQL to fetch certain patterns in the data, manipulate it and then store the results. My solutions were taking mere hours to run! I became known as the guy who could migrate these large data sets very well. The senior developers would start coming to me for advice whenever they needed help in this area. Have you ever solved a problem and then been asked questions like these? "How did you do that?" "What did you do there?" "Why did you do that?" This probably indicates that you've found a knowledge or skills gap in your team. You should jump all over that topic and become the "go to" person. You might think that being known as the "regular expression guy" is not that useful. But that's not what people will think. In reality, you will be viewed as someone who can think outside the box. You will be viewed as someone who can solve tough problems. So, when promotion time comes along, guess who will be already on the minds of the decision makers? Connecting With Past Co-workers Here's tip number 2. If you've been in the field for a few years and have worked for a few different companies, then this next tip is for you. One thing I started doing is contacting past co-workers and managers on LinkedIn. First, I will ask them how they are doing. Next, I'll let them know - in a couple sentences - what I've been up to recently. And finally, I'll let them know that I am available to chat with them and help them with anything they need. This is a short and concise way to connect with them on a personal level and let them know that you are just there to help them in any way. Don't expect to be told immediately that your past co-workers have something they need help with. (Although that has happened to me, and I've landed some big opportunities this way.) The main point is to merely put it in the minds of these people that you are available. When they move on to another company and are looking to hire software developers, guess who's going to come to mind first? If you have a history of doing good work and being friendly and helpful to your co-workers, then you will be surprised where this simple tactic can lead! Teaching Have you noticed that the vast majority of the tech leaders you follow have either done public speaking, written books or recorded video tutorials? My final tip will really accelerate your career: teach other developers in public. Start speaking and presenting at user groups, meetups or even conferences. Start writing technical blog articles that address very specific issues developers are facing in their day-to-day work. You could even write a book which can skyrocket your credibility. Or, you could begin recording video tutorials that help developers learn to build software better, use their tools more effectively, and so forth. At the end of the day, simply helping people by teaching them to be better than they were yesterday will always win. Thanks! I hope you found these tips practical and useful! Thanks for letting me steal your thunder for a few minutes, Steve! No problem, Jmaes. Thanks for the great tips. Listeners, I hope you'll sign up for James' newsletter to get more career-oriented tips from James in your inbox. Show Resources and Links devBetter Find James Online 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.
Introducing SOLID Principles
Episode of
Weekly Dev Tips
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 47, in which we'll introduce the SOLID principles. I'll spend a little time reviewing these principles in the upcoming episodes. What are the SOLID principles of object-oriented design? Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript Depending on how long you've been programming, you may have heard of the SOLID principles. These are a set of 5 principles that have been around for several decades, and about 15 years ago someone - I think it was Michael Feathers - had the idea to arrange them in such a way that they formed the macronym SOLID. Prior to that, I think the first time they were all published together was in Robert C. Martin's 2003 book, Agile Software Development: Principles, Patterns, and Practices in which their sequence spelled SOLDI - so close! This same sequence was used in the 2006 book Agile Principles, Patterns, and Practices in C#. So what are the SOLID principles? As I mentioned, SOLID is a macronym, meaning it is an acronym formed by other acronyms. In this case, these are SRP, OCP, LSP, ISP, and DIP. All those Ps at the end of each acronym stand for principle, of course. Listing each principle, we have: Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion You may already be familiar with these principles. If you're a developer who's using a strongly typed language like C# or Java, you should be extremely familiar with them. If you're not, I recommend digging into them more deeply. Applying them can make a massive difference in the quality of code you write. How do I define quality? Well, that's probably a topic I could devote an episode to, but the short version is that quality code is code that is easy to understand and easy to change to suit new requirements. It's easily and quickly tested by automated tests, which reduces the need for expensive manual testing. And it's loosely coupled to infrastructure concerns like databases or files. How do these principles help you to write quality code? They provide guidance. You need to write code that solves a problem, first and foremost. But once you have code that does that, before you call it done and check it in, you should evaluate its design and see if it makes sense to spend a few moments cleaning anything up. Back in Episode 6 - you are listening to these in sequential, not reverse, order, right? - I talked about Kent Beck's approach of Make It Work, Make It Right, Make It Fast. SOLID principles should generally be applied during the Make It Right step. Don't apply them up front, but as I discussed in Episode 10, follow Pain Driven Development. If you try to apply every principle to every part of your codebase from the start, you'll end up with extremely abstract code that could do anything but actually does nothing. Don't do that. Instead, build the code you need to solve the problem at hand, and then evaluate whether that code has any major code smells like I discussed in episode 30. One huge code smell is code that is hard to unit test, meaning it's hard to write an automated test that can just test your code, without any external infrastructure or dependencies like databases, files, or web servers. Code that is easy to unit test is generally easy to change, and code that has tests is also easier to refactor because when you're done you'll have some degree of confidence that you haven't broken anything. In upcoming episodes, I'll drill into each principle a bit more. I've published two courses on SOLID at Pluralsight where you can obviously learn a lot more and see real code as opposed to just hearing me through a podcast. The first one was published in 2010 and so the tools and look were a bit dated. The more recent one is slimmed down and uses the latest version of Visual Studio and .NET Core. There are links to both courses in the show notes - the original one also covers the Don't Repeat Yourself principle. Let me wrap this episode up with a very brief overview of each principle. The Single Responsibility Principle is generally applied to classes and suggests that classes should have only one responsibility, which can also be thought of as one reason to change. Responsibilities include things like business logic, ui logic, data access, and more. Following this principle, you'll tend to have smaller, more focused classes. The Open/Closed Principle suggests that you should be able to change the behavior of your system without changing its source code. This generally relies on some kind of parameter or plug-in capability to provide new behavior to an existing class or service. The Liskov Substitution Principle cautions against creating inheritance hierarchies in which child types are not 100% substitutable for their base types. When violated, this can result in messy code and bugs. The Interface Segregation Principle suggests that classes that use interfaces should use all or most of the interface's exposed members. This then leads to interfaces that are small, focused, and cohesive, much like SRP. Finally, the Dependency Inversion Principle recommends that low-level concerns depend on high level concerns, not the other way around. This means for example that business layer code shouldn't directly depend on data access code, but rather an abstraction should exist that the business code works with and that the data access code implements. At runtime, the data access code will be provided as an implementation of the interface the business code is written to work with, providing loose coupling and more testable code. Show Resources and Links devBetter SOLID Principles for C# on Pluralsight Refactoring Fundamentals on Pluralsight SOLID Principles of Object Oriented Design on Pluralsight (published in 2010) Agile Software Development: Principles, Patterns, and Practices on Amazon Agile Principles, Patterns, and Practices in C# on Amazon See Visualizations and Subscribe to WeeklyDevTips in YouTube Clean Code on Amazon 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
52
Podcast Count
2
Total Airtime
6 hours, 50 seconds