 Right so go ahead and get started here. So my name is Micah Wood and I've been doing wordpress development for Over 15 years and along the way learned some things about software architecture and Wanted to kind of share I think software architecture there's a lot to it there's a lot of aspects there's way more that we could possibly cover in an hour, but I wanted to kind of introduce some of the basic concepts and The things I found helpful in working with WordPress so That is where we will start We do have the chat if anybody has questions as we go I do have the chat open on another screen and do look at the questions So I'll try to keep up with that as we go and we'll make it as interactive as we can so Hopefully This will be helpful so First before we get too much into the architecture We kind of want to take a step back and just look at the software development lifecycle, right? So what is what does it look like? What is it that we're trying to To pay attention to So I think most people the average person Developer I should say who is building something typically only does the things that are on the top half of the gray bar They figure out what the requirements are they go ahead and build it based off what's in their head and Then they do whatever maintenance is required to keep it running that the client or Improvements that the client may ask for There's a few things that kind of get overlooked a lot of times Number one is how should we build it, right? Like have we really considered all the options? Is this really the best way of doing it? And then the quality assurance, right? Like, you know, did we build it the right way? Did we test it all the ways that we should have tested it? And so I think a lot of times As we build things We're more likely to start doing the quality assurance before we start doing the design I mean, we do think about the design, right? Like we have a concept in our head of what that is But we don't necessarily commit as much time to that as we probably should and I think as long as we can kind of understand some of the design patterns and some of the Principles behind the architecture it gets easier and easier to kind of reason about well, this is probably a better way of building software So On that note We're gonna kind of look at it also from the client's perspective, right? So what is it that the client cares about? Ultimately it kind of comes down to three different things. So number one, you know, what is what is it gonna cost me, right? The client wants to know is this going to be a super expensive endeavor? Is it a cheap thing? And then the other thing they want to know is, you know, how long is this going to take? Then essentially how effective is the solution going to be and by effectiveness? There's some nuances there For the most part effectiveness means it serves the purpose or the goal that the client has in mind So basically the software does what it's supposed to do But at the same time effectiveness is the software will last As long as the client needs it to last to serve their purposes, right? So that means maintainability. So that's an important thing to keep in mind But essentially it all kind of boils down to these three things When we're looking at a project The Difficulty of making changes to a project the further It goes on In the delivery process Can make things very difficult to implement. So in other words, if we have a design and the client says hey We want to we want to change The way this layout is or we want to make this button do something different That's pretty easy to do in the design stage, right? Like you just you know move the button or do whatever it is you need to do there and Visually it changes, but obviously we haven't built anything yet. So it's it's easy to do once you get into the implementation You know changes are going to be a little bit more costly It's possible that as you are still in the implementation phase you might not have completely built out the thing that needed to change and So there's that But suppose, you know, maybe you've already built Some of that at least at this point. It's not in production. So making changes doesn't mean breaking things for people who are potentially using it But then you know once you've delivered a solution and and things need to change reworking those things is Guaranteed to take a lot more time and effort and money to to get it done But if we have good architecture And we built software in a better way, I guess we could say Then it will be easier Then it might normally be to make changes After we get into the more implementation and delivery stages. And so really architecture is about Probably more so the maintain ability of a project Than anything obviously it needs to serve its purpose But usually when we're taking all the math into effect, it's really the long-term Sustainability of the project That is what the architecture drives So let's take a quick look at what makes the project effective, right? So it's going to solve the problem And it's going to be easy to maintain, right? So Like I said, the the ladder is more likely to be What you need software architecture for So we've got a formula for you and then you can put real dollar signs to this But this we're basically introducing some principles things ways of thinking about things to put real numbers that you can use with clients And figure out, you know, is this worth doing? Do we need to change it? and so on so So you can have let's say two ways of building a particular project, right? And you can look at it and say, okay Well, the D here represents the desirability of a change, right? So whatever the the score is here the better the score is You know, the more likely it is we'll go that route as opposed to another route So we want to take the value of that Change now if we made the change now, you know, what is the Business value that it brings to the table And of course we can use dollars What is the future value That this change will bring to the table because there could be diminishing returns or it could be, you know, effectively Incremental or whatever But then we divide that by the effort of the implementation plus the effort of maintenance And so that's where we kind of balance out our costs So we can kind of figure out, you know, is is this change worth doing or is one solution or one type of change going to be better for us to make or essentially it could even be more costly so Basic formula, but a good formula to To keep in mind, especially if you're you're trying to weigh a few different options and figure out what makes the most sense So one thing to keep in mind too with software architecture is Technical debt and essentially we all know credit cards. They they have, you know, the big Interest rates and things that can us often cause issues Naturally, likewise if you have a project where you have not paid too much attention to the architecture Things have gotten a little messy Over time as the client asks for more changes That technical debt is going to be the thing that will bankrupt your project and we'll see A little bit more about this in a bit, but essentially Technical debt is literally One of the main things that kills projects, especially like let's say an enterprise, right? We get enough people working on something and not thinking about how they're doing it Next thing you know, the business can't Continue to fund the project because It's taking an absurd amount of time and development power to keep the project going So the first, uh, law here that we're going to talk about is the law of change and that basically just says that the longer that your project or software exists It's the more likely that any part of it is going to have to change So Obviously you could have a short lived thing that dies off quickly. Um, and that's probably not very useful to anyone Hence why it would die off quickly But the longer the program exists it means it's meeting the goals of the client and the client is going to Over time have different needs and different requirements that they need from the software. So obviously that's going to result in changes. So That's just a fact of any project is assuming it's Worth its salt to the client it will change in the future and the longer it's around the more likely it is to happen Um Likewise, we have something called the law of defect probability. So this is basically where the Chances of introducing a defect is proportional to the size of the changes you make So if I make a one line change in code It's likely not going to cause Too many defects, right? Uh, but if I make a I don't know change to say 157 files The chances of me introducing a defect to the software is very very high So anytime you make a change And you're thinking about, you know, how should we go about making changes as we continue to build and maintain a project? Keep this in mind because this is actually It's really easy to fall into the trap of oh, let's just refactor it Um, and then the reality is you end up with just a lot of things broken Whereas you might be able to say well, we could change A few lines of code and make that actually work the way it's supposed to without Introducing more defects. So uh, there's just kind of a thing to keep in the back of your mind And a nice tool when you're kind of weighing different options To make sure that you're not Introducing more technical debt accidentally Uh, and along those lines, we have the law of simplicity, which is basically saying that It's a lot easier to maintain things that aren't complicated right, so and and simplicity, uh, you know, there can be Areas of code that are simple and air of code that are complex and it's obviously going to be more A lot easier to maintain those that are um Simple and clear to anybody who looks at them And we'll take a little bit of a look at how we can how we can simplify some of these things, but But yeah, again as we go through if you have questions or specific things that Come out of these let us let us know in the chat This one is one that is actually a little bit newer to me. I hadn't heard of it before But I like the the concept of it as locality of behavior. So it's basically saying that When you look at any piece of code, it should be obvious What the behavior of that code is just by looking at it, so if you think about A project where you've got Maybe like some html And it's got some data attributes and then you've got some javascript and it's got some interactivity with those data attributes But they live in very different files. It's not at all going to be obvious from looking at the markup That there's this functionality that goes with it. And if there's this functionality and you're looking at it It may not be clear where Or how That actually interacts with the the market uh, so Locality of behavior basically says if you can kind of pull those two pieces together And so you think of something like alpine j s or You know where you have html and it's kind of clear like What the actions are they're happening if you trigger something That's locality behavior And so having things closer together so that it's a little more obvious what's going on Is something that is going to be huge when you're trying to maintain a project, especially as developers switch out so That's a good Principle to keep in mind and anytime it's possible. Follow it. I try to do that But yeah, so like we said talking about designing systems, you know, what is How do we keep those things simple And obviously one of those things is keeping everything easy to understand Uh, so a lot of times what that means keeping it easy to understand is, um Breaking it down into small pieces, you know using real words instead of abbreviations um, you know making sure that you've um It could be modularizing code creating packages things like that To to kind of break things down in a way that Makes sense So you also want to make sure that it things are easy to modify And so by easy to modify you want to make sure that you don't have so many Things depending on other things which are also depending on things related to those things And then you end up with this big spaghetti mess of dependencies kind of Separating that and making sure that you have um an obvious Direction direction of control going through the the software And by that I mean, uh, you know if you have Two different components each dependent on each other directly It's going to be hard to modify one without modifying the other Um, so you want to be able to make a change without having to be forced to make changes in places In more places right because the more code that we change the more likely we break things And so the more we have duplication or we have These interdependencies it's going to be a lot harder to modify and we're more likely to cause bugs And likewise we want to make things easy to test and a lot of times kind of this Splitting things out is going to help us with the testing as well So ultimately we want to make sure that we have self-documenting code And so what that means is making sure that we Write code in a way that Um, ideally comments aren't necessary Now that's not to say that comments are never necessary or that we you know, we shouldn't be writing comments I think it's definitely helpful, but a lot of times comments in code lie because code changes People forget to change the comment and now your comments are lying to you about what is actually happening So it's better to have the code Clean and simple and um broken down in such a way that it's easy to mentally see What's going on in the code and have the code document itself essentially Um, you know, it's it's I think it's better to have comments that are generic innocence that they Describe the overall purpose of a bit of code And maybe you know, you might obviously need some comments if there's something really weird going on that's no There's no easy way to make it clear Um, but otherwise as much as possible, you know making sure that your variables Are named Something that makes sense even if those names are longer Um Then some three letter abbreviation Um And then make sure that you know, you break things down into functions and those functions have specific purposes and We're not throwing a lot of Extra things in a function that would cause side effects or things like that. Um so By keeping things as simple as we can and having the code self document It actually helps prevent bugs from the get go Um And then the other thing we want to do is make sure that we limit our cognitive load right because part of the problem when it comes to Working with code is well for one we have to we have to read the code to understand what it's doing um and The more code that you read The more things you have to remember in your head, right? So you're creating that cognitive load When you have a lot of code that you have to keep in your head to be able to make a proper change So if you have small bits and pieces that make Sense as a unit and then I can say well within these five lines of code I can reason with about what's happening here and I can make a change Then that will allow me to limit the kind of cognitive load and I can use my brain power for Making the change instead of trying to remember how it all still works You know take uh as another example you know 600 lines of code that have changed that you have to keep in your head And understand before you can actually Make a change without potentially really screwing stuff up It's going to take you a lot longer to make that change because you have to keep so much information in your head And this applies for code reviews as well, right? They've shown that if a code review is more than 200 lines of code Then the person who's doing the review Uh, essentially their eyes gloss over at some point and they completely just Don't look at the rest of the code So if you want if you want people to properly review code You also have to limit the cognitive load and keep those pull requests and things small in order to To prevent those kinds of issues Uh So then we have uh the dry principle. I think a lot of people have heard this. This is probably one of the more commonly echoed architectural concepts And of course of course don't repeat yourself everyone says basically, well, you know, we shouldn't we shouldn't create a copy of Any of this code over here because then we have duplication and we have to change things in multiple places and it becomes a problem and um So I wanted to kind of dig in a little bit to the dry principle because I think it's relatively misunderstood a lot of times What exactly it means and what it doesn't mean? Uh, and I think that it gets a little bit overused and improperly used So I want to kind of talk a little bit about this so Repetition is the mother of learning Says the latin proverb, right? Which would obviously go against something like the uh dry principle If you're completely, you know duplicating things everywhere you turn But uh every programmer ever, you know, don't repeat yourself So so what does it really mean to use the dry principle? Don't repeat yourself And I think there's a myth that goes around that basically says if I was a good coder All my code would be dry and there wouldn't be any reason for all this repetition Or duplication essentially in the code um And while that there is some truth to that like I said, there's also some things that are not entirely true So the dry principle originates from a book called the pragmatic programmer and it basically states In a very different different manner Every piece of knowledge must have a single unambiguous authoritative representation within a system And so we're going to break that down just a little bit So On the left We're looking at duplication of knowledge is a violation So from the definition that we just read duplication of knowledge, right? So this would be like information data Things like that you don't want to have for example a checkout system Where you have to keep up with prices For products in two different places because the likelihood of you remembering to change the price in all the places You know is low And that duplication would cause serious Issues when a customer goes to buy a product And then when they end up on the cart, it's a different price or something like that, right? So if there's competing data, uh, it's definitely not a good thing Um, but duplication of code is technically not a violation right, um and so As long as the data has a single source of truth duplication of code technically doesn't violate the drive principle the um Yeah, and uh I had a comment here in the chat that says the rules engine is really helpful to coordinate those business and system rules in one place and avoid duplicates Um Yeah, so we're talking. Yeah, exactly. We're talking data. We're talking business logic algorithms All of these are things that we don't want to duplicate or accidentally You know Have copies of it that are laying around somewhere else the um Code Includes variables code structures and function calls, right? So these are things that can be duplicated um reusing variables You know, you might have uh functions that are used a lot um, you probably shouldn't have like Two functions to do the same thing because that would be more like Uh, potentially could be business logic, I suppose but um, but yeah, like code structures for example, like let's say we have um a class that handles functionality um For the admin in WordPress and then we have a code or that needs to be accessible on the front end and it feels like the same thing So we just end up copying that code over or reusing that code for the front end And then what ends up happening is we start to realize oh well the front end does need to operate a little differently than the back end but we've essentially You know Are using the same code we didn't actually duplicate it if we had duplicated it We could then change it just for the front end versus the back end um So those are kinds of things where it's fine to duplicate Especially when you know like there's a different context at play and that uh, the future maintainability of the project could depend on that actually being Just a copy that we can edit and know that it only affects certain aspects of the software so Ambit excuse me ambitious application before there is duplication Is uh, what we call premature optimization, right? so we're trying to eliminate duplication and in the example of having code that is working on the back end and then we Optimize by using the same code on the front end because It seems the same and we don't need to create duplication Um, we've essentially prematurely optimized in a way that is actually counter counterintuitive or not counterintuitive counterproductive um But the ambitious application to code structure Hold on. I worded that wrong. All right. It seems weird at the moment. Um Yeah, uh ambitious application to code structures of the drag principle results in unnecessary coupling and complexity so um by that we mean uh Again that example of let's just use this again on the front end We've essentially created coupling between the front end and the back end Even though we're using just the same code if that makes sense so Uh, so then we're going to jump over here to the single responsibility principle so there's there are a bunch of Uh principles that are considered Uh object oriented programming principles. So there's the solid principles. We're not going to cover all of them um, I feel like some of them are Especially for like a basic software architecture principles. Some of them are very confusing sometimes Uh, so we're going to kind of stick to some of the more basic things um, but the single responsibility principle basically says that um A class or a module or a particular piece of code Should have one and only one reason to change meaning that um, if I have let's say a function that is supposed to add two numbers um There's no reason for me to change that if I need to change how multiplication works, right? Uh, it should only Only only changes the way we add things should go into the function that handles the addition So that single responsibility principle is fractal meaning that you can have a module That has a single responsibility For a specific concept, right? So like you might have for example An onboarding module And so the the concept of onboarding is its single responsibility that it's Covering, right? So you wouldn't want to put something related to e-commerce directly into an onboarding module because you know Maybe that's for the e-commerce module um So we won't you know, we don't want to Have those single responsibilities leaking into other things because that's where we start to develop that architecture And we don't have the proper separation between things to make it easy to swap things out that kind of thing But the single like I said, it's fractal. So you can have a module that covers a specific thing You could also have a class that covers a specific thing. So if we're talking about onboarding you might have I don't know 10 classes or more That might all have their own specific responsibility For I don't know handling dependency injection or handling all these things that you know handle data for Module or you know, there's a lot of things that would go into a module that in general covers a specific thing um And of course in a class you'll have Methods so functions that would have specific responsibilities So that kind of trickles down all the way And so you want to make sure you break things up in a way that makes sense So that every bit of code The smallest bit to the broader general concepts Follow the single responsibility principle Uh, the other principle, uh is the open close principle and this is one that WordPress is a shining example, uh in a very easy example to explain But basically the whole idea of the open close principle is that software should be open for extension but closed for modification so meaning that Using wordpress and writing code for wordpress I shouldn't be modifying wordpress core, right? doing that means that Well, number one if The wordpress core gets updated all my stuff goes out the window, right all my changes to wordpress core And then of course it means that the the software operates differently and potentially in a buggy way And hasn't been tested by millions of people right and hardened by dozens Well, probably hundreds of developers so No one should be able to modify wordpress core except the people who work on wordpress core But we do want people to be able to write software and extend wordpress Which of course people can do by writing plugins As well as themes plugins being obviously the probably better example so Wordpress gives us a way to extend WordPress by writing plugins without actually modifying wordpress itself It doesn't give us that control so it does a good job of following the open close principle and likewise As you write plugins for wordpress Your plugins should be extendable But your plugin should be modified by somebody who's not the owner of that thing, right? so wordpress gives us hooks and You know actions and filters and all those things so that we basically can use those to Naturally follow the open close principle in any software that we write for wordpress Um, and of course, there's other ways of following the open close principle But I think that's a a really good example. This should be relatively easy to to grasp for anybody working with WordPress So I want to talk a little bit about modularity so In general when we write software, especially as we continue to Build things and build things we start to realize that there's patterns right like things that we do a lot Over and over again code that we have a tendency to copy and paste And so it would make sense that we might try to modularize that and to kind of create its own package essentially that would allow us to reuse that code and maintain that code Kind of on its own, right so with modularity We want to make sure that we have clear boundaries between the modules, right? So again, we're talking a module should have like a single responsibility And as part of that single responsibility, it should by nature Have clear boundaries as to what it does what it doesn't do And so right so we would know how it's going to be used how it's going to be interacted with um And so the other thing we want to do is make sure that a modular a module I should say is Decouple So we want to make sure that a module shouldn't have direct dependencies on each other meaning Well, there's two there's really we say decoupled a lot of times we end up with a couple different scenarios, right? We have tightly coupled things we have loosely coupled things um And by loosely coupled a lot of times that's what we mean when we say decoupled uh, so for example If I've written code in module a That directly calls functions in module b Then I've created what's called tight coupling, right? I have Internal classes and functions and things that I don't realize are being used by some other thing And then when I need to change this it will break Module a if I change module b, right? um, and so it's tightly coupled so things in both modules have to change at the same time in order for um, a change to be successfully made And that's what we call tight coupling loose coupling is when you have the ability to make a change in same module a And module b is dependent on module b but there's a public api a um an interface That can be relied on Not to change So everything underlying in one module can change um, as long as that interactive functionality doesn't change Then no other module needs to change, right? So a good example of this is a module that does logging, right? So you you might want to log errors to um an error log You might want to log errors to a third party service that handles Monitoring errors you might want to log errors to I don't know Some random service that puts them up on screen Somewhere it can be anything, right? So being able to to have the idea of I can call These functions and methods to log something, but I don't have to know anything about How it's being logged that can be switched out underneath um without affecting The code that actually would trigger the logging, right? So that's kind of what we mean when we're talking about a loose loose coupling And and again as we just saw it's easy to swap things out meaning that if We wanted to for example have uh code that interacted with service a And then all of a sudden service a is no longer a feasible service We could swap it out for service b and as long as the API that all the other modules or pieces of code are using don't change then we can make that switch without a problem Um, so then the other concept here is continuity So basically this is saying that a requested change should only impact one module in your application um And so it's Kind of in line with like the single responsibility principle like as long as you're following that usually you have continuity um but uh But yeah, so the concept there comes from mathematics works basically saying that the percentage of impact is related to the percentage of change essentially I think the other other thing we're going to look at is protection, right? Like we want to make sure that if an error happens in one module It shouldn't break another module, right? Like we don't we don't want to have that kind of Uh leakage of errors or exceptions and and those kinds of things so making sure that we have a good way to handle that So that we don't We don't pass those errors along so a lot of times when you're building out those apis that kind of allow those pieces to communicate um It may mean that you handle all of the errors and you know If something fails you might return like an empty value as opposed to Something else, but then the other modules would You know the expectation is that an empty value is an acceptable response if there is An error and then as long as that's built into the communication protocol Then the other modules can handle that without breaking um We don't want to just randomly like throw an exception and not handle it And then all of a sudden now the other things are breaking because of it Um, and then of course we're talking extensibility, right? So we want to be able to extend the module for different use cases And this could mean creating additional modules with additional functionality, but it could also just mean You know essentially the open close principle within the context of a module So I think understanding modularity is very important And that is a big part of for example Thinking about how do we what do we put in a plug-in because essentially a plug-in is a module um, and likewise A composer package that you might put in a plug-in or a theme is also a module And uh, and so those are you know Different ways we might package code up and use it in WordPress, but essentially the concepts are all there So when we're talking about kind of these packages and things like that um You know a lot of times people will like I say copy paste code But the problem with copy pasting code is that you copy it from project a to project b And then you copy it from project b to project c And then somewhere along the way you patched a bug in project a but it never made it to project b So it obviously didn't make it to project c and then project c got a bug fixed But it didn't get back to where b or a and so everything's in a different state and there's no real way to like track You know, what is the status of the code? Um, how do I know I'm using the most recent like how we're how can I release a bug fix across all my projects? um, these are all issues that you run into if you don't properly have a way to handle um packages and Essentially what we're talking about here with the reuse release principle Is that only things that are released through a tracking system? Quote unquote tracking system can be effectively reused For the most part what we normally mean when we say tracking system um At least as developers is usually version control right so if I have all my code related to some Module that I've created let's say Could be a plug-in could be something else if I have that all in I'll let's say github then I'm able to uh Track the changes You know If I do a patch I can put it in that repo Gives it one source of truth for that code Which can also be versioned So that you can include specific versions in your project And typically the way that we would do that is using tool like composer in Which is the php package slash dependency management tool Um, and that will essentially serve as our tracking system That allows us to effectively reuse code meaning that So for example one of the packages it's not a plug-in. It's just a collection of code That excuse me happens to be in the city's repository in a repository I have a um A module essentially a package that I created and its sole purpose is to allow setting of an expiration date on a post of any type any custom post type And then when that post expiration is hit it automatically trashes the post Um, and so that's all that the code does And it's super handy because it can be used to expire notifications, uh news items it could be used to expire promotions coupons. Um, you know Lots of use cases where you might need to expire something right? Um, so we have a package here that does just that But the only way that I can properly reuse it across all of my projects is to have it um In a repository with you know releases being tagged Which then composer is able to say okay, you're using version one over here and 1.2 over there and so But technically 1.5 is the latest so anytime you run a command In composer you can actually just update that and um And then you'll have the latest thing with all the bug fixes and uh, whatever and of course if there is a breaking change Then the major version would change right? So we're using semantic versioning and and handling all that appropriately So that um, you know, I can create a package and just reuse it easily. So um And that's one of the benefits too about as you become a more seasoned developer You start to actually build some of these packages that you are able to reuse and um projects get easier and easier to build because you've already Used a lot of the principles of software architecture To create these little bits and pieces of code that can be pieced together with a little bit of glue And then you're able to complete things much quicker So, uh, robert c martin who by the way if you're interested in the topic of software architecture is Someone I would highly recommend that you look into um He says that a good software architect will delay decisions as long as possible Which sounds kind of lazy But the reality is that um, a lot of times uh, we have a habit of Making decisions too far in advance. Uh, and a lot of times it's better to Uh, wait until you have very good reason to go a particular direction, right? um so I wanted to present the concepts of the clean architecture that uh, he introduces and uh, so this will kind of be we're getting towards the end here, but um, but basically Uh This diagram that we're looking at Uh, when you're building things a lot of times you want to try to think from the inside of the circle out um, so the things on the outside are the things that um A lot of times we make decisions about first Oh, well, you know, we know we needed a database and it's going to be my sequel, you know, we're going to need um You know a web tool and it's going to be wordpress well It's fine to specialize in those kinds of things and to know in advance that you're building on certain technology Um, but it's another thing to like prematurely like decide on something before you even know like How the thing needs to operate? So the idea here is that we should work from the inside of the circle out And we should start with the entities um And so when we're talking wordpress, we're thinking, okay, what are the custom post types? What are the taxonomies? What are the things that we're going to need? um that will make up like the core pieces of the You know Business logic, right? What is the what are these entities? And then from there we step out a little bit into use cases. So we say, okay, well, we have I don't know a recipe for example Like how is a recipe going to be used in the greater concept of what we're trying to build, right? And so really so you might have very specific use cases Where you you have different business rules that need to be used to change The data associated with an entity or something like that, right? And then as you kind of work your way out um, then you have the The things that interface essentially with your technology To present or uh process You know input from from users that kind of thing. So um So ultimately, yeah, you're you're you're creating code kind of working from the inside out And then what that does it allows you to um Make better decisions because you're starting with the with entities Then you're creating a business logic layer And then you're creating the More of like the hard interfaces where it's like, okay. Well, this is how this is the way we're presenting the data You know, which in wordpress, you know be like php template or something um So these all these things um If we work from the inside out it makes it a lot easier because we are delaying Decisions about some of the details that we don't really need to Worry about until we get Some of the core logic figured out so if we start with the technology And then how we build things in the technology and then we figure out all the post types Then we're working it totally backwards and especially if we You know do all that and then we still don't know what the business logic is Um, and we haven't built that in Then we'll be putting business logic in presentation layers and things like that, which is not something we want to do um so, um, there's a Few resources, uh, if you find this interesting that I think would be very helpful Um, so like I said, we've kind of just very very tip of the iceberg kind of conversation about what these basic principles are um But I would highly recommend Excuse me A number of these books, uh and things here. So we have the book code simplicity is actually presents a lot of the like, uh The laws and the formulas and stuff some of those things that were in this talk Um, so I'd highly recommend grabbing that it is actually a thin book that is very simple and short to the point um I will post the slide deck to the Meetup page and You'll be able to actually just click on the links in the slide deck to go to these resources um But yeah, the code simplicity book. It's simple. It's thin. That's it. It's not a hard read, but um, it's written by somebody who has really had Some harrowing development experiences and has come out for the better um And then uh refactoring by martin fowler is is a is a really good book. Um, there's a php design patterns book that Is really good about just walking you through like some of the basic um Well, I didn't know as I was I started out You know self-taught learning wordpress wordpress has grown And since gotten custom post types since I started using it, but um, so a lot of things have changed But uh, you know, you kind of start with doing what you can do and at some point you get to where you're like I would like to create better software, right? Uh, and the design patterns are the thing that for me was like the the thing that started to unlock a lot of that so I would recommend Picking up like the php design patterns book and going through that and figuring out Okay, what are some of the common patterns? You don't have to follow on Perfectly to a t you can tweak them and customize them um But yeah, there's some some really good design patterns out there that I think would be inspiring for anybody that's interested in writing better software Um, and then there's the clean code and clean architecture books Also that I would recommend and then of course there's a couple of links here as well that you can take a look at But like I said, we'll we'll get those posted up on the um Um page and then um, if anybody has any questions, I think we're out at time