|
Others mentioned Componentization, and Inheritance.
I agree. First the common controls / components should be built.
But I believe the framework gives you some of this.
So, I really like the idea of either inheriting from a base class.
I have one application that grew from 3 to about 10 "Wizard" input screens. Walking the users through complex steps inspecting things at an engineering level.
Having taken the time to build a single wizard page (Base Object), that identifies ALL mistakes or required entries, and business rule violations. A Virtual Method for custom validations, etc...
I can tell you it was ALMOST a PLEASURE adding new screens. 100% completely different screens, mind you, but the inherited approach meant that the user flow was the same.
So, sometimes a beautiful solution that fits perfectly, but is hard to extend... Sucks...
Sometimes a flexible solution that fits, but is so complex, you hate having to relearn the 17,000 things you have to do to make it work, and test it... [see "frameworks", lol]... Makes it a pain...
Great question. I think you look at the progression of the requests. Upcoming future stories, and creating a code base that is anti-fragile, and even enjoyable to work with... And you can't go wrong.
If you did, refactor it when you learn better....
|
|
|
|
|
I think you already have some good answers here. The following are my general rules for this sort of situation.
No code, string, or logic that ever needs to be kept in sync should ever be duplicated via copy and paste. It will get out of sync if you do. And trying to keep it in sync will drive up the cost of the development/debug cycles despite the "increased complexity" of someone updating a single pasted copy.
To facilitate this, apply the following in order:
When 'magic strings' are required, they are put into constants and referenced so one can't be changed without breaking compilation.
If you KNOW that you are only going to have 2 or 3 versions of whatever you are maintaining, simple if then else logic is perfectly fine as you haven't violated the primary rule of not duplicating any code/logic/markup that needs to be kept in sync and more importantly in all likelihood, you want a future developer to consider the impact on the other uses of the logic rather than being able to ignorantly get things out of sync by updating one form and not the other.
When code can be placed in a function and effectively called from each required location, do this.
When composition/aggregation can be used to capture the logic into a reusable component, do this.
When the above are not possible, consider inheritance and/or a metadata driven approach.
NOTE that all of these rules only apply assuming you are coding in a language that can be compiled or linted (well), such as a traditional language (C,c++,java,c#,Typescript,...), annotated python, ... These would not ALL apply to vanilla JS, non-annotated python, lua, or other similar languages that only break at runtime and require developers to create tests to replace what a compiler and linter mostly does for a good code base.
Further, they assume that performance is not a concern.
Dave B
modified 13-Oct-21 12:40pm.
|
|
|
|
|
Make sure there is no business logic in the UI.
Try to do all of your heavy reuse in the business layer. Design the interface between the UI and the business layer in such a manner that the UI will have a compile breakage for incompatible business layer changes.
Lots of other good posts on how you might organize UI layers. Reuse in UI layers would map to reuse in the business layers.
At some point you might have to diverge, this should allow that to proceed without too much mess.
|
|
|
|
|
General question - general answer:
I mainly see different pros/cons than you:
Duplication: It's really bad when the different copies of the same code start to drift apart. It has to be made sure that whenever someone changes one copy of the code, the changes are copied to all other copies of the code. So everyone in the team has to know that there is copy/paste code, which might be a problem in large teams or teams with a lot of fluctuation. If you're a one-man team, then you don't have this problem. Unless your memory is bad and you can't remember what you did last year! 
Complexity, or as I would call it, "clean code": It takes a lot more time to avoid copy/paste code, and the return on this investment is not visible on the surface. There are cases where it's more efficient to not make this investment. So the decision depends on whether you're working on a one-shot project or on a product you're going to have to maintain for decades. For long-term software, the clean-code approach usually pays off in the long term. The *very* long term! Which is something that project managers usually don't like to hear and thus software developers have to take care of themselves.
|
|
|
|
|
i would first go with duplication and time/experience will show what is for reuse. so it will end hybrid.
i am working with people who like to overuse (reuse) and sometimes that creates dependencies.
|
|
|
|
|
Sometimes elements that appear to be common at first are not really common. Say for example, both forms have a name field. One might jump to the conclusion that the name field is common to both forms and factor it out for reuse. Then down the track one of the forms needs the name field to be changed to say nick name. Now we realise in hindsight that just because the code was identical between the forms in the first instance they were not really common code and more refactoring is now required. When you factor out common code try to make sure the cut is in areas that are unlikely to change if requirements change.
|
|
|
|
|
Meyer-Briggs can't report verbatim. (8)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Ambivert - anagram of verbatim.
|
|
|
|
|
After yesterday's ambi-words and seeing this one in a headline on abc.net.au, I was helpless. YAUT!
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
What through me was the spelling it's Myers Briggs - don't think I'd of got it though 
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Oops!  But what's an E for an S all threw crosswords anyway? 
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I saw what you did there
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
|
|
cool 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
No way! Probably between 8k°C and 30k°C - just not cool at all! 
|
|
|
|
|
|
|
OriginalGriff wrote: You'd wake up if that hit you. Or more likely, never wake up again.
You'd wake up dead for sure.
|
|
|
|
|
But on the positive side:
Quote: Onlookers had enjoyed a meteor sighting earlier that night at Lake Louise
|
|
|
|
|
I repaired a house where a tree limb, about 24" in diameter came through a woman's roof into her bedroom and took out her bed. The thing about it is she had just got up to go to the bathroom. She left and went to a motel for the rest of the evening.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
My wife and I had a tree fall on our house right over the master bedroom. Fortunately it was a pine and the branches weren't long enough to reach from the roof line/slope to the bed, but they did break through both the upper roof and the drywall ceiling over the bedroom.
The worst part was it was pouring rain so everything go soaked.
|
|
|
|
|
You were lucky, hers was an oak and went all the way through floor too!
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Agreed. We were lucky. We also got lucky that it was daytime and the bedroom had no one in there. The luckiest part occurred after the fact. My renters insurance, the property owners insurance, and the insurance company of the guy whose tree fell were all USAA, so there was no wrangling over which insurance company was going to pay for the repairs. The sad part was that the tree's owner had been out doing his due diligence and removing dead trees from his property - the one that fell looked like it was healthy. I made sure USAA knew this.
|
|
|
|
|
Call Websters now. We must redefine bedrock.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
