In this first episode we look at how we got into this mess in the first place: We start by exploring common pitfalls and patterns that lead to failure in Web projects. Next, we go back through a brief history of quality on the Web since its inception, analyzing the forces that set the stage for poor code quality in front-end code. Once we've looked at the historical forces, we move on to cultural forces. We talk about the division between front-end and back-end developers and how these rifts reinforce cultures where quality is not valued. Finally, we will look at Client-Server architecture and how its role in the Web has shifted over the last 50 years. These changes have introduced architectural challenges to Web developers and make it more difficult to maintain best practices.
In the first part of "Clean Code in the Browser" Episode 2, we start talking about the "S" in the SOLID Principles: the Single Responsibility Principle. First, we discuss the meaning of software "best" practices. Everyone knows those are the practices that we're all supposed to be using, but is that always the truth? We dive into the Single Responsibility Principle, identifying what it means, why it matters, and how we can apply it specifically to JavaScript. Picking up from some code we started in Episode 1, we use SRP as our guide for refactoring code structure and finding the right place for each piece of logic to live. Finally, we explore how Command Query Separation can be a complimentary technique to SRP for reducing the scope and role of individual methods and functions. We work our way through another code example, finding opportunities to use both SRP and Command Query Separation to avoid code churn and cohesion. This episode had so much content that we had to split it int
The Single Responsibility Principle
It's 4:55 pm on a Friday afternoon. You're packing up your things to head out for the weekend when suddenly the phone rings. It's the boss. Don't worry, they only need "one little change"...shouldn't be too bad, right? Join Chris Powers in this fun episode as he desperately tries to get home on time while discovering the benefits (and challenges) of using the "O" in SOLID: the Open Closed Principle. This episode specifically hones in on applying the technique to browser code in JavaScript. Through a series of poor implementations and subsequent refactorings, we learn how the Open Closed Principle helps reduce code churn and improve maintainability by making it open to extension but closed to modification. Along the way, Chris explores the topic of production incidents and how leading practices should (and should not) be used while systems are "on fire". He also discusses the importance of team collaboration, the hidden danger of Lone Wolves, and the critical nature of building shared
It's all fun and games until an angry enterprise customer calls demanding new features and expecting them now! Hopefully, a dollop of React UI code and a dash of SOLID principles will get the job done before the weekend arrives. In another entertaining and informative video, Chris Powers discovers the importance and implications of the "L" in SOLID: the Liskov Substitution Principle. This principle tends to be the most overlooked and misunderstood of the SOLID principles, and it's not immediately clear how it applies to JavaScript. Yet, after some digging, Chris discovers that LSP may just be more meaningful to developers using dynamic languages than to developers using static types! Along the way, Chris dives into the topic of identifying and managing complexity within our software development process. He uses the Cynefin framework to distinguish between "complicated" and "complex" problem domains—turns out they have dramatically different paths to success! He draws on inspiration f
Our "Paintastic 2000" software is selling like hotcakes, but now the bosses are asking for more features than ever. Our code is bloating—fast! We need new strategies to keep our code slim, decoupled, and legible as the app outgrows its original abstractions. This time, Chris Powers calls upon the value of the "I" in SOLID: the Interface Segregation Principle. At first blush this principle might not seem to offer much value in JavaScript. After all, how can a language without interfaces possibly benefit from the Interface Segregation Principle?! Thankfully Chris is able to demonstrate to us how this principle genuinely applies to JavaScript, both in metaphor and in live coding. Along the way, Chris explores the misleadings of multitasking, the focus of flow state, and the gravity of Gantt charts. Software development teams can make huge gains not just by changing the quality of their code, but also by improving the quality of their time. Chris discusses the intrinsic motivators that p
The time has finally come—an investor is considering buying out the Paintastic 2000! This is the bosses' big chance to strike it rich, but there's one problem: the JavaScript client isn't extensible enough to work with the investor's service layer! Can they refactor and cash in, or will they become yet another failed startup? In this episode, Chris Powers demonstrates the "D" in SOLID: the Dependency Inversion Principle. Dependency structures can be difficult to visualize in dynamic languages like JavaScript, but they are still there, quietly constraining how your code can be executed and tested. By clearly delineating between high-level policy and low-level implementation details, Chris uses this principle to decouple otherwise twisted code. But of course, that's not all! Chris and his merry band of minions are up to the usual hijinks. They explore the topic of effective documentation, discussing how to get the most value out of the least effort. Chris also explores team and organiz