دانلود کتاب به نظر من خوب میاد -بررسی‌های سازنده کد

Ah, code reviews! We need them, but we dread them. We do them, but not well. And despite the tools we have at our disposal, we still manage to mess things up. How do we deal with gigantic PRs? How do we make code reviews shorter? Why can’t we write effective code review comments? Is SSDaaRB (Single Senior Developer as a Reviewer Bottleneck) something we just have to accept? Are we doomed to debate with our colleagues over technical implementations? Will code reviews always be like this? These questions (and plenty more) are the matters that I gravitated toward in my now 12-year career. I’ve worked on teams that had no code review process at all. I’ve worked on teams that had a process, but it was barely enforced. I’ve worked on teams that had a wonderful process. And I’ve worked on teams where the process made me want to pull my hair out because it was so tedious. As I gained knowledge in those roles, both in technologies and team processes, I couldn’t help but return to those questions. Looking back, I realized a big part of whether I enjoyed working with certain teams was whether our code review process was amicable and effective. Yes, you write code when you become a professional software developer, but you spend way more time reading and making sense of it. You also spend a lot of time reading code you didn’t write! This realization made me look at code reviews in a different light. More recently, I’ve been earning pretty pennies as a developer advocate, focused on teaching developers how to do “developer things” well. I accidentally fell into this role, but I’m glad I did; my software development background (and apparent skills in public speaking and written communication) really helps in creating technical educational content that shines. A big part of that is because I like to focus on what I believe are essentials—things that we tend to forget or assume that everyone already knows in the software development industry—and teach them in an approachable way. When Manning asked me what topic I would want to write about, given the chance to choose anything, the choice was absolutely clear: code reviews. Are there other resources on code reviews? Absolutely. Do other developers have insights that may relate better to you? Guaranteed. But one fact remained: there is no “official” or single, comprehensive resource on code reviews, not in the way I imagined. I wanted to answer the questions I previously mentioned. I wanted to focus on the code review process and the team dynamics that surround it rather than list out code smells to watch out for (that would be a huge book if I accommodated everyone). I wanted to share all the insights, experience, strategies, and tactics I’ve learned and collected throughout my career to build a better code review. And I wanted to do it in a friendly, approachable way. I wanted to be THE book on code reviews. So that’s what I did. Now that you’re reading this labor of love, I’m excited to guide you through the human side of code reviews. I want you to do better than LGTM . I want your code reviews to be great!