Posts

Notes about Tidy First?

This is a short new book by Kent Beck, having almost 100 pages #surprising . Most of the chapters are one or two pages long. Foreword I liked an old quote by Benjamin Brewster in Foreword, saying: In theory, there is no difference between theory and practice, while in practice, there is. According to Larry Constantine, who wrote the Foreword and who coined Cohesion and Coupling, Cohesion and Coupling are how our brains deal with complicated systems. Using relationships between pieces of code. Nice and tidy. That's the theory. Preface Beck calls his design "Empirical". Why? The most debates in software design are about microservices, how big repositories should be, events versus explicit calls, objects versus imperative code. These "What" debates hide more fundamental disagreement in software design. What Beck misses in the debates is "When". We have two extremes from the "When" perspective: Speculative design - we know what we will want to d

Notes about Growing Object-Oriented Software, Guided by Tests

These are my notes about the the book of London school of thought regarding TDD. Both Martin Fowler in his essay and Kent Beck in the Foreword say they practice TDD differently. Therefore I was expecting what I thought was mockist style of testing, with too-small unit tests coupled too much to the implementation, based on what I saw in some companies in Prague (Czechia). I was very surprised with the quality of tips the authors provided. I don't like the first part of the title of the book, a farming metaphor of programming, because if overextended, it would seem like we are out of control of growing the software. I do like the subtitle, being "guided by the tests". The authors make a point of " listening to the tests " and responding to hints of the tests about the design of the production code as well. Chapter 1 - What Is the Point of Test-Driven Development? We know building the software is a learning process and we know there will be changes. What we need i

Notes about A Philosophy of Software Design

My notes about the book by John Ousterhout. It is quite a short book. Originally I made a mistake of reading just the Conclusions of the chapters but there is a lot of contents not in the Conclusions. After really reading the whole book, I started to like the Red Flags and other small pieces of hints. Chapter 2 - The Nature of Complexity Complexity is anything related to the structure of a system that makes it hard to understand or modify. Isolating complexity in a place where it will almost never be seen or touched is almost as good as removing it. There are many symptoms of complexity: Change amplification - when change requires modification in many places.  Cognitive load - how much a developer must know in order to make a change. Sometimes more code is simpler than less code because of cognitive load. Unknown unknowns - it is not obvious which places should be modified or what knowledge the developer must have to make a change. Complexity is caused by 2 things - dependencies and o

Notes about the Building Microservices

These are notes for my future self about Sam Newman's book, Building Microservices 2nd edition.  Preface Microservices are an approach to distributed applications that use finely-grained services and change, deploy and release them independently. Microservices have become the default go-to architecture when designing system, which Newman finds hard to justify #surprised and want to share his view on why. Foundation Chapter 1 - What are Microservices? Microservices are independently releasable services modeled around a business domain . They are kind of SOA, but the one which is opinionated about how service boundaries should be drawn and where independent deployability is the key. Microservices should implement information hiding and expose their API in some way, e.g. via REST/JSON API or by emitting events. They should have their own database schema. To highlight that the services are as independent as possible, Newman draws them as hexagons, a homage to Alistair Cockburn's H