Junior Developer Sent Me A PR For Review
Vložit
- čas přidán 27. 08. 2024
- In this video, we'll take a look at a pull request (PR) submitted by a junior developer for review. As a more experienced developer, it's important to provide constructive feedback to help junior developers learn and grow. We'll walk through the PR step-by-step and discuss best practices for reviewing code changes.
Whether you're a junior developer looking to learn more about code review, or an experienced developer looking to improve your reviewing skills, this video has something for everyone. Join us as we explore the world of code review and help junior developers take their coding skills to the next level!
Join waiting list here: amigoscode.com...
Don't Forget to
===========================================
💯 Subscribe to Amigoscode - bit.ly/2HpF5V8
💯 Courses Available for free here - amigoscode.com...
💯 Join Private Facebook Group and Discord - amigoscode.com...
🙊 Here are the goods for all my videos video 🙊
► Recommended Books
===========================================
- Clean Code - amzn.to/2UGDPlX
- HTTP: The Definitive Guide - amzn.to/2JDVi8s
- Clean Architecture - amzn.to/2xOBNXW
► Computer and Monitor
===========================================
- New Apple MacBook Pro - amzn.to/3464Mmn
- Dell 27 INCH Ultrasharp U2719D Monitor - amzn.to/2xM3nW1
- Double Arm Stand Desk Mount - amzn.to/3aYKKfs
- USB C Hub Multiport Adapter - amzn.to/2Jz7NlL
► Camera Gear
=============================================
- Sony ILCE7M3B Full Frame Mirrorless Camera - amzn.to/346QIJn
- Sigma 16 mm F1.4 DC DN - amzn.to/2wbic3Q
- Sigma 33B965 30 mm F1.4 DC DC - amzn.to/39G37Fd
► IDE & Tools I use for coding 💻 🎒
===========================================
- ITerm
- VsCode
- GoLand
- IntelliJ Ultimate
- Sublime
P.S
===========================================
💯 Don't forget to subscribe | bit.ly/2HpF5V8
💯 Join Private Facebook Group and Discord - amigoscode.com...
💯 Follow me on Instagram | bit.ly/2TSkA9w
❤️ Thanks for watching
Join the waiting list here folks: amigoscode.com/p/full-stack-professional
For me it's better getting 800£ a month and learning programming at a real place than taking a 500$ course
🤣
This got me thinking that maybe interviewing developers by allowing them to review a PR like this and explaining their suggestion will reveal a lot about their competence.
never thought about that
I actually got a couple of interviews that were like that
I've done interviews where I had debug code. Never a proper PR though.
Idk its highly subjective i think 💭
No bro, you have to do two sum and reverse the linked list. It's the only way
This is awesome!!!! Watching this video we can see , what a senior developer, think about a junior developer code. And... Paying attention in those tips/movements, we can improve!!!!!! Our code!!! EUREKA!!! Actually, It deserve a playlist
6:57 You suggest a RuntimeExcpetion as base class. It's ok at first. But every Project should have at least one base type of it's BusinessException which extends from RuntimeExpcetion. This makes the error handling in the rest controlelers and the transaction rollback handling for specific use cases relay easier.
Always good to watch PR reviews but IMO it Would be good to add explanation on top of code changes in the comments otherwise it is hard/impossible to understand why the changes are required/suggested
If you have a specific question you can ask here and I'll try to answer. I thought, that his comments and suggestions were very detailed and thought it's because some of his mentee are new to Spring. This video took 20 minutes for a rather short PR. IMO The time a junior dev spends on researching your suggestions is valuable and senior dev has better things to do then explain. Besides, he could also just DM him on DC and ask.
I was exactly thinking the same thing. I might give too much explanations and sources sometimes. Buy it only takes s couple second to at least at one sentence explaining why the suggested change is required or recommended.
Other then that great video, useful to see someone else's thought process while doing a code review.
@@niklas3128 why even make it possible to generate a DM? That takes even more time than a simple explanation of suggestions. This type of review isn't helpful at all for juniors. They need to learn the *why*s. He also fails to justify his disagreements. "Returning the entity to a create is wrong" is an opinion, and one he fails to justify in any way. The purpose of a senior engineer is twofold: produce code and mentor juniors. If you treat juniors like they're a bother, then you're not doing your job.
or give them this video to watch 😂
@@niklas3128 you must be joking. "This is wrong" is not detailed explanation. LOL
There are no videos like this out there. Please more of these videos. This was very interesting.
You should do this more often! Very helpful!! Thanks
9:13 Actually the HTTP Protocol nowhere states that you shouldn't return the resource back. You can return the created resource in this case "User" as long as you provide the identifier with it.
I agree. I'd say it depends on how often the API user will make a follow up GET to retrieve the user data
Hateoas
i agree
The code is returning entity via REST, which is BAD. Not sure why wasn't it called out. As the project progresses and the User will have `password` field in it, it will also be returned back via REST. The entity should be converted to DTO.
Also, Lombok should be used to validate field values. No need to validate them in service layer i.e., if email exist or not. Service layer can be used to validate business logic.
I agree, returning the raw entity as is could be dangerous if it contains sensitive information. I think that's why a resource layer is needed to transform an entity to a response, within that resource object it can be decided which data from the entity should be returned or serialized
I'd prefer simply annotating fields that shouldn't be serialized to exclude them and have a test in place in case someone removes annotations by mistake. It's just that creating DTO in this case produces a lot of repetitive code. Thoughts?
EDIT:
come to think about it, in this particular use-case since the data is so sensitive it makes sense to use a DTO without a password, since the risk is too high
@@maksym.pavlenko for simple use case it would work i.e., when you know for sure that password field doesn't need to be serialized. But you would still need some object which can serialize incoming object to a class. For example, a user wants to update the password. If you have put an anootation on password not to serialize, how will you translate this request to an object which can then be persisted?
In simpler terms, Entitys and VOs/DTOS has different purposes and different logic is applied there. These objects shouldn't be shared.
To check if the email exists you need to use the repository so you have to perform that validation in the service layer. Nulls and date formats could be validated with just annotations in a dto. Is that right?
Review took 15 min
I can't even imagine how much time it takes to review sophisticated business logic with 15+ pages or more
If someone's PR is that big, I'll simply reject it. Unless it is a major refactor or something that has to be that large.
Also it is a good practice of returnung DTO's instead of entities
I'd say it's even more than just a good practice - a must-have, especially when working on users.
"DTOs" should technically only be used in service to service communication, not as a return payload of a http request
@@slicex3408 , rly? So it is better to return a whole entities on GET requests? ))
@@Norua2007 no , never. When we return entity, all the fields are returned which is unnecessary and increases load time. With DTO, we can only return the response we need.
Create DTO if possible, it also helps to avoid LazyLoading Exception.
@@badripaudel77 , I know it, but dude above thinks that DTO's are for interservice communication only :)
Hiya! Would really like to watch more of such videos where you do a live Review with us. This is really very helpful. Please keep them coming. Thank you
Maasha Allah, that's so interesting, even though I'm not a pro but I understand and I'll also take note of these mistakes, I really wanted to grow my java knowledge because when I was in university almost everyone hates Java, and I don't know how Allah makes it easier to me, and following your tutorial really opened my eyes to what Java really is, but still I wasn't able to purchase even one of your course due to our economy situation, but believe me I have almost all your CZcams videos (Spring boot related) download on my PC.
And in Sha Allah I'll try to share my work based in what I learnt from just the CZcams videos, but that'll be after you permit me to.
I don't have enough words to show my gratitude to you but only Allah will reward you abundantly. JazaakAllahu khairan
Yunus from Nigeria
This is awesome bro. It was my first time to see code reviewing. It really motivated me bro. tnx a bundle
Thanks buddy, watching code reviews really helps us improve!
Had a little chuckle at the end, "theres no way this PR makes it's way into the main branch.". I work at a major bank, and you'd be amazed at some of the shit that gets yolo merged...
This video should be a mandatory watch, even for seasoned devs
I would suggest to remove the code with endpoint comments because swagger can doc the endpoints with more details (request, response, endpoint, etc) but it's not a big deal (I'm sorry if looks like nitpicking, that's not the idea). Awesome video, I'm a developer for 6 years and I'm focusing on leave Brazil and move to UK or Ireland in the next months, I really appreciate your content, thanks for that!
@@mofobo it’s possible, but most companies are from USA. It can be possible to work from Brazil, but for European companies is more restrict based on my experience
Boa sorte mano
As a junior developer, I made note that a lot of the comments/suggestions you left on the PR didn't have explanations why lines should be modified, added or removed. Is this something you talk about at length outside the PR to teach your developers why those changes should be made?
Depends on the person and kind of changes. It is expected that juniors ask questions when something doesn't make sense in PRs. If it's very business specific usually people leave in comments, otherwise you're expected to figure it out or ask
@@tejeshreddy6252 That somewhat reinforces my experience. Tech lead often doesn't explain what's wrong, just tells me to change the code. Conversely, one of my colleagues has been really helpful in learning and teaching the way of work in my company. Being personally proactive has helped a ton as well.
It’s not their job to teach you how to approach things. If you happen to have someone that coaches you, then you are lucky. But most of the time they just want to explain things to you so you don’t ask them the same question over and over again.
@@queenofpain6483 Which is why I ask a lot of questions but I try not to ask it twice. Having a written answer helps because I can refer back to it.
As a developer for 30+ years, I wouldn't be this detailed on a PR. I would give a note such as 'Look into changing your mappings. Start with a users mapping, and inside this, create an empty post mapping for registrations and a {id} mapping for users. This would simplify things. Contact me if you have any questions'. Something along those lines. I'd like the junior developer to figure this out and learn something. What will happen when a junior developer sees this PR, they'll just blindly go with his suggestions, not know why. They'll be happy to get an approved PR and move on to something else.
These videos are very good, it would be really cool if they happened more often
that was good! yes, i know it is not very easy to write excellent code, so it is a good idea what you saud in the video and in the code review.
The thumbnail really worked for this lol, I probably overlook all sorts of bad coding practices and redundant or overly complicated code but that no new line eof drives me bonkers 😂
Hey Amigos! Greetings from a fellow senior developer. I have to say I completely disagree with how you did the review. Considering this is a fellow junior engineer, all you did is point where he did the mistake and not why he did it. At the end when you suggested to check if email is taken, you should’ve suggested how. Is that a new func? Is it an ON CONFLICT query? And what if its taken? Would you leak out that information to the client?
I think the most important thing at PR review is the WHY which according to me you failed to deliver
Thank you! We want more code reviews!❤
Assalamu alaikum nelson..You are videos are very useful, Jazhakhalla. Can u put a video about api version and tell some tips for coding like the one you do in code reviews.
the spacing is a company issue not a developer issue. each project should have some form of formatting (ex: prettier) and the dev should have his env set up to format based on what is provided for the project. or just have a pre-commit tool like husky that will auto format the code with prettier. That way no matter what dev touches the code its format stays consistent.
Use a linter that will be helpfull
from experience, I have pre-commit auto-format disabled since sometimes it doesn't do a good job and there a couple of ways to make it work even by its own rules. But yeah, without possibility to use autoformat, life turns into pain
Kudos Amigo! keep doing code review it's eye opening to silly mistakes we can make in our codes
Nice video. I would like to know why returning the whole resource is wrong when creating a resource? In my opinion, returning the whole new resource is more convenient, it can save the consumer to submit an additional request to get the resource. Could you elaborate on the wrong argument? Thanks!
At 1:46
"Develop: In progress
Architecture diagram: In progress
Create ERD: Done
User Stories: Todo"
Designing and building the project before they have any user stories: it's just like at a real company! :shobon:
I found it interesting to see this side of software engineering
I learnt so much from the lesson. God bless you with more wisdom and trying to get one of your course
On your first point, i personally like spacing rtc, however its down to your lint rules. If your project doesn't have lint rules then its not particularly fair to criticize a junior for not following linting. Its the responsibility of the seniors
I agree with the part of not throwing an exception when a resource is not found, unless that exception is handled by the framework and transformed into an 404 http response, otherwise it is more convenient to return a 404 response when the resource is not found.
This video is really great! Would love to see more content with senior commenting on junior code.
As someone who’s coded Java since 1999, I don’t follow regarding the ‘no space’ argument between the ) and {
Just look at the Java source code and it’s ) { and not ){
That’s a poor example of a PR review. That just pisses your colleagues off and adds zero value to the PR.
He told him to add a space not remove it. I think you did a mistake watching the video.
Hi, little suggestion (regarding 7:34 ). We can use a code formatter whatever the IDE we use, right? So those spaces, new line issues can be fixed with that. 😊.
Anyway good to see these kinds of videos and very interesting how you explain them.🥳
Thanks for video, actually pretty fair request for changes in the end
About createUser method. Shouldn't he use some dto / request class rather than entity User class? 👿 Normally we don't want to use entity class as param, right? So something like CreateUserRequest would be preferred 🤔
you're such a great mentor! really appreciated
Since when should a http post request (create) not return the entire entity? You said that the user endpoint should only return the id
Was thinking exactly this. I thought PUT was for creating resources? Also while we're on it, I'm a bit mystified about avoiding returning a user object and instead only returning an id. DTO, sure instead of a bare instance but otherwise seems ok to return a more complete object to avoid additional unnecessary calls ...
what's the reason for only returning the ID instead of the user object?
you have this GET /api/v1/users/{id}
id + HttpStatus is enough response for user creation
Just to point out also using Nullability annotations and formating rules would be awsome as well.
Hi Nelson, Many thanks for the great content. I learn a lot from your channel. Enjoying the code review videos as well, I would like to see more of those too. Greetings from Zambia 🇿🇲.
Thanks a lot. Keep on this series. Extremly helpful
i love these videos. You are an excellent teacher. Thank you
Amazing video, it gave me clear idea about how code reviewer will think. It will help me alot, Thank you.
Review comments should follow a questioning manner rather saying "do this" we can say " can we do this? what do you think? Juniors will take this in a more productive manner. Also complement the good things of the juniors in the code that really boost their motivation.
Quick question shouldn't the API signature be (according to REST)
/users/user/{id}
instead of
/users/{id} -> this case would suggest for me a list of users not a single user
And I agree with people who said such videos of code reviews are indeed a good idea
and a very good practice especially for beginners (but not only) so they can follow certain guide rules - we also can discuss certain points covered by you in the comments and everybody can bring their input from their practice (in that way people may learn something new and the way they were doing things maybe is not the most correct or recommended)
Big thumbs up for this video
No, according to rest /users/id is right
Thank-you, this was so helpful. I agree with everyone else, this idea would make an awesomely helpful playlist.
Learned so many things, Jazakallh Nelson
This was great video. Would like to see more PR process related videos.
That would be a nice you could make a video about how to deal with PR when developers are challenging your suggestions and comments.
Hello, the idea of building a full blown application is amazing. I’d love to be a part of this, please let me know if you need one more Java Developer in the team. Regards!
Great video, I learned that it's better to return ID from a POST resource. 👍🏿
It was interesting, but i think your review lack descriptions. Specifically, why? Why do you need space there? Why should it extend this class and not that? How can you avoid this kind of mistakes later? Yes, you answered some of it in the video, but not everything. These kind of "suggestions" will lead to people either blindling doing the same stuff without even thinking, and thus making more mistakes later, when those "suggestions" are no more applicable; or it will lead to a pointless and rather negative argument later. When i was junior at python, i had my portion of blank reviews with "just to it like that" or "change it". Man, how many hours were wasted on fighting that person, before we could understand each other.
For example, i tend to use type annotations, and the code base was old enough, that was written when they weren't supported. Guy said i must remove them. That's it. Just "remove". Only few weeks later i figured that he was concerned more about code to have the same style everywhere, rather than for it to gradually become more type safe.
Honest question: why use Long with user id over the user object?
+1, still don't understand why returning back user object is wrong.
Return user Object is not a wrong. User Id enough for future reference that's why he suggest to return userid (Long)
In my view using just long with userId have many advantages:
1. is more secure in the sense it doesn't need to provide whole user data to the client by limiting the user information
2. If clients wants then client can use the id to retrieve the userInformation. So it gives more control to the client.
3. Also, in some case the user object might be big or contains lots of data. So returning whole object might effect the performance.
@@nilavkhatiwada2076 Good Explanation bro👍
If you use a user object as result of POST , on next step -> you can compare result with expectation in Int Test (TDD) and can check controller/service/repository and all logic is right, if you use only id you can check only status 2XX or 4XX and all logic in repository you should check by handle ...
Why shouldn't the custom exception extend Exception and make it a checked one? what's the advantage of using an unchecked runtimeexception? I'd rather handle it myself
Why would a user not existing throw an error, wouldn't a simple optional type be better here
As Junior this was very interesting to watch :)
Amazing job!
Great video, can we have please some more details about your mentorship program and maybe a description of the projects we can contribute?
At 5:53, when you added a suggestion for the @GetMapping endpoint, you forgot a “/“.
Very nice video, tho
Approve, Like, Merge
Hey Nelson, As-Salamu Alaykum. I don't understand how the groups with projects works, can you explain it?
I am brazilian software engineer student and this type of project will be amazing for my career. So i am very interesting on this mentorship.
Join waiting list
I think at 14:30, it's more semantically correct to throw a "422 Unprocessable Entity" rather than a "400 Bad Request", as it provides more context to the error.
why put the service and repository as "final"?
Very informative video, would be helpful for junior developers to make all the checks before submitting PR. Can we validate the user data in controller layer, instead of user service implementation for createUser()?
Me gusto mucho este video, se deben de seguir las mejores practicas de ser posible.
The part of making the repository throw an exception when it don't find the user seems excessive to me, it would be similar to a database returning an error when your query didn't return any records. In my opinion it would be more convenient to return a value that represents the absence of a result, like a null object or value.
No HTTP and Rest exist so the appropriate stuscode should be used.
Jazaka Allah kheir , thanks very interessant
this kind of video is very useful, i learned a lot, thanks
we need more of this! thanks!
Wow. This video is amazing, but I have some questions 😁😁
1. Can you use the @Autowired annotation instead of including "final" in the private UserRepository userRepository?
2. That is the difference between the two?
3. When do we use the @Autowired annotation
1. since we use @AllArgsConstructor we're basically doing constructor injection. There's no need to use @Autowired in that case.
2. There's no difference. You could also just use field injection instead of constructor injection.
3. When using field injection, multiple constructors, or @Autowired(required = false) when you don't want to autowire certain parameters in your constructor injection
@@DeGoya thank you!
@@DeGoya I will add one more thing here
@Autowired is considered deprecated and it will not be used in future versions and it's good practice is to use dependency injection via Constructors (especially if the project will suffer an version upgrade in the future)
I usually do it via @RequiredArgsConstructor
@@patrickstorm8334 correct! you can even use
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
When you want to use Lombok, but only autowire certain variables, that are declared with final static.
I do follow you and like your videos. However, I have to disagree on some points like no explaining the reasons of the change (you are explaining them on the video, but the PR author needs to know them too)
Additionally, we need to be as objective as possible and not try to enforce our own style of coding.
ye, I was missing some explanation too, sadly
There was important thing not mentioned, AllArgsConstructor for private final should not be used, it's should be RequiredArgsConstructor, i personaly prefered just make constructor
I like to do this one
@requiredargsconstructor(onconstructor = @__(@autowired))
@@DeGoya if You have one constructor there is no need for that
@@kamilczubaszek6850 yes, but sometimes you want to use regular variables, instead of Autowiring them when using Lombok
Thank you very much!
Could you please do more of these videos? They are really helpful.
would it be a better approach to check for mandatory fields (bad request) immediately in the controller? or maybe it would even be done by spring if you specify the fields in request body object as non-nullable?🤔
You have check it within controller with manual code. Or you could use some library like hibernate-validator etc which would make it declarative. depends on the team
@@blasttrash I thought Spring would automatically respond with 404 if some of the required parameters are missing or have different type🤔
@@andrewdremov2835 parameters could be part of both queryparams or request body(even GET requests can have request body). But that said, for such requests usually people return 400 bad request, not 404.
Since the endpoint that consumers hit, actually exists in our app. Its just that they did not form the full request properly(missing fields or blank strings or null values etc)
I think the service could be an implementation from the start as well, why should the service be an interface? It's against the YAGNI principle
what about creating a video about the testing you mention in the last? thanks.
Can you tell me why not return user object but return user id?
With the request to return the newly created user information, how should it be handled?
Nice video. Thanks
You telling about returning the identifier in the HTTP Post request after creating an entity.
I too return the entity itself . Does it not depend on what the client wants in the response. Could you provide the reason why returning its identifier after the entity being created in the response is a good practice?
Thank you!! :)
ye, I think it depends. Also some subset of entity data may be needed, not whole.
And it's Cyprus, not Cyrous :)
I'm a junior Dev (Java) need a video on runtime exception,custom exception and so on. The chain that connect this exceptions together.thank you
If we are returning id instead of entire resource but we care about performance, wouldn't it be a problem if we make two API calls instead of one?
Actualy it depend of the next steps. If you need to display or edit the entity after creation, it's better to return the full entity. But if you don't, the id is lighter. 2 endpoints can be a solution
8:11 I would request to change the User entity to have 'id' instead of 'customer_id'. Also if they use liquibase or flyway or equivalent to migrate the data. After months or maybe years, nobody will understand why is it customer_id, or they may mix it with a badly written FK
Hi, am a regular follower of your channel.... Just a question... At 12.46, shouldn't the arrow be -> instead of =>
Yeah, you're right
Well done, Nelson Jamal
From nigeria
Hey Nelson. I want to take Microservice and Distributed systems course. What are prerequisites for that course.
I'm on your list and in a fb group. I wonder why I never heard or got notification of your group project?
I've just built my first Spring Boot Backend and this was incredible! Why is it wrong to return the user when its created? Appreciate the content!
Edit: Is it ok to return an ObjectID?
Also interested in the response here. He says it's wrong but doesn't provide a justification. That's nonsense. Returning the Entity it perfectly fine imo. Unless he means that you need to define a DTO and not return the object itself, in which case he is not being clear in his commentary.
Probably don't need all of that data to be returned, just returning the ID is simpler.
@razermoon I unterdtanded it that way also
@@SegNode thank you for the response, had that interpretation from his explanation aswell! But still sparked my interest!
I'd return just an ID, as well. Or a DTO or an abstraction to the real User object. The client usually doesn't need to know every field of the User.
very helpful, i would to join these cohort once i have my finances in order probably end of next year. I have a question re the deletion of code, is it not safer to mark as @Depracated or i am mistaken. thank you for these sessions.
Returning the entity in Controller is bad practice, you should map it to DTO instead and return the DTO.
Brother please doing video that why we should stick with java instead of kotlin
Great video, keep it up 👍
very cool video. I want more of that :)
Excelente, sou Brasileiro e comecei a ver seus vídeos para estudar inglês e programação (nos próxmos eu escreve em inglês rsrs)
I was curious about the thumbnail. What's the deal with the end of the file line?
watching your review motivated me to do the same HAHAHA
Code formatting issues like missing spaces in code reviews seems quite odd. The pipeline should fail on such issues and the developer can fix these before someone reviews the code.
so senior should know the right code , without running it . What if senior missed code mistake in PR review and error happened in production ?
why was 'throws UserDoesNotExistException' removed from controller ?