15 Laravel Tips to Work in a Team

hello guys today we have a part two with 15 more tips how to work in a team more effectively and this time more specifically about laravel and php and this will be a longer video so grab a cup of coffee for those who haven't seen the part 1 i will link that in the description below and let's go with 15 more tips tip number one is related to dot env and dot env dot example files if you have any variables any values that you need to put in env file for some package to work or for some external service here in my example there's stripe related group of values and also mailchimp then how your teammates would know that they need to put that in their nv file or on staging server or on live server imagine the scenario you push your code and then someone else your teammate pulls it down and then the code throws 500 errors or just doesn't work how would they know that they need to put that in env file apart from putting that in the read me the information that they need to put something here you need to put those keys but without the values in env dot example file which comes by default with laravel you need to fill that in with empty values for the same variables then the teammates would know that those variables with those exact keys should be present because also otherwise how would they know probably they know that they need something around stripe or mailchimp but how exactly should those values be called of course they can find that out in the config or in some documentation but the quickest way is env example and even if you look at the laravel official repository laravel laravel there's env example file that comes with every laravel installation if you do like larval new something with laravel install or composer require laravel laravel you get this in the example and also in the composer json of that repository there is a command this one file exists dot env if it doesn't exist then it copies env example to env file tip number two we're not running away too far from env files do not call env variables in your code there is a function called env and then you put this key in the parameter like this so env with the key but that env should be used only in the config files so for example config newsletter in my case for the package of spicy newsletter and if you find env in your code somewhere in the controller in service or in whatever of your application code this is kind of bad practice and the reason is the configuration cache so here i've opened the documentation of laravel if you execute config cache if you use config cache you should be sure that env function is only called within your configuration files so config slash something so if you have a new variable in your env file put that in env locally then put in env example as i mentioned before and then in the config you can create your own config file or in config app.php for example come up with some key and then call that env variable and also even the best possible option is the default value so even if someone else on their computer or on their server doesn't have that value the default will still help the application not to break tip number three is pretty important and it's related to environment in general your own server local server staging server and your teammate server the main thing is to use the same php version quite often we had problems with our team where someone had 7.3 others had 7.4 and wanted to use the syntax of 7.4 and it didn't work on other computers or on some staging that wasn't updated so it's crucial to have at least the same php version and then other libraries that you need for a specific project or maybe for your global team settings should be present on all computers you can come up with some kind of docker file docker environment to share with all your teammates to have for some teams it's an overkill the minimum thing is to have php version the same or at least be able to switch that quickly like laravel valet allows you to do that and also talk to your team which php version syntax you use so do you use latest features of laravel 8 or 7.4 or if for some reason i don't recommend that but if you have still 7.3 or some other unsupported version on your server then talk to the team that they wouldn't use and you wouldn't use the newer syntax from 7 4 and 8. tip number 4 is related to migrations basically do not edit all the migrations which are already committed to the repository so if any other teammate has that migration there's a chance that they actually run that and then if you edit that on your machine and recommit that to repository they wouldn't have the same change so for example if i open random migration and change foreign id to nullable here or change string to text here for example and you would run that locally on your machine or maybe on all the servers that you want but we're talking about teamwork here and let's imagine other teammate the latest changes pull down on their machine means get pull autism migrate and then maybe some more commands like cash or something so artisan migrate doesn't rerun the old migrations and you would ask so what to do then if i need to change that thing if you need to change some type or delete some field or something like that you create a new migration so you do php autism make migration which would rename string to text or something like that and then when they run when the teammate runs the autism migrate then that change would be run on their machine as well tip number five is also about database but it's about the data not the schema so use cders if there is some data that you need to be present in the beginning of the project imagine someone else installing the project for the first time probably they need some kind of super admin some categories something that they would be able to run the application so use cders and prepare the dummy data or semi-real data for anyone that would install the project or even for yourself in the future if your computer crashes or something or on any server that you would install the application new from scratch so prepare the seeders and for example user cedar so super admin for example or some typical pages here's my example from checklister project and also you may go one step further here's a tweet by adam i actually tweeted the question what do you suggest for teamwork and laravel and one of the answers was from adam instead of having create here like page create you could use first or create to prevent if someone else runs accidentally or maybe on purpose they run seed again so artisan seed or artisan migrate seed they will have duplicate data so two pages are created on the first run and then another two pages on the second run of the seeds which may cause some bugs so you may do first or create and i think you don't even need to change anything here it just runs like this actually double check the syntax for first or create but basically if the laravel finds this record in the database it doesn't do anything otherwise it would create it tip number six is use the same coding styles and coding standards here's an article from my quick admin panel blog about psr standards in php psr 2 and psr 12. the best example of that is tabs and spaces and new lines so for example if someone writes methods this way with this on the same line other person writes it in this line and then you may have conflicts while merging the commits or merging the changes just because your phpstorm or vs code is formatting it differently from other ones and for example if someone else pulls your code down to their machine and have auto formatting on their editor which they should do then it immediately causes some conflicts in the code or the thing i hate the most the commit contains the logic of the code and some formatting within the same commit which makes it harder to read to review and to approve that pull request but that's not only about indentation and naming actually naming i have a separate video laravel i will zoom it in how to name various things so there are like 10 or dozen of various tips like book controller or books controller related to laravel so i will link that in the description below but it's not only about psr and about just generally small things it's also about structure of the code and how you do how your team does various things so how to structure the laravel project what folders what subfolders what design patterns do you use repositories or services or something like that first for example if you are new team member working on the existing project then analyze what design patterns what namings what folders are already there and then use that pattern or if you want to use a new pattern then consult the senior teammates whether you're allowed or maybe there's some reason why they use another pattern from what you want to use or there may be a situation which i had in the past i want to use a different pattern and the senior team members agree that this pattern is better but they didn't have time to refactor all the repository for that so maybe you would take the job not only to create your own feature that you're working on currently but also refactor the code the old code so it would follow the same pattern and i want to summarize that tip with my own tweet that your code should not stand out it should be the same standard and style and pattern as everyone else has in the team otherwise if your code is individually different then it would cause confusion conflicts and problems down the line tip number seven is be careful with composer update specifically composer update not composer install if you have composer update running it would update all the packages which some of them you may want to update but some of them are pretty risky and if that is run on the server if someone else runs composer install on the live server or on other machine it may break something for those of you who maybe don't know the difference between update and install composer install just installs everything that is changed in composer.log file composer update actually updates all the packages that it finds newer version and then updates composer log file which you should push to the repository as well and then on the server or on other teammates computers they just run composer install to take the changes from composer lock so don't run composer update without confirmation from your teammates or senior team members who are responsible for the deployment that you do update the versions and also follow the versions monitor the versions in fact what packages do you use and which versions what is in the require or required dev so basically your goal is to not break anything with composer update because for example i've run composer update on my checklister project and look how many things are updated just within a few weeks which i haven't run the composer update of course they are minor versions but you never know which version may break something introduce some breaking changes which they shouldn't but things happen even in laravel core i've encountered a few times with our quick admin panel that laravel version for example 7.29.3 or something that's random number artificial broke something so introduced some parameter which was rolled back pretty quickly after they noticed that or something was reported but still things happen even in laravel core so be careful with composer update tip number eight quick one if you use translations if your project is multi-language from the beginning do not forget to put translations everywhere for all the texts everywhere that you have any english language or whatever language you work with always always put translations because if you don't do that you wouldn't really notice and then the client may notice or the users may notice and then your teammates would have to fix that afterwards so just if you use translations use them from the beginning and use them everywhere it should become kind of a habit whenever you code that project so whenever you have any text like new checklist or whatever or pages or log out it should be always with translations tip number nine it's not that much about teamwork directly but install laravel debug bar locally or any analog of debugging your code and look for specifically a thing called n plus one query i have a separate video about laravel n plus one query detector also i mentioned n plus one queries in my other videos but the thing is that you shouldn't run too many queries on your database and locally you may not have notice what will help you notice is that laravel debug bar it will show you bigger numbers for queries or for models or something like that so it will help you to detect the issues while on locally because usually locally developers test with small amount of data but still in the debug bar you will see too many queries anyway because if you don't install laravel debug bar and locally your project works really quickly then you commit to the repository and then your teammates in the future encounter problems on the live server with bigger amount of data reported by client and then for them it's really more difficult to debug your code to find where is the problem so prevent the problems before that by installing laravel debug bar or there is a new thing coming in laravel 8 at this moment at the moment of shooting this video it's not really released yet but it should be out soon so muhammad said from laravel core team shipped this change to prevent n plus one query in the very beginning so you can read about that a bit more on laravel news article with the demo and with the setup and that could be a new potential way to prevent n plus one query problem but even in general laravel debug bar is quite a good helper to debug any issues that happen locally tip number 10 comes from matias as a reply to my original tweet kind of a small detail and not about the teamwork itself but this is an example so don't use auth user in some internal like service commands or jobs because you may call that from the user session like from controller but maybe in the future someone else will use that service without session or on automated tests or something like that so whenever you are writing the code which potentially could be used by someone else in the future like a helper method like service class like a job think about the scenarios that some crucial part of that job wouldn't be present if someone else calls that function in some other way so that auth user doesn't necessarily exist if your internal command could be run like from artisan tinker even or in other scenarios so always think about how other developers in the future it's not necessarily your current team members would run the same code that you're writing right now tip number eleven partly comes from rigid fix the tests you break so generally my advice would be write tests specifically for the crucial part of your application first so other team members would be kind of sure that some crucial parts actually work but also there's another part of the testing thing so whenever you write some feature you're finished your own feature you should run all the test suite with php artisan test or whatever tool you use for the testing and then some test may break which is written not by yourself so your code could break someone else's code in some case for their scenario and of course probably you should contact that developer and ask about more details but actually it's your responsibility to change your code so it wouldn't break someone else's code in some rare cases you should contact the developer and ask them to fix their part because it's not relevant anymore but more often than not it's your responsibility as brigitte says to fix the tests that you break doesn't matter if the test or the code is not written by yourself in the first place and finally i have four more tips for doing laravel things in a certain way so i would suggest one way but it's not necessarily the correct way all four tips will have the pattern use it the way i say or contact your team and ask how they want to do that or is there a reason that they do not want to do it the way that i suggest it's my suggestion but it's not the 100 rule so fillable and guarded in eloquent models i found tony's article about fillable and guarded which explains it in a simple way but basically fillable attribute on your model specifies which articles could be created like this with request all which i don't recommend by the way or request validated so use fillable i totally recommend that or if your team doesn't want to use fillable for some reason use guarded it's one way or another and in my experience i do like fillable more because it's more readable so any developer could go to model and see which fields are fillable but if it's really dynamic in your case and you cannot really specify the fillables then you may use guarded but contact the teammates and consult them and ask whether we as a team use fillables or we as a team use guarded of course it could be also individual case model by model but there should be one main direction in the team tip number 13 similar to that my advice or actually advice by chris in the tweet reply but i totally agree with that that you need to agree where to put middleware my personal preference is to use middlewares in the routes web or routes api file so do not call the middleware in the controllers or somewhere else so if you see in the controller this middleware something then all your team should use middlewares there in my personal experience it's more readable to have it in one place in routes web where any developer can check the middlewares otherwise if it's all over the place in controllers or maybe even in route service provider as a setting then someone may miss or misunderstand what middleware is active where again advise to use it in routes but if your team does it differently go your way but consult the team first tip number 14 two tips to go is to use form requests for validation again it's an advice it's my personal preference and experience that all validation would come in the form request file as rules array you can also do that with this validate or validator make make i think this is the syntax and have the rules here but generally it makes the controller longer and if that's the case if that's what you want then go with that but in my experience i personally prefer to have validation as a separate layer in form request class and then all the teammates know that i do that with form requests and we all agree that we do that inform request and then we all know where to find the validation rules in the app http request folder that's all clear for everyone again it's not the rule it's the advice the main goal is to have it the same way for all the teammates so everyone would know where to expect to find that information and finally tip number 15 in the same class in the same file use route model binding whenever possible again it's not the rule it's the advice but it makes the controller shorter and it's quite a good feature of flowerville itself again everyone should use it on your team if you use that or if you don't use it for some reason then everyone should do it something like this so id and then do checklist group checklist group find or fail id there's nothing really wrong with that if you prefer to do it this way but then your teammates should be aware that you don't use route model binding on your team and actually it is important for new team members for future team members as i mentioned in the beginning of this video new team members should analyze the code and if they see that pattern they would follow it in the future which is fine if they find route model binding like this they would go further with route model binding way and there are more examples probably like this one in laravel structure in general in laravel syntax because quite usual in laravel there are a few ways to do or to call the same thing from different structure so your team should follow the same pattern basically and avoid any surprises in the code which may confuse newer developers or even yourself in the future so that's it 15 tips quite a long video i didn't expect that to be long and also there's part one for those who haven't seen that it's a bit shorter about non-tech and non-larval related tips about teamwork but generally i hope that these tips will help any new developers especially those who come from solo environment being a freelancer or working on a small project as a one developer into a team environment that comes with a lot of challenges and this video contained quite a lot of tips to overcome those challenges if you want more videos like this one subscribe to the channel and support me financially by checking out one of the three products that you can see on the screen admin panel generator livewire set of components and my courses on teachable and see you guys in other videos

Channel: Laravel Daily

Views: 16,471

Keywords:

Id: 0ieY-YmtGKA

Length: 23min 14sec (1394 seconds)

Published: Wed Jun 09 2021