 Okay It's okay. Okay, great. Okay, so I was saying I'm Rodrigo Aguilera. I work here in Barcelona. I'm from Madrid. I work at IMRA and Sometimes I contribute to Drupal multilingual Hi everyone, I'm I'm Pedro and I'm a Drupal freelance. I used to work here in Barcelona and I work in London and I've been in Drupal for a long time. So so What do we mean with with quality because that could be a very strange or very broad concept We are going to Talk in this in this session about how how can you get better communication inside your team? How can how can you get an increase on transparency in both? code and processes and that will result in a better ownership of the of the code base and How can Processes and deadlines can be can be solid and meaningful instead of being a date set by someone else and This one is a is a very very challenging one not making the same mistake twice we'll talk about that and That this is 80% that dude and 20% toolbox and we are going to show tools here but those are just for a framework or demonstration purposes and The main goal is how to get you peace of mind on your development processes But we know that this is kind of a Nirvana thing, but the closer you can get the best, right? And We split this this talking three three parts We're going to talk about pure real. We're going to talk about how to make processes that increase communications in team We're going to talk about testing very very in in a Passing it in a very overview Mode and we are going to talk a bit about deployment some things and how can you sleep at night and The first part is a code review Well the first thing that I wanted to ask you how many of you consider you do code review inside your team Okay, that's that's good so I'm here because it really changed my life as a developer and I want to talk about it And I think for those of you who don't do Who doesn't consider that that's called reviewing or peer-review inside your team. I think it will happen eventually So why I'm not going to criticize you about amongst the ones of you who does code review Everyone does code review the way they like it at the way they are comfortable with We'll be finding like Code bad code in the wild. So I think there's not enough code review being performed. So It's a process that Improves quality but reducing defects everyone. It's on the code. So express code ownership and Helps new people on board on their team because They get a new sense of the code and it's a learning experience for for everyone on the team And it helps you spending time the moment you have it because you solve the problems before then when there is a thing breaking in production then when you don't have the time and Things might break so kind of riffs is sad because nobody does code review and Well Phrases that you heard in the wild is like my code is a perfect snowflake. So We are programmers and we should be able not just coding but to communicate the changes that we made to the project and things about Things and there might be ego involved in it So we are going to show you how to get the ego out of the problem and Well, if you say I'm too busy to do code review Maybe you need to convince yourself first about code quality like how it's important how it's important to have code standards and Some say the code review is those processes but as I was telling you fix in a bag during production is much more Expensive that doing it during the code review process and if you're worried about the idea There is a bunch of tools that helped you to do that And you should be prepared some stuff that must be done before Like for example, try to make everything cold like not only your logic of your application But the way you deploy the boilerplate code you use for that and You name it. I mean and try to review everything Not only the logic in it the configuration the fine names if you use third-party code You're not going to review all the code But maybe you review the likes that it has on github the stars or if it's a patch on on Drupal.org Try to review that patch if it's small And if it can be diffed it can be reviewed Maybe you're interested in different images. There is tools for that and if your projects requires do it and There is challenges for example if you use SAS to generate your CSS You don't want to review the CSS You just do want to review the the SAS and if you include the CSS in the repo that might Set the challenge, you know So it's going to be a change, but it's going to be fun So finally the code is going to be read by someone that comment that I'm writing I'm not writing for my future self like you sometimes we say I'm writing it for the whole team and Sometimes I heard oh Can you have a look at my chains? But if you don't have a process established that never happens actually So code activity is visible because this is what we do day-to-day guys is is Every comment it's every every member of the team can see it and Introduce iteration in improvements what I'm trying to say with this is that Code review encourages to make smaller changes So the changes you introduce in the application are smaller and it can be iterated and Supports conversations because we are going to introduce you to some tools that are going to be the Where you have the conversations about code and that's great to be able to talk about the code and The code ownership is very important like No one is to blame land not one person But if there is a problem, we are a team at the end of the day and we are going to solve it together And well That's the thing. We are not individuals. We're a team. Let's Let's face it together and For new commerce in the team. It's great. I cannot emphasize enough. How good is code review for this or peer review? I'm Rodrigo and I'm going to tell you my story When code review was introduced in my team I was a bit fresh and I was grumpy when someone was telling me like no do it this way But it works, but I but I was learning and I started to love it and that's that's a great experience when they when a new member is introducing the team they come to do code and they want to get code committed, but this process makes them think about code, you know and Because they need the feedback actually to get their teams committed That gets them into the process of getting feedback if feedback and that's I think it's very healthy and Please leave your ego at the door. I mean if you identify some problems between members of your team code review might help you talk about these problems and Yeah makes incremental changes easier like you have Bigger changes to review smaller changes and the smaller changes are what you're looking for So everyone in the team has a voice Yeah, oh We have this even even the bad the bad guys in the team have a voice And There is this thing in maybe you have heard about it The unknown and online in the Toyota production fabrics the factories is that says there there's a string that anyone in team come You know pool and they will stop the production if there's a quality fault I'm not suggesting that you install strings all over your offices like it was a bus or something, but It is very good that everyone in the team feels that they have a voice they can say hey This may not be the best idea. I have a better suggest You know how this is how this this should be done in another way So it is not a way of maybe they are not right. Maybe they are they are playing wrong And that's that's that's fine as well, but everyone needs to feel like they can do it like there is no It is encouraged to Propose changes and to propose changes in the in the process so Everything that I'm saying about cold review like Pedro said can be applied to processes review Like why are we doing all the stuff? So to get started, please go slow maybe you can start with just one team just one rep or just one project and And please just the just the deeps like we do when just we submit patches to Drupal dot org You don't change stuff that is that is around the the patch, but you focus on the problem Maybe you just want to review the just the scary smelly parts Because we all know what parts are those and we want to make them better refactor things like that And maybe you want to do code review on demand, but make a process like Open a ticket or something. Maybe you can use a post review tool And everything felt review bingo. There is like one very old pattern in Drupal dot org that you can go to An issue that needs review and maybe you can try that in your team So and one thing very important That should emphasize is that everyone on the team like in the online school review and get reviews Because sometimes you see that the role of the reviewer and I don't like that all at all So as I was saying we have two kinds of tool the pre-commit tool That is the most interesting is what most people mad what most tools do and it works like a firewall for your code and Doesn't get the changes until they are okay And all the team agrees on them and it's a great moment to change the architecture of your application if you Have decided on something is not written on stone. You can change it And there is also post commit or audits like you can with the code that already exists You can propose changes to it and might be interesting for you so Automate stuff Machines can also do some kind of code review. They can talk about coding standards Maybe they there's they are mean The machine is don't say please can you review this part of the code? There is a comma missing here They just tell it to you so we as humans avoid those kinds of comments that maybe make a sound pedantic So they run tests. That's great. If you have a test room development workflow They can make continuous integration There is a lot of tools that and they take complexity in your code duplicate code maybe test coverage things like that and For as I was saying for newcomers for new members of your team, maybe they find it Difficult when they find these tools at the beginning, but if you explain them the niceties of coding standards They will be convinced about it But hey, we are people and Machines are not going to replace it and replace us yet so we can do a lot of stuff we can review requirements That needs the application once we see the code we have them Available the architecture if the code being submitted fits the the architecture that we agreed on It can make the code future proof because ROOPAL 8 and PHP 7 are around the corner and We can write code code now that fits those requirements and maybe in our team we have coding idioms the way we Retrieve a node and maybe we wrap it with entity API or maybe we don't and That things that kind of things should be agreed on the T agreed on the team and For the code were used the members of the team know which functions exist maybe they can be reused and Again, it spreads the knowledge Amongst all the members of the team And guys review happens in other professions like journalism why it's not happening in in development in software development So what happens if you don't do code review you look at the fire and you write you continue to write your email It's not a cautionary tale. It's things that you might identify in your team and they might get better so This happens a lot code and that's been very personal. There is that part that that guy knows about and All the teams would be aware of that We get a lot of Monster code around all scary. There is no bigger picture of the project And You get code that it's very obscure very dark because no one looks at it and technical debt get it gets ignored things like that and Maybe you have external contractors you can get them also into your review process. So your code to get more ownership of the code things like that and little code review and Members of the team find it hard to improve the school skills in the code writing craft because maybe we work We consider that we're working with very intelligent people very bright, but we are not getting Anything really from them because we don't look at their code. We are very busy and this is a very less a learning experience so for tools We're going to help you. Well, we're going to give you some examples what I'm currently using I know there is other tools But let's see some some technical size of it So Mostly they serve us as a workflow and notification management When to do code review when to merge things like that and They you have like threads they make discussions and you can keep them You can review them later to see what happened. That's very That's very useful They're also asynchronous because when you talk about peer reviews someone thinks about pay programming but pay programming is only used for for the for the two people doing it and There is no record of the discussion So it's it's lost in and for also for for remote teams It's great to have a tool that you hold the discussions on Some of the tools are very opinionated They know how you use how you should make the commits how you should make them if you can configure them a bit but some know how How you should do your workflow? For us the minimum requirements is that you can make tips you can make comments under the under the line of code that's being changed and nothing else, but It's nice to have rows to merge the code automatically to make reverse notifications and integration with continuous integration like Jenkins things like that So First tool very old patches we all know from Drupal.org It's kind of the legacy way to do code review But it worked for us to release to polite. So might not be that bad. You need credit or to Do a proper code review. It's very handy Then we have full requests that are very popular too common to github the bucket give lab that is a very cool tool and What they are is good with code reviews like if you don't put any Layer on top of github of the pull request. There is anyone can merge stuff like that That sometimes makes the makes the git history a bit and clean Well They were merging code from one branch to another you get a lot of comets as you are fixing your your feature things like that And well there This fancy and I should mention then there is well, I think try is This mentioned something this morning about having branches. So there is also an initiative That is called issue workspace. That is kind of having full requests on Drupal.org so and I currently use Garrett for code review is The tool that I like because it does it's does one thing and does it good but it also serves as a code repository as a Repo as a repo a hosting repo tool because it takes control over your repo and is Garrett that does the merges of the code things like that it allows you to have a clean common history and Introduces the concept of the change pool the as a list of changes that you can That the machines can get and make continuous integration and the developers can also download and makes and make reviews So there is a lead a lot of big projects using the using Garrett mostly Google projects Here is a list of changes. You can see a column on the right That is how big the change is so before you review it You know that it's going to take you a long time to review it or not And this is what mostly encourages to have a To have a small a small commit so all the people can review it Here I made a gift on how is the submit a Step for Garrett you submit the code and it gets merged automatically can be verified by machines They get like different stream of conversations the In a pull request you only get one One thread of comments, then you have the machines apart in Garrett things like that It has some drawbacks like the interface is not it is not very nice actually has a learning curve because you have to know how Garrett manages their the repos and the commits and It's it's not a drawback that it requires you to define a review process It's like you enforced you to have a repress a review process So I think that's also cool, and it's also it's solely pre-commit. There is no audit You have to make changes and uncommit them and I wanted to make another example of a post-commit review tool like it's a plugin for RedMind and you can open issues and For request of changes as things that you are you don't see that they are right There is other tools Atlassian has a certain code review tools Facebook has inside the fabricator suites the differential tool and well Make your choice a student very good, and I hope you do a code review. So here is okay, so Change sometimes can get hairy because you are in an organization and maybe You cannot you don't have the tools or you don't have them them. You don't feel you have the power to do this So This is where I well I found these two guys there. I thought that was a good representation of some Japanese concepts like kinds and kai-kai these are very These are concepts very Linked with the lean Methodologies and Gile and things like that The first one means that you do incremental changes that you do a change you plan it You measure it and then you act and then you do it again. So it's a cycle And the second one it means radical change So maybe in the organization incremental change just do not work because there is not enough Not enough Support or not enough Commitment so you may want to do a radical change and then you do incremental change Say you don't use code review. You don't you don't use peer review at all Everyone commits everyone so one one way to face it will be well. Let's try to do it in just one project Let's try to do it in just one team. Let's try to do it very slowly and Second the second option is yes. Well, you know from Monday we do peer review. That's it and then to look how how it works and Another thing that is very similar to code review in terms of how you can implement it in a team is testing How I guess most of you do to test in who who does something like be had or php Unifolder Okay, that's great But it is hard to do it is hard to convince teams and and organizations to start to do it and It's half one and Plans go go well or not. Well, you have to have patience as well You have to evaluate the organization. Maybe your organization is not ready for doing VDD out of the box maybe Maybe you can't do TDD and I mean Drupal 7 is not the friendliest thing to do TDD in the in the market to be honest. Maybe you implement your own stuff You know, there are tools like PSPS back there out there. There are a lot of things You have to do to do a work for making the tools Easy and making the tools and adapt the tools to the team and not otherwise maybe your team is ready for for some things but not other and You have to sell the plan very well, and that's probably hardest And you have to show results. Why are we spending so much time and Directly money in testing that doesn't release our projects faster It starts small but Don't stop don't don't leave it. Even if it's frustrating. Those are oompa loompa and stanching Some of you like what is that? Pick your battles that's that's the main thing you you need to start small you need you cannot testing test everything That is not possible. I mean you won't have infinite budget But hey if you have infinite budget Give me a call or something You have to identify the key areas what the business rules are important the the User interface is important. You have to identify what's the key area for your application and start testing that and Your day-to-day can kill you. It's like oh if you don't if I don't integrate testing in the core Like I do things directly the day-to-day as well Take take all my time I can do it and performance is really really important if your test goes low You don't want to spend time waiting for the test to finish. So that's a very important often overlooked Thing in testing You need to to keep everything up today because there is nothing as Anoying as a test that it is not longer relevant. There is nothing. There is no worse enemy than that So test should be a core processor your day-to-day don't meet Developers we are lazy And we don't want to do this But it is very difficult to convince some developer that say oh, we are not building rockets or planes. We don't need testing So we need to automate and make things fast And if you have to look at it, it is not automated. Okay, that's that's important It is not that if you have to press the button and everything happens Well, you may have a hook or something that that can Can help you And it is very important to not leave broken windows, you know the broken window theory that you leave a building with a broken Window one day and then well, and then you end up with some You don't want that so when a broken when a test is breaking or you do a change and you break a test That's actually good news. It's like hey, this is these are that we are doing it works I mean, it's one of the things that when they breaks it work. It means it's raw working. Don't leave broken tests wrong If it's broken and you can't fix it You need to either evaluate if you want to fix it or if you want to just delete it and Color view helps a lot There is these Japanese concept called kintsugi That's a ceramic Base, so there is a this Japanese craft that when Ceramic base is broken. They fix it with golden paste So the result of that is a much more valuable product or a much more valuable and solid Oh, yeah, so make sure that your test Fix things with gold paste. Okay, so you don't get those annoying calls Okay, you tell me what's fixed your client calls and say hey this thing. I told you last week You told me what's fixed, but it's not is failing again. You don't want that call So very important stakeholders whoever those may be for for your case needs to be on board It is very important if you if you have people writing tests for you like your Pre money your sprague donors, whatever whatever who whoever you can involve in your in your Project and your testing it is very important Because behavioral driven development is not just be had it's about a whole set of philosophies Like that say that you need to write a test first and the test needs to be Red and then you need to make it green, you know, that's if you use in be had doesn't necessarily mean you use in VDD and Be had is not just the language we had used it has a lot of implications So you can choose test your business roots test your user interfaces Test your API your integration with others. Maybe that's the your key. That's your thing I don't know. Maybe you get calls from their client because the user interface for fails. Maybe that's your main concern and You can choose different purposes tools for different purposes. That's that's fine. We're going to see a few a few of those tools So the the first one that we are and this is going to be very Drupal specific Simple test, how many of you do tests with simple test for your client projects? P of you Simple test is is is really good in terms of being a Drupal specific and have all the tools and But this is pretty much only Drupal who uses these at this point in time It's really slow I don't think anyone can argue that simple test is really slow because it goes and clicks and it does that inside of This is how a simple test test look So you have folder or your Drupal things and you can do more More stuff like that and this will this will boost up Drupal and things like that That's that's expensive. You have to you have to take care with this And and this is great to do integration with doing between pieces of your code. You have PHP unit PHP unit is not straightforward to integrate with Drupal until Drupal 8 Okay, so you're doing Drupal 8 you have that out of the box and that's great. It's a key Thing because PHP unit is as fast as it gets. It's just practically immediate and you want that But if you're doing Drupal 7 you can still use PHP unit But you have to modernize your code ways really Which is good and is bad because you have to spend time on that and this is how a PHP unit test looks like You can check Drupal 8 is full of those And you have to tell them tell the PHP unit because it's a unit test doesn't know everything about anything So just test one thing and one thing only and you have to tell it what to expect what to What to have what you have there? This is faking Functions to call or methods to call and that's good, but it is it is a change on And you can test the interfaces as well I will say that if you have to test interfaces you are better off with things like be had Than simple test, but it's probably a matter of opinion We had a PHP tool and cast can test everything. There is a fairly good in integration with RuPauline's extension And you can integrate it further The main drawbacks of we had And you can test everything JavaScript or anything you can Throw Selenium tests and you can get the browser and see how the you know the small guides had we had clicking in places, you know But if you do be had you have to do Dictionary based phrases. There's a be had test you know, this is very you can read this right and Maybe your your project managers and pro donors can't do and can't write those But you could end with all with a really really long glossary of things to keep like and I press and I Go to there and I and I do this action and you can have a you need to find a way to make that glossary Meaningful and easy to browse easy to discover for for new for new people That said if you don't have your your project managers your product owners on board You may want to go for something like Casper GS or other tools similar It is a JavaScript based testing framework and It uses more or less Same tools that we had that but in the JavaScript world It doesn't have any droopal integration just a front end testing tool and it looks like like this it looks like a JavaScript and these and these you can't ask your your product owner to write, right? But if they don't want to write tests, you may want to have code as your tests Why not if they are not on board? Why would you water on on having meaningful meaningful natural language tests? Maybe that's your tool That's it for testing. Yeah So Automate everything that is Related what we were saying that you don't want to make the same mistake twice So you want to be vigilant around what you're doing? What processors are? done by humans and What can be automated? Continuous integration is the main candidate to be to be automated. It's very easy can be script As I was talking the code review made by machines coding standards Complexity with practices you could you want your machines to to run the test the test suites You want to have the deployments under control? So you can deploy in a Friday and afternoon. So once you You reach this point you get like send tranquility and maybe you want to use something to generate your files to Push the code to the client because he's the one deploying the code things like that So this is your tool belt and Jenkins is a great tool. Maybe Travis might be bamboo You can use for your deployments Capistrano Ansible also is going to provision your your machine Chef well, there is new kids on the block like Docker. It's been talk lately a lot Yeah, I mean it's a matter of The same again with a code review and testing is that you need to choose you need to know your organization You need to know which tools you want to do And if you want to automate something you need you need probably your chances are that you need some of these or similar names So for example, if you if you do provisioning and you don't have any Ruby developer on the team or anyone that Wants to get near Ruby. Maybe you don't use Capistrano use thing instead because you know PHP and Maybe you want you want a faster onboarding. Maybe you want to look into Docker Maybe you have a DevOps person that can do chef or puppet. Maybe you don't have it So maybe you have someone that can be a Jenskin server and they know how to do it Or maybe you want to pay Travis to host your continuous integration So did this some other of know the know the guns you have to do the job Yeah, also on the developer side there is no grand golf things like that you have javascript fanatics in your team You may have end up using the golf to the plot. That's fine So as a final note before taking questions or something I wanted to say that I think all this Quality approach is a new step forward on the pragmatism of free software that We demonstrated that we are able to deliver tons of free software, but the quality is so we need to focus Now that in the current moment on how are we doing stuff? So it has more quality is more pleasant to work with so It's come to the spring some Friday and Well, this is some of the images that we have Thank you everyone for coming. Thank you So we have an open mic session now if you want to make some questions and say well your guys are so wrong on these things Yeah, you need to you need to somehow yeah, otherwise I cannot be the question. Yeah Okay, hey So I know that you said please take to the mic, okay, I know that it is fine Okay, I know that you said that having slow tests is a problem, but you always reaching a point where you have too many automated tests mean too many many and the automated tests becomes slow and What we can do in at that point What what should be the approach to learn only business critical tests and to earn other tests Manually or how that's that's a great question And that's where your continuous integration and automation Automatization tools coming coming to kicking and help you you can explore it depends on your application a lot You know, but you can explore like building your application with Docker So the bill doesn't take anything so you deploy your docker and you test there You have things like the Cloud now very modern made in very Very fancy and you can you can deploy machines that you run in parallel your tests You can do things like the machine reviews and things They don't need if you are reviewing your code as well as your as your Testing you can review the code without installing the size tall inside. You have to break the thing in pieces I'm probably a good idea is to Things like be had have a very smart a smart tagging Mechanism. Yeah, you can tag your tests. So, you know, what are core what are not? So you did you say these are the ones that I want don't run old test But don't run this beat because this beat is critical and everything else is Nice to be tested. I mean, but this is broke if it's broken. I won't get a call right away This is broken. So you have to identify your you have to pick your battles in your testing. Yeah, what's not critical You don't run it very often. That's what we you have a nightly. Yeah Criticals and you have a whenever a change is made around around the core tests. Okay, all right I was in a in a in a project that we tested Every carrot change even if it was a line of CSS So we learn to mark things as this shouldn't trigger a test every time it's committed walking like that. That's valuable. Thank you For for checking code style. There's code sniffer. I'd like to know if anyone has Real-life experience with the other tool that comes with it to automatically fix a number of those code styles For example adding a period to the line. Do people that use it still learn To do themself or don't we care just do it automatically ever always? I I know how to automate it, but I think it's a very good practice. Like I have it on the development side I automatically fix my files, but Well, you're saying that not only your review if you run automated Mesh detector a code is minifer That the tool itself will fix your code That there is there is with code sniffer also a tool that can do it automatically, but my my my concern is do people Still learn to do it right or don't we care just like using a calculator you don't you you You can't Calculate in your mind anymore you need to calculate it. Do we care or do we don't we care? I mean If you have a human review and you get a review that is you're missing a dot. It's like well, okay But um, I don't know if I will feel comfortable with a tool fixing those automatically like every comment or something But I guess a good thing is to have like an ide configuration file somewhere That make sure that every developer has the same code standards in their machines So I think this is a problem that eventually You know can be fixed Over time I wouldn't say it's a big thing But if you have a Drupal 7 thing that you want to move to Drupal 8 you want to you don't want to be Worrying about coding standards. You have to have those fixed by that and that we agree on. Yeah Yeah Yeah, you you say just to summarize for other people who can't maybe can't hear you you say many ideas have an integration I Yeah with code sniffer. Yeah That it's also for Drupal 7. Yeah, that's that's the one I was talking about the automator. Yeah Yeah, still my questions unanswered. Is it is it good? When is it good to use it the automated? Fixer and when is it not good to use it? Okay. Thank you. Yeah, I know yeah Yeah, yeah, that's that's The discussion maybe for the recording is whether to use automated fixing or not and Joao comments that maybe if you have A huge number of problems where you do a cleanup with automating things Have you if you have automated tests? You know, it's less risky, but if you don't have automated test if you don't have that um, I don't know maybe you can fix the dot thing But if you have other Things like renaming Comments or something that's that's more that's that's different Just one last question Rodrigo mentioned some very great things we get from gold review Especially when we work as part of a team But I have a question for Pedro as a freelancer and I don't know if this is the case But if you work on a solo project, you are by yourself you have no team With you that can review your code What practices do you suggest to review your code instead of other than yourself? Obviously, and also having testing in mind, but it's not exactly the same Yeah, this is a great question. I normally work with teams when I'm freelancing now But it is like the question of do you do agile on your own? Right, I don't I don't know it depends. How complicated is the stuff you're working on? Um But I have the I have the idea that um if you If you are selling something to a client the client doesn't if you do testing It is not that it's something that the client should say you do it or not It is something that comes with your With your uh product or whatever you're selling, right? So, um Having a Jenkins for yourself. Well, it depends. Do you maintain the client websites? Or is this something that you do and then you let off Well, it depends. That's that's a yeah, if you if you are maintaining it, maybe it maybe is worth it Why not? Maybe you can have some testing for for some stuff if the client is maintaining it Sorry So one question on the tools you mentioned some tools for continuous integration and for deployment um You also mentioned that uh, sometimes it's good to review only the smelly parts of the code Uh, but how do you detect because if if I'm putting myself in the head of a very lazy programmer That has done some really smelly code And doesn't want that doesn't want the hassle of going through a lengthy uh code review So what I'm going to tell you is the smelly code Is the code that I'm actually more proud of and the one that has less problems I'm going to try and hide away under the the rug the the really smelly code So what kind of other tools because code sniffer. Okay tells you yeah, this is where he left out some points or some he left some extra white space or some very stupid things but Real code analysis which tools should we use? Well, we have p and d php mess detector That is going to tell you well And not only that you can also maybe based on performance the code that is not based on a x h prof. Yeah I would say I know that this is not your question, but I would say Ask the current or former developers They will know what is the smelly part It's like ask what is what is the thing that you wouldn't touch in this project? That is what you have to test or your attribute The parts without tests also I guess when when when we said this as the review the smelly parts We wanted to mean start somewhere start somewhere that has adds value Whatever it adds more value, I guess I did I ate the ie 18 n module since then Okay, the recommendation was blackfire.io for testing performance Okay, I think we should So look for the usual suspects in Drupal like hooking it or crazy alters or things like that So the comment was like the Drupal API is going to tell you what are the dangerous hooks and things like that Well, you know, you know, what are the where where the big hooks are, right? Yeah I hook in for example For the recorder So I think we should yeah, that's a wrap up. Thank you everyone