When I'm doing client work as freelancer I refuse to work in teams without a proper code review process. I want to tell you the reasons but first o...
For further actions, you may consider blocking this person and/or reporting abuse
We don't have code reviews in place yet, but I've been able to convince my manager and colleagues to at least talk about implementing one. Our first meeting to discuss the process is tomorrow, so this article will come in handy. Thanks!
What a coincidence! I will keep my fingers crossed! Would like to hear if your meeting was successful!
I see many articles in dev.to like "I bla bla and you should too!" and I think it's time to stop such article titles.
I am pretty sure you make good points in your article about whatever, but it doesn't mean that others "SHOULD TOO" do whatever you do.
You are a developer, be creative like a developer. Create a better title for your next article, and let's together stop the "..and you should too!" titles :)
I absolutely agree with you! ;)
By the way, it's the first part of your article that caught my attention, and I discussed it with my colleagues today.
I used to have a tough team lead who put a huge emphasis on clean code. By clean I mean "THE BEST COMPACT CODE" you can write. I hated it at the beginning, but then I saw how I hugely improved as a developer and most importantly, the "Impostor Syndrome" from which I was suffering my first 5 years of my career was MAGICALLY gone!
Keep on spreading your message, I am struggling to get heard in my current company, but we have to do it, for the better of all of us!
A good tool for brownfield projects and important code (code with high risk like db schema changes, or that has matured and stabilized and become a dependency of lots of other code). And, I guess, the way you describe it (approx a PR/code review per commit), it's not too onerous.
There are contexts, though, where the cost of code review is high, and the value is low (and sometimes even negative), so don't be too religious about it.
I won't join another team for these same reasons! Great post!
Thank you for your article Manuel!
I review code every day and something that helped our team a lot was having a bit of automatism regarding code review, there are nice libraries and services checking possible errors and standards such as Danger, Codacy or Code climate.
These last two are free for teams of four or less, so it’s easy to start testing them even on private repos.
I'd rather just pair program, work on small increments and forget the ceremony.
Trunk based development for the win.
I would agree here but if you're working with React, it can quickly add up. Let's say you're working with Redux and Styled Components and you strictly seperate everything by file. So for a still relatively simple component you might have changed or added:
That's already 14 files that have been touched (or added) for one single component. So it really depends on what you're working with and how you're working. 15-20 sounds like a lot but it's still okay if the files are short.
Great post bro, i never thought about it but i have been always looking for ways to learn as a one a man team, its always hard to really know what you are doing. Cheers
agreed!
I agree with every point of this article, especially this one No code is ever directly pushed to the master absolutely, no doubt!