I feel like I would stop at 16:59, code seems more readable for me, but it's just personal preference. I don't like to inline arrays that much and 'mess' with de indentation. Not saying its a bad video, it is awesome, just my personal preference. Thanks Jeffrey!
I really enjoyed to see how you was writing code that was "good enough" to be shipped to production! That's the mindset I hope one day I will have. I shall ship as long as my code is readable enough and does the job. The perfectionist will never deploy something.
Nice one! To my very personal opinion, i would rather use one codition and then return the result. I would omit else part and return if it reaches there! But I get your main point. We just need to recheck and refactor wneneer possible.
Nice! Very nice! Personally, I would choose to keep the $isOnATeam variable so that I can change the value at a single point if ever there is a need to do so.
Totally agree! Moreover it is always a better practice to choose resource over readability, however here even with assigning variable, readability did get worse.
It seems to me it would be nice to use a technique inspired by early return - to set the "default" value outside of any conditionals. Then have one conditional block, that would set the more complicated values with query string, etc. It feels weird and prone to errors down the road to have the ternary duplicated.
At 14:30 he referes to a method "Auth::user()->isOnATeam" English is not my first language, so I could miss something My question is, this "isOnATeam" is a built-in method or I have to create this method on the User's model ?
What do you think about destructuring assignment? You could rewrite it so that you have to check the condition only once: [$message, $url] = $isOnATeam ? ['message1', 'url1'] : ['message2', 'url2'];
![[UNCUT] The Loyal Pin ปิ่นภักดิ์ EP.15 (3/4)](http://i.ytimg.com/vi/IVwR87OH0_A/mqdefault.jpg)
I am usually having a feeling of "over" refactoring.
But seeing you doing the same as mine, is a relieving...
Thanks for making such videos..
Great video, I'm a senior developer and I still enjoyed watching.
Very helpful video; the thought process of your refactor was great to hear. Often coding videos are missing the "why" of decisions. Much appreciated!
I feel like I would stop at 16:59, code seems more readable for me, but it's just personal preference. I don't like to inline arrays that much and 'mess' with de indentation. Not saying its a bad video, it is awesome, just my personal preference. Thanks Jeffrey!
It's whatever looks prettier. Sometimes, that's inlining the array. Other times, I'd rather keep the variable.
Nice refactoring. I like this gradual refactoring style - very clear. Thank you.
I really enjoyed to see how you was writing code that was "good enough" to be shipped to production! That's the mindset I hope one day I will have. I shall ship as long as my code is readable enough and does the job.
The perfectionist will never deploy something.
You refactor so nicely when you talk through it. I sometimes imagine you talking when I do the same 😂
Nice one! To my very personal opinion, i would rather use one codition and then return the result. I would omit else part and return if it reaches there! But I get your main point. We just need to recheck and refactor wneneer possible.
Nice! Very nice! Personally, I would choose to keep the $isOnATeam variable so that I can change the value at a single point if ever there is a need to do so.
Totally agree! Moreover it is always a better practice to choose resource over readability, however here even with assigning variable, readability did get worse.
If you ever need to do that (with emphasis on ever), *then* you extract the variable.
Tiny bits of refactoring **Proceeds to make an 18m long video** KEKW
such kind of tutorials are really helpful.
It seems to me it would be nice to use a technique inspired by early return - to set the "default" value outside of any conditionals. Then have one conditional block, that would set the more complicated values with query string, etc. It feels weird and prone to errors down the road to have the ternary duplicated.
The message could also easily be inlined imo!
Great tutorial of refactoring, not just for beginners, may i say.
Thanks!
Of course not for beginners, they should write code at first...
At 7:45, what's the keyboard shortcut for selecting the whole thing?
I liked everything you did, but I would only do the last part differently. I mean I prefer creating a variable rather than repeating the query.
Very helpful..thanks a lot.
Which PHPStorm theme are you using now? @Laracasts
Love your lesson, 'n love listening to you.
At 14:30 he referes to a method "Auth::user()->isOnATeam"
English is not my first language, so I could miss something
My question is, this "isOnATeam" is a built-in method or I have to create this method on the User's model ?
You would manually add that method to your User model. And call it anything you want. $user->onTeam(), $user->isTeamMember(), etc.
Thank You!!!!!
amazing refactoring ...
Mostly in my team after refactoring , it always ends with silly bugs
wow 😲 it was really cool
good job
even with these little refactors .. i think its better to run unit tests .. because who would grantee that code still works ?
Of course. You do both.
Doing so to all files i visit... And asking devs to follow like stop declaring variables that are not variables or they are used only once.
What do you think about destructuring assignment? You could rewrite it so that you have to check the condition only once:
[$message, $url] = $isOnATeam ? ['message1', 'url1'] : ['message2', 'url2'];
Yeah, if you want. I probably wouldn't go that route, but it's fine.