开云体育

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

I like to separate between the ideal and pragmatic designs. If an idealized model says the record should already exist, but for pragmatic reasons we haven't created it yet, allocating on fetch

In my view TDD requires three distinct skills to be "fully effective": 1. Writing the test first (as opposed to after) 2. Writing good tests (as opposed to crappy tests: You can write crappy tests

Yup!

First thing first, it looks strange to look for something by giving the values it should fetch. On the UI side I would usually have a get that fetches me data to get a state of my application. And at

In the case of identifying for medical reasons, it would be vital to distinguish the person: a "find or create" method would invite duplicate records, and loss (or at least unawareness) of other

When developing web applications we should bear in mind that some people that do not want to have I.e. any citizenship, this would lead to dirty data Mit Freundlichem Grü?en Ahmet

This seems really important. Do other people see the same thing?

Thank you so much JB! It's appreciated ;-)

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

Last place I was at “we can’t touch anything in X library, because too much depends on it, and it might break” Of course the way to fix about 50% of their problems was to add methods to the

Autocorrect: yeah->teach

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 (https://github.com/ardalis/kata-catalog). I also have

Ouch, that sucks. I'm part of a smallish team, but we deploy via CI/CD and if any of the test suite, code coverage minimum, linter, or typespec checker fails, it doesn't go out. We reject PRs for not

The other problem is there is a megaton of lip service done to TDD. You’ll even have working tests. They make some framework change that breaks the tests, and they stop running them, or “crunch

Hi all, Spontaneously I would guess there is a difference in experience between us trying to learn TDD with 5-10 years or more of programming experience and loads of examples of why it was necessary,

Pragmatically, in the vast majority of applications much less data is required for finding an entry than creating it. Creating an entry with so much missing data can create data integrity

Apologies for brevity. I’m on my phone. I think it depends on how transactions are being managed. If called within a transactional scope, I’d be happy with separate “findPatient” that returns

Yes. I don't know how to get my hands on good, realistic examples, because they are typically confidential material. I don't have the energy to spend months finding and refining good, realistic

Hi, folks. An old issue came back to the surface this month in consultation with clients and I'd like your opinion. It regards the old "find or create" pattern. It seems to violate Command/Query