No 10 "Testability is correlated with good design." is underrated.
No 8 "Designs get stale." is something juniors don't get.
No 7 "Copy-paste is OK once." is not totally true. It depends. But saying "create a good enough abstraction" is just wrong. Extracting something to a function DOESN'T mean you make an abstraction. The word "abstraction" is loosing it's sense nowadays. Interface is not an abstraction. Creating a module that hide complexity and exposes a simple api - that's abstraction.
Disagree. The term "abstraction" is the general one here that applies to everything. Pulling instances of code out and replacing with a function for it absolutely IS "abstraction." Your argument is backwards. You don't have to be using an existing object-oriented pattern or have an API to call it an abstraction. I can't think of a single programming language that uses the keyword "abstract" .... waaaait. Yes I can. C++ and C# use that don't they. But THERE it has a specific meaning and it is rigidly defined.
Abstraction is something that hides complexity. If COULD be a function, a class, a module, a subsystem. But if you just pull some code out in sake of DRY, it doesn't have to be abstraction. In most cases every details of the implementation LEAKS from it.
A programmable Socket is an abstraction over huge complexity of the network. Your exaples are leaky, poor abstractions that doesn't fight complexity, just code duplicatin.
Agree to disagree then. I hate how in Las Vegas every hotel on the Strip is all "suites" now instead of just "rooms". A suite used to specifically mean a hotel room w/ a separate 'room' for the bed. Now I'm not sure how you get that in Vegas, because the word that used to represent that has been devalued.
I think there's a little more to it than that. Hiding complexity is one motive/type (or even side-effect) of abstraction. But I believe it's import to note that abstraction is primarily about generalization and that concept applies anywhere. Like you said, it *could* be a function, class, module, etc.
What is the *goal* of Rule #7? I think we're all on the same page here, we're just disagreeing about what we call it?
However he also advocates for Mocks. Mocks are the salt water for the thirst of testability. Sure they help, but rely too much on them and sooner or later you will start pissing blood.
I’m trying hard to get into No 8. Software is abstract and extremely malleable but it’s so easy to stick with something you wrote as sunk cost. Tearing it all up to improve it should not be as painful as I feel it.
When copy-pasting, ask yourself, "is this actually doing the same thing?".
Sometimes, two data structures are similar, but not the same and unrelated. The copy pasted code will change independently. Any abstraction you write for it will eventually tear apart.
Sometimes, two data structures are the same deep (or not so deep) down, and you can abstract over this same-ness.
I wasn't discussing if there's a sense in using or not DRY.
My objection is for using the word "abstraction" or something that is a simple language construct. Even if you use an interface, it not necessary will be an abstraction.
I agree with the first stmt in no 10, but making it easier to mock is not making it testable, it is making it coupled and is the opposit of no 8 - stale designs.
For me testable is making decoupled componentd that is easy to test.
Hi, did you mean to say "losing"?
Explanation: Loose is an adjective meaning the opposite of tight, while lose is a verb.
Sorry if I made a mistake! Please let me know if I did.
Have a great day! Statistics
^^I'm ^^a ^^bot ^^that ^^corrects ^^grammar/spelling ^^mistakes.
^^PM ^^me ^^if ^^I'm ^^wrong ^^or ^^if ^^you ^^have ^^any ^^suggestions.
^^Github
^^Reply ^^STOP ^^to ^^this ^^comment ^^to ^^stop ^^receiving ^^corrections.
With number 9 I’d also add a cost dimension. There’s tech debt where things were done at high cost so it could be done quickly or a migration half done that’s causing resource duplication, and addressing them will save money.
Absolutely agree, but you can kind of squeeze them into the three categories.
That said we are currently working on a noSQL DB that is completely balls to write for, in it, that like two people in company know to use without bringing it to a halt.
We could switch to version 7 that helps us use JPA and not having to worry about each little operation, but according to that list it's in the third category. Because it might stop us doing something.
Good write-up. I agree with most of them. A huge one for me is to "just walk away". What I mean by that is, when I get hung up on something I usually tend to keep grinding at it for hours. But I have found that when I get up and walk away, take a short walk, shower, etc, ....I come back and fix it within minutes.
Write unit tests. I never really bought into test first (Where you write the unit tests before you write any code) but I keep getting closer and closer to actually doing it. Sure, your initial velocity might go down, but your error rate and regression rate will also trend toward 0. And if you also write unit tests to replicate reported bugs before you fix them, you'll never have a regression for that particular bug again.
I see a lot of attitude among many of my co-workers that they're too busy to write unit tests. I'm too busy to not write unit tests, and all my estimates these days include them.
ETDD - eventual test driven development. There will be tests, but the tests will not be written first, it will be written eventually during, but before the pull/merge request has been created.
yeah my experience has me trending towards that as well. I cant write tests before I write code, because writing code is part of the thinking process for me. But as I figure out what structure the code should take, I can figure out what the tests can and should look like and use them as insurance against myself.
I write things inline, with exceptions for data structures. In a theoretical sense, our only argument to the function is the current continuation - latest versions of local variables, parameters to the caller, and global variables. Tests come after I can put an interface on it.
A recent project I was on the unit tests were contractually obliged by a government agency and we were writing them two years after the original code was written. And every object in their code base was a singleton.
Good call. In game dev, this is done less. But it should be done. It's a lot easier to prove what the bug is, if you have a test program with a clean address space. I fixed a typo in my intrusive red-black tree. It's a lot easier than also debugging the Vulkan memory management code at the same time. The memory management looks simple, but it is actually correct? Callees have the constraint of being bug free.
The initial velocity drop is a pain to get over, though. A bunch of my coworkers will cut tests when product asks how we can get something shipped sooner.
Bad dev smell. To me development includes tests and, when relevant, testability (e.g. being able to inject an event via REST). It’s what I do, not coding with optional tests.
Remember, the ones asking you to do things don’t know how to do it themselves so why should they have a say?
I find writing code without having unit-test infrastructure too be painful. It's just a pain in the a** to write some algorithm, having to deploy it in some test environment and reproduce the issue every time. Instead I can just have unit tests ran in 1-2s and think about that long process in the end when the code is ready.
Unit tests are a good idea because 90% of the time, they make things easier right away. ...99% of the time, they prevent something from breaking later. ...But 100% of the time, they mean I don't have to think about it anymore
You know, as I get older, and all that sort of stuff becomes second nature, I've come to realise one of the most important ones that no one ever mentions is:
Get a good nights sleep beforehand. If you're operating on 4 or 5 hours sleep as you've been up all night doing something fun, don't bother doing any work the next day. You'll just have to redo it properly anyway.
How do I move through this politically ob my team? I don’t know how to communicate or “ask for a break” without being seem like I’m just avoiding work. I wont have any update for a standup the next day, which puts a pressure on me to do something just for the sake of seeming like im not slacking off.
I work on 4-5 hrs sleep a lot lately and the results are often very low quality or sometimes I just end up my day not producing any value just fiddling with calls emails because I can’t really concentrate. I feel like I need to be online and produce something even tho I know that it’s affecting my long term productivity over a period of time.
Small breaks may be a useful substitute if you really couldn't get enough sleep (or even otherwise). You should implement a 5' break in each hour of work, where you stand up, walk, breathe, drink.
Nah sorry dude, but the DRY experiment is well understood to have been a massive failure.
You should prefer to copy and paste over abstracting. The reason for that is because as good as you may think you are at predicting the future, you aren’t. You suck at predicting the future, and copy/paste handle your bad predictions better.
the DRY experiment is well understood to have been a massive failure.
Lol, since when? That's like, your opinion, man
copy/paste handle your bad predictions better.
That's where you're wrong. Abstraction is easy to convert to copy-paste. The converse is not.
The problem with your mentality is it is fundamentally opposed to abstraction. It's an anti-abstraction movement being pushed by people who aren't good at abstraction. That's my impression. It's a collapse of the entire framework for good programming. Why ever create a function when you can just copy paste code everywhere? It's absurd
I do assume that, and I will continue to assume that.
Every talented engineer I’ve worked with has easily been able to identify abstraction as one of the most powerful but dangerous tools.
The engineers who do not respect the gravity of abstraction have been grifters in my experience. Coincidently, you happen to also speak like a grifter.
Your code is probably more dog shit than you realize.
This is a very common misunderstanding. DRY as a god like rule has been the cause of so much needless abstractions since it was espoused as the cardinal rule
I think the problem with abstractions is that people use it to reduce code duplication. That's not what abstractions are for. Abstractions are for cutting complexities into multiple parts, where each part is simpler to understand and easier to test. A bad abstraction - one designed with only code deduplication in mind, will cut a complexity of 100 into 50+50. Or maybe 25+25+25+25, or any other similar combination depending how many duplications are you are removing. But a good abstraction will turn it into 10*10.
If the abstraction is not something that makes sense to do even if you only had one instance, don't do it just because you have 3 instances. Never follow DRY unless the thing you deduplicate also satisfies SSoT.
Yeah. It also depends on the number of people working on the code. Copy & paste works very well for a long time if you have a small and stable number of people.
I have seen copy & paste leading to bugs in large and old code bases, where the bugs were annoying to fix, and the bugs had already done harm.
If the developers before you looked at code, and decided that it was easier to copy & paste a function elsewhere instead of refactoring it and reusing it, you might eventually end up with 10+ copies with different and buggy behavior, even though all the copies were supposed to do the exact same thing.
Also, if you want to fix a bug in one copy, and you are not aware of the other copies, you might end up fixing it only in that copy. And if you are aware of the other copies, you have to spend more time finding the copies and fixing the same bug in all those copies, relative to if there was only one copy. And that can mean developers wasting a lot of time over the years debugging, finding and fixing the same bugs, just in different copies.
The right decision in such a case is typically to refactor the function, even if code has to be reorganized. It may also be a sign of issues with architecture, if code is not easy to reuse.
I do agree that if you have two functions, and they are supposed to do different things, copy & paste followed by modification can be the best option. Sometimes, refactoring slightly common functionality does not make sense. But copy & paste has to be done with care. A rule of thumb could be that if two functions are meant to do the exact same thing, they should be refactored into one function.
I think the takeaway is that don't be overly redundant. Myself I have been through both pain points where the overly abstracted code base makes things extremely inflexible if the architecture isn't on point which can and will happen (how can you predict the future of the business logic changing down the road etc...).At the same time you touched on the idea that if you have 2+ copies of functions then having to hunt them down is just huge pain in itself also
so really your last sentence is what people should strive to do. Use common sense. Multiple copies of functions that do the same thing will result in potentially the same issue has having multiple values that rely on a reserved value where if you need to change that one value then you need to go hunt all instances of that value vs just having the value being defined in a prop file or something so you just have to change it once
I do point 4. I call them exploration tests, it is tests that I write that assert my desired outcome out of the framework / library and my understanding of it. It helps me detect problems when I upgrade the framework / library throughout the applications lifetime.
Sure there is a finesse to it, I dont sit and write code that tests ASP.NET or Spring.
I used to care about this sort of stuff but now I just don't. There are too many exceptions to every rule and there are too many times where it's just not my damn problem.
A coworker confronted me with the rule of 3 when I wanted to extract some logic into its own module to be reused. He would've copy pasted it from one app to another. I think it's a fair rule but in this case I already knew we'd want to use this module in yet another application (it was basically code to call an internal rest api, kind of like an internal SDK). If we copy pasted it I don't think we would've built the module since then it'd just be one more copy paste away, especially if the logic isn't exposed via an interface (like my module did do, but the copy paste code was just spring boot rest cliënt stuff)
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far.
Be very careful with that. Make your commits too small, and you'll never be able to revert (or cherry-pick) just one commit - other commits will always have to accompany it. And now you need to keep track of which sets of commits needs to be moved around together...
Ideally a commit should be big enough to represent an entire meaningful change on its own and small enough to not represent anything else other than that meaningful change. Of course, as all ideals, in real life we have to do pragmatic compromises - but the point is that the ideal is striking a balance rather than going to one of the extremes.
This post discusses ten practical habits for maintaining speed and quality in software development. It highlights the importance of small commits to simplify troubleshooting, continuous refactoring for flexibility, and rapid deployments to gauge progress. It warns against over-testing frameworks and encourages creating new modules when functions don't fit existing ones. Testing-first approaches can clarify design, and minimizing copy-pasting fosters better abstractions. The article emphasizes adaptability, clear technical debt management, and how ease of testing reflects good design.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
i_andrew@reddit
No 10 "Testability is correlated with good design." is underrated.
No 8 "Designs get stale." is something juniors don't get.
No 7 "Copy-paste is OK once." is not totally true. It depends. But saying "create a good enough abstraction" is just wrong. Extracting something to a function DOESN'T mean you make an abstraction. The word "abstraction" is loosing it's sense nowadays. Interface is not an abstraction. Creating a module that hide complexity and exposes a simple api - that's abstraction.
pyabo@reddit
Disagree. The term "abstraction" is the general one here that applies to everything. Pulling instances of code out and replacing with a function for it absolutely IS "abstraction." Your argument is backwards. You don't have to be using an existing object-oriented pattern or have an API to call it an abstraction. I can't think of a single programming language that uses the keyword "abstract" .... waaaait. Yes I can. C++ and C# use that don't they. But THERE it has a specific meaning and it is rigidly defined.
i_andrew@reddit
Abstraction is something that hides complexity. If COULD be a function, a class, a module, a subsystem. But if you just pull some code out in sake of DRY, it doesn't have to be abstraction. In most cases every details of the implementation LEAKS from it.
A programmable Socket is an abstraction over huge complexity of the network. Your exaples are leaky, poor abstractions that doesn't fight complexity, just code duplicatin.
pyabo@reddit
FYI, here is exactly how I wrote this 'rule' a few years ago in a file I just dug up:
i_andrew@reddit
In my opinion that's devaluation of the meaning of the "abstract" word.
pyabo@reddit
Agree to disagree then. I hate how in Las Vegas every hotel on the Strip is all "suites" now instead of just "rooms". A suite used to specifically mean a hotel room w/ a separate 'room' for the bed. Now I'm not sure how you get that in Vegas, because the word that used to represent that has been devalued.
pyabo@reddit
I think there's a little more to it than that. Hiding complexity is one motive/type (or even side-effect) of abstraction. But I believe it's import to note that abstraction is primarily about generalization and that concept applies anywhere. Like you said, it *could* be a function, class, module, etc.
What is the *goal* of Rule #7? I think we're all on the same page here, we're just disagreeing about what we call it?
-Y0-@reddit
However he also advocates for Mocks. Mocks are the salt water for the thirst of testability. Sure they help, but rely too much on them and sooner or later you will start pissing blood.
i_andrew@reddit
Oh, yeah. Mocks are last resort. If the tests are based on mocks - e.g. mocks heavy - tests are no safety net.
mirvnillith@reddit
I’m trying hard to get into No 8. Software is abstract and extremely malleable but it’s so easy to stick with something you wrote as sunk cost. Tearing it all up to improve it should not be as painful as I feel it.
I practise in Factorio and Shapez ;)
Rattle22@reddit
When copy-pasting, ask yourself, "is this actually doing the same thing?".
Sometimes, two data structures are similar, but not the same and unrelated. The copy pasted code will change independently. Any abstraction you write for it will eventually tear apart.
Sometimes, two data structures are the same deep (or not so deep) down, and you can abstract over this same-ness.
Don't ask me how to tell them apart...
i_andrew@reddit
I wasn't discussing if there's a sense in using or not DRY.
My objection is for using the word "abstraction" or something that is a simple language construct. Even if you use an interface, it not necessary will be an abstraction.
rtc11@reddit
I agree with the first stmt in no 10, but making it easier to mock is not making it testable, it is making it coupled and is the opposit of no 8 - stale designs. For me testable is making decoupled componentd that is easy to test.
ammonium_bot@reddit
Hi, did you mean to say "losing"?
Explanation: Loose is an adjective meaning the opposite of tight, while lose is a verb.
Sorry if I made a mistake! Please let me know if I did. Have a great day!
Statistics
^^I'm ^^a ^^bot ^^that ^^corrects ^^grammar/spelling ^^mistakes. ^^PM ^^me ^^if ^^I'm ^^wrong ^^or ^^if ^^you ^^have ^^any ^^suggestions.
^^Github
^^Reply ^^STOP ^^to ^^this ^^comment ^^to ^^stop ^^receiving ^^corrections.
i_andrew@reddit
STOP
i_andrew@reddit
Just a typo. No need to pull out the big gun!
UnidentifiedBlobject@reddit
With number 9 I’d also add a cost dimension. There’s tech debt where things were done at high cost so it could be done quickly or a migration half done that’s causing resource duplication, and addressing them will save money.
-Y0-@reddit
Absolutely agree, but you can kind of squeeze them into the three categories.
That said we are currently working on a noSQL DB that is completely balls to write for, in it, that like two people in company know to use without bringing it to a halt.
We could switch to version 7 that helps us use JPA and not having to worry about each little operation, but according to that list it's in the third category. Because it might stop us doing something.
Perfect-Campaign9551@reddit
A good habit is SLOW DOWN AND THINK. The feature isn't so important you can't take time to get it right...
fried_green_baloney@reddit
The joke that's way too true:
JayTeeEye@reddit
Good write-up. I agree with most of them. A huge one for me is to "just walk away". What I mean by that is, when I get hung up on something I usually tend to keep grinding at it for hours. But I have found that when I get up and walk away, take a short walk, shower, etc, ....I come back and fix it within minutes.
FlyingRhenquest@reddit
Write unit tests. I never really bought into test first (Where you write the unit tests before you write any code) but I keep getting closer and closer to actually doing it. Sure, your initial velocity might go down, but your error rate and regression rate will also trend toward 0. And if you also write unit tests to replicate reported bugs before you fix them, you'll never have a regression for that particular bug again.
I see a lot of attitude among many of my co-workers that they're too busy to write unit tests. I'm too busy to not write unit tests, and all my estimates these days include them.
netfeed@reddit
ETDD - eventual test driven development. There will be tests, but the tests will not be written first, it will be written eventually during, but before the pull/merge request has been created.
Rattle22@reddit
yeah my experience has me trending towards that as well. I cant write tests before I write code, because writing code is part of the thinking process for me. But as I figure out what structure the code should take, I can figure out what the tests can and should look like and use them as insurance against myself.
MajorMalfunction44@reddit
I write things inline, with exceptions for data structures. In a theoretical sense, our only argument to the function is the current continuation - latest versions of local variables, parameters to the caller, and global variables. Tests come after I can put an interface on it.
Insurance is a great word for it.
FlyingRhenquest@reddit
A recent project I was on the unit tests were contractually obliged by a government agency and we were writing them two years after the original code was written. And every object in their code base was a singleton.
MajorMalfunction44@reddit
Good call. In game dev, this is done less. But it should be done. It's a lot easier to prove what the bug is, if you have a test program with a clean address space. I fixed a typo in my intrusive red-black tree. It's a lot easier than also debugging the Vulkan memory management code at the same time. The memory management looks simple, but it is actually correct? Callees have the constraint of being bug free.
Imperion_GoG@reddit
I'm stealing that!
The initial velocity drop is a pain to get over, though. A bunch of my coworkers will cut tests when product asks how we can get something shipped sooner.
mirvnillith@reddit
Bad dev smell. To me development includes tests and, when relevant, testability (e.g. being able to inject an event via REST). It’s what I do, not coding with optional tests.
Remember, the ones asking you to do things don’t know how to do it themselves so why should they have a say?
PuzzleCat365@reddit
I find writing code without having unit-test infrastructure too be painful. It's just a pain in the a** to write some algorithm, having to deploy it in some test environment and reproduce the issue every time. Instead I can just have unit tests ran in 1-2s and think about that long process in the end when the code is ready.
Poobslag@reddit
Unit tests are a good idea because 90% of the time, they make things easier right away. ...99% of the time, they prevent something from breaking later. ...But 100% of the time, they mean I don't have to think about it anymore
InternetCrank@reddit
You know, as I get older, and all that sort of stuff becomes second nature, I've come to realise one of the most important ones that no one ever mentions is:
Get a good nights sleep beforehand. If you're operating on 4 or 5 hours sleep as you've been up all night doing something fun, don't bother doing any work the next day. You'll just have to redo it properly anyway.
No_Nobody4036@reddit
How do I move through this politically ob my team? I don’t know how to communicate or “ask for a break” without being seem like I’m just avoiding work. I wont have any update for a standup the next day, which puts a pressure on me to do something just for the sake of seeming like im not slacking off.
I work on 4-5 hrs sleep a lot lately and the results are often very low quality or sometimes I just end up my day not producing any value just fiddling with calls emails because I can’t really concentrate. I feel like I need to be online and produce something even tho I know that it’s affecting my long term productivity over a period of time.
_alter-ego_@reddit
Small breaks may be a useful substitute if you really couldn't get enough sleep (or even otherwise). You should implement a 5' break in each hour of work, where you stand up, walk, breathe, drink.
InternetCrank@reddit
If you can work remotely, I recommend just having a lie in, you'll produce more work than you would by starting on time.
No_Nobody4036@reddit
well, i feel validated, thanks
jesusrambo@reddit
Fantastic advice
I realized this about myself in undergrad. If I stayed up late cramming for an exam, the information probably wouldn’t stick and I’d feel groggy
Same thing applies to my work now. Better to start a bit late and be clear minded all day.
CampDigiDan@reddit
proceeds to give us an
SolidGrabberoni@reddit
Don't agree with 7. The amount of really bad abstraction I've seen is mainly due to prematurely doing it.
rtc11@reddit
This. Refsctoring becomes naturally obvious, do not strive for abstraction
billie_parker@reddit
Lol
uCodeSherpa@reddit
Nah sorry dude, but the DRY experiment is well understood to have been a massive failure.
You should prefer to copy and paste over abstracting. The reason for that is because as good as you may think you are at predicting the future, you aren’t. You suck at predicting the future, and copy/paste handle your bad predictions better.
billie_parker@reddit
Lol, since when? That's like, your opinion, man
That's where you're wrong. Abstraction is easy to convert to copy-paste. The converse is not.
The problem with your mentality is it is fundamentally opposed to abstraction. It's an anti-abstraction movement being pushed by people who aren't good at abstraction. That's my impression. It's a collapse of the entire framework for good programming. Why ever create a function when you can just copy paste code everywhere? It's absurd
Dr_Findro@reddit
Based on these two comments, I am fully convinced you have left behind some nasty messes to some poor devs.
billie_parker@reddit
Again - you assume I am bad at abstractions. We're not all children. Some of us are actually good at programming.
Dr_Findro@reddit
I do assume that, and I will continue to assume that.
Every talented engineer I’ve worked with has easily been able to identify abstraction as one of the most powerful but dangerous tools.
The engineers who do not respect the gravity of abstraction have been grifters in my experience. Coincidently, you happen to also speak like a grifter.
Your code is probably more dog shit than you realize.
billie_parker@reddit
Right back at you
turudd@reddit
This is a very common misunderstanding. DRY as a god like rule has been the cause of so much needless abstractions since it was espoused as the cardinal rule
somebodddy@reddit
I think the problem with abstractions is that people use it to reduce code duplication. That's not what abstractions are for. Abstractions are for cutting complexities into multiple parts, where each part is simpler to understand and easier to test. A bad abstraction - one designed with only code deduplication in mind, will cut a complexity of 100 into 50+50. Or maybe 25+25+25+25, or any other similar combination depending how many duplications are you are removing. But a good abstraction will turn it into 10*10.
If the abstraction is not something that makes sense to do even if you only had one instance, don't do it just because you have 3 instances. Never follow DRY unless the thing you deduplicate also satisfies SSoT.
amemingfullife@reddit
Yeah. It also depends on the number of people working on the code. Copy & paste works very well for a long time if you have a small and stable number of people.
tommythemagic@reddit
I have seen copy & paste leading to bugs in large and old code bases, where the bugs were annoying to fix, and the bugs had already done harm.
If the developers before you looked at code, and decided that it was easier to copy & paste a function elsewhere instead of refactoring it and reusing it, you might eventually end up with 10+ copies with different and buggy behavior, even though all the copies were supposed to do the exact same thing.
Also, if you want to fix a bug in one copy, and you are not aware of the other copies, you might end up fixing it only in that copy. And if you are aware of the other copies, you have to spend more time finding the copies and fixing the same bug in all those copies, relative to if there was only one copy. And that can mean developers wasting a lot of time over the years debugging, finding and fixing the same bugs, just in different copies.
The right decision in such a case is typically to refactor the function, even if code has to be reorganized. It may also be a sign of issues with architecture, if code is not easy to reuse.
I do agree that if you have two functions, and they are supposed to do different things, copy & paste followed by modification can be the best option. Sometimes, refactoring slightly common functionality does not make sense. But copy & paste has to be done with care. A rule of thumb could be that if two functions are meant to do the exact same thing, they should be refactored into one function.
heroyi@reddit
I think the takeaway is that don't be overly redundant. Myself I have been through both pain points where the overly abstracted code base makes things extremely inflexible if the architecture isn't on point which can and will happen (how can you predict the future of the business logic changing down the road etc...).At the same time you touched on the idea that if you have 2+ copies of functions then having to hunt them down is just huge pain in itself also
so really your last sentence is what people should strive to do. Use common sense. Multiple copies of functions that do the same thing will result in potentially the same issue has having multiple values that rely on a reserved value where if you need to change that one value then you need to go hunt all instances of that value vs just having the value being defined in a prop file or something so you just have to change it once
DressedUpZebra@reddit
I do point 4. I call them exploration tests, it is tests that I write that assert my desired outcome out of the framework / library and my understanding of it. It helps me detect problems when I upgrade the framework / library throughout the applications lifetime. Sure there is a finesse to it, I dont sit and write code that tests ASP.NET or Spring.
CherryLongjump1989@reddit
I used to care about this sort of stuff but now I just don't. There are too many exceptions to every rule and there are too many times where it's just not my damn problem.
Nimweegs@reddit
A coworker confronted me with the rule of 3 when I wanted to extract some logic into its own module to be reused. He would've copy pasted it from one app to another. I think it's a fair rule but in this case I already knew we'd want to use this module in yet another application (it was basically code to call an internal rest api, kind of like an internal SDK). If we copy pasted it I don't think we would've built the module since then it'd just be one more copy paste away, especially if the logic isn't exposed via an interface (like my module did do, but the copy paste code was just spring boot rest cliënt stuff)
ISvengali@reddit
One thing we did for our rule-of-3 situations was to comment where the other version of the thing was. They both pointed to the opposite one.
This made it really obvious when we hit the third and needed to combine them into their general form
Red_Thread@reddit
Good advices but feels a bit outdated, especially on abstraction or testing parts.
wildjokers@reddit
In what way is it outdated?
somebodddy@reddit
Be very careful with that. Make your commits too small, and you'll never be able to revert (or cherry-pick) just one commit - other commits will always have to accompany it. And now you need to keep track of which sets of commits needs to be moved around together...
Ideally a commit should be big enough to represent an entire meaningful change on its own and small enough to not represent anything else other than that meaningful change. Of course, as all ideals, in real life we have to do pragmatic compromises - but the point is that the ideal is striking a balance rather than going to one of the extremes.
upsetbob@reddit
Good post, will share it with my newbies.
fagnerbrack@reddit (OP)
This is a summary of the post:
This post discusses ten practical habits for maintaining speed and quality in software development. It highlights the importance of small commits to simplify troubleshooting, continuous refactoring for flexibility, and rapid deployments to gauge progress. It warns against over-testing frameworks and encourages creating new modules when functions don't fit existing ones. Testing-first approaches can clarify design, and minimizing copy-pasting fosters better abstractions. The article emphasizes adaptability, clear technical debt management, and how ease of testing reflects good design.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
^(Click here for more info, I read all comments)