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

61–70 of 133 posts

Re: Learning Software Architecture

#61

Post by mplanchard »

jerf wrote: post #41
woodydesign wrote: post #2

[flagged]

I think of it this way. Software architecture can not be taught. (This is not particularly uncommon, and so not a claim to being particularly special.) But you can sensitize people to the problems they will encounter and solutions they should consider. You can't "teach" someone into being a software architect of 10 "software architecture goodness units", but you can accelerate the rate at which they accumulate SAGUs…

It’s tangential to your point, which I agree with completely, but this is also exactly why I get so frustrated with the idea that higher education is about acquiring job skills. Ideally, regardless of major, a university teaches you how to think, critically and deeply, and how to learn. If you have those things, job skills are easy to pick up, but instead we treat college like an RPG skill tree, where you’ve got to put points into your intended career path in order to unlock the skills you’ll need to do the job.

Edit: although I do think university focus is important for subjects that are less about job skills and more about knowledge synthesis, such as most sciences, critical analysis, and so on, if you intend to not just do a job but contribute to the overall knowledge base of the field.

Re: Learning Software Architecture

#62

Post by collabs »

gavmor wrote: post #57
theteapot wrote: post #48

Earlier quoted context omitted.

Completely agree. Had me until the very last point. WTF. Communicate.

I wonder if they don't mean "between systems".

> Communication is a tax that you should justify before paying it.

I thought it meant like keep things as local as possible. Like within the same process, within the same machine, avoid going through the network because staying on the processor is always the fastest, going to ram is next fastest, and if you need to communicate across the network it is always slowest

Re: Learning Software Architecture

#63

Post by AnimalMuppet »

laszlojamf wrote: post #39
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…

I'd add - data migrations are inevitable and should be planned for (corollary of versioning) - planning is good, sometimes you just have to try things out - everything costs money. Designing without costs in mind will force hard choices down the line

I'll add another to that:

- Code lives longer than you expect. You forget sooner than you expect. Make a readme/architecture overview/theory of operation document. Put more in it than you think is needed. Check it in with the code.

Re: Learning Software Architecture

#64

Post by [deleted] »

theteapot wrote: post #26
npl wrote: post #19

I think there is huge space for architecture case studies that help a non coder learn how to critique llm architecture decisions. I’m a NP - lots of learning came in clinical rotations where you see real life situations and how they are addressed. I want something like this for software architecture. The closest I’ve seen is the open source case study books referenced previously but these are older. I’d like to be ab…

Nurse Practitioner? I would say SOLID [1] is a good start, but then I watched this [2] and now I'm in crisis and can't code anymore. [1]: https://en.wikipedia.org/wiki/SOLID [2]: https://www.youtube.com/watch?v=wo84LFzx5nI

[deleted]

Re: Learning Software Architecture

#65

Post by alex1sa »

jdw64 wrote: post #11

Most codebases eventually take on similar shapes, depending on their size and on the IoC model imposed by the framework. And when you try to prevent that IoC from leaking into the domain too much, the design often starts to look like hexagonal architecture. Programming often feels like inventing a new form, but in the end we tend to converge on the shapes that previous programmers already discovered.

[dead]

Re: Learning Software Architecture

#66

Post by ah1508 »

I think that words like "clean code" or "beautiful code" does help juniors to learn best practices of software architecture.

  - Junior asks to senior: what did you we use an ORM ?
  - senior answers: because it's cleaner.
  - junior: ???
I prefer when people are able to define a clear list of objectives:

  - maintenable;
  - performant, scalable;
  - efficient;
  - resilient;
  - observable;
  - testable (and tested);
  - secured;
  - readable for new devs that come on board.
Each criteria balance the others, and the more we add criteria the more it helps to make good choice when we hesitate. It is also meaningful for people outside of the dev team, we can reach an agreement with the customer so he knows what he pays for.

"maintenable" can be also defined, since a project is mostly in maintenance mode during its lifetime (which means the project is successful, which is good !). The ability to incorporate new features without breaking architecture or even without breaking a single method signature is a good starting point.

Being super careful with abstractions. Here someone wrote something like that: "abstraction often hides how what you want is simple". True, ORM I am looking at you. In most case data should be threaten as first class citizen, it also fosters good collaboration with the DBA.

Thinking beyond "the happy path" without falling in premature optimization is also a challenge. A nice one, once again to it avoids to go head first in implementing a good idea without considering drawbacks.

I also tend to imagine that the one that will work on my code had a very bad day so it must be pleasant to read what I wrote. Comments here and there, locale variable here and there even if they can be avoided, variable naming, etc...

Being selective about frameworks. They are good servant but bad leaders. "Be an engineer, not a frameworker" says an article.

Re: Learning Software Architecture

#68

Post by alternatex »

collabs wrote: post #62
gavmor wrote: post #57

Earlier quoted context omitted.

I wonder if they don't mean "between systems".

> Communication is a tax that you should justify before paying it. I thought it meant like keep things as local as possible. Like within the same process, within the same machine, avoid going through the network because staying on the processor is always the fastest, going to ram is next fastest, and if you need to communicate across the network it is always slowest

I don't think performance advice should be part of a general architectural principles list, so I don't think that's what they meant. Otherwise might as well add "avoid nested loops", etc, and then it devolves into a general programming advice list.

Performance is and always was something dependent on the domain rules. You don't start architecting for performance before understanding requirements so why make it a pillar of all architecture.

Re: Learning Software Architecture

#70

Post by getnormality »

A lot of people seem to lean too much on Conway's Law. It takes social organization as primary instead of itself shaped by the nature of a problem. Maybe the reason Sales and Engineering are different departments is because they are different things.
Post reply on HN