My initial reaction wasn't very enthu Review based on beta version B2. Again like in his previous book he's using mainly the tool he's working on CodeScene , but this time it doesn't appear like black magic - you can easily follow the operations performed, tool is used mainly for illustration purpose.
What else on the pros side? I kinda measure the quality of tech books with number of bookmarks made during the read - I didn't make that many for at least half a year.
Anything on the cons side then? Maybe but I doubt that it's a matter of me reviewing the Beta version, but too frequently I had a feeling that Adam is starting the chapter with a nice concept, a plan for the chapter, a vision of what he wants to send as a message, but Like author has forgotten what was the point or he had a good idea but didn't know what to do with it. Otherwise than that, it's a really good book. View 2 comments. The analysis that the author exposes and the explanations behind them are incredible!
He teaches us how to take advantage of our version control to analyze our way of working and to help us in taking technical decisions refactorings, technical debts priorization Highly recommended!
While I consider first part as far better than the second, such an analytic approach to the code was really refreshing or even enlighting experience. Many of the technical are really actionable, and focus on techniques not tools is definitely most interesting part of this publication.
Dec 02, Nathan Brodsky rated it it was amazing. Easy to follow book. Very clear explanations without a bunch of fluff. Great answers to the whys that you ask when designing software. I'd like to start with the following statement: this is one of the most valuable books on software engineering I've read to date. The rest of the review will hopefully explain why I think so.
The main idea of the book is that we can get lots of valuable information about our code, our architecture and our organization by mining the data in our version control systems.
The reason is that these systems come closest to a log of how the code and architecture have evolved over the years. We can thus " I'd like to start with the following statement: this is one of the most valuable books on software engineering I've read to date. We can thus "replay" and filter this history to detect issues and pull some interesting metrics. For me, I sort of knew the data was there but lacked the guidance on how to make sense of that data.
This book provides both - a way to mine the source control system examples use Git as well as advice on how to make this data useful. The techniques to mine the source control data are presented in both a conceptual and practical way. I really liked that, as the conceptual description allows translating these techniques to other source control systems and the practical examples with specific Git commands, ready to apply allows to try these techniques out.
The guidance on how to interpret this data is what makes this book stand out. The content can be roughly split into three main questions that the book tries to answer: 1.
How to discover the files, methods, and components where paying back technical debt brings the biggest return of investment? Does my architecture support the way my system evolves and if not, how to make it so? Does my organizational design make it easy to work with my system the way it is structured and if not, what can I do about it? This book might at the first sight look like a "legacy code" book, but it very soon proves to be much more than that - for example, the second part not only shows how to detect suboptimal architectural decisions, it also discusses several architecture styles, their pros and cons and how to use data to determine whether a particular style is for you.
I had lots of fun confronting the author's data-driven conclusions with Robert C. Martin's Clean Architecture, which I consider a more principle-based book. The author himself does a lot of such comparisons - putting the industry-accepted principles within the context of real data is what shines throughout Software Design X-Rays.
That is also why you should not expect a prescriptive approach here. The book does not describe any "silver bullets". Rather, it discusses various options, nuances and contexts. Also, it respects software development as an evolutionary process and does not only describe a desired outcome of software engineering effort e.
I saw a lot of this in the third part where Adam suggests that, instead of fighting the way our code is structured with idealized teams breakdown, it might be sometimes more optimal to organize teams around the structure of the code, no matter how broken it is. As mentioned, the content goes way above just "legacy code" and if I could change the subtitle of the book, I would probably name it "Modern software engineering through the lens of data".
You will not only learn from this book how to approach technical cleanups, you will also get valuable lessons from evolution of existing, real-life projects. The examples use publicly available pieces of code written in several different programming languages as well as some polyglot projects. Most of the techniques presented in the book are surprisingly simple, which makes them even more powerful as when reading through the book, I could not reject the urge to start implementing some of them myself and I mostly did.
I had lots of fun analyzing my pet projects, both with my own, half-baked implementations and using the CodeScene tool that Adam has created with his team and which is free for limited use but only with public Git repositories. Indeed, if you are seriously planning to dig into the contents of the book, you'd better familiarize with this tool as most of the examples and illustrations use it. Another plus for me is that the content is presented in a lightweight form, with lots of illustrations and examples and occasional dose of industry humor.
This is not an academic book, and even though it talks a lot about metrics, you can hardly find a math formula inside. All of this made the book an easy read for me. Before I finish this review, several words of warning. First of all, this is the second book by Adam Tornhill on the topic of behavioral code evolution, succeeding Your Code as a Crime Scene.
I did not read that book, but if you did, there might be some content here that you already know. Second, this is probably not a book for novice programmers as it is accurately presented on the cover. You need to at least have some experience with the problems author is addressing to understand why they are relevant and to interpret the results of the techniques presented in the book. Overall, I wholeheartedly recommend this book.
It shifted and expanded my views on code, design, architecture and software organizations and I cannot help but look at these topics now from the perspective of product evolution they are meant to support.
Great book that I should have read before. Really, you are interested in productive modern software development - go get it. It's all about sustainable and well-explained metrics that you may gather and base next actions relying on. Jun 09, Johnny rated it it was amazing.
A great book about how to understand code without spending too much time reading it. If you are interested in the big picture this book will be a great help.
It explains in great detail how you can use Git to find out what part of your code change often, who changed it, which parts need attention and offer themselves as a good starting point for refactoring. With all the commands and ideas on how to visualize them, you can go and use those tricks in your own projects. It is surprisingly easy and A great book about how to understand code without spending too much time reading it.
It is surprisingly easy and helps you to add facts to your suspicions on what part of the codebase should be improved. Jan 28, Marek Kowalcze rated it it was amazing. Very interesting book about how to look at legacy codebase. Too often we just analyse the code as a static snapshot and forget about the time dimension to see how it was changing. Version control history can give us important insights about where the technical debt really is. Highly recommended for anyone related with software development.
Jan 29, Riley Holmes rated it liked it. But I really liked the methods presented for reading the version control history to find problematic pieces of code. I hope to revisit and use these techniques eventually if an appropriate situation arises.
Dec 25, Matt rated it it was amazing. Original, innovative, and outright fantastic. On top of that, Adam's writing is succinct and spot on. This is a top recommendation for any dev thinking about maintainable code. Nov 26, Tom rated it it was amazing. Excellent set of practical tools to use in supplying numerical data to support plans of attack to improve large codebases.
This review has been hidden because it contains spoilers. To view it, click here. Some good technical discussion and quantitive analysis on how modularity can vary within a codebase, but also a lot of liberal bullshit about "social coding". Wrong - how can this be a meaningful discussion? Every technical phenomenon is necessarily preceded by a social phenomenon, at least until AI takes over the world.
There's no point in discussing whether the cause of a technical problem was ultimately Some good technical discussion and quantitive analysis on how modularity can vary within a codebase, but also a lot of liberal bullshit about "social coding".
There's no point in discussing whether the cause of a technical problem was ultimately social or ultimately technical, because it is always both.
Tornhill's distinction between social and technical issues is misguided, in my opinion. When code is written by humans, they're the same damn thing. The most valuable part of this book is not the discussion of git commands or the fancy d3 visualizations or the exercises which I didn't do , but seeing what Tornhill counts. The metrics used to quantitatively analyze problems can also be used to analyze your own codebase in a rigorous way.
For example, that you can measure code duplication by counting linked modifications to different files over many commits, or that writing modular code is most important for large files with many modifications. That last point might me obvious, but I had never seen it articulated so clearly before. May 17, Supriya Srivatsa rated it liked it Shelves: tech. The book has some amazing, really good ideas.
It presents several facets of how something as daily-use as Git can offer numerous, in-depth insights into a codebase, its evolution and even the often undermined social and organisational aspects of software engineering.
The author also brings in psychological constructs often and how it relates to software engineering. I found these interesting but it may not appease all. What I really think could have been better - the writing and structure of the The book has some amazing, really good ideas.
What I really think could have been better - the writing and structure of the book. While it brings forth amazing ideas and concepts, the writing comes across as highly repetitive, often iterating over the same concepts and ideas at different levels of abstraction. Aug 05, Justin rated it really liked it Shelves: software. It manages to eloquently and concisely introduce the idea that technical debt it a human rather than a technical problem, explain the interplay among various actors programmers in this case , and provide a detailed set of instructions to visualize said interplay and technical debt.
Reading this made me realize how little I understand of the codebase lifecycle and the various design patterns proffered as organizational solutions Feb 01, Richard rated it really liked it. Summary: use information from your git logs to track behaviours and bottlenecks hindering project velocity.
Pragmatic tips on CLI based analyses to get you started quickly paired with in depth tips for deep dive into version control history. Unexpectedly, the advice is paired with references to studies backing up the claims of validity for the methods employed in this book.
Nov 26, Zaki Shaheen rated it liked it. A good introduction to behavioral code analysis. This provided me with tools that help me navigate a legacy code base. While Adam is knowledgeable, he does seem to promote his product codesense a bit too much in the book and a lot of tools in the book are only available in codesense. This textbook provides an in-depth introduction to software design, with a focus on object-oriented design, and using th. Early praise for Software Design X-Rays Adam has made one of the most significant contributions to software engineering over the past years.
Listen and ye shall learn. This is a must-read! His social code-analysis techniques turn a dry static codebase into a living, breathing ecosystem and chart its interactions over its lifetime, helping you to identify those areas worth refactoring.
Definitely the right way to go in our industry! Software Design X-Rays provides immediately useable tools and approaches to spot the parts in most dire need of improvement and helps you manage your technical debt. Adam does a great job at explaining that this seemingly complex analysis is actually not that hard and that you can do it right now.
Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information including program listings contained herein.
Our Pragmatic books, screencasts, and audio books can help you and your team create better software and have more fun. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America.
ISBN Encoded using the finest acid-free high-entropy binary digits. Book version: P1. The World of Behavioral Code Analysis. Identify Code with High Interest Rates. Pay Off Your Technical Debt. The Principles of Code Age. Is Software Too Hard? Analyze Code in Multiple Repositories. The Hazards of Productivity and Performance Metrics.
Data Mining with Git, cloc, and CodeScene. Or at least I thought I did, as it turned out to be so much harder than I initially expected. I also want to thank my editor, Adaobi Obi Tulton, for all her support, motivation, and great work in shaping the book. Thanks for all your helpful advice and constructive criticism. Thanks to all of you—your feedback and friendly words are what motivates me to keep doing this.
Finally, I want to thank my family—Jenny, Morten, and Ebbe—for their endless love and support. You mean everything to me and I love you. This is important because our average software project is much less efficient than it could be. The history of large-scale software systems is a tale of cost overruns, death marches, and heroic fights with legacy code monsters.
Repaying technical debt is hard due to the scale of modern software projects; with hundreds of developers and a multitude of technologies, no one has a holistic overview.
In this book, you learn a set of techniques that gives you an easily accessible overview of your codebase, together with methods to prioritize improvements based on the expected return on investment. Good code is as much about social design as it is about technical concerns. We reflect that by learning to uncover organizational inefficiencies, resolve coordination bottlenecks among teams, and assess the consequences of knowledge loss in your organization. In doing so we miss out on long-term trends and social data that are often more important than any property of the code itself.
This means we need to understand how we—as an organization—interact with the code we build. Rather than magic—which is usually a dead end for software—this book relies on data science and human psychology. So this book makes sure to include references to published research so that we know the techniques are effective before attempting them on our own systems. We also make sure to discuss the limitations of the techniques, and suggest alternative approaches when applicable.
Instead, view this book as a way of building a set of skills to complement your existing expertise and make decisions guided by data. The reward is a new perspective on software development that will change how you work with legacy systems. Who Is This Book For? 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 fairly large software projects and experienced the various pains and problems we try to solve in the book.
Most of our 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. You should also have experience with a version-control system. The book progresses from smaller systems to large-scale codebases with millions of lines of code and thousands of developers. The early chapters lay the foundation for the more complex analyses by introducing fundamental concepts like hotspots and dependency analyses based on time and evolution of code.
No analysis is better than the data it operates on, so whatever path you chose through the book, make sure to read Know the Biases and Workarounds for Behavioral Code Analysis, on page , which explains some special cases that you may come across in your work.
If you get stuck, just turn to Appendix 4, Hints and Solutions to the Exercises, on page
0コメント