Weekly Dev Tips

Maintain Legacy Code with New CodeMany developers work in legacy codebases, which are notoriously difficult to test and maintain in many cases. One way you can address these issues is by trying to maximize the use of new, better designed constructs in the code you add to the system.Sponsor - DevIQThanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos.Show Notes / TranscriptLegacy code can be difficult to work with. Michael Feathers defines legacy code in his book, Working Effectively with Legacy Code, as "code without tests", and frequently it's true that legacy codebases are difficult to test. They're often tightly coupled, overly complex, and weren't written with modern understanding of good design principles in mind. Whether you're working with a legacy codebase you've inherited, or one you wrote yourself over some period of time, you probably have experienced the pain that can be involved with trying to change a large, complex system that suffers from a fa

Smarter Enumerations Enumerations are a very primitive type that are frequently overused. In many scenarios, actual objects are a better choice. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Enums are an extremely common construct in applications. They provide a simple way to give labels to numeric values. They're especially useful for efficiently capturing a set of flag values by using binary AND and OR operations on values set to powers of 2. However, as primitive value types, they don't have the capability to add behavior to the values they represent, and this often results in a particular flavor of the primitive obsession code smell that I discussed in episode 12. One of the first signs that you're stretching the limits of an enum in C# is if you find that you want to display the names associated with the values to the user, and some of the names should have spaces in them when displayed. For example, you m

Be Thankful and Show Gratitude It's highly unlikely that you're a software developer who works in a vacuum. Here are a few tips for showing your gratitude to the people, companies, products, and tools that help you to be successful. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Last year around Thanksgiving I published an article about showing gratitude as a software developer. I'll link to it in the show notes and I encourage you to read it if you find this topic interesting. The topic of showing gratitude and being thankful, specifically as software developers, remains relevant today, so I thought it worth revisiting. Since you're listening to this podcast, I'm going to go out on a limb and assume you're a software developer. A programmer. A coder. Maybe that's not your title, and maybe it's not even your main responsibility, but you've built software. In building that software, regardless of your platform or

Primitive Obsession Primitive Obsession describes code in which the design relies too heavily on primitive types, rather than solution-specific abstractions. It often results in more verbose code with more duplication of logic, since logic cannot be embedded with the primitive types used. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Primitives refer to built-in types, like bool, int, string, etc. The primitive obsession code smell refers to overuse of primitive types to represent concepts that aren't a perfect fit, because the primitive supports values that don't make sense for the element they're representing. For example, it's not unusual to use a string to represent a ZIP Code value or a Social Security Number. Many systems will use an int to represent a value that cannot be negative, such as the number of items in a shopping basket. In such a case, if the system even bothers to enforce the invariant statin

Encapsulating Collection Properties Encapsulation is a key aspect of object-oriented programming and software engineering. Unfortunately, many systems fail to properly encapsulate collection properties, resulting in reduced quality. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Encapsulation essentially means hiding the inner workings of something and exposing a limited public interface. It helps promote more modular code that is more reliable, since verifying the public interface's behavior provides a high degree of confidence that the object will interact properly with collaborators in a system. One area in which encapsulation often isn't properly followed is with collection properties. Collection Properties Any time you have an object that has a collection of related or child objects, you may find this represented as a collection property. If you're using .NET and Entity Framework, this property is often ref

Pain Driven Development Pain Driven Development, or PDD, is the practice of writing software in such a way that you only "fix" problems when they are causing pain, rather than trying to preempt every possible issue. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Many of you have probably heard of various "DD" approaches to writing software. There's TDD, or Test Driven Development. There's BDD, for Behavior Driven Development. In this tip, I want to introduce you to another one, PDD: Pain Driven Development. Pain Driven Development Software development is full of principles, patterns, and best practices. It can be tempting, especially when you've recently learned about a new way of doing things, to want to apply it widely to maximize its benefits. Some time ago, when XML was a new thing, for instance, Microsoft went all-in with it. They decided to "XML ALL THE THINGS" and in some pla

