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

131–140 of 246 posts

Re: A Theory of Software Architecture

#131

Post by froman88 »

speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

I agree that it may be overkill for such a simple function, but the author (at least the original author, Brandon Rhodes) is drawing an analogy to more complex applications.

He uses such a simple example so that his idea that applies to much larger, more complex codebases can expressed in a presentation/article, not to argue that all such simple functions need this level of decoupling.

https://en.wikipedia.org/wiki/Straw_man#Steelmanning

Re: A Theory of Software Architecture

#132

Post by Izkata »

winkeltripel wrote: post #88
MeteorMarc wrote: post #81

Earlier quoted context omitted.

You only want to test on public API, because else you cannot change the implementation without adapting your perfect unit test on implementation details. So, I prefer the first code example and do not mind some mocking (unless the extracted functions make sense on the public API).

A large application has lots of implementation leak to the API, doesn't it?

For this reason, when mocks are involved (that is, just about any external API), I think Listing 2 is the ideal - extract a small function designed around the desired interface, a facade that's easily mockable and won't change with the library implementation.

Re: A Theory of Software Architecture

#133

Post by barumi »

OneGuy123 wrote: post #54
barumi wrote: post #49

Earlier quoted context omitted.

> Show me how you’d implement a basic MS Paint clone and we can talk! A MS Paint clone is one of those apps that fits rather nicely on a Clean Architecture. You have the domain model (raster image), you have the application layer (image processing operations over the raster image), and you have the IO/service layer (image exporters/importers, GUI, platform-specific features, etc).

Are you actually a programmer? You sound more like an academic with no real life experience on large software. You do realize that within those "neatly separated layers of yours" there will be an insane amount of complexity which will be impossible to separate in layers?

> Are you actually a programmer?

Why, yes I am.

> You sound more like an academic with no real life experience on large software.

Well, I do work as a software engineer for a FANG, so that does fit the bill I guess.

> You do realize that within those "neatly separated layers of yours" there will be an insane amount of complexity which will be impossible to separate in layers?

Well, there really isn't you know?

I mean, unless you don't know what you're doing.

In my line of work, the hardest problem is to reign in complexity. It's very easy to mess up and end up with insane amount of complexity, specially if you don't have a clue about what you're doing.

In fact, as the saying goes, incompetent developers make complex things, while competent developers make simple things.

It seems you make a living struggling with complex things that ends up piling on a lot of complexity. Perhaps you would do yourself a favor by improving your skillset and learn how not to follow that path.

Re: A Theory of Software Architecture

#134

Post by froman88 »

nxpnsv wrote: post #75
bilekas wrote: post #73

Earlier quoted context omitted.

I support this a bit, I would have different idols in mind, but I wont fault someone for theirs. Once something is learnt it really doesn't matter. The pain is the title..

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.

Re: A Theory of Software Architecture

#135

Post by adamkl »

I spend a lot of time thinking about these sorts of topics (actually, I just taught a 4 hour session yesterday that used most of the terms in this article), working with newer, less experienced developers, and trying to figure how to distill the essence of "architecture" down to something simple that everyone can start with.

This is what I’ve started telling people:

Use mostly functions, try to make most of them pure.

I think that can get people (even new devs) 80% of the benefits (testability, composability, loose coupling, and the ability to reason about code) of more complicated, prescriptive architectures (Hexagonal, Onion, Ports & Adapters, Clean, etc) with a minimal amount of ramp up.

Of course, this isn't the solution to every problem (it obviously depends on the domain you are working in, for me its webDev and backends), but I think maybe its a good way for people to start.

Edit: Here is a great talk demonstrating that by following a simple functional approach, your code can naturally fall into a “pit of success”: https://youtu.be/US8QG9I1XW0

Re: A Theory of Software Architecture

#136

Post by bluGill »

nahname wrote: post #128
speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

There are people who cannot use an abstraction unless they understand every line of code behind it. Abstractions are blockers, rather than aids. This lowers the value of abstraction for those individuals. Others find it tiresome to read every line of code and develop intuition around abstractions instead. The "find_definition" function will be all that is parsed. The funny thing is people shift between the two as the…

In a real project - millions of lines of code - there is no chance to understand it all. You have to trust the abstraction does what it says without caring how it works. You only break the abstraction and understand when you have reason to suspect that it somehow isn't obeying your quick mental model of what it does - normally this means you suspect the bug you are working on is down that abstraction, but sometimes it is just the name is bad and so you need to figure out what it is really doing.

Re: A Theory of Software Architecture

#137

Post by eatthoselemons »

jonahx wrote: post #9
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,…

> (..Manager, ..aggregator,etc.) Names ending in Manager are usually a poor choice. See Peter Coad's "-er-er" principle: > The “-er-er” principle. Challenge any class name that ends in “-er.” If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves. See also: http://www.carlopescio.com/2011/04/your-codi…

Perhaps you can explain this part from the post you linked which is perplexing me:

> AppDomainAffine, therefore, would be a more appropriate name. Unusual perhaps, but that's because of the common drift toward the mechanics of things and away from concepts (because the mechanics are usually much easier to get for techies)

how is 'AppDomainAffine' not a concept?

Re: A Theory of Software Architecture

#138

Post by whoomp12342 »

std_badalloc wrote: post #82

I don't think the example here is the best. There's a case to be made for extracting pure functions and organizing them like this, but I don't think this code makes it. The benefit of pure functions IMO is primarily in that the code becomes easy to reason about if it doesn't depend on state. But any app that does anything will have state, and the question is how you manage that. One guideline could be that individual…

There is absolutely a problem here. Having worked in disasters of a code base, the architectural pattern in the first example is probably fine... until the software grows. The first function truly is a thing-do-er which violates SRP. Then it will easily become a ball of mud.

Why is this so bad? Its not because its expensive, yes that is bad, but the largest issue with working in a ball of mud architecture, is that the code becomes so fragile and interdependent that changing any one thing can easily lead to breaking many other things. This leads to a culture of fear of change which grows tech debt. Then one day someone steps up and decides to actually refactor this ball of mud to have some semblance of logic to it, what a noble soul. That person is then subject to a barrage of bugs and issues from the refactor and is that the mercy of their supervisor.

Dealing with state and other side effect like issues is certainly something to consider in architecture, but it is a different argument entirely.

Re: A Theory of Software Architecture

#139

Post by ratww »

tarruda wrote: post #105
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 don’t think that purely functional programming writ large is a pragmatic development plan, because it makes for very obscure code As a functional programming enthusiast, I agree with this. Recently I worked on rewriting a relatively large backbone web application in React/Redux (For those that don't know, Redux is a framework for writing JS in a more functional style). While moving all app logic to functional sty…

You're not wrong, but I don't really think this is the fault of FP.

I had the exact same experience with people not understanding new paradigms with Procedural (programmers experienced with Assembly using GOTO for everything), OOP (programmers used to procedural using only static methods), MVC (by putting everything in the controllers and ignoring views/modules/helpers), MVVM (by modifying state by themselves instead of using the MVVM mechanism).

All those things were always "obscure" for newcomers since it was different from what they learned in college, but after a while they became second nature.

I think the answer is not to avoid those paradigms because they're hard, but rather to teach people how to work with them. It's expensive but it's only way forward IMO.

Re: A Theory of Software Architecture

#140

Post by boredumb »

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.

A decade ago I was writing a big C# application using Ninject* DI framework and this is identical to my experience.
Post reply on HN