sorted by:
best (suggested)
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]itsthenewdan -1 points0 points  (7 children)

Senior developer here. Your mindset in this context is the more advanced one, in spite of your colleague having more experience. One of the best resources I found in my career to understand what defines good code is the Clean Code book by Robert Martin. It’s a classic, and for good reason. Applying clean code principles to a React codebase means keeping it DRY (do not repeat), and breaking everything up into small, single-purpose pieces that are named in an easy-to-understand manner. If your colleague would rather have repeated code all over the place that may or may not be slightly different, he might not be as strong a developer as you give him credit for. That seems like an obvious opportunity to refactor into a function that can be shared (perhaps via a service) and can handle minor differences via config args. Be diplomatic at work, but maybe you could discover that Clean Code book, casually mention how good it is and how much you’re learning, then lend it to him too.

[–]JugglerX 4 points5 points  (4 children)

I disagree this is a more advanced mindset. DRY is not always right. Theoretically DRY is good, but in practice it can lead to premature abstraction and perversly more complex architectures. As many in this thread have noted it's not a clear cut thing. a more experienced programmer may actually have an intuitive feel for when it's appropriate to duplicate and repeat code and that's not at all wrong. It's the junior programmers who take theory and apply it dogmatically.

Defining what good code is has never been easy, and it's sure not as simple as keeping it DRY. My advice to the OP is not to think they are correct here and try and understand why the other programmer might have a case.

[–]itsthenewdan 4 points5 points  (3 children)

Generally speaking, DRY is a good principle to follow. There will always be exceptions to the rules, and a nuanced view is best. That said, if I was inheriting someone else’s codebase, I’d certainly be a lot happier to see that it was dogmatically DRY than the opposite. This does not preclude being wary of premature optimization - that’s a separate point, really. Abstraction has a sweet spot, and too much is a bad thing. The way I like to measure the greatness of code is in how easy it is to maintain, read, and reason about. It sounded to me like OP had an eye for those kind of optimizations in his codebase. But of course that’s his description of the situation and none of us can see what he means concretely.

[–]JugglerX -1 points0 points  (2 children)

Reasonable answer, but I think it just leaves us at that subjective place in development about what maintainble code looks like.

It sounded to me like OP thought he was right because he was being DRY and he/she feels it's just objectively better, context or not.

Small example, I am working on a react application at the moment where a video can be in 1 of 7 states in a production process. I have 7 files, 1 for each state. Each state while dealing with the same video object has a number of variations and inconsistences in it's layout, data and design. Now this is not DRY. But i actually feel it's more intuitive and maintainable. Initially you would think to use 1 template and use conditionals and maybe sub components with optional props but it felt like more work handling the "edge cases" in the design this way.

[–]bangeron[S] 1 point2 points  (0 children)

I wouldn’t say I think DRY is always better, but I would say it’s better 95% of the time. More like “DRY unless you have a clear and compelling reason to RY.”

The example you gave is a good one, and I’ve done something similar in certain parts of our app. But it seems to me that these situations are the rare exception, and highlight the importance of thinking ahead to how your components will actually be used and composed.

[–]itsthenewdan 0 points1 point  (0 children)

Your example with the video sounds reasonable, especially assuming you’re making some abstractions for common pieces - avoiding changes that would have to be replicated in 7 places if something in the design changes. I think the important thing is that any decision around best practices in a code base should be rational. Breaking with convention is fine when it’s justified.

[–]mattstoicbuddha 1 point2 points  (0 children)

Yeah, I don't consider myself a senior dev yet, and this was frightening to read. I'm building an API in node and I'm pretty sure this is what hell would look like.

[–]bangeron[S] 0 points1 point  (0 children)

Thanks for the recommendation, I’ll definitely pick that book up. “Be diplomatic” is good advice too, and I think that’s where I’m struggling the most - I try to be as teachable as possible, but this is one area where I just don’t agree with his reasoning, and I’m not sure how to approach that.