Enjoy fast, FREE delivery, exclusive deals and award-winning movies & TV shows with Prime
Try Prime and start saving today with Fast, FREE Delivery
Tuesday, June 13
Ships from: Amazon.com Sold by: Amazon.com
Other Sellers on Amazon
+ $3.99 shipping
85% positive over last 12 months
Usually ships within 4 to 5 days.
+ $3.99 shipping
84% positive over last 12 months
Usually ships within 2 to 3 days.
& FREE Shipping
71% positive over last 12 months
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required. Learn more
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis 1st Edition
90 days FREE. Terms apply.
90 days FREE of Amazon Music Unlimited. Included with purchase of an eligible product. You will receive an email with signup instructions. Renews automatically. New subscribers only. Terms apply. Offered by Amazon.com. Here's how (restrictions apply)
Purchase options and add-ons
Are you working on a codebase where cost overruns, death marches, and heroic fights with legacy code monsters are the norm? Battle these adversaries with novel ways to identify and prioritize technical debt, based on behavioral data from how developers work with code. And that's just for starters. Because good code involves social design, as well as technical design, you can find surprising dependencies between people and code to resolve coordination bottlenecks among teams. Best of all, the techniques build on behavioral data that you already have: your version-control system. Join the fight for better code!
Use statistics and data science to uncover both problematic code and the behavioral patterns of the developers who build your software. This combination gives you insights you can't get from the code alone. Use these insights to prioritize refactoring needs, measure their effect, find implicit dependencies between different modules, and automatically create knowledge maps of your system based on actual code contributions.
In a radical, much-needed change from common practice, guide organizational decisions with objective data by measuring how well your development teams align with the software architecture. Discover a comprehensive set of practical analysis techniques based on version-control data, where each point is illustrated with a case study from a real-world codebase. Because the techniques are language neutral, you can apply them to your own code no matter what programming language you use. Guide organizational decisions with objective data by measuring how well your development teams align with the software architecture. Apply research findings from social psychology to software development, ensuring you get the tools you need to coach your organization towards better code.
If you're an experienced programmer, software architect, or technical manager, you'll get a new perspective that will change how you work with code.
What You Need:You don't have to install anything to follow along in the book. TThe case studies in the book use well-known open source projects hosted on GitHub. You'll use CodeScene, a free software analysis tool for open source projects, for the case studies. We also discuss alternative tooling options where they exist.
Frequently bought together
Special offers and product promotions
- 90 days FREE of Amazon Music Unlimited. Included with purchase of an eligible product. You will receive an email with signup instructions. Renews automatically. New subscribers only. Terms apply. Offered by Amazon.com. Here's how (restrictions apply)
From the brand
From the Publisher
Q&A with author Adam Tornhill
Why did you decide to write this book?
I've spent much of my career trying to improve existing code, and I found it progressively harder as software systems and organizations keep growing in scale. Even though the software industry has improved dramatically over the two decades I've been part of it, we do keep repeating avoidable mistakes by isolating our influences to technical fields. I wrote this book to provide that missing link between technical and social sciences. This blend, behavioral code analysis, lets us prioritize technical debt based on the most likely return on investment, evaluate our software architecture based on how well it supports the work we do, bridge the gap between developers and business oriented people, and much more. My goal was to take mainstream software development one step closer to a point where decisions -- both technical and organizational -- are influenced by data and research from multiple fields. I'm really, really happy with the end result and hope you'll enjoy it too.
What kind of experience would help readers get the most out of this book?
To get the most out of this book you should be an experienced programmer, technical lead, or software architect. The most important thing is that you have worked on larger software projects and experienced the various pains and problems. You don't have to be a programming expert, but you should be comfortable looking at smaller code samples. Most of the discussions are on a conceptual level and since the analyses are technology-neutral, the book will apply no matter what programming language you work with.
What do you hope readers take away from this book?
The key point in the book is to base decisions on data by putting numbers on our gut feelings. Software development, and in particular the people side of it, is notoriously hard to get right. By embracing behavioral code analysis we get to tap into the social side of code and start to measure things that we cannot deduce from the code alone, like communication and coordination needs, Conway's Law, and long-term complexity trends. I also want to point out that behavioral code analysis doesn't offer any silver bullets, nor does it intend to replace anything. Instead the techniques in this book are here to complement your existing expertise by focusing your attention on the parts of the system that need it the most.
How does this book compare to 'Your Code As A Crime Scene'?
Software Design X-Rays represents the evolution of the ideas from my previous book, Your Code As A Crime Scene. If you read the previous book, you're already familiar with hotspots and some of the change coupling metrics presented in chapters 2 and 3. These two concepts lay the foundation for the more advanced analyses, and the new book goes deeper into both areas. Most of the material points out new directions that I haven't covered before. Software Design X-Rays is of course also interdisciplinary and blends software engineering with psychology, but this time there are no direct forensic references.
What's your favorite part of the book?
I like chapter 4 on refactoring patterns since it makes the technical debt detection techniques actionable by providing specific recommendations. I also enjoyed writing chapter 7, Beyond Conway's Law, that brings some valuable findings from group psychology into the software field. Those findings fill out the missing pieces in Conway's Law and helps guide your organization towards better code. Finally, I have to mention the last chapter which explores preventive and predictive uses of behavioral code analysis. I like that chapter because the resulting information becomes like an extra team member that points out areas of the code in need of our attention as we code along.
|Your Code as a Crime Scene|
|Also by Adam Tornhill||Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs|
About the Author
- Publisher : Pragmatic Bookshelf; 1st edition (April 17, 2018)
- Language : English
- Paperback : 276 pages
- ISBN-10 : 1680502727
- ISBN-13 : 978-1680502725
- Item Weight : 1.14 pounds
- Dimensions : 7.5 x 0.58 x 9.25 inches
- Best Sellers Rank: #1,204,792 in Books (See Top 100 in Books)
- #273 in Computer Hardware Design & Architecture
- #1,581 in Microsoft Programming (Books)
- #3,385 in Software Design, Testing & Engineering (Books)
- Customer Reviews:
Top reviews from other countries
I find really hard day-to-day is to justify refactoring to managers or non-technical decision-makers. It is often seen as a nice to have, and I always had difficulty communicating about it. The insights I found in this book help me better communicate where the complexity lies, and where more design is necessary, as well where it is not, as often the biggest downside of mentioning refactoring is it can take too long without immediate benefits. Now I don't find it necessary everywhere and I can better prioritize slices of where features get stuck and reduce maintenance difficulties at the same time.
This book also helped me look at how a function or class grows over time in order to mine the assumptions hidden behind why it is like that and how to change it further. It helped with my mental model of how to navigate my implementations day to day too.
On part pourtant d'un constat de base simple : le fonctionnement de Git (ou autre SCV peu importe) fait que vous avez à votre disposition tout l'historique du projet, d'où la question "que peut-on tirer de cette mine d'informations ?" Et bien énormément, ce que l'auteur nous démontre au fil du livre, en se basant sur l'analyse de véritables projets open-source.
Quand on parle de dette technique, ce qui limite l'utilité de la métaphore, c'est qu'on se heurte vite au problème du manque de données. Ce qui fait de ce livre de loin le meilleur que j'ai lu sur ce sujet, c'est qu'il est le plus concret : aborder une codebase inconnue, trouver les problèmes, les prioriser, les rendre tangibles pour les stakeholders, complèter les outils d'analyse statique qui ne peuvent pas prendre en compte l'aspect "legacy" et vous annonce des 40ans/homme de problèmes à résoudre, diagnostiquer les problèmes de bottlenecks entre équipes, etc.
Le tout basé non pas sur des approximations ou des impressions mais des données concrètes et vérifiables.
Anecdote: j'ai pu trouver un bug dans du code inconnu d'une autre équipe juste grâce à l'analyse coupling/duplication.
Bref change complètement la donne quand on parle de dette technique, à recommander à tout professionnel.
À noter que le code utilisé dans le livre est sur Github donc on peut aussi jouer avec.