[HN Gopher] Beyond Clean Code
___________________________________________________________________
Beyond Clean Code
Author : pbw
Score : 34 points
Date : 2024-07-26 18:55 UTC (4 hours ago)
(HTM) web link (tobeva.com)
(TXT) w3m dump (tobeva.com)
| ilrwbwrkhv wrote:
| the problem with code is that the abstraction changes and data
| needs to be migrated:
|
| e.g. a user is enabled if they have paid... time passes... now a
| user is enabled if the team they belong to has paid. now you need
| to move the logic to another struct / class and the data to
| another table.
|
| now this is where "payables" and things come in and you start
| going the path of clean code with 1000 classes.
|
| instead, the best way to do this is immutable data streams and
| event listeners.
|
| after over a decade of programming, i feel for most software with
| a customer focus (not low level, embedded etc), immutable data
| streams where data flows through and listeners do things to
| themselves is the best way.
| pezo1919 wrote:
| Same conclusion here. May I ask about your stack/domain?
| charlie0 wrote:
| I fully agree, but this requires a certain level of experience
| to organize code in a way that makes it easy to navigate and
| modify. It's quite easy to end up with with "rube goldberg"
| code where you don't know what listeners are being triggered by
| what streams. Or to end up with a ton of edge cases where
| things aren't handled properly when issues occur.
| nateglims wrote:
| Casey Muratori is basically describing Data Oriented Programming.
| Perhaps the most famous talk about it was from CPPCON 2014 [1]. I
| come from an embedded background (microcontrollers and bare
| metal) so I'm pretty sympathetic to his argument. If you work in
| it long enough, it feels natural and "clean". Uncle bob's Clean
| Code probably feels natural to Java devs.
|
| Personally, my biggest gripe comes from experiencing people
| trying to introduce it to a team. Inevitably someone tries to
| enthusiastically implement some part of it and suddenly are
| writing 1 line functions everywhere. I think this is the type of
| thing Casey is also implicitly talking about when he's railing
| against the rules being brought up.
|
| [1] https://www.youtube.com/watch?v=rX0ItVEVjHc
| jpardy wrote:
| In addition to Mike Acton's talk, there is also the "DOD Book":
| https://www.dataorienteddesign.com/dodbook/
| wiseowise wrote:
| > Uncle bob's Clean Code probably feels natural to Java devs.
|
| No.
| tcfhgj wrote:
| Don't see a problem with one line functions per se, especially
| if the name of the function helps understanding the code
| SatvikBeri wrote:
| My work has adopted DOD for roughly the last 3 years. Compared
| to OOP/FP[0], I would say DOD is generally more performant,
| more work to set up initially, harder to adapt to small
| changes, and easier to adapt to big changes.
|
| DOD is generally going to have less in the way of user-defined
| classes/types. This can sometimes make it harder to convey the
| intent of the code, but in term it means there's a lot less to
| do if there's a big change in the problem domain - e.g. you
| don't have to refactor a whole class hierarchy.
|
| Jonathan Blow has mentioned some ideas in his language Jai that
| would let you write code that can easily switch between OOP and
| DOD ideas, e.g. Array of Structs vs. Struct of Arrays, and I've
| seen that in some languages like Julia as well. I'm hoping it
| becomes more common place so that there's less of a tradeoff to
| make.
| KaiserPro wrote:
| I like this article. At the start I feared it was going to be one
| of those polemics written by someone who's never had to read
| other people's code, or worry about speed, efficiency or third
| party users.
|
| However thats not the case. The author has distilled lots of
| experience into something reasonably readable.
| Uehreka wrote:
| So like, Clean Code really does say you should write four line
| functions, and does not put caveats on that statement, Uncle Bob
| even gives a lengthy terrible-looking example of a class written
| with 4-line functions and holds it up as the ideal. His views as
| expressed in that book are extreme and uncompromising, the
| "everything in moderation, there are many ways to write clean
| code" stuff is a rhetorical act he does when people call him out.
| Then when they're gone and he thinks he can get away with it he
| starts speaking in absolute statements again.
|
| Like, this is a conversation Uncle Bob had with Casey Muratori on
| GitHub, I came away feeling like Uncle Bob is more interested in
| playing rhetorical judo than anything else:
| https://github.com/unclebob/cmuratori-discussion/blob/main/c...
| paulddraper wrote:
| Uncle Bob sounds good verbally.
|
| Like "small functions." I say, okay, okay, stop writing these
| 2000 lines of spaghetti, I'm a hundred percent on board.
|
| Then when you get to the concrete example, it's decomposing
| this 15 line function.
|
| Good idea. Calibration is waaaay off.
| booleandilemma wrote:
| He's the son of a pastor, he's definitely interested in
| rhetorical judo.
| icholy wrote:
| Has uncle Bob actually produced any useful software? Are there
| any examples of his work out there which can be analysed?
| tcfhgj wrote:
| People can give good insight about things despite even not
| creating these things, see e.g. physicists who study atoms
| theLiminator wrote:
| Yeah, I get the impression that he just sells his image as
| some "guru" of software engineering, and that he doesn't
| actually deal with or write much real life code.
| buescher wrote:
| I think the aspirations of the agile manifesto are great,
| but basically everyone involved in it was an enterprise
| software methodology consultant. I forget who the company
| exception was; someone will remind me.
| buescher wrote:
| He's got a GitHub. This seems to be the most notable thing:
| https://github.com/unclebob/fitnessedotorg
| dakiol wrote:
| Isn't that the same case for Robert Martin? I'm not going to
| be the one defending Uncle Bob, but most of the people out
| there giving advice about "clean code/architecture" come from
| the consulting world without any work that can be analysed.
| hirvi74 wrote:
| > I came away feeling like Uncle Bob is more interested in
| playing rhetorical judo than anything else
|
| That's his only option.
|
| I am not trying to speak ill of the man, but I am quite dubious
| of his advice.
|
| I truly believe everyone has something to offer. However, I
| would feel more inclined to follow Uncle Bob's advice if he
| actually had the portfolio to back it up.
|
| If Linus Torvalds were to give advice on how to build an
| operating system's kernel, I feel as though I should listen.
| Not only because Torvalds had/has good ideas, but because he
| also has demonstrable experience and work to back up his
| claims.
|
| Uncle Bob has a lot of words, but projects speak louder.
| rileymat2 wrote:
| Perhaps the Uncle Bob principles do not create the best code,
| or most clear code, but more dogmatic adherence does make it
| harder to create the code I see on a daily basis that is so
| much worse and much more unmaintainable.
| tester756 wrote:
| The most important thing when evaluating things you need to know
| is: context matters
|
| Principles arent universal across technologies
|
| Hell, principles arent even universal across software kind (e.g
| goto arent used in C# web dev, but std lib? yes)
| agumonkey wrote:
| And across teams, business.
| throwway120385 wrote:
| The other cool thing about an OOP approach to this problem is
| that you can hide your optimized LUT behind the OOP if you're
| careful about the design of it. This lets you have your cake and
| eat it too. Your users who might be more comfortable with an OOP
| approach get a way to declare the kinds of shapes they're
| interested in and the number of shapes they want to work with.
| Then you can take responsibility for building a LUT that meets
| their needs and give them the supporting optimizations they need
| to be successful.
___________________________________________________________________
(page generated 2024-07-26 23:04 UTC)