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

71–80 of 246 posts

Re: A Theory of Software Architecture

#71

Post by username90 »

scsilver wrote: post #13
otabdeveloper4 wrote: post #7

Way off the mark. "Software architecture" is about how you make the disparate parts of a software system work together towards a common goal. Most of these parts aren't code: hardware, programmers, tech support, HR, licensing and legal, etc.

Completely agree, software does what its told, thats easy, driving consensus across people is the hard part

If it was easy why don't you just implement the solution directly instead of spending time in meetings discussing how to implement the solution? The reason we spend time caring about software architecture is because writing software is hard and anything that can make it simpler is very helpful, like structuring its architecture beforehand.

Re: A Theory of Software Architecture

#72

Post by Cthulhu_ »

aryehof wrote: post #38

To me, a software architecture is an implementation of the decisions made (amongst competing choices) in meeting its requirements , both functional and non-functional. I simply don't find the article to provide a grand unified theory across different genres of software at all. What worries me is that newcomers to the industry will, until they move to the next discovered silver bullet unified theory.

While I agree there is no silver bullet, most applications will have a lot of similar nonfunctional requirements - API, data processing, and i/o. Having a common basis to go to - then evolving it - is a good practice. Cowboying or reinventing the wheel is not a good practice.

Re: A Theory of Software Architecture

#73

Post by bilekas »

nxpnsv wrote: post #64

Nice and all, but It feels quite pompous to tout this as a grand unified theory of anything. This is a highly specific little corner of software architecture, and is neither grand, unified or even a theory.

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..

Re: A Theory of Software Architecture

#74

Post by ZephyrBlu »

ravenstine wrote: post #67
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…

This reminds me of Brian Will's "Object-orientation is Bad" where he makes the case that most decoupling tends to be more confusing than long-form code that's got sufficient comments. https://youtu.be/QM1iUe6IofM?t=2235

I hate unnecessary functions with a passion and it's refreshing to hear his opinion.

Sometimes a big, fat block of code is just easier to understand.

Re: A Theory of Software Architecture

#75

Post by nxpnsv »

bilekas wrote: post #73
nxpnsv wrote: post #64

Nice and all, but It feels quite pompous to tout this as a grand unified theory of anything. This is a highly specific little corner of software architecture, and is neither grand, unified or even a theory.

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.

Re: A Theory of Software Architecture

#76

Post by golergka »

zmmmmm wrote: post #37
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,…

> think a thousand times before you name something I gave up .... I write mostly in languages that allow you to deterministically rename things with refactoring tools, so I frequently rename important classes 5 or 6 times before I'm done.

This.

Not only renaming, but re-bundling entities, moving layers, changing abstractions – refactoring is crucial during and immediately after development. As you implement your idea, you will inevitably find a better way to express it, and it's crucial to be able to re-do these things as many times as possible to reach the best possible result (if it's not a throwaway prototype, of course): no maintainer, including yourself a month later, will have a picture as full and clear as you right after finishing the first iteration.

Re: A Theory of Software Architecture

#77

Post by marco_craveiro »

zmmmmm wrote: post #37
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,…

> think a thousand times before you name something I gave up .... I write mostly in languages that allow you to deterministically rename things with refactoring tools, so I frequently rename important classes 5 or 6 times before I'm done.

Completely agree. I find that the right name takes ages to come about. Worse, it may require a lot of architectural refactoring that, many times, has nothing to do with the one entity you are trying to name. Instead, it is connected with the entire workflow you are designing. Nothing worse than spending ages coming up with the right name for a class, only to find out the entire class is not needed and you got the workflow all wrong :-) which I have done many a time, to be fair

Re: A Theory of Software Architecture

#78

Post by wsc981 »

ZephyrBlu wrote: post #74
ravenstine wrote: post #67

Earlier quoted context omitted.

This reminds me of Brian Will's "Object-orientation is Bad" where he makes the case that most decoupling tends to be more confusing than long-form code that's got sufficient comments. https://youtu.be/QM1iUe6IofM?t=2235

I hate unnecessary functions with a passion and it's refreshing to hear his opinion. Sometimes a big, fat block of code is just easier to understand.

> 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...

Re: A Theory of Software Architecture

#79

Post by makach »

username90 wrote: post #66
makach wrote: post #43

We have built software for a long time and we have learned a lot. There are many good ways (patterns) to reuse when you need to solve a particular problem. Uncle Bob speaks the truth. For me, the challenge has never been with the architecture or our combined technical knowledge. What I have observed as the main challenge is that most technologists start solving the problem before they know what the problem is.

If the people asking you to solve a problem don't know what problem they want solved then there isn't much you can do except try to solve something and see if they complain. You could argue that you should talk more with the stakeholders, but most of them don't have the skills required to accurately identify their own problems. Instead they need to see something running and then notice when things are missing, which…

An business analyst appeared in the wild (..) as a consequence of stakeholders not knowing or having the necessary skills. BAs are experts in illiciting user requirements and transforming them into specifications and goals you can use to solve a problem.

Unless you know your goal you will never be able to deliver on your customer's expectations.

Re: A Theory of Software Architecture

#80

Post by ChrisMarshallNY »

I tend to write in a modular, layered fashion (I call it the “layer cake” pattern), and I like to try breaking up large methods to reduce CC. For example, I might break a large switch statement up into “sets” of handlers.

The main motivation for this, is because I use what I call “evolutionary design.” I tend to refine design as I progress through development, as opposed to having it substantially complete at the start (A lot of classic developers probably just defecated masonry at the very thought of that, but it WFM). Having a finer granularity goes a long way, in supporting this methodology.

It also helps a lot for refactoring, improvements, and testing. The overall quality of my products is drastically enhanced by modularity.

Post reply on HN