- Let's talk about performance quality attribute.
It's one that people are constantly forgetting about.
You know when it's something you can't
just look at your watch and say,
"Does the screen come up in, oh, three seconds?"
Right?
So there's lots of different ways to at performance.
One way that I kinda like to do it
is to research similar applications.
What are people used to?
What are the users expecting?
- Right, and now that a lot of web applications
have more logic in the client itself
that can slow it down,
we have to look at ways to improve perceived performance.
- Ah.
- So, if a user sees the page starting to load,
so the faster loading things
go ahead and render on the screen,
they're happy.
They got something.
And so it's okay that some things might take longer.
So, it's a good idea if performance is an
important criteria for your application.
To plan an architecture spike,
write some throw away code that
embodies the approach that you want to use.
Do some load testing, make sure it works for ya.
And then go back and write your real code.
Discuss architectural options.
For example, using caching logic in your client later.
Optimizing your database queries.
Think about your trade offs with the ease of maintenance
for your code and whether you can add features later on.
- Those are all really good ways
to be thinking about how to improve.
You used a word there, spike.
Architectural spike.
What do you mean by an architectural spike?
- Well, if the developers have come up with
an architecture that they think would scale
to the number of users who will be using the application,
they wanna know if they were right about that.
And so, they can kind of write a skeleton of the code
without doing testing in development,
and just throw some code together that does
what they expect using that approach.
Do some load testing and just to see if it scales.
And give 'em more confidence that now they can
write the real code the real way,
and it'll be okay.
- Like a proof of concept.
- Exactly. - Yeah.
So the one thing I urge you to really think about,
if you hear the word proof of concept, spike,
maybe even prototype. - Prototype.
- Those are all throw aways.
You throw it away and then you start.
Because otherwise you put in technical debt.
Immediately in.
So watch for those sorts of things.
I find too that when I work with the programmers
and we're talking about performance,
quite often they'll say,
"Hey, Janet, we can put hooks into the framework
so we can actually measure."
Then you can start thinking about how do you monitor it.
So it's important to keep that whole team working on,
and thinking about, what it is you want to do.
Our last section in this lesson,
is planning for the end game.