The Boy Scout principle and the "don't break it" can be resolved somewhat easily (but enjoyably!) by having adequate code coverage on your unit tests, but it's extremely hard to convince programmers to use unit tests. It's virtually impossible to refactor even fairly simple programs without unit tests, but it's easy to write, rewrite, and refactor even fairly complex programs with unit tests. I personally avoid big refactoring such as splitting or combining classes until I have a better understanding of the information they represent, but I do notice if I just go ahead and refactor then I end up with a much better understanding of the information. I do lots of little refactors, though, but I make sure each path is thoroughly unit tested.
Boy Scouting is hard to enforce. For context: we have over 50 repos, 30+ of those are your regular applications (the rest is configuration, gitops, rollout scripts for our alerting system, documentation, or config backups). So I've built an internal tool to be able to apply a refactoring to all our repos in one go (clone all our repos into a local folder, switch them to a branch, apply a script to all repos, add and push the change, and even open up a PR with one or more team mates to review). Now we can boyscout all out repos in one go.
@@NostraDavid2 sounds like you are applying some automation that performs the refactorings. Is this some kind of AST transformation, perhaps? Just curious as I have written a couple of small ones for single repositories within the last year.
@@NostraDavid2 My biggest concern is convincing people to even use unit testing so refactoring can occur safely, and not the specific process of refactoring. And I can understand their viewpoint as it took about 2 years to convince me unit testing was important, and only because I was required to. It's hard to articulate to others just how important unit tests are, and how they make programming so much easier with much less code breakage. I feel large programs eventually get "frozen" as any small change has large effects, but unit tested programs don't seem to suffer from such problems.
Talking about a book for 10 minutes without giving any information 🙄, just opinions. So how do you look now on those contradicting ideas? You said the book gave you a new perspective, but how? What is your perspective now? And price? You say it's expensive. How expensive? What's expensive for you may not be expensive for me. And yes, I can Google it. But I'm here, now, you're talking about it. Why not just say it?
Thank you for sharing, great insight. I'm entirely convinced to read it :)
Hope you enjoy it!
I am guilty of long pause refactoring. A new book by Kent Beck! Thank you for sharing :)
The Boy Scout principle and the "don't break it" can be resolved somewhat easily (but enjoyably!) by having adequate code coverage on your unit tests, but it's extremely hard to convince programmers to use unit tests. It's virtually impossible to refactor even fairly simple programs without unit tests, but it's easy to write, rewrite, and refactor even fairly complex programs with unit tests.
I personally avoid big refactoring such as splitting or combining classes until I have a better understanding of the information they represent, but I do notice if I just go ahead and refactor then I end up with a much better understanding of the information. I do lots of little refactors, though, but I make sure each path is thoroughly unit tested.
Boy Scouting is hard to enforce. For context: we have over 50 repos, 30+ of those are your regular applications (the rest is configuration, gitops, rollout scripts for our alerting system, documentation, or config backups).
So I've built an internal tool to be able to apply a refactoring to all our repos in one go (clone all our repos into a local folder, switch them to a branch, apply a script to all repos, add and push the change, and even open up a PR with one or more team mates to review). Now we can boyscout all out repos in one go.
@@NostraDavid2 sounds like you are applying some automation that performs the refactorings. Is this some kind of AST transformation, perhaps? Just curious as I have written a couple of small ones for single repositories within the last year.
@@NostraDavid2 My biggest concern is convincing people to even use unit testing so refactoring can occur safely, and not the specific process of refactoring. And I can understand their viewpoint as it took about 2 years to convince me unit testing was important, and only because I was required to.
It's hard to articulate to others just how important unit tests are, and how they make programming so much easier with much less code breakage. I feel large programs eventually get "frozen" as any small change has large effects, but unit tested programs don't seem to suffer from such problems.
Probably, in some time, the term 'tidy' would have same connotation as refactoring
I don't care, I'll buy it because of the cat!
Sponsored by Whiskas 😉
Talking about a book for 10 minutes without giving any information 🙄, just opinions. So how do you look now on those contradicting ideas? You said the book gave you a new perspective, but how? What is your perspective now? And price? You say it's expensive. How expensive? What's expensive for you may not be expensive for me. And yes, I can Google it. But I'm here, now, you're talking about it. Why not just say it?
Portugal mencionado?? The book seems relatively good, but seeing as though it's connected to TDD and Clean code, I think it's gonna be a miss from me
Olá Hugo 😉