[jmac01]

Clean code leads to more testable code leads to more tests leads to better products. Don't be so quick to dismiss "clean code" as some BS.

I've seen first hand how someone writing a 500 line function struggles to test it. But splitting it up into more manageable chunks of functionality makes it easier to write a test.

Imo perfectionism is chasing that last 5% performance.

Clean code, design patterns etc are just good engineering practices... Not perfectionism ....

[dakiol]

> Clean code, design patterns etc are just good engineering practices... Not perfectionism ....

This is what I don’t like about software engineering. The dogmatism. The absolutism. The more I work in the field, the less I talk about “clean code”, “ddd”, “good practices”. I find myself saying more and more “it depends”, and more often than not what the business requires is not 5 layers of code in which the concerns are separated among dozens of files and following good design patterns, but a damn single file that get things done.

There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.

[rectang]

I really liked how jmac03 put things, and I don’t see the dogma you’re seeing — consider that it’s “struggles to test” not “impossible”. I don’t see any advocacy for ”dozens of files”, just breaking functionality down into “manageable chunks” to facilitate testing. In fact, “dozens of files” are arguably not “manageable“, and I don’t see an argument for that, any more than you’re arguing that every function needs to be 500 lines.

Every single startup I’ve worked for has eventually come to terms with needing some best practices. In my view, there actually is a baseline: CI, partial coverage unit tests for the most easily testable code, and modularization/loose-coupling so that unwinding tech debt has linear rather than exponential cost. But even that is driven by my opinions about ROI, not theory in isolation.

[johnnyanmac]

>There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.

Clean code for a bad product won't turn it into a good product. That's the core issue. These are engineering principles but you are looking at them through business logic.

The best metphor here is to compare clean code to insurance. You don't want to insure this? Okay, you can take that risk and maybe save if nothing happens. But if/when something happens it'll be more expensive than if you paid the insurance up front.

Meanwhile, Clean code from a good product will make it resiliant to becoming a bad product. I'm sure if you played any modern video games that you've had at least a few games that you loved but had horrible technical hiccups. Unoptimized, untested logic, crashing. The issue is some of these games still sell, so maybe the business logic prevailed over properly engineered code. But they are entertainment at the end of the day, not Crowdstrike.

[aswanson]

Absolutely. Breaking a design down into verifiable, testable chunks is, imo, the major delineator between a school project and a professional product.

[dgb23]

Le me clarify: good modularization and abstractions emerge from engineering concerns (like the ones listed above) and not the other way around.

The reason I wrote the above comment is because I've seen this being flipped on its head too often by myself and others.