I'm trying to convert a legacy .NET Framework web api to .NET Core, the project and its supporting libraries are in awful conditions and to make things worse at a certain point someone has the genius idea of introducing Uncle Bob's "Clean" Architecture into a part of it so stuff which could simply look like this

public string doStuff(string input){
// Do the stuff
return output;
}

becomes a convoluted mess like this

public class StuffDoerRequest {
public string Input{get;set;}
}

public class StuffDoerResponse {
public string Output{get;set;}
}

public interface IStuffDoer {
public StuffDoerResponse Execute(StuffDoerRequest request);
}

public class StuffDoer {
public StuffDoerResponse Execute(StuffDoerRequest request) {
// Do the stuff
return new StuffDoerResponse() {
Output = actualFuckingOutput;
}
}
}

Edit: sorry for the lack of indentation, apparently DevRant trims leading whitespace

Not complicated enough. As a minimum, everything should be async, and where's your IStuffDoerBuilder?

@donkulator and then have everything have interfaces for every little f**king property just because "it's more base-ic"

MY BLOOD BOILS AGAIN AND AGAIN, GLORY TO SELF LEARNT SIMPLICITY

You probably have a deep urge to delete and start over, right?

Helping a dev with a WCF->.Net Core Web Api conversion filled with IDoThis, IDoThat layers of complexity, I gave up trying to figure out the communication conversion, deleted most everything. I stepped back and looked "What the heck is this service supposed to do?", then it was simple. Service receives an order, perform some business logic, updates some data to send back to Amazon.

D: "But, what about the unit tests?!!!"

Me: "Deleted em'. Only real business logic is the data validation, which doesn't make sense in the unit tests since all the values are hard-coded, the tests would never fail. Created integration tests that performs the validation we care about."

D: "But there were 6 library projects, they are gone!"

Me: "Didn't need em. All the behavior can be handled in the controller. Supporting classes are all contained to the project."

D: "But...but..."

Me: "Keep it simple my friend, keep it simple."

@PaperTrail please tell me you wrote tests to fuzz the inputs and check the outputs, at least? that's one of many things i like about python: you can make test harnesses for modules you're only supposed to inport and they can be made to run only when starting the module directly.

@Parzi are you... testing on prod?

@melezorus34 you can safely leave the test harness in place on the prod server if you build it properly. taking every function, building fake data for that function in particular, then doing 100k iterations on a test machine and examining the output isn't too hard unless you're building a huge ass state machine. (It also serves as a great speed benchmark, where needed.)

@Parzi > "please tell me you wrote tests to fuzz the inputs"

Fortunately, the data is already 'clean', and its really testing the integration between the different systems. Moving to container orchestration (Nomad) integration tests are getting more and more important.

For the vast majority of my integration tests, I've introduced a 'Chaos Monkey' where the data is/can be somewhat random. Its been an excellent tool to test what happens when (not if) the edge cases occur.

Right now (probably fixed by the time I finish this reply), our pricing system is down because the developers assumed the stored procedure(s) would always return the price record(s). Good example and opportunity to instead of logging null reference exceptions (with no context of what object is null), the developer could log 'Product 123456 Retail Price is missing from the database'. Easy unit test and integration test to verify the behavior.