Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
welcome to the session where I talk about obscure programming the title is sounds worse than I actually meet it but you know you guys are all here so it worked I'm marks on about my performance engineer document you you might wonder why formance engineer
is so interested in this type of stuff and comes back to the idea that you can't it's really difficult to make something more performant that no one understands and so the understandability and the simplicity of a system is very important it when you're
actually trying to make it perform an edge like things that make sense so just quick overview where we are like drupal 7 we had some classes ap eyes are pretty much procedural we all know it was not very interested and we all know it was pretty tightly coupled
and it's also very complex I think I think everybody could agree on that there's there's been better things written about the complexity of Drupal in Drupal 8 we'd up to some sympathy components we have many more classes we're actually
still not unit testable we're still tightly coupled and we're actually somehow more complex and this type of stuff sort of scares me because we have existing contributors who shouldn't be as scared of d8 as they appear to be so in general when
people talk about object-oriented I mean it's talked as a tool to to manage complexity but we somehow took that and made it more complex and that's what we're talking about here though I really like this quote from martin fowler the key to controlling
complexity is a good domain model that's not really a word we we say that often here and every time i say model somebody says this but just because you may not have the m in the sea doesn't mean you don't have the m everyone has the m right if
you if you are doing anything with objects you need a domain model a domain model doesn't it isn't a literal thing like there's there are lots of the criticisms much we're programming because it doesn't always map like to real world things
it isn't a half like an object doesn't have to map to a real world thing it has to map to some abstraction that makes sense in your domain we have nouns that we use for these things all the time those are essentially what our domain objects end up
being so they're usually nouns I won't go too much into ubiquitous language but a few seen throughout the book domain driven design I highly recommend it he goes into it much more but the basic idea is like the words we use when we're speaking
to each other and the words were used when we're in code should be or there's there's an overlap there and that's our ubiquitous language like when we talk about blocks blocks are like that's a very clear deck domain model yet when we're
in here see we talk about block entities and block plugins and no one can understand each other that's why that that's part of its really important so here's like the most obvious Drupal models right we usually think of these as entities we just
got in a patch to where all the all the main Drupal entities have interfaces now which is great but that's roles interface this suggests to me the role has no business logic but I don't think that's exactly true if you start looking around he's
first seen things like this i would say that changing permissions is well within the domain of a role that's something that maybe it should be responsible for and that's a really simple refactoring you just stick that on the role object and so like
there's that one method but then I'm implying two more with grant permissions and revoke it however needs to do that job doesn't really matter those methods should just exist on that object comments look similar now here's just a sort of a
shortened list of its properties notice the comments on a bunch of those properties the names are really ambiguous right what what is a what is male on a comment right that doesn't really make a lot of sense but the comments tell you what it is in most
cases if you look through drupal code and see a comment think about if that could be a better method name or something that described that thing better don't be afraid of using multiple words like long variable names and long bet the names are totally
fine if they say exactly what they do that's always better than a comment so the first thing i would do to refactor this is out add descriptive access or methods and so it would end up looking something like that but now there's sort of another code
smell whenever you're working with one object if another noun starts appearing at a bunch of methods that's a good indication that you probably need another object now people who understand the naaap I are probably freaking out now because they're
like you can't do this and that may be true although I don't know if I actually believe that because still these are like the internal properties to comment and comment can instantiate its values however it wants to so I don't I don't see a
reason why we couldn't say make a comment author object because this isn't exactly a user right this isn't our normal user object this is a comment author it may inherit from user and may not it doesn't seem like it has the same responsibilities
right but just having something that says a comment author is a thing that we have and the thing we refer to in this domain tells you a lot about what's going on so here's another instance of hidden business logic and procedural functions this function
prepares the author object that we are the author property words talking about before there's not really a reason that that needs to exist outside but it also suggests something else so if you look at that actually so it's saying entity create with
a UID of zero we all know the uid 0 means anonymous but that that's really just an implementation detail there's no reason we need to just code that all over the place with that assumption have all of our code know that you 0 means anonymous I don't
see why we wouldn't just have an anonymous coming author they can inherit from comment and just hard code it's uid 20 and then that code I think reads a much better so this is from the actions module this one is pretty rough and this should stay there
right so it's the actions modulus this action it's not going to go anywhere but it knows how to find the subject within the comment which would be one thing if it was just subject but it's actually subject for value which is a little strange it
also knows how to get to status and it knows this constant to compare it to now you could say there's an argument that like that's sort of okay because these were the these are within the same package of common module and I would believe you but there's
really no reason it needs to do that so when you have like when you look at the code around an object should always remember like it doesn't have to know how you like this object is going to do something it just needs to say what it wants right it just
needs to tell it to do something so this is what this code I think should look like you just call a publish method or you just call a subject method doesn't matter where that comes from the contract here is just i'm going to call subject on you and
you're going to return me a straight and then it's up to comment module to comment a class to do that and so here's another instance of like knowing those constants and in this case it's actually looking if it's published or not and when
i see that code i say ok there's a business case for having an is published muffin and then we just add that and you probably recognize the publishing is actually not unique to comments at all and when we see things like that those are basically roles
[ ... ]
Nota: se han omitido las otras 3.892 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.