Developers

Recommendations

Info

What does “agility” mean?
Observe Orient Act Decide John Boyd, US Air Force
Page 1 and 2:
Software Architecture for Developer
Page 3 and 4:
Jersey
Page 5 and 6:
I help software teams understand so
Page 7 and 8:
A developer-friendly guide to softw
Page 9 and 10:
What is software architecture?
Page 11 and 12:
Designing software
Page 13 and 14:
Documenting software
Page 15 and 16:
What is software architecture?
Page 17 and 18:
What is “architecture”?
Page 19 and 20:
As a verb... Vision The process of
Page 21 and 22:
Enterprise Architecture Structure a
Page 23 and 24:
What is design? All architecture is
Page 25 and 26:
Web Application Significant Another
Page 27 and 28:
Is software architecture important?
Page 29 and 30:
No defined structure, inconsistent
Page 31 and 32:
Shared vision of WTF?!
Page 33 and 34:
What is software architecture? Arch
Page 35 and 36:
Seeing the big picture
Page 37 and 38:
Software architect as team leader P
Page 39 and 40:
Project Manager, Software Architect
Page 41 and 42:
The software architecture role is d
Page 43 and 44:
Surely we must be able That’s ***
Page 45 and 46:
Abstract Specific Sometimes you nee
Page 47 and 48:
Software architecture is a post-tec
Page 49 and 50:
Learn how to step back and see the
Page 51 and 52:
The low-level details are important
Page 53 and 54:
Is that how we are going to build i
Page 55 and 56:
Should software architects write co
Page 57 and 58:
Software architects must be master
Page 59 and 60:
Software architecture is about tech
Page 61 and 62:
Leadership Communication Influencin
Page 63 and 64:
Talking with Tech Leads From Novice
Page 65 and 66:
Be proactive and lead by example
Page 67 and 68:
Architectural Drivers Understanding
Page 69 and 70:
Software architecture introduces co
Page 71 and 72:
1. Agree on some things 2. Put some
Page 73 and 74:
Sits in an ivory tower Architect Fo
Page 75 and 76:
Most importantly, rockstar engineer
Page 77 and 78:
Implementing the role
Page 79 and 80:
Generalising Specialist Generalisin
Page 81 and 82:
Generalising Specialist Generalist
Page 83 and 84:
How can I write code when I have se
Page 85 and 86:
Every software development team nee
Page 87 and 88:
The role Responsibility 1 Responsib
Page 89 and 90:
The software architecture role It
Page 91 and 92:
Requirements
Page 93 and 94:
How many elephants did you see at t
Page 95 and 96:
Quality Attributes Performance Scal
Page 97 and 98:
Understand how to refine them What
Page 99 and 100:
Understand how to challenge them Ar
Page 101 and 102:
Learn about and understand the (oft
Page 103 and 104:
Software lives in the real world, a
Page 105 and 106:
Scope Small scope = low cost and sh
Page 107 and 108:
People & skills (e.g. team size, le
Page 109 and 110:
Beware that constraints can drive t
Page 111 and 112:
Understand what the constraints are
Page 113 and 114:
Principles are the things you want
Page 115 and 116:
Architectural layering, no business
Page 117 and 118:
Designing software
Page 119 and 120:
How do you design software? (techni
Page 121 and 122:
Questions Will we receive all of th
Page 123 and 124:
Don’t blindly focus on the code;
Page 125 and 126:
Communicating design
Page 127 and 128:
What’s been challenging about the
Page 129:
Review the diagrams 3 things we lik
Page 132 and 133:
9 out of 10 people don’t use UML
Page 134 and 135:
In my experience, software teams ar
Page 136 and 137:
Moving fast requires good communica
Page 140 and 141:
Are these effective sketches?
Page 142 and 143:
Boxes & No Lines
Page 144 and 145:
Stormtroopers
Page 146 and 147:
Generically True
Page 148 and 149:
Deployment vs Execution Context
Page 150 and 151:
Homeless Old C# Object (HOCO)
Page 152 and 153:
Should have used a whiteboard
Page 154 and 155:
Effective sketches
Page 156 and 157:
Collaborative design (e.g. pair arc
Page 159 and 160:
Titles Short and meaningful, number
Page 161 and 162:
The C4 model
Page 163 and 164:
Do the names of those views make se
Page 165 and 166:
Software System iner file system, e
Page 167 and 168:
System Context The system plus user
Page 169 and 170:
C4++ Enterprise context User interf
Page 171 and 172:
Diagrams are maps that help a team
Page 173 and 174:
A common set of abstractions is mor
Page 175 and 176:
Context •What are we building?
Page 177 and 178:
Components •What components/ serv
Page 179 and 180:
I do use UML (activity, class, sequ
Page 181 and 182:
Software architecture vs code
Page 183 and 184:
Does your code reflect the abstract
Page 185 and 186:
Controller A Presentation layer Con
Page 187 and 188:
Controller A Controller B Feature S
Page 189 and 190:
https://github.com/techtribesje/tec
Page 191 and 192:
Controller A Controller B Feature S
Page 193 and 194:
“In the early days of computing w
Page 195 and 196:
Instead of blindly unit testing eve
Page 197 and 198:
System Tests UI, API, functional an
Page 199 and 200:
Software architecture as code
Page 201 and 202:
Diagramming tools see packages and
Page 203 and 204:
Spring PetClinic https://github.com
Page 205 and 206:
What are the architecturally signif
Page 207 and 208:
A component diagram, based upon the
Page 209 and 210:
Is the architecture in the code?
Page 211 and 212:
Context People Security groups/role
Page 213 and 214:
Components People Security groups/r
Page 215:
Create an architecture description
Page 220 and 221:
Structurizr Simple, versionable, up
Page 222 and 223:
Spring PetClinic - Containers
Page 224 and 225:
A model as code provides opportunit
Page 226 and 227:
Software architecture really is for
Page 228 and 229:
The C4 sketches are a great way to
Page 230 and 231: Architecture sketching assists with
Page 232 and 233: Architecture sketches are not compr
Page 234 and 235: Leave your sketches on the wall
Page 236 and 237: Communicating design Agree upon a c
Page 238 and 239: Working software over comprehensive
Page 240 and 241: Should software be documented?
Page 242 and 243: The code doesn’t tell the whole s
Page 244 and 245: The bus factor (it’s not just abo
Page 246 and 247: Context What is this all about? Fun
Page 248 and 249: Software Architecture Document Maps
Page 250 and 251: An example software guidebook for t
Page 252 and 253: Functional Overview Functional Over
Page 254 and 255: Constraints System must be deployed
Page 256 and 257: Software Architecture Software Arch
Page 258 and 259: Code
Page 260 and 261: Infrastructure Architecture
Page 262 and 263: Operation and Support
Page 264 and 265: How much of the document is up to d
Page 266 and 267: Product vs project
Page 268 and 269: Documenting software The code doesn
Page 270 and 271: Software architecture in the softwa
Page 272 and 273: The software architecture role shou
Page 274 and 275: The “Waterfall” Model Requireme
Page 276 and 277: Agile (e.g. Scrum) Skills Sprint 1
Page 278 and 279: Agile is about moving fast, embraci
Page 282 and 283: Agility is relative and time-based
Page 284 and 285: A good architecture enables agility
Page 286 and 287: Agility is a quality attribute
Page 288 and 289: Think about how to align the softwa
Page 290 and 291: Firm foundations
Page 292 and 293: “just enough”
Page 294 and 295: Analysis or coding?
Page 296 and 297: New project checklist Complex non-f
Page 298 and 299: Web tier Middle tier Database tier
Page 300 and 301: An example timeline from “Beyond
Page 302 and 303: Probability Low (1) Medium (2) High
Page 304 and 305: Like estimates, risks are subjectiv
Page 306 and 307: Risk-storming A collaborative and v
Page 308 and 309: What are the risks of your solution
Page 310 and 311: Does your architecture work? (write
Page 312 and 313: 1. Current Situation abuse and frau
Page 314 and 315: The software architecture role and
Page 316 and 317: The process of software architectin
Page 318 and 319: Sketches for early and quick up fro
Page 320 and 321: A quick summary...
Page 322 and 323: Abstract Specific Sometimes you nee
Page 324 and 325: Software System iner ion server, st
Page 326 and 327: The C4 sketches are a great way to
Page 328 and 329: The code doesn’t tell the whole s
Page 330 and 331:
Documentation should describe what
Page 332 and 333:
Just enough up front design to crea
Page 334 and 335:
There’s a common misconception th
Page 336 and 337:
Software architecture needs to be m
Page 338 and 339:
Define the software architecture ro
Page 340 and 341:
Talk about software architecture in
Page 342 and 343:
I know we need architecture, but ho
Page 344 and 345:
Present the facts, risks and soluti
Page 346:
Do whatever works for you simon.bro
show all

Developers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?