Re: "I think the community needs more explicit direction...."
On Mon, Nov 25, 2019 at 9:56 AM Avi Kessner < akessner@...> wrote: I'm currently in the process of getting both senior and junior developers to look at the existing code as "inspiration" to write easier to change code, rather than a gold standard to mimic.
I remember a time not that long ago that folks were encouraged to look at other peoples code. Reading code was as good a skill as being able to write code. "You have the full source for every website right in your browser! Go read it and learn from it!" They'd say.
Is it possible reading code has encouraged too much copy/paste? It is technologically easy to copy/paste code. I mean, what other purpose does stackoveflow serve?
I was never fond of literate programming, but mostly because I don't write prose well. Is it possible that focusing on communication of the thought process was always more important than the code itself? I mean, I think that has always?been the case otherwise we wouldn't need comments and documentation.
Or perhaps we just don't do enough teaching design prior to the workforce. Should we solve problems in school? Yes, we learn from trying things out and failing and trying again. But should we have problems to solve or solutions to design to meet certain criteria? The difference might be subtle and students who have spent their entire K-12 learning career mostly memorizing facts and solving math problems with single answers will always find it easier to "solve a problem" rather than design a solution.
-- Edwin G. Castro
|
toggle quoted message
Show quoted text
Happy to help
On Mon, Nov 25, 2019 at 1:08 PM Roy Osherove < roy@...> wrote: Happy to help.
Hi, folks.
We need moderators. Please volunteer!
Your central responsibility involves approving new messages and new members. We will have a significant amount of old-new traffic for the next few weeks as people return to the group. I would prefer not to continue to act as the bottleneck. :)
When a "new" member writes a not-obviously-horrible message for the first time, I approve the message and turn moderation off for them. I ban people who spam us. Mostly, that's it.
Thanks!
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.
Something which you, I, and everyone else would call "Tuesday", of course.
|
Re: "I think the community needs more explicit direction...."
Why code review and not do pairing?
Not enough hours in the day. I do code reviews on my phone, while waiting for my food to cook, etc.? Such is modern life.? The code I review is sometimes done in pairs.
I'm currently in the process of getting both senior and junior developers to look at the existing code as "inspiration" to write easier to change code, rather than a gold standard to mimic.
Wouldn't pairing with them work better than code reviews?? If not, why not? On Mon, Nov 25, 2019 at 10:16 AM Avi Kessner < akessner@...> wrote: We hire a lot of developers straight out of school or working less than 3 years.
From what I have seen, TDD is viewed as a skill used on Greenfield projects, and refactoring is seen as something you do with legacy code. (And still gets confused with 'throw it away and start over')
I have to have more than one code review with them until it clicks that you do both together, always.
|
Re: "I think the community needs more explicit direction...."
What gets me is how many managers that used to be experienced, technical contributors with this background seem to forget it almost immediately when switch to management.
I understand culture and mindsets are hard to modify, but what do we *do* to make positive impact in difficult circumstances like these?
Demonstrating the effects of the practices is difficult because?often you're not given enough time to show a design that falls over do to improper care.
-- Edwin G. Castro
On Mon, Nov 25, 2019 at 9:46 AM Charles Gallo < Charlie@...> wrote:
And then they get to the point the program is buggy, because it is anti-DRY, and not SOLID at all, and they (Management) throws up their hands, bring in some new technology, and throws THAT at it, hoping that at least parts work, until they re-write the whole thing
AKA they not only haven't learned from Fred Brooks, they probably have never heard the name, because they are a good dressing 35-40 year old, and of COURSE things are different now, and everyone knows this new framework/package is going to cure all our problems
Silver Bullets, Mongolian Horde method of programming, and a re-write will always be better (How much business logic have I seen in controllers, and repeated multiple places, because they don't want to touch the classes the ORM generated
Charlie
(looking for a new gig btw)
On 2019-11-25 12:36, Tim Ottinger wrote:
EVERYTHING a new programmers sees is "memorize how to do this, use it to get an effect, move on quickly" and of course going faster is the hallmark of a good programmer. What does a code craft person know? They took all day on this code, but I spat out more code in a half-day and completed more tickets. What good is TDD, Refactoring, etc if it slows us down!?
And managers generally agree. Faster is better. More faster is more better. The fastest programmer is the best programmer.?
So *learning* is a waste. *knowing* is a waste. Refactoring is waste. Testing is waste. Just get the effect and move on, friends.
Except that all of that is wrong and a dead end.?
But how can you tell people whose whole worldview is, and has always been, exactly to get an effect and move on??
|
Re: "I think the community needs more explicit direction...."
Of course you do - Don't you know it costs 2x the money? </sarc>
It doesn't help (at least where I've been) the average IT department is 4-8 people - total.? That includes the CIO and the Manager, who spend all their time in meetings getting specs (Manager) and planning networks and servers (CIO), so you have 2-4 people to be DBA, Developers, Tester, operations etc - and they think the department is properly staffed.? One of the two (CIO/Manager) will come by every couple of weeks, grab whatever they can find (usually logging into the database or the web server) and making changes right in Prod, and when you get upset, it is your fault
It has gotten to the point I told both my kids not to go into the field, unfortunately, my son isn't listening to me, and is studying Computer Engineering
toggle quoted message
Show quoted text
On 2019-11-25 12:40, Edwin Castro wrote:
Yes, but I still see a lot of resistance to pairing. Code reviews are much more accepted.
?
--
Edwin G. Castro
?
|
Re: "I think the community needs more explicit direction...."
And then they get to the point the program is buggy, because it is anti-DRY, and not SOLID at all, and they (Management) throws up their hands, bring in some new technology, and throws THAT at it, hoping that at least parts work, until they re-write the whole thing
AKA they not only haven't learned from Fred Brooks, they probably have never heard the name, because they are a good dressing 35-40 year old, and of COURSE things are different now, and everyone knows this new framework/package is going to cure all our problems
Silver Bullets, Mongolian Horde method of programming, and a re-write will always be better (How much business logic have I seen in controllers, and repeated multiple places, because they don't want to touch the classes the ORM generated
Charlie
(looking for a new gig btw)
toggle quoted message
Show quoted text
On 2019-11-25 12:36, Tim Ottinger wrote:
EVERYTHING a new programmers sees is "memorize how to do this, use it to get an effect, move on quickly" and of course going faster is the hallmark of a good programmer. What does a code craft person know? They took all day on this code, but I spat out more code in a half-day and completed more tickets. What good is TDD, Refactoring, etc if it slows us down!?
And managers generally agree. Faster is better. More faster is more better. The fastest programmer is the best programmer.?
So *learning* is a waste. *knowing* is a waste. Refactoring is waste. Testing is waste. Just get the effect and move on, friends.
Except that all of that is wrong and a dead end.?
But how can you tell people whose whole worldview is, and has always been, exactly to get an effect and move on??
|
Re: "I think the community needs more explicit direction...."
Yes, but I still see a lot of resistance to pairing. Code reviews are much more accepted.
-- Edwin G. Castro
Wouldn't pairing with them work better than code reviews?? If not, why not? On Mon, Nov 25, 2019 at 10:16 AM Avi Kessner < akessner@...> wrote: We hire a lot of developers straight out of school or working less than 3 years.
From what I have seen, TDD is viewed as a skill used on Greenfield projects, and refactoring is seen as something you do with legacy code. (And still gets confused with 'throw it away and start over')
I have to have more than one code review with them until it clicks that you do both together, always.
|
Re: "I think the community needs more explicit direction...."
Students, programmers, managers, etc all have the same problem in this case.? The goal is to do the assignment and get it "over with" ASAP so they can move on to the next one. Spending time with code? That's just going to make you late. You need to have it on time, that's the main thing. If it's on time and gets the right answer, it's a good answer.?
And this has been reinforced for decades. A lot of people don't have a place in their minds for the idea of code craft as expression of ideas for human beings.
Most people learn to program (or pick up new skills) from tutorials that say "Okay, make a new file. Type this into it! Look: it works! It got the effect we wanted! Great! Now go type this! Look! The effect! Now you have examples you can copy from and you know how to use XXX framework!"?
Most of those tutorials are built for exposition -- how to USE a thing to get an effect. And that's it. Few of them suggest anything about good code vs poor code, style, readability, refactoring, testing, any of that. The goal is you can write a first program (that works!) in Angular, React, whatever. How that works, and whether it is a good expression of business ideas, or a good use of the underlying language and its facilities? Who cares. You can go get a job now. And finish a thing, move on to the next.
EVERYTHING a new programmers sees is "memorize how to do this, use it to get an effect, move on quickly" and of course going faster is the hallmark of a good programmer. What does a code craft person know? They took all day on this code, but I spat out more code in a half-day and completed more tickets. What good is TDD, Refactoring, etc if it slows us down!?
And managers generally agree. Faster is better. More faster is more better. The fastest programmer is the best programmer.?
So *learning* is a waste. *knowing* is a waste. Refactoring is waste. Testing is waste. Just get the effect and move on, friends.
Except that all of that is wrong and a dead end.?
But how can you tell people whose whole worldview is, and has always been, exactly to get an effect and move on??
On Mon, Nov 25, 2019 at 3:59 AM Frank Carver via Groups.Io <frank.carver= [email protected]> wrote: I teach programming at the local university and have found that one of the biggest mental blocks which students need to overcome is the assumption that there is only one way to solve any problem, and that the job of a programmer is to find that way.
This mindset makes it really hard to teach refactoring, particularly in the context of eager new practitioners of TDD who want to rush on to the next test as soon as the first one passes.
I'm not sure where this attitude comes from. Perhaps the way that programming and/or software development has been reframed as "coding", and the implications of the name, or maybe that first experiences in the field often come from poking at HTML and CSS with a stick to get something that looks right, and then copy/pasting a bit of Javascript or PHP to make something happen, or perhaps the prevalence of fill-in-the blanks frameworks, or perhaps that so many students prefer to learn by following a linear set of steps from YouTube, Who knows
I'd love to investigate this in more detail, as I too, can see how much new developers struggle with the concept and skills of refactoring.
If it helps, I have found that I get slightly better traction if I lead with the idea of "code smells."
Frank Carver
-- Peace, Tim
-------------------------------------
|
Re: "I think the community needs more explicit direction...."
Wouldn't pairing with them work better than code reviews?? If not, why not?
On Mon, Nov 25, 2019 at 10:16 AM Avi Kessner < akessner@...> wrote: We hire a lot of developers straight out of school or working less than 3 years.
From what I have seen, TDD is viewed as a skill used on Greenfield projects, and refactoring is seen as something you do with legacy code. (And still gets confused with 'throw it away and start over')
I have to have more than one code review with them until it clicks that you do both together, always.
|
Re: "I think the community needs more explicit direction...."
We hire a lot of developers straight out of school or working less than 3 years.
From what I have seen, TDD is viewed as a skill used on Greenfield projects, and refactoring is seen as something you do with legacy code. (And still gets confused with 'throw it away and start over')
I have to have more than one code review with them until it clicks that you do both together, always.
Hi Roy,
?
Good points!
On Nov 25, 2019, at 4:20 AM, Roy Osherove < roy@...> wrote:
Teaching all three at the same time is hard. I've seen people try to just jump into TDD in places and failing because climbing this wall is too high in one go.
I've created courses separately for the design part and named them "refactoring skills for TDD" because even in a 5 days class, teaching the first two skills is difficult enough.
?
I particularly like this notion. We do encounter students who seem to lack even elementary notions of code clarity and expressiveness.
?
I'm not including here the skill of refactoring?LEGACY code into a testable state. I do teach that stuff, but there seems to be a distinction, at least to me between continuous refactoring during new code vs legacy (not tests) refactoring which is a much more dangerous state and might even require integration tests to begin. Perhaps we are really talking about 4 skills and not three.
?
At least some important details, since Michael Feathers wrote a million-page book on the topic. :)
Impossible is not a fact. It is an opinion. ?-- Muhammad Ali
P.S. For some reason my mails don't come thru. Probably my email addresses.
|
Re: "I think the community needs more explicit direction...."
I will say it is so good to see so many of the ¡°old names¡± here.
I remember the old SD Mag form on CIS, and then it going to the web. Is there any place like that today? I feel like I have no place where I can talk with folks to kick things around
¡ª
Charlie
73 de KG2V
toggle quoted message
Show quoted text
On Nov 25, 2019, at 11:11 AM, Charlie Poole <charliepoole@...> wrote:
?Hi Frank,
Interesting thoughts. I have noticed the problem but thought it might
just be my own attitudes as I get older!
As I think about it, folks of my generation had to climb a very steep
learning curve just to write our first programs. I learned about
refactoring back in the 90s, by which time it seemed like a way to
make my work easier, not harder. The same was true for all the XP
practices at the time... but times have changed.
One thought on teaching this stuff... use at least some commonly
reversible refactorings. For example... convert to method vs convert
call to inline code. I talk about "forces" in this context, in the
same way I teach architectural patterns. In different contexts, the
forces want to resolve in different ways. When I make __choosing__ the
refactoring seem more intellectually challenging than doing it ('cause
it is!) I find that at least some folks start paying attention.
Another think I believe strongly is that folks should learn
refactoring first __without__ tooling to do it for them. Once they do
a few of them by hand, particularly if they are wide-ranging in the
code, they end up with a better understanding about what the tool
needs to do. This also gives the opportunity to talk about how the
presence of tooling changes the balance of the above forces. They also
need to learn about the danger of limiting oneself to only those
refactorings supported by the IDE.
Charlie
On Mon, Nov 25, 2019 at 1:59 AM Frank Carver via Groups.Io
<frank.carver@...> wrote:
I teach programming at the local university and have found that one of the biggest mental blocks which students need to overcome is the assumption that there is only one way to solve any problem, and that the job of a programmer is to find that way.
This mindset makes it really hard to teach refactoring, particularly in the context of eager new practitioners of TDD who want to rush on to the next test as soon as the first one passes.
I'm not sure where this attitude comes from. Perhaps the way that programming and/or software development has been reframed as "coding", and the implications of the name, or maybe that first experiences in the field often come from poking at HTML and CSS with a stick to get something that looks right, and then copy/pasting a bit of Javascript or PHP to make something happen, or perhaps the prevalence of fill-in-the blanks frameworks, or perhaps that so many students prefer to learn by following a linear set of steps from YouTube, Who knows
I'd love to investigate this in more detail, as I too, can see how much new developers struggle with the concept and skills of refactoring.
If it helps, I have found that I get slightly better traction if I lead with the idea of "code smells."
Frank Carver
|
Re: "I think the community needs more explicit direction...."
Hi Frank, Interesting thoughts. I have noticed the problem but thought it might just be my own attitudes as I get older! As I think about it, folks of my generation had to climb a very steep learning curve just to write our first programs. I learned about refactoring back in the 90s, by which time it seemed like a way to make my work easier, not harder. The same was true for all the XP practices at the time... but times have changed. One thought on teaching this stuff... use at least some commonly reversible refactorings. For example... convert to method vs convert call to inline code. I talk about "forces" in this context, in the same way I teach architectural patterns. In different contexts, the forces want to resolve in different ways. When I make __choosing__ the refactoring seem more intellectually challenging than doing it ('cause it is!) I find that at least some folks start paying attention. Another think I believe strongly is that folks should learn refactoring first __without__ tooling to do it for them. Once they do a few of them by hand, particularly if they are wide-ranging in the code, they end up with a better understanding about what the tool needs to do. This also gives the opportunity to talk about how the presence of tooling changes the balance of the above forces. They also need to learn about the danger of limiting oneself to only those refactorings supported by the IDE. Charlie On Mon, Nov 25, 2019 at 1:59 AM Frank Carver via Groups.Io <frank.carver@...> wrote:
I teach programming at the local university and have found that one of the biggest mental blocks which students need to overcome is the assumption that there is only one way to solve any problem, and that the job of a programmer is to find that way.
This mindset makes it really hard to teach refactoring, particularly in the context of eager new practitioners of TDD who want to rush on to the next test as soon as the first one passes.
I'm not sure where this attitude comes from. Perhaps the way that programming and/or software development has been reframed as "coding", and the implications of the name, or maybe that first experiences in the field often come from poking at HTML and CSS with a stick to get something that looks right, and then copy/pasting a bit of Javascript or PHP to make something happen, or perhaps the prevalence of fill-in-the blanks frameworks, or perhaps that so many students prefer to learn by following a linear set of steps from YouTube, Who knows
I'd love to investigate this in more detail, as I too, can see how much new developers struggle with the concept and skills of refactoring.
If it helps, I have found that I get slightly better traction if I lead with the idea of "code smells."
Frank Carver
|
Re: "I think the community needs more explicit direction...."
As I said, I was let go for not succeeding with them, so no longer my circus. My impression ranged from ¡°wants to learn, but busy¡± (accepted the paper) to ¡°it is a paycheck ¡°
toggle quoted message
Show quoted text
On Nov 25, 2019, at 8:06 AM, Jeanne Petrangelo <jeanne@...> wrote:
? ¡°How do you mentor 20 somethings when they won't READ, even short stuff¡±
I have a 19yo son going to college for software engineering, and he doesn¡¯t like to read. He prefers videos. It is frustrating. We tried pointing out that vast swaths of information in the world is written down and if he doesn¡¯t learn to ingest information that way, then he¡¯s cutting himself off from that info. Reasoning hadn¡¯t motivated him enough; it¡¯s too abstract. But you have a specific case. Do you get the sense these 20 somethings want to learn, or are they happy enough with the way things are? Maybe starting with goal setting so they understand ¡°why¡± and what¡¯s in it for them, first? On Mon, Nov 25, 2019 at 1:03 AM Charles Gallo < Charlie@...> wrote: Steve (et al)
So here is the real question I have
I've gotten older, and it seems out of touch with a lot of the younger
developers
I was brought in to mentor them on this stuff, refactoring, TDD etc (and
of course get out code, setup CD/CI etc etc - of course all at the same
time ASAP)
How do you mentor 20 somethings when they won't READ, even short stuff
I tried to get them interested in "Brownfield Development" - Or
Feathers, etc - and even when you hand them something as small as a
partial chapter, or a simple write-up, you get blown off that they don't
read (and this is management, as well as the Jr developers)
I've noticed at the last couple of places.? One place - Give them the
basic instructions for GIT/TortoiseGIT, no one can be bothered to read
it, and one culprit (the CEO no less) would cowboy code, have it on his
PC, not in any source control, and yell when you can't get things to
work (the only semi working copy of the web site source was on his
laptop)
I don't understand how to get through to these folks anymore
Trying to get them to understand WHY you TDD - Why you can't get CI/CD
setup on a legacy project in a week (all manual builds off a developers
PC, with no tests run, even though there were tests)
On 2019-11-24 19:49, Steven Smith wrote:
> Autocorrect: yeah->teach
>
>
>> On Nov 24, 2019, at 19:48, Steven Smith via Groups.Io
>> <ssmith.lists=[email protected]> wrote:
>>
>> ?I yeah refactoring a lot, and I think practice helps (shocking, I
>> know). I include it in my workshops as well as in free resources on my
>> github (). I also have three
>> different Pluralsight courses on refactoring, including the monster 8
>> hour course Refactoring Fundamentals. Anyone can access these with a
>> trial account and most enterprise shops I talk to have subscriptions
>> for their folks.
>>
>> But to JB¡¯s point, I do think it¡¯s a part of TDD that newer devs lack
>> confidence and probably skill to perform, at least until they gain
>> experience with it.
>>
>> Steve
|
toggle quoted message
Show quoted text
On Mon, Nov 25, 2019 at 1:08 PM Roy Osherove < roy@...> wrote: Happy to help.
Hi, folks.
We need moderators. Please volunteer!
Your central responsibility involves approving new messages and new members. We will have a significant amount of old-new traffic for the next few weeks as people return to the group. I would prefer not to continue to act as the bottleneck. :)
When a "new" member writes a not-obviously-horrible message for the first time, I approve the message and turn moderation off for them. I ban people who spam us. Mostly, that's it.
Thanks!
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
-- Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.
Something which you, I, and everyone else would call "Tuesday", of course.
|
toggle quoted message
Show quoted text
Hi, folks.
We need moderators. Please volunteer!
Your central responsibility involves approving new messages and new members. We will have a significant amount of old-new traffic for the next few weeks as people return to the group. I would prefer not to continue to act as the bottleneck. :)
When a "new" member writes a not-obviously-horrible message for the first time, I approve the message and turn moderation off for them. I ban people who spam us. Mostly, that's it.
Thanks!
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
Hi, folks.
We need moderators. Please volunteer!
Your central responsibility involves approving new messages and new members. We will have a significant amount of old-new traffic for the next few weeks as people return to the group. I would prefer not to continue to act as the bottleneck. :)
When a "new" member writes a not-obviously-horrible message for the first time, I approve the message and turn moderation off for them. I ban people who spam us. Mostly, that's it.
Thanks!
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
Re: "I think the community needs more explicit direction...."
Hi Roy,
?
Good points!
On Nov 25, 2019, at 4:20 AM, Roy Osherove < roy@...> wrote:
Teaching all three at the same time is hard. I've seen people try to just jump into TDD in places and failing because climbing this wall is too high in one go.
I've created courses separately for the design part and named them "refactoring skills for TDD" because even in a 5 days class, teaching the first two skills is difficult enough.
?
I particularly like this notion. We do encounter students who seem to lack even elementary notions of code clarity and expressiveness.
?
I'm not including here the skill of refactoring?LEGACY code into a testable state. I do teach that stuff, but there seems to be a distinction, at least to me between continuous refactoring during new code vs legacy (not tests) refactoring which is a much more dangerous state and might even require integration tests to begin. Perhaps we are really talking about 4 skills and not three.
?
At least some important details, since Michael Feathers wrote a million-page book on the topic. :)
Impossible is not a fact. It is an opinion. ?-- Muhammad Ali
P.S. For some reason my mails don't come thru. Probably my email addresses.
|
Re: "I think the community needs more explicit direction...."
¡°How do you mentor 20 somethings when they won't READ, even short stuff¡±
I have a 19yo son going to college for software engineering, and he doesn¡¯t like to read. He prefers videos. It is frustrating. We tried pointing out that vast swaths of information in the world is written down and if he doesn¡¯t learn to ingest information that way, then he¡¯s cutting himself off from that info. Reasoning hadn¡¯t motivated him enough; it¡¯s too abstract. But you have a specific case. Do you get the sense these 20 somethings want to learn, or are they happy enough with the way things are? Maybe starting with goal setting so they understand ¡°why¡± and what¡¯s in it for them, first?
On Mon, Nov 25, 2019 at 1:03 AM Charles Gallo < Charlie@...> wrote: Steve (et al)
So here is the real question I have
I've gotten older, and it seems out of touch with a lot of the younger
developers
I was brought in to mentor them on this stuff, refactoring, TDD etc (and
of course get out code, setup CD/CI etc etc - of course all at the same
time ASAP)
How do you mentor 20 somethings when they won't READ, even short stuff
I tried to get them interested in "Brownfield Development" - Or
Feathers, etc - and even when you hand them something as small as a
partial chapter, or a simple write-up, you get blown off that they don't
read (and this is management, as well as the Jr developers)
I've noticed at the last couple of places.? One place - Give them the
basic instructions for GIT/TortoiseGIT, no one can be bothered to read
it, and one culprit (the CEO no less) would cowboy code, have it on his
PC, not in any source control, and yell when you can't get things to
work (the only semi working copy of the web site source was on his
laptop)
I don't understand how to get through to these folks anymore
Trying to get them to understand WHY you TDD - Why you can't get CI/CD
setup on a legacy project in a week (all manual builds off a developers
PC, with no tests run, even though there were tests)
On 2019-11-24 19:49, Steven Smith wrote:
> Autocorrect: yeah->teach
>
>
>> On Nov 24, 2019, at 19:48, Steven Smith via Groups.Io
>> <ssmith.lists=[email protected]> wrote:
>>
>> ?I yeah refactoring a lot, and I think practice helps (shocking, I
>> know). I include it in my workshops as well as in free resources on my
>> github (). I also have three
>> different Pluralsight courses on refactoring, including the monster 8
>> hour course Refactoring Fundamentals. Anyone can access these with a
>> trial account and most enterprise shops I talk to have subscriptions
>> for their folks.
>>
>> But to JB¡¯s point, I do think it¡¯s a part of TDD that newer devs lack
>> confidence and probably skill to perform, at least until they gain
>> experience with it.
>>
>> Steve
|
Re: "Find or Create" functions: a discussion
Hi All
10 years since I posted here?? Maybe! Hope everyone is well!
CQRS means that views are permitted to have less than absolute correctness, ie a scale of CAP, Brewer's theorem, etc.?
So, when doing an insert, the same considerations will apply - I guess the question is "When do you need to know the command was successful?Immediately, or later on?" ;)
The find operation is just another view, how correct it needs to be will depend on the workload.
If you're worried about it, those new fangled distributed hashing algorithms would probably increase the odds of success -
Ken
|
Re: "Find or Create" functions: a discussion
I think there's an issue of naming and grouping here too.
What we are calling findOrCreate sits in a soup of possible API actions for this sort of task. Some other common options include: - strict get - fail if not present, get if present
- lazy get - default if not present, get if present
- strict create -
create if not present, fail if present,
- strict update - fail if not present, update if present
- replace/put -
create if not present, update if present,
- ensure - create if not present, ignore if present
- strict delete - fail if not present, remove if present
- lazy delete - ignore if not present, remove if present
Some of the confusion in this area comes from looking at he needs of the system?though different "lenses". The CRUD view prioritises strict get, strict create, strict update, and strict delete. The REST view prioritises pure or lazy get, replace/put, and lazy delete.
One of the many things I find myself explaining much too often is that REST is not CRUD. Conflating the two worldviews leads to all sorts of confusion.
Frank.
|
J. B. Rainsberger
Frank Carver