Software Architecture for Developers Technical leadership by coding,coaching,collaboration,architecture sketching and just enough up front design

A DEVELOPER-FRIENDLY GUIDE TO SOFTWARE ARCHITECTURE,TECHNICAL LEADERSHIP AND THE BALANCE WITH AGILITY
This book is a practical and pragmatic guide to lightweight software architecture for developers. You’ll learn:
The essence of software architecture.
Why the software architecture role should include coding,coaching and collaboration.
The things that you *really* need to think about before coding.
How to visualise your software architecture using simple sketches.
A lightweight approach to documenting your software.
Why there is *no* conflict between agile and architecture.
What “just enough” up front design means.
How to identify risks with risk-storming.
JavaRanch awarded the book 10/10 – “Highly recommended reading.”
FIVE THINGS EVERY DEVELOPER SHOULD KNOW ABOUT SOFTWARE ARCHITECTURE
1. Software architecture isn’t about big design up front
Software architecture has traditionally been associated with big design up front and waterfall-style projects,where a team would ensure that every last element of the software design was considered before any code was written. Software architecture is basically about the high-level structure of a software system and how you get to an understanding of it. This is about the significant decisions that influence the shape of a software system rather than understanding how long every column in the database should be.
2. Every software team needs to consider software architecture
Regardless of the size and complexity of the resulting product,every software team needs to consider software architecture. Why? Put simply,bad things tend to happen if they don’t! If software architecture is about structure and vision,not thinking about this tends to lead to poorly structured,internally inconsistent software systems that are hard to understand,hard to maintain and potentially don’t satisfy one or more of the important non-functional requirements such as performance,scalability or security. Explicitly thinking about software architecture provides you with a way to introduce technical leadership and stacks the odds of a successful delivery in your favour.
3. The software architecture role is about coding,coaching and collaboration
The image that many people have of software architects is of traditional “ivory tower” software architects dictating instructions to an unsuspecting development team. It doesn’t need to be like this though,with modern software architects preferring an approach that favours coding,coaching and collaborative design. The software architecture role doesn’t necessarily need to be undertaken by a single person plus coding is a great way to understand whether the resulting architecture is actually going to work.
4. You don’t need to use UML
Again,traditional views of software architecture often conjure up images of huge UML (Unified Modeling Language) models that attempt to capture every last drop of detail. While creating and communicating a common vision is important,you don’t need to use UML. In fact,you could argue that UML isn’t a great method for communicating software architecture anyway. If you keep a few simple guidelines in mind,lightweight “boxes and lines” style sketches are an effective way to communicate software architecture.
5. A good software architecture enables agility
There’s a common misconception that “architecture” and “agile” are competing forces,there being a conflict between them. This simply isn’t the case though. On the contrary,a good software architecture enables agility,helping you embrace and implement change. Good software architectures aren’t created by themselves though,and some conscious effort is needed.
Contents
Part I – What is software architecture?
Chapter 1. What is architecture?
Chapter 2. Types of architecture
Chapter 3. What is software architecture?
Chapter 4. What is agile software architecture?
Chapter 5. Architecture vs design
Chapter 6. Is software architecture important?
Chapter 7. Questions
Part II – The software architecture role
Chapter 8. The software architecture role
Chapter 9. Should software architects code?
Chapter 10. Software architects should be master builders
Chapter 11. From developer to architect
Chapter 12. Broadening the T
Chapter 13. Soft skills
Chapter 14. Software development is not a relay sport
Chapter 15. Software architecture introduces control?
Chapter 16. Mind the gap
Chapter 17. Where are the software architects of tomorrow?
Chapter 18. Everybody is an architect,except when they’re not
Chapter 19. Software architecture as a consultant
Chapter 20. Questions
Part III – Designing software
Chapter 21. Architectural drivers
Chapter 22. Quality Attributes (non-functional requirements)
Chapter 23. Working with non-functional requirements
Chapter 24. Constraints
Chapter 25. Principles
Chapter 26. Technology is not an implementation detail
Chapter 27. More layers = more complexity
Chapter 28. Collaborative design can help and hinder
Chapter 29. Software architecture is a platform for conversation
Chapter 30. SharePoint projects need software architecture too
Chapter 31. Questions
Part IV – Visualising software
Chapter 32. We have a failure to communicate
Chapter 33. The need for sketches
Chapter 34. Ineffective sketches
Chapter 35. C4: context,containers,components and classes
Chapter 36. Context diagram
Chapter 37. Container diagram
Chapter 38. Component diagram
Chapter 39. Technology choices included or omitted?
Chapter 40. Would you code it that way?
Chapter 41. Software architecture vs code
Chapter 42. You don’t need a UML tool
Chapter 43. Effective sketches
Chapter 44. C4 – FAQ
Chapter 45. Questions
Part V – Documenting software
Chapter 46. The code doesn’t tell the whole story
Chapter 47. Software documentation as a guidebook
Chapter 48. Context
Chapter 49. Functional Overview
Chapter 50. Quality Attributes
Chapter 51. Constraints
Chapter 52. Principles
Chapter 53. Software Architecture
Chapter 54. External Interfaces
Chapter 55. Code
Chapter 56. Data
Chapter 57. Infrastructure Architecture
Chapter 58. Deployment
Chapter 59. Operation and Support
Chapter 60. Decision Log
Chapter 61. Questions
Part VI – Software architecture in the development life cycle
Chapter 62. The conflict between agile and architecture – myth or reality?
Chapter 63. Quantifying risk
Chapter 64. Risk-storming
Chapter 65. Just enough up front design
Chapter 66. Introducing software architecture
Chapter 67. Questions
Part VII – Appendix A: Financial Risk System
Chapter 68. Financial Risk System
Part VIII – Appendix B: Software Guidebook for techtribes.je
Software Architecture for Developers
by: Simon Brown
Pages: 275 pages
Edition 版本:‏ 1
Language 语言: English
Publisher finelybook 出版社:‏ Leanpub
Released: 2015-09-12

Software Architecture for Developers Technical leadership by coding,coaching,collaboration,architecture sketching and just enough up front design.epub
Software Architecture for Developers Technical leadership by coding,coaching,collaboration,architecture sketching and just enough up front design.pdf