• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Five Lines of Code: How do you approach code refactoring

 
Ranch Hand
Posts: 97
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Christian,

How do you approach code refactoring in real world?
Do you do iterations? What do you refactor first and what later?

There are many recommendations of what to refactor and how, but not a guide of how to push the overall effort.

Thanks.
 
Ranch Hand
Posts: 57
1
Redhat Notepad Fedora Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Theoretically speaking you can go on refactoring indefinitely because there is NEVER a perfect code. I think the best way to approach this is to capture all potential improvements (use a keyword in the comments of your code that the entire team will agree on and use, e.g. #TODO:) during the "initial" development sprints. Scrum master/PM should then turn it into lower priority tickets as you go and then have at least one more "refactoring" sprint(s) only for these tickets. This way, you will not go too far and start attacking "theoretical" problems, but identify and fix components that have actually bitten you along the way.
 
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Lucian Maly wrote:I think the best way to approach this is to capture all potential improvements (use a keyword in the comments of your code that the entire team will agree on and use, e.g. #TODO:) during the "initial" development sprints. Scrum master/PM should then turn it into lower priority tickets as you go and then have at least one more "refactoring" sprint(s) only for these tickets.


Ouch. You just described what many practitioners would call an anti-pattern. Refactoring is best done as soon as you get tests to pass, which should be done frequently and incrementally. This (what you described) is more like a way to ensure that refactoring gets pushed to "later when we have more time," which of course you only do when, as you say, you have already been bitten (usually by a P1 in production).

This kind of misunderstanding of what refactoring is is what I was afraid would result from the recommendation to wait until you've written all the code to refactor. In my experience, that "big bang refactoring in the end" approach just gets you in more trouble than it supposedly saves you; it's usually much more costly than  incremental and in-the-moment refactoring.

In my opinion, larger scale refactoring efforts that require their own "tickets" (ugh) should be reserved for legacy code that you have to maintain. Certainly, spending some time refactoring and fencing in legacy code with characterization tests is a good and prudent practice.

This way, you will not go too far and start attacking "theoretical" problems, but identify and fix components that have actually bitten you along the way.


Sure, there's a chance that inexperienced folks get too carried away and get too "theoretical" about what should be refactored and how it should be done but in general, if you keep with the Four Rules of Simple Design, you really only need Rename, Extract, and Compose Method most of the time. Almost all other refactoring techniques are just one or a combination of these three applied to a specific set of conditions. I have found Rename, Extract, and Compose Method to be sufficient for 80% of the refactoring that I need to do "in the moment."
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Five of Lines of Code rule is, I think, a good rule of thumb. If you can more or less follow this rule in your code and keep things reasonably small (again, keeping with the Four Rules of Simple Design, specifically the 4th rule) as you're writing your code then I don't think you'll get too deep in trouble by doing more of a big bang refactoring effort towards the end, before delivering. You'll probably end up not needing that big bang in the end refactoring anyway.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's a Catch-22 in all this though. I think I understand where Christian is coming from with his recommendation to wait a while before refactoring. People with less design/development experience will have a less keen sense of "smell" and will therefore need to see more code in order to discern that they're in trouble, design-wise. You won't refactor something that doesn't smell to you and it might take you more than a few lines of code to get a sense of something being out of whack and that it's "refactor time."

People with more experience tend to sense that things are going south a lot sooner. That's why as you gain more experience and get better at sniffing out code smells, you tend to refactor much more often than less experienced people. I've seen and experienced this in many pair/mob programming sessions. Even renaming things (one of the hardest problems in programming, as Christian also mentioned somewhere) gets easier—this is probably the one thing I spend most of my refactoring time doing. There's a reason why Rename and Extract Method are the main refactoring techniques that IDEs like Eclipse and IntelliJ offer on their menus.

Code smells are hard to master and developing a keen nose for them requires time and experience. The Five Lines of Code is a good way for beginners to smell trouble earlier and start refactoring sooner and more often. I think it's a good way to give yourself an initial leg up but treat it like a "gateway" rule to refactoring.
 
Jorge Ruiz-Aquino
Ranch Hand
Posts: 97
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:larger scale refactoring efforts that require their own "tickets" (ugh) should be reserved for legacy code that you have to maintain.


Junilu Lacar wrote:People with less design/development experience will have a less keen sense of "smell"... You won't refactor something that doesn't smell to you...


I agree with these.
Let's say, there is a legacy-like system with newbie folks working on it making a combination of factors causing more code that need to be refactored.
Newbie folks tend to c&p existing blocks of code to replicate some logic ending with tons of code duplication.
Also they tend even to replicate the old friends "hundreds" and "thousands-lines-method".
However, here is where the "peer reviews" come handy. Hoping that the experienced guy have in mind good practices and the sense of "code smell".

Thank you for these insights from you both.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jorge Ruiz-Aquino wrote:
Newbie folks tend to c&p existing blocks of code to replicate some logic ending with tons of code duplication.


As a newbie on a real-world project, you should have been told that Copy/Paste programming is grounds for immediate termination of employment.

Seriously though, stop making this OK just because you're a newbie. This should be Lesson #1 on Day #1 : Copy/Paste coding, BAD! BAD PROGRAMMER!
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jorge Ruiz-Aquino wrote:
However, here is where the "pair reviews" come handy. Hoping that the experienced guy have in mind good practices and the sense of "code smell".


I think you meant "peer reviews" but "pair reviews" works, too, if you were referring to the instant code reviews that pair programming affords you.

Count yourself lucky if you get to work with an experienced guy who minds good practices and has a keen sense of code smells. In my own (limited) experience, there's a 20% probability of finding yourself in such a situation. More than likely, however, the average "experienced guy" in large corporate settings (not counting the unicorns like NetFlix, Google, Amazon, Spotify, etc.) has practically little to no experience in refactoring or unit testing. In fact, I'd bet that if you brought up this Five Lines of Code to your lead developer, there's a good chance you'll get a strange "WTF you talkin' about?" look back. But then again, that's just me being cynical and jaded.
 
Jorge Ruiz-Aquino
Ranch Hand
Posts: 97
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:As a newbie on a real-world project, you should have been told that Copy/Paste programming is grounds for immediate termination of employment.
Seriously though, stop making this OK just because you're a newbie. This should be Lesson #1 on Day #1 : Copy/Paste coding, BAD! BAD PROGRAMMER!


so true and funny.

Junilu Lacar wrote:I think you meant "peer reviews" but "pair reviews" works, too, if you were referring to the instant code reviews that pair programming affords you.


Yes, my bad. I meant peer review. I updated my comment.


Junilu Lacar wrote:More than likely the average "experienced guy" in large corporate settings ... has practically little to no experience in refactoring or unit testing.


I'm in a large corporate (no-unicorn). So, I plenty agree with you.

Junilu Lacar wrote:I'd bet that if you brought up this Five Lines of Code to your lead developer, there's a good chance you'll get a strange "WTF you talkin' about?" look back.


Challenge accepted.  

 
Lucian Maly
Ranch Hand
Posts: 57
1
Redhat Notepad Fedora Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:I think the best way to approach this is to capture all potential improvements (use a keyword in the comments of your code that the entire team will agree on and use, e.g. #TODO:) during the "initial" development sprints. Scrum master/PM should then turn it into lower priority tickets as you go and then have at least one more "refactoring" sprint(s) only for these tickets.
Ouch. You just described what many practitioners would call an anti-pattern. Refactoring is best done as soon as you get tests to pass, which should be done frequently and incrementally. This (what you described) is more like a way to ensure that refactoring gets pushed to "later when we have more time," which of course you only do when, as you say, you have already been bitten (usually by a P1 in production).

This kind of misunderstanding of what refactoring is is what I was afraid would result from the recommendation to wait until you've written all the code to refactor. In my experience, that "big bang refactoring in the end" approach just gets you in more trouble than it supposedly saves you; it's usually much more costly than  incremental and in-the-moment refactoring.

In my opinion, larger scale refactoring efforts that require their own "tickets" (ugh) should be reserved for legacy code that you have to maintain. Certainly, spending some time refactoring and fencing in legacy code with characterization tests is a good and prudent practice.

This way, you will not go too far and start attacking "theoretical" problems, but identify and fix components that have actually bitten you along the way.
Sure, there's a chance that inexperienced folks get too carried away and get too "theoretical" about what should be refactored and how it should be done but in general, if you keep with the Four Rules of Simple Design, you really only need Rename, Extract, and Compose Method most of the time. Almost all other refactoring techniques are just one or a combination of these three applied to a specific set of conditions. I have found Rename, Extract, and Compose Method to be sufficient for 80% of the refactoring that I need to do "in the moment."



Can you please provide a legitimate source for your statement that this is an anti-pattern? I worked in some fast-paced agile environments and immediate refactoring was always perceived as a "waste of the development time" and "not adding any features while there are deadlines to meet". It would be nice to hear what is Christian Clausen's opinion of this...
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
https://www.scrum.org/resources/blog/can-you-find-3-smells-i-added-refactoring-story-next-cleanup-sprint

You might also get a sense of how and when refactoring should be done from this conversation with Martin Fowler. It's quite a long video and the relevant ideas are scattered throughout the length of it but if you listen carefully and collect the bits and pieces, they pretty much add up to the same conclusion that refactoring is best done as and when you're adding small increments of functionality.

Actually, go to the 36:46 mark of that video where Martin Fowler specifically addresses the question of "refactoring doesn't add features."
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Lucian Maly wrote:I worked in some fast-paced agile environments and immediate refactoring was always perceived as a "waste of the development time" and "not adding any features while there are deadlines to meet".


That is about the most un-agile statement about refactoring that you can get. I would correct that typo: "some fast-paced agile environments and immediate refactoring ... "

I'd refer you to other authorities on refactoring like Kent Beck, Bob Martin, Martin Fowler, Ron Jeffries, Michael Feathers. None of these authorities would agree with the statement you just made. Read and understand Fowler's book on Refactoring.

Just about the only situation where you'd have significant refactoring effort that has to be planned that is in line with these folks' approach would be that of dealing with legacy code. If you're developing new code, the recommended approach is to refactor as you go.

The perception of "waste of development time" is largely because of people's inexperience and inability to refactor effectively. This is exacerbated by the short-sighted attitude that refactoring "does not add any features while there are deadlines to meet."

Christian has some great pointers in his book but the idea that you would delay refactoring until you're ready to deliver is just not in line with the approach recommended by other experts in the field. That's pretty much like closing the barn door after the horse has run out.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I realize that the idea of refactoring as you go seems counterintuitive to many people. However, I'd encourage you to watch Ward Cunningham's short video where he explains The Debt Metaphor.

If you listen carefully to what he says, you'll realize that "debt" is really a lack of understanding on the programmer's part which is also reflected in the code. Think about it for a minute: what is easier to clear up, a small misunderstanding or a big misunderstanding? If you've done development for any significant amount of time, you should understand that the sooner you address a problem, the easier it is to fix. Otherwise, that problem will have other problems piled on top of them, complicating and compounding your problems. The longer you wait to start fixing problems, the harder it becomes to fix them.

Bob Martin summarizes the philosophy well with "The only way to go fast is to go well."
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I will concede, however, that there may be valid business situations where the business can tell developers to forego refactoring. For example, if you have an urgent problem that needs to be addressed ASAP to avoid significant impact to the viability of the business. If you have a production problem that could significantly impact your customers, your reputation, or just needs to be fixed RIGHT NOW otherwise your business loses significant amount of $$$, then sure, skip refactoring and just fix the darn thing. If you're operating in lean startup mode and just trying to get quick experiments out to market to test the waters so you can get your next round of funding then sure, skip refactoring. In these cases, as Christian mentioned somewhere this week, refactoring now becomes a business decision.

However, for long-term success and sustainability, accumulating debt becomes a liability that can lead to an inexorable downward spiral -- cleanup sprints and waiting until the end of the sprint to refactor are bad practices that you should avoid because they'll just put you into that vicious cycle a lot faster. In these cases, refactoring is the programmer's business and it's their decision because it's part of their job to refactor, just as it's part of a surgeon's job to make sure he doesn't leave a pair of clamps in your abdomen when he closes you up and it's a mechanic's job to tighten all the screws in your engine after he's done maintaining it. Imagine a mechanic telling you he'll get all those loose screws the next time you come in for a 30K mile tuneup.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Lucian Maly wrote:Theoretically speaking you can go on refactoring indefinitely because there is NEVER a perfect code.


The FLoC rule is actually a good way to tell when you can stop refactoring in many cases. My absolute limit in terms of lines of code is zero. That is, I've moved every single idea out of the method and have shown that it was either a redundant idea in the first place and eliminated the duplication or that I have discovered a better way to organize the different ideas in it through a series of extractions.

And no, you shouldn't strive for perfect code. That's one of the biggest sinkholes of time. One of the guidelines I've come to adopt is "Don't let perfection be the enemy of good enough."

Just about the only time you should strive for perfection is when you're practicing and trying to hone your skills. For that I have another guideline: "Practice only makes habit. Only perfect practice makes perfect."
 
Marshal
Posts: 70234
282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . My absolute limit in terms of lines of code is zero. . . .

You mean you have never written a method with −1 lines in?
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:You mean you have never written a method with −1 lines in?


Dunno, depends on how you count negative lines of code I guess
 
Campbell Ritchie
Marshal
Posts: 70234
282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Same way as you count positive lines, but negatively.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To OP's question about approaches, I'd say there are a few different cases that call for slightly different approaches to refactoring:

1. Adding new features
2. Fixing a bug discovered not discovered during the course of initial development. That is, you thought you were done but somebody else found a bug.
3. Dealing with legacy code.

Michael Feathers has an entire book dealing with #3: Working Effectively with Legacy Code otherwise known as the WELC book. It includes topics on seams, characterization tests, sprout classes and methods, pinch points, and many more curiously-named but useful approaches in refactoring legacy code. Get the book and master the techniques in it. It was a lifesaver when I was maintaining legacy code.

For #1, there are two subcases: Adding entirely new features (green field development) and changing existing behavior.

When adding entirely new features, I really recommend refactoring as you go. It doesn't necessarily have to be in the TDD cadence of Red-Green-Refactor but refactoring is best done while the code is still fresh, while it's still soft and pliable. As code ages (think minutes and hours, not just days, weeks, or months), the design around it starts to harden if you put off refactoring for very long. A poor decision can lead to more poor decisions and poorly-factored code gets coupled to more poorly-factored code which is coupled with yet more poorly-factored code and so on. Pretty soon, you'll get a big, hard Ball of Mud that's practically impossible to work with. So refactor while the "clay" is still wet and soft and keep shaping and forming/reforming it as you go.

If you're trying to add a new feature to existing code and finding a hard time figuring out how to do it without creating a mess, the advice given by Beck, Fowler, and others is to first refactor the code so that it's easy to add the new feature. Again, there are many specific scenarios that fall under this category but I always go back to Beck's Four Rules of Simple Design. Refactoring code so that it adheres to these 4 rules usually gives me enough insight into the code to understand how it can gracefully take in the new feature.

For #2, my first step is to write a failing test to demonstrate that the bug can be reproduced. This not only helps me understand the context in which the bug manifests itself, it's also a great way to pinpoint exactly where the fix needs to go. Once I have a test that reflects what I understand to be the proper behavior, I'll refactor any code that I think caused the initial misunderstanding in the first place so that, as Ward Cunningham explained, the code will then reflect my newfound understanding of how it should work.

 
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Such an interesting discussion!

There are so many points I would like to comment on, so I will probably miss some.

How do you approach code refactoring in the real world?



Firstly, in the real world, I always treat the team as the only method of delivery, which means that the biggest refactoring effort comes from talking with the team, and deciding on a common level of quality, and then holding each other to it.

That being said, if by "real world" you mean I start with a large chunk of unrefactored legacy system, then I have two answers depending on the context. If you are about to make a change in the legacy code, my answer would be to do refactoring before implementing changes. It comes from the Kent Beck quote:

First make the change easy, then make the easy change



I have a section about that in the book: https://livebook.manning.com/book/five-lines-of-code/chapter-1/v-2/point-8551-54-54-0.

If on the other hand, you are just annoyed that the legacy system slows you down, then I discuss this in chapter 9 (which I am working on now). First I isolate the legacy code, then I add monitoring, so I can see which parts are being used a lot, and which not at all. Then, because I like easy decisions, I start with the most and least used parts, and either eliminate, refactor, or rewrite them. Note: this is simplified, but you can look up the detailed version in the book in a month or so.

And everything is iterations in software, the shorter the better.

there is NEVER a perfect code



Actually, I like to say that code can be perfect for a specific change, that is some change is as easy as possible. This means if you know the direction the software is taking, then the code can be perfect for that. Of course, in practice, the direction is not entirely known, and also changes. But based on this principle I tend to spend more time refactoring parts that change often.

"refactoring" sprint



Please don't do these, they will be a nightmare, both from all the merge conflicts, but also for the customer who does not see any value. Another problem with this, following what I write in the book, is that we can only deliver (push to master) once our code is refactored, so putting this in a separate sprint means we cannot put any code on master before this sprint.

there's a chance that inexperienced folks get too carried away and get too "theoretical"



I totally see where this is coming from, however, people grow so much doing this. Going crazy and making some small piece of code (like the guilded rose kata) totally gold plated, refactored over the top is an excellent exercise. Once or twice. Of course, we should not spend all our time doing extreme gold plating, some things will never change once written, and therefore require no refactoring at all. But there is a lot of learning and growth in doing it a few times in the beginning.

Rename, Extract, and Compose Method



These are definitely powerful, but I am missing something that introduces classes in this: Replace type code with classes, introduce strategy pattern, encapsulate data.

his recommendation to wait a while before refactoring



I just want to clarify that I only mean wait until you are ready to push your code to master, which I think you should do every day. This is because while we are writing the code it is often quite fluent which means we can change data structures or approaches easily. I don't want to refactor the code to support some algorithm, if I then change my mind and have to undo the refactoring. Only once I have the desired functionality mostly locked down I start refactoring.

Copy/Paste programming is grounds for immediate termination of employment



I know this is a joke, I just want to go on the record and say: there is a place for c&p while working, just not when you deliver (push to master). It is a super quick way to get something up and running, and refactoring should remove the duplication anyway. Copying something you don't understand should be grounds for termination.

I think you meant "peer reviews" but "pair reviews" works



I love synchronous peer review (ie. pair or mob programming). However, I am not a fan of blocking peer review (ie. pull requests), because they prevent continuous integration, which causes bad merges, and longer lead time. But this is running off a tangent far from refactoring.

the average "experienced guy" in large corporate settings [...] has practically little to no experience in refactoring or unit testing



This is what motivated me to contact Manning.

Challenge accepted



Let me know how that goes, I am very curious!

capture all potential improvements



Not all improvements are cost beneficial. One of my common pet peeves is when people show me some highly optimized code, which has become completely unreadable in the process. I have to be pragmatic in my job, so I usually say that improvements should be guided by usage statistics. Notice, having a well-refactored code base is not an improvement, it is a necessary condition to keep high velocity, and therefore should be part of developers daily work.

delay refactoring until you're ready to deliver is just not in line with the approach recommended by other experts



If you consider that by deliver I mean the change (ie. push to master), not the product, then I don't agree, the approach I recommend nicely aligns with other experts' approaches, in particular red-green-refactor. I just added a few more steps, like push to master, spike, and work, which were all present although implicit in other approaches.

there may be valid business situations where the business can tell developers to forego refactoring



Like if the software is scheduled to be decommissioned.

then sure, skip refactoring



* delay, not skip.

accumulating debt becomes a liability



Here I take Robert C Martin's opinion: a mess is not technical debt. Reference



 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:

"refactoring" sprint

Please don't do these, they will be a nightmare, ...


Yes, they are. I'm glad we agree on this.

But more importantly, refactoring sprints are not as effective as programmers optimistically think they would be and they tend to discourage further refactoring efforts. It's very much like how putting off writing unit tests tends to make unit tests more difficult to write and thus discourages programmers from actually writing unit tests at all. Timeliness in doing these two things is critical. The closer they're done to the time you write the production code, the better.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:Copying something you don't understand should be grounds for termination.


Also known as "StackOverflow programming."

Not understanding what you're copying is definitely not a joking matter. It's also where a lot of security-related problems come from.

I love synchronous peer review (ie. pair or mob programming). However, I am not a fan of blocking peer review (ie. pull requests), because they prevent continuous integration, which causes bad merges, and longer lead time.


Another thing we agree on!    

Also known (at least to me) as "offline" or "asynchronous" reviews, they do still happen. The trick is to limit their scope to things that can quickly be resolved with minimal impact, like say not following coding conventions or things that need a more high-level perspective to discern/address like maybe some kind of impact to the overall architecture or performance.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:
I just want to clarify that I only mean wait until you are ready to push your code to master, which I think you should do every day. This is because while we are writing the code it is often quite fluent which means we can change data structures or approaches easily. I don't want to refactor the code to support some algorithm, if I then change my mind and have to undo the refactoring. Only once I have the desired functionality mostly locked down I start refactoring.


Maybe you meant "quite fluid"? Yes, this sounds much more reasonable to me. I was concerned you were advocating for a more "Dos Equis" approach, i.e., "I don't always refactor but when I do, I do it just before going to production."
 
Campbell Ritchie
Marshal
Posts: 70234
282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . StackOverflow programming. . . . .

Hahahahahahahahahahahaha! That is SO funny.

Joking aside, we do appreciate the effort you have put into answering questions, CC, beyond the call of duty, and as I said last week, we have had some very interesting dicussions.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:Firstly, in the real world, I always treat the team as the only method of delivery, which means that the biggest refactoring effort comes from talking with the team, and deciding on a common level of quality, and then holding each other to it.


Same here! We really do agree on quite a few things.
 
Junilu Lacar
Marshal
Posts: 15876
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

. . . StackOverflow programming. . . . .

Hahahahahahahahahahahaha! That is SO funny.


I see what you did there...
 
Christian Clausen
Author
Posts: 31
8
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Same here! We really do agree on quite a few things.



I think we agree on most things about software development, Junilu, you seem very knowledgeable and we share a lot of the same references. We share the same values, we just have different ways of teaching them. Your way is right for some people, and I hope mine is for some as well.
 
Lasagna is spaghetti flvored cake. Just like this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic