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

Learning Software Architecture

matklad.github.io

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Learning Software Architecture

#81

Post by dmitrijbelikov »

CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Good, really good. But not real. You can achieve such ideal only without human which makes no sense.

Re: Learning Software Architecture

#82

Post by vova_hn2 »

> the phenomenon of “scientific code”

I have some experience being a software engineer in a data science team or in a team adjacent to a DS team, a lot of problems that they think are "data science problems" are actually software engineering problems being solved in an extremely convoluted and weird way.

I think that if DS community wasn't so resistant to basic SE good practices, or involved engineers in making architectural decisions, total time and effort needed to solve some problems would be greatly reduced.

When I'm in a bad mood, I even entertain a silly conspiracy theory in my head: they do everything in the most ugly and weird way specifically to keep people like me out :)

Re: Learning Software Architecture

#83

Post by skydhash »

NeutralForest wrote: post #18

Software design/architecture is a strange beast. It feels that if you want to learn it, you should spend time in legacy systems and large codebases of rewrite a project 3 times to explore counterfactuals. A lot of books on the subjects are abstract and give such simple examples, they are useless.

> A lot of books on the subjects are abstract and give such simple examples, they are useless

They are abstract because architecture is for dealing with pain, and you can’t explain pain. You need to experience it and reflect on what was done wrong to be in trouble. The examples are like a gentle pinch which does not prepare you for pulling a muscle in your back or having a nail in your foot.

My strategy is to read the books, try to implement the things at least once to get a sense of the costs, and then get back to it once you’re experiencing pain in your project. It may be too late, but you will then learn the lesson.

Re: Learning Software Architecture

#84

Post by ragnese »

mwexler wrote: post #44
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Can you explain the last one? What types of communications are you suggesting an arch would avoid? Otherwise, a very wise list!

When I read it, I assumed it meant like network communication in your program. File and network I/O having/being a "tax" makes sense to me.

Re: Learning Software Architecture

#85

Post by perkovsky »

electrosphere wrote: post #52
CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Good list! One addition? * start with a modular monolith

Yes. I’d add: design the module boundaries before splitting deployment.

A modular monolith still forces you to name ownership, data boundaries and invariants, but without making every mistake a networking/ops problem.

Re: Learning Software Architecture

#86

Post by bfivyvysj »

CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Great list but I dunno about coupling being evil, it is literally the only place anything important happens.

Re: Learning Software Architecture

#88

Post by kachnuv_ocasek »

CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

What exactly do you mean by “make state explicit”?

Re: Learning Software Architecture

#89

Post by avgDev »

CSMastermind wrote: post #37

I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…

Good list, although things get weird when you are limited by some legacy software/database.
Post reply on HN