[deleted]
A Theory of Software Architecture
151–160 of 246 posts
Re: A Theory of Software Architecture
#152My theory is software should be architected with debugability, deployability, and developer friendliness in mind. If you can't deploy your solution on a predictable schedule, with multiple teams working on it in parallel, and keep stakeholders happy, then you are on a fast path to irrelevance no matter how "sophisticated" the architecture is.
Re: A Theory of Software Architecture
#153Earlier quoted context omitted.
> (..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?
I read that as saying that AppDomainAffine is a concept, and that's why it's an unusual name, because a lot of naming these days focuses on mechanics instead of concepts (c.f. MarshalByRefObject)
Re: A Theory of Software Architecture
#154Earlier 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.
It’s less of a problem but it’s still a problem because it forces people to have to keep more context in addition to what they’re really working on. Even experienced developers with the latest IDEs are slowed down when the culture encourages layers of gratuitous complexity, and the gains offered by advanced tooling are often cancelled out by people seeing that tooling as reducing the counter pressure against adding more.
Re: A Theory of Software Architecture
#155But its all rules of thumb and common sense, largely. When are we going to get an axiomatic theory of software engineering/architecture which shall allow us to argue about and compare different architectures for a solution and arrive at an ideal one?
Re: A Theory of Software Architecture
#156Earlier quoted context omitted.
Generally, to those of us who apply the functional approach everywhere, it comes naturally whatever the problem. There are idiomatic ways to program in particular languages (even in Python or JavaScript) which are strictly against the functional approach, even though nothing in those languages prohibits it. It gets trickier with external dependencies which are "forced" on you too. Do you have a concrete "domain" exam…
A shadow DOM. A state manager ;). A protocol implementation which needs state. There are cases where the domain has state. Like said, typically, for request/response cases which is 90% of everything we program nowadays, this state is typically loaded from somewhere else. I am also not particular arguing for OOP here. It is just the absolutism which are an issue.
What about an "update(state, event) -> NewState" design for state machines and stateful protocols?
Re: A Theory of Software Architecture
#157Earlier 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…
No need to create interfaces generally in spring when there will only be one class implementing. For testing, mocks can be created directly from the actual classes.
Re: A Theory of Software Architecture
#158This 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.
> only to eventually discover that there's only one class that implements that interface
I mean, in this case it's literally:
* right click on "someInjectedService"
* select "Go To Implementations"
and you'll be there.
Generally I do relate to the complaint though. DI makes your project feel like a "system" as opposed to a "program" (not that this is a bad thing or unnecessary).
Re: A Theory of Software Architecture
#159I prefer the first example. It’s more straightforward and avoids accidentally creating dependencies (for example some other code calling pluck_definition) that will be make it harder to modify when you need to add features or the API changes.
Testing pluck_definition by itself is completely pointless since it does nothing on its own. This is the “test public interfaces, not private implementation” principle.
Similarly build_url and pluck_definition need to be coupled because they both depend on the specifics of a third party API. It makes it much more clear what the expected output is to keep them together so that if something breaks you know which url to check and what the response should look like.
I also dispute that it’s hard to unit test the first function—-you would simply mock the api response and then you have a great test. Much better than having separate tests for tiny helper functions that do nothing on their own.
Now maybe this example is just too simple and the presented architecture makes more sense on larger code but if so then the article is poorly written. Examples need to be realistic enough not to obfuscate.
Re: A Theory of Software Architecture
#160Earlier quoted context omitted.
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.
BA's work on business software which is typically written to help support processes and workflows that lean toward structure, definition, repeatability and so forth. There's lots of software in the world (all creative software, for example) that doesn't share these attributes, and all the skills of a BA are useless. The scope of software is larger than webdev and larger than business.
Completely agree, and for that you probably have a clear picture of what you want.
I whimsically develop programs for myself that I could manually sort out in 5-10 minuts if done sequentially.