It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
His concern is that when we introduce many small commits over time, it becomes difficult to review the feature in its entirety to make sure the code is consistent and works with all of the previous pieces of code that were introduced. My position is that automated testing directly addresses his concern. It will become apparent pretty quickly if new code is incompatible with previous code, based on the automated test results.
Your colleague is correct to be concerned about this, and you're talking past him. Automated testing helps you catch unintended consequences of changes. He is worried that breaking up a complex change into multiple commits to meet an arbitrary length limit, especially if those commits are integrated and released individually, will make it more difficult to ensure that the change itself has been implemented correctly and completely -- which it absolutely will. When you say "automated tests will save us!" he smells bullshit, and, to be blunt, he's right.
Bite-sized commits are much easier for a reviewer to digest, and allow the reviewer to focus on style, readability, etc..., instead of whether the code wors properly.
Keeping commits small is a worthy goal, but not always a reasonably attainable one. A better criterion: one commit = one change, whatever the length of the diff. Rebasing and squashing make managing this as easy as rebasing and squashing ever are.
You will at some point, despite the absolute best of intentions, have to land a very large, complex change. It's going to be a pain to review. Your workflow needs to be able to accommodate it. And if you're going to sell your team on CI/CD being part of that workflow, there needs to be less busywork for them with CI/CD than without.
I'm a software engineer working in the intellectual property space. When I'm not at work, I'm at home with the family which includes a wife, son, two cats, guitars, and a varying number of banjos.
First, let me correct any impressions that I'm going to force this change on my team without taking into account any of their concerns. We had a long discussion about this and I absolutely said his concerns are valid and I that would do some research into how we can find some kind of middle ground that would work for us all. I actually make it a point to listen to and empathize with my teammates, because every concern they have, everything they are feeling as a developer, I've also been there.
I've also never been one to say that automated tests are some kind of magic bullet, and am still a vocal proponent of having a QA person on-hand to test for correct application behavior or regressions.
I can see how in my original post, I may have come across as some authoritarian who imposes policies as I please without considering the concerns of others. That's not the case, but I regret that it may have come across that way in my attempt to be concise.
Having said all that, the feedback is appreciated.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your colleague is correct to be concerned about this, and you're talking past him. Automated testing helps you catch unintended consequences of changes. He is worried that breaking up a complex change into multiple commits to meet an arbitrary length limit, especially if those commits are integrated and released individually, will make it more difficult to ensure that the change itself has been implemented correctly and completely -- which it absolutely will. When you say "automated tests will save us!" he smells bullshit, and, to be blunt, he's right.
Keeping commits small is a worthy goal, but not always a reasonably attainable one. A better criterion: one commit = one change, whatever the length of the diff. Rebasing and squashing make managing this as easy as rebasing and squashing ever are.
You will at some point, despite the absolute best of intentions, have to land a very large, complex change. It's going to be a pain to review. Your workflow needs to be able to accommodate it. And if you're going to sell your team on CI/CD being part of that workflow, there needs to be less busywork for them with CI/CD than without.
First, let me correct any impressions that I'm going to force this change on my team without taking into account any of their concerns. We had a long discussion about this and I absolutely said his concerns are valid and I that would do some research into how we can find some kind of middle ground that would work for us all. I actually make it a point to listen to and empathize with my teammates, because every concern they have, everything they are feeling as a developer, I've also been there.
I've also never been one to say that automated tests are some kind of magic bullet, and am still a vocal proponent of having a QA person on-hand to test for correct application behavior or regressions.
I can see how in my original post, I may have come across as some authoritarian who imposes policies as I please without considering the concerns of others. That's not the case, but I regret that it may have come across that way in my attempt to be concise.
Having said all that, the feedback is appreciated.