Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code doesn’t have to be a mess

danielsieger.com

Post reply on HN
Print view View original

11–20 of 190 posts

Re: Code doesn’t have to be a mess

#11

Post by commonlisper »

rbongers wrote: post #6

There's a great section in The Practice of Programming where the book describes how you should structure your code to not just be structured nicely now, but to plan for the future; to structure it so that changes are easy, organized, and don't break anything. It's not exhaustive but it's a powerful general idea and I always like introducing developers to it for the first time.

I must say here that I agree this point but one should also exercise caution that they don't go overboard with abstractions while planning for future. Abstractions for future planning should be lean and flexible enough to be extensible.

Re: Code doesn’t have to be a mess

#12

Post by [deleted] »

rbongers wrote: post #6

There's a great section in The Practice of Programming where the book describes how you should structure your code to not just be structured nicely now, but to plan for the future; to structure it so that changes are easy, organized, and don't break anything. It's not exhaustive but it's a powerful general idea and I always like introducing developers to it for the first time.

[deleted]

Re: Code doesn’t have to be a mess

#13

Post by foobarian »

bbarn wrote: post #10
dsieger wrote: post #2

Would be curious to know what strategies other people apply in order to keep complexity down over time!

Trust your tooling, and your repository. It's safe to delete if you still have a record of the way the code was before. Too often I see code that doesn't need to exist because someone is afraid to remove it. Modern IDEs are excellent at showing dependent code, and GIT and other source control tools are excellent at giving you freedom to remove things. Oh, and have good testing in place to make sure you aren't breakin…

That's what we call 'scream testing'

Re: Code doesn’t have to be a mess

#14

Post by mystickphoenix »

dsieger wrote: post #2

Would be curious to know what strategies other people apply in order to keep complexity down over time!

For me the number one thing I try to focus on is _naming_. If something is hard to name, it's likely hard to understand or overly abstracted (misdirected). If something is easy to name, it likely follows [insert any software development "best practice" here].

What's a good name? I love the phrasing from _Elements of Clojure_ by Zachary Tellman [1]

> Names should be narrow and consistent. A *narrow* name clearly excludes things it cannot represent. A *consistent* name is easily understood by someone familiar with the surrounding code, the problem domain, and the broader [language] ecosystem.

1. https://leanpub.com/elementsofclojure/read_sample

Re: Code doesn’t have to be a mess

#15

Post by nosianu »

bbarn wrote: post #7
idontwantthis wrote: post #3

Earlier quoted context omitted.

Unit Tests. If you can't write a unit test for it, it's too complicated and it's going to snowball quickly into a giant mess.

I love unit tests, but admit I have absolutely seen unnecessary complexity including complete classes and namespaces solely to enable testability in many cases. It's a justifiable trade off for me, but I don't pretend that unit testing reduces complexity.

I think it is of at least slight interest to some who missed it, to bring back this thread from 2018, about Oracle code (I too once worked on it so I immediately saved that comment link when it was posted):

https://news.ycombinator.com/item?id=18442941

Re: Code doesn’t have to be a mess

#16

Post by nicoburns »

dsieger wrote: post #2

Would be curious to know what strategies other people apply in order to keep complexity down over time!

I'm a big fan of the "IO Sandwich". This is where you keep complex computation as pure functions as much as possible. And push the IO to the edges of the system. So you might have read-compute-write. This keeps the computation functions testable and composable.

Re: Code doesn’t have to be a mess

#17

Post by cassianoleal »

ape4 wrote: post #8

Ah the Unix philosophy. `man ssh' gives `ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destina…

Did you mean `ssh --help`?

`man ssh` gives me detailed descriptions of all flags.

Re: Code doesn’t have to be a mess

#18

Post by lifeisstillgood »

To me the simplicity argument is the greater argument t for microservices

We should stop seeing microservices as a technical problem / solution they are how to divide a "business domain" up into account the smallest constituent parts according to vat business view in the domain

Re: Code doesn’t have to be a mess

#19

Post by eyelidlessness »

nicoburns wrote: post #16
dsieger wrote: post #2

Would be curious to know what strategies other people apply in order to keep complexity down over time!

I'm a big fan of the "IO Sandwich". This is where you keep complex computation as pure functions as much as possible. And push the IO to the edges of the system. So you might have read-compute-write. This keeps the computation functions testable and composable.

In probably my favorite software-related talk[1] (certainly the one I most frequently share), this is referenced as “functional core, imperative shell”.

1: https://www.destroyallsoftware.com/talks/boundaries

Re: Code doesn’t have to be a mess

#20

Post by matheusmoreira »

idontwantthis wrote: post #3
dsieger wrote: post #2

Would be curious to know what strategies other people apply in order to keep complexity down over time!

Unit Tests. If you can't write a unit test for it, it's too complicated and it's going to snowball quickly into a giant mess.

My experience with automated testing was great until I had to test I/O functionality: files, databases. That's when the test suite itself became too complicated.
Post reply on HN