Data Transfer Object Tips (Part 2) One classification of objects in many applications is the Data Transfer Object, or DTO. Here are some more tips that may help you avoid problems when using these objects. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Last week we talked about the definition of a DTO and how they're typically used. This week we'll cover a few more common problems with them and offer some Dos and Don'ts. Mapping and Factories It's fairly common to need to map to a DTO and another type, such as an entity. If you're doing this in several places, it's a good idea to consolidate the mapping code in one place. A static factory method on the DTO is a common approach to this. Note that this isn't adding behavior to the DTO, but rather is just a static helper method that we're putting on the DTO type for organizational purposes. I usually name such methods with a From prefix, such as FromCustomer(Custom

Data Transfer Object Tips (Part 1) One classification of objects in many applications is the Data Transfer Object, or DTO. Here are some tips that may help you avoid problems when using these objects. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Data Transfer Objects, or DTOs, are, as the name suggests, objects whose main purpose is to transfer data. In Object Oriented Programming, we typically think about objects as encapsulating together state, or data, and behavior. DTOs have the distinction of being all about the data side of things, without the behavior. Why do we need DTOs? DTOs are used as messages. They transfer information from one part of an application to another. Depending on where and how they transfer information, they might have different names. Often, they're simply referred to as DTOs. In some cases, you may see them characterized as View Models, API Models, or Binding Models. Not all view mod

Prefer Custom Exceptions Low level built-in exception types offer little context and are much harder to diagnose than custom exceptions that can use the language of the model or application. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Given the choice, avoid throwing basic exception types like Exception, ApplicationException, and SystemException from your application code. Instead, create your own exception types that inherit from System.Exception. You can also catch common but difficult-to-diagnose exceptions like NullReferenceException and wrap them in your own application-specific exceptions. You should think about your application exceptions as being part of your domain model. They represent known bad states that your system can find itself in or having to deal with. You should be able to use your ubiquitous language to discuss these exceptions and their sources within the system with your non-technical d

Make It (Work|Right|Fast) Don't fall into the premature optimization trap. Follow this sequence when developing new features. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript There's a three step process that I first heard of from Kent Beck. Following these steps when implementing a new feature can help you remain focused on getting the work done, and can avoid falling into the trap of premature optimization. The First Step: Make it work The first step is to make it work. Since we're talking about software, there is no cost of materials. You can make the code do what it's supposed to do in whatever ugly, messy manner you want, so long as it works. Don't waste time worrying about whether your approach is ideal, your code elegant, or your design patterns perfect. If you can see multiple ways to do something, and you're not sure which is best, pick one and go with it. You can leave a TODO comment or make a note in yo

New is Glue Be wary of the new keyword in your code, and recognize the decision you're making by using it. Show Notes / Transcript This week we're going to talk about the phrase, "New is Glue". I came up with this phrase a few years ago and wrote a blog post about it, and have incorporated it into a number of my conference presentations and training courses on Pluralsight and DevIQ. The goal of the phrase is to stick in developers' heads so that when they are writing or reviewing code that directly instantiates an object, they understand that this is tightly coupling their code to that particular object implementation. Let's step back for a moment and talk about coupling, and then return to why tight coupling and the new keyword can be problematic. Coupling Your software is going to be coupled to a variety of things in order to function. Software that has no coupling is too abstract to actually do anything. Some things, like your choice of framework or language, are likely tight coupling decisions y

Your methods should fail fast, if doing so can short-circuit their execution. Guard clauses are a programming technique that enables this behavior, resulting in smaller, simpler functions. Show Notes / Transcript Complexity in our code makes it harder for us and others to understand what the code is doing. The smallest unit of our code tends to be the function or method. You should be able to look at a given function and quickly determine what it's doing. This tends to be much easier if the function is small, well-named, and focused. One factor that's constantly working against you as you try to keep your functions manageable is conditional complexity (a code smell) - if and switch statements. When not properly managed, these two constructs can quickly cause functions to shift from simple and easily understood to long, obtuse, and scary. One way you can cut down on some of the complexity is through the use of guard clauses. A guard clause is simply a check that immediately exits the function, either with a re

Listen (and learn) Faster If you can do it without getting left behind, listen or watch educational content at a higher speed. Show Notes / Transcript I've always been interested in speed reading. As a child, it seemed like a super-power, since it would dramatically increase how quickly I could consume information, giving me more time to do other things. On a related note, I often have wished for a nice substitute for sleep that didn't have nasty side effects. But I digress... Listening faster If you're listening to this episode on a phone or mobile device, the app you're using most likely has an option to change the speed. I try to record these at a fairly measured pace, even if I'm otherwise animated or excited by the topic, because I want to make sure they're understandable even to those of you for whom English is not your first language. However, for those of you who can manage it, I encourage you to listen faster by adjusting the play speed to 1.25 or 1.5x, or even faster if you can manage it. If you're

Check In Often As a developer, you should be using source control. You should probably be using distributed source control. And you should check in, probably more often than you think. Show Notes No matter what specific tool you use for source control, you should be checking in your code to a source control repository. Right now, do you have code that you're working on (or were recently working on) that isn't checked in? How long ago did you check it out? If it's been more than a few hours, that's probably too long to go without checking in your work. Why should you commit often? The more often you commit your code to a central repository, the sooner you'll discover integration issues. This works best if you're using continuous integration, which we'll talk about later, but even without it, someone else on your team may discover an issue with your code sooner if it's checked in somewhere they can get to it sooner. Committing is like ctrl-S. If you grew up using word processors like Word, you've probably devel

##Episode 1: Overview of Weekly Dev Tips What is this podcast about, who is it for, and how can you participate in it? If you have questions or comments, join my mailing list and reply to the email you receive.