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

A Theory of Software Architecture

danuker.go.ro

Post reply on HN
Print view View original

141–150 of 246 posts

Re: A Theory of Software Architecture

#141

Post by ratww »

UK-Al05 wrote: post #106
wsc981 wrote: post #78

Earlier quoted context omitted.

> Sometimes a big, fat block of code is just easier to understand. John Carmack made once the same comment: http://number-none.com/blow/blog/programming/2014/09/26/carm...

I haven't read that in awhile. But the argument was around optimisation rather how easy it is to understand.

Not really, Carmack explicitly states that this is not a performance optimisation in the article:

> In no way, shape, or form am I making a case that avoiding function calls alone directly helps performance.

Rather, he argues that (among other things) this is a way to make current bugs more visible and to avoid future bugs by disallowing calling functions that should be inlined.

Re: A Theory of Software Architecture

#142

Post by gwbas1c »

[Meta]

The introduction to the article relies on so much context and assumed knowledge that I almost didn't read past the third paragraph.

Who are Uncle Bob, Gary Bernhardt, and Mr. Brandon Rhodes? I have no idea, and I don't need to know who they are to read the rest of the article. (Which itself is extremely well-written.)

IMO: Have an introduction that doesn't rely on unneeded context. It's appropriate to credit people; but do it in a way where a reader unfamiliar with the context doesn't assume that they need to know the context to read further.

Re: A Theory of Software Architecture

#143

Post by tonyarkles »

PaulKeeble wrote: post #120
tonyarkles wrote: post #116

Earlier quoted context omitted.

> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.

But then despite that the class is getting a generated proxy that does basically nothing or is causing the problem and it is really hard to determine anything except tracing it at runtime to find out what actually is being run. People do some crazy things with Spring and interface injections in Java and it can get really Opaque quickly but also often it really is just 1 class implementing an interface and there are n…

For the one project I worked on that was Spring-based, my joke was that Spring was a really effective way to convert compile-time errors into run-time errors :)

Re: A Theory of Software Architecture

#144

Post by arcbyte »

PaulKeeble wrote: post #120
tonyarkles wrote: post #116

Earlier quoted context omitted.

> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.

But then despite that the class is getting a generated proxy that does basically nothing or is causing the problem and it is really hard to determine anything except tracing it at runtime to find out what actually is being run. People do some crazy things with Spring and interface injections in Java and it can get really Opaque quickly but also often it really is just 1 class implementing an interface and there are n…

And now you're into the Liskov substitution principle. All of your implementations should honor the same contract even if they do it in different ways.

Re: A Theory of Software Architecture

#145

Post by shock »

iainmerrick wrote: post #115

This is good advice and a good writeup, but I take exception to one (boldface!) line: Coupling kills software I hear this a lot but I think it’s highly overstated. The “clear” final version is still strongly coupled -- you can’t call find_definition without it directly calling the build_url helper! The key aspect isn’t the coupling, it’s that the high-level imperative function is calling a simple, low-level, testable…

> Coupling kills software

> I hear this a lot but I think it’s highly overstated.

Coupling is like trying to get to your destination by swimming through molasses – each move you make impacts atoms far away from you because they are tightly bound to the ones near you, and those atoms exert a force back.

Re: A Theory of Software Architecture

#146

Post by scaladev »

tonyarkles wrote: post #116
iainmerrick wrote: post #115

This is good advice and a good writeup, but I take exception to one (boldface!) line: Coupling kills software I hear this a lot but I think it’s highly overstated. The “clear” final version is still strongly coupled -- you can’t call find_definition without it directly calling the build_url helper! The key aspect isn’t the coupling, it’s that the high-level imperative function is calling a simple, low-level, testable…

> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.

It's not a problem if you're using a proper IDE. Rider and IDEA will take you right to the implementation (or will display a list if there are multiple implementations) on Ctrl+Alt+B. This works on any of the parent classes/interfaces, or any inherited field or method.

Re: A Theory of Software Architecture

#147

Post by Lio »

dheerajvs wrote: post #24
kumarvvr wrote: post #2

Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…

Another pet peeve of mine is variable names suffixed with "Data" and "Info".

Worst variable name I’ve ever seen was “data2”. There was no longer a “data” in that code but presumably there had been at one point.

Re: A Theory of Software Architecture

#148

Post by nxpnsv »

froman88 wrote: post #134
nxpnsv wrote: post #75

Earlier quoted context omitted.

Yes, sure a little unfair and nitpicky, but still the title baited me to click and left me unimpressed. I wonder if my impression had been better if the content matched the expectations.

Frankly, if you really thought a single article could deliver a "grand unified theory" of anything, that's on you. People pick catchy titles; it's a key part of getting noticed these days.

I have a past as a physicist, so I am a little sensitive to that phrasing. Optimally a catching title matches relevant content - probably get lower bounce rate that way too...

Re: A Theory of Software Architecture

#149

Post by swaits »

froman88 wrote: post #134
nxpnsv wrote: post #75

Earlier quoted context omitted.

Yes, sure a little unfair and nitpicky, but still the title baited me to click and left me unimpressed. I wonder if my impression had been better if the content matched the expectations.

Frankly, if you really thought a single article could deliver a "grand unified theory" of anything, that's on you. People pick catchy titles; it's a key part of getting noticed these days.

And we have a word for it, clickbait. It’s okay that it exists. It’s also ok for us to call it out when we see it.

Re: A Theory of Software Architecture

#150

Post by humbleMouse »

scaladev wrote: post #146
tonyarkles wrote: post #116

Earlier quoted context omitted.

> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.

It's not a problem if you're using a proper IDE. Rider and IDEA will take you right to the implementation (or will display a list if there are multiple implementations) on Ctrl+Alt+B. This works on any of the parent classes/interfaces, or any inherited field or method.

Yeah this is what I was thinking. I pity the people who navigate java projects without ctrl+alt+b. What an existence that must be.
Post reply on HN