Goodbye, Clean Code • Hacker News Board

Re: Goodbye, Clean Code

#551

Post by qlk1123 » Mon, Jan 13, 2020, 3:39 AM UTC

Fanmade wrote: post #375

vonseel wrote: post #362

Earlier quoted context omitted.

I’m just wondering where you draw the line. As with everything, it often becomes a big grey area on what is acceptable and what is not. Example: my (fictional) company sells a B2B platform which provides companies with an online marketplace or some other type of online application. Each installation requires different, though often similar, integrations with the customer back-ends - think Postgres vs MySQL, but some…

Ironically, we're handling this with the concept called "clean code". We do have a core, which does implement the base logic. Everything in there is domain driven, but only using DTOs and providing interfaces for input and output, using repositories and presenters. When the data source changes, we only need to add the new repositories and set those within the context. If we have to implement some specialized logic ju…

Interesting. I'm curious how long did your core system with basic-logic take to reach that maturity, and how many people involved? What kind of development model did you use?

Also you state that you "still struggling to get my head around this approach," does it mean that the system somehow violates the principle of least astonishment? (https://en.wikipedia.org/wiki/Principle_of_least_astonishmen... )

Re: Goodbye, Clean Code

#552

Post by galangalalgol » Mon, Jan 13, 2020, 4:03 AM UTC

djsumdog wrote: post #330

altitudinous wrote: post #244

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…

> Rewriting requires retest, introduces new bugs If you don't have automated tests, and start writing them as early as you can, you're not going to have a good time. I hate working at shops or on jobs where there is zero unit testing. You have to have tests to safely refactor things. If you miss something, you add a test. If you get a false failure; figure out what was wrong with the test. Retesting should be as simp…

I'd rather have automated integration or system test and no unit test than the other way around. I find unit tests uncover the fewest problems of the three.

Re: Goodbye, Clean Code

#553

Post by int_19h » Mon, Jan 13, 2020, 7:40 AM UTC

_y5hn wrote: post #484

hota_mazi wrote: post #463

Earlier quoted context omitted.

> Except exceptions are rarely understood and used correctly by most programmers That's pretty condescending. The mechanism for exceptions has been around for more than 20 years, it is well understood by most programmers. The problem is that error handling is hard. Exceptions are an adequately sophisticated solution to that hard problem. Go's approach only encourages ignoring errors (since the compiler never enforces…

Is it really: Are programmers omniscient then that they can trap all kinds of exceptions correctly from external code? It's a sophisticated method that dumps the problem on the user instead. Golang also output stack traces and even supports panic() if one wants to have something similar to handling exceptions. The difference is that this is used for classes of errors that ideally are programmer error, and not for all…

Exceptions are basically error types with dynamic typing in an otherwise statically typed language. So if you can deal with dynamic typing in Python, you can handle exceptions in Java.

Re: Goodbye, Clean Code

#554

Post by int_19h » Mon, Jan 13, 2020, 7:40 AM UTC

_y5hn wrote: post #483

flavio81 wrote: post #460

Earlier quoted context omitted.

>Except exceptions are rarely understood and used correctly by most programmers. That's just your opinion.

When applications and services still defaults to dumping full stacktrace and reporting programmer's errors, it's from longer-term experience also.

What are they supposed to do? And how is that different from panics?

Re: Goodbye, Clean Code

#555

Post by int_19h » Mon, Jan 13, 2020, 7:44 AM UTC

hota_mazi wrote: post #464

_old_dude_ wrote: post #458

Earlier quoted context omitted.

The main issue with any discussions on exception is the elephant in the room, Java. Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. I really like the exception model of Erlang, recovery is only possible from another routine. It's is in my opinion the best exception model. Go code is nice because everything is fully explicit but it's hard to re…

> Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. Unless you have a specific complaint about Java's model (which I'd love to read), I strongly suspect that your beef is with a few standard Java library functions misusing checked exceptions than a statement against exceptions in general. The combination of runtime and checked exceptions offers…

The big problem with Java's model is that exceptions aren't part of the type system: they're that whole separate thing that is applied to methods, but it's not a part of that method's type in any meaningful sense. This means that it's impossible to write a higher-order function along the lines of "map" or "filter" that would properly propagate exceptions, because there's no way to capture the throws-clause of the predicate and surface it on the HOF itself.

Re: Goodbye, Clean Code

#556

Post by dx034 » Mon, Jan 13, 2020, 8:18 AM UTC

scarface74 wrote: post #292

Impossible wrote: post #217

Earlier quoted context omitted.

Future coding has lead to some of the most overcomplicated systems I've worked with. It's one of the reasons (among many) I quit my last job. I was constantly told code that had no use cases was "important to have" because "we needed it".

So does that same idea apply to all of the many abstractions thst geeks do just to stay vendor or cloud agnostic just in case one day AWS/Azure go out of business?

Vendor agnostic code doesn't anticipate AWS going out of business, just them raising prices significantly. It can be smart to be able to switch in a reasonable amount of time so that you can evaluate the market every few years. This way spending extra time to be vendor agnostic can also pay off. But there's no technical reason for that, it's a cost issue.

Re: Goodbye, Clean Code

#557

Post by dx034 » Mon, Jan 13, 2020, 8:20 AM UTC

_pmf_ wrote: post #472

kqr wrote: post #321

Earlier quoted context omitted.

> As an apropos to the article, and touched upon therein, checking in a fairly major change to de-duplicate some code without consulting the original author/team is a wee bit rude. This sounds like the outcome of bad culture. Ownership of the code should be shared to the point where it should never be considered rude to improve the code. Any part of the code. > Ask your colleagues first why such code still exists bef…

> This sounds like the outcome of bad culture. For 90% of shops outside the cornucopia of SV with unlimited budgets and internal customers only, the client drives decision mercilessly and ruthlessly.

And for a good reason. The product doesn't exist because they're fun to develop. They exist because they solve a problem customers have. So ultimately, decisions should always be based on what customers (long-term) benefit most from.

Re: Goodbye, Clean Code

#558

Post by the6threplicant » Mon, Jan 13, 2020, 8:56 AM UTC

bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

I get giddy with excitement whenever I see someone has rewritten/touched my code.

Re: Goodbye, Clean Code

#559

Post by marcus_holmes » Mon, Jan 13, 2020, 9:33 AM UTC

_old_dude_ wrote: post #458

_y5hn wrote: post #444

Earlier quoted context omitted.

Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.

The main issue with any discussions on exception is the elephant in the room, Java. Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. I really like the exception model of Erlang, recovery is only possible from another routine. It's is in my opinion the best exception model. Go code is nice because everything is fully explicit but it's hard to re…

This is kinda my point: it's hard to read until you get used to it. I can totally see why someone used to Python has a hard time with Go's error handling, because they're not used to the rhythm of it (logical statement, error check, logical statement, error check, logical statement, error check); they're more used to (exception handling setup, logical statement, logical statement, logical statement, exception handling completion). It's different, and therefore strange and weird. But after a while you get used to it, and expect to see an error check after each logical statement, and it sort of merges into one structure in your mind.

There are packages for wrapping errors, and I believe some form of error wrapping (using the fmt package for some reason) is being adopted. More than that is up to the coder to implement.

Re: Goodbye, Clean Code

#560

Post by dx034 » Mon, Jan 13, 2020, 10:45 AM UTC

genezeta wrote: post #366

bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

> ...and you want to rewrite code I wrote... I think the key to most of this situation is right there. It's also something the original author largely misses. The key is this: want . If you want to rewrite some code you find, then kindly leave that keyboard and go play with some toys. This, "wanting", is the actual origin of the author's anecdote. "I saw this and I thought it was bad and I felt the urge to rewrite it…

> What is missing is knowledge on the circumstances of the code. You see some piece of code and you're only seeing that, the code itself. But why is it that way? Is this code supposed to be modified/extended/reduced/deleted in a near future? Frequently? Or simply, as a first question: Does this code need to be better?

That's exactly why you should always be very careful refactoring old code that you don't fully understand. It might look like spaghetti code that contains a lot of weird artifacts, when in reality it once was clean code that had to be edited dozens of times to handle edge cases. Not that it can't be refactored, just that it's likely not to look that much cleaner if it's to provide the same functionality. Refactoring old cold just because it looks ugly is often a waste of time and money.