AOSA Series

AOSA Vol 1. Preface

목공은 까다로운 기술이며, 사람들은 목공을 잘하는 방법을 배우기 위해 평생을 보낼 수 있습니다. 하지만 목공은 건축이 아닙니다. 피치 보드와 연귀 이음에서 한 발짝 물러나면 건물 전체를 설계해야 하며, 이를 수행하는 것은 공예나 과학만큼이나 예술입니다. Carpentry is an exacting craft, and people can spend their entire lives learning how to do it well. But carpentry is not architecture: if we step back from pitch boards and miter joints, buildings as a whole must be designed, and doing that is as much an art as it is a craft or science.

프로그래밍 또한 까다로운 기술이며, 사람들은 평생 동안 프로그래밍을 잘하는 방법을 배우는 데 시간을 할애할 수 있습니다. 하지만 프로그래밍은 소프트웨어 아키텍처가 아닙니다. 많은 프로그래머는 더 큰 설계 문제에 대해 수년간 고민하거나 씨름합니다: 이 애플리케이션을 확장할 수 있어야 하는가? 그렇다면 스크립팅 인터페이스를 제공해야 하는가, 플러그인 메커니즘을 통해 해야 하는가, 아니면 완전히 다른 방식으로 해야 하는가? 클라이언트가 해야 할 일은 무엇이고, 서버에 맡겨야 할 일은 무엇이며, '클라이언트-서버'가 이 애플리케이션에 대해 생각할 때 유용한 방법일까요? 이는 계단을 어디에 놓을 것인지가 목공의 문제인 것처럼 프로그래밍에 관한 질문이 아닙니다. Programming is also an exacting craft, and people can spend their entire lives learning how to do it well. But programming is not software architecture. Many programmers spend years thinking about (or wrestling with) larger design issues: Should this application be extensible? If so, should that be done by providing a scripting interface, through some sort of plugin mechanism, or in some other way entirely? What should be done by the client, what should be left to the server, and is "client-server" even a useful way to think about this application? These are not programming questions, any more than where to put the stairs is a question of carpentry.

건물 건축과 소프트웨어 아키텍처는 공통점이 많지만 한 가지 중요한 차이점이 있습니다. 건축가는 교육 과정과 커리어를 통해 수천 개의 건물을 연구하는 반면, 대부분의 소프트웨어 개발자는 소수의 대형 프로그램만 잘 알 수 있습니다. 그리고 그 대부분은 자신이 직접 작성한 프로그램인 경우가 많습니다. 그들은 역사상 위대한 프로그램을 보거나 숙련된 실무자가 작성한 프로그램 설계에 대한 비평을 읽을 기회도 없습니다. 그 결과, 그들은 서로의 성공을 기반으로 구축하기보다는 서로의 실수를 반복합니다. Building architecture and software architecture have a lot in common, but there is one crucial difference. While architects study thousands of buildings in their training and during their careers, most software developers only ever get to know a handful of large programs well. And more often than not, those are programs they wrote themselves. They never get to see the great programs of history, or read critiques of those programs' designs written by experienced practitioners. As a result, they repeat one another's mistakes rather than building on one another's successes.

이 책은 이를 바꾸기 위한 시도입니다. 각 장에서는 오픈 소스 애플리케이션의 구조, 각 부분의 상호 작용 방식, 그렇게 만들어진 이유, 다른 큰 디자인 문제에 적용할 수 있는 교훈 등 오픈 소스 애플리케이션의 아키텍처에 대해 설명합니다. 이러한 설명은 소프트웨어를 가장 잘 아는 사람들, 즉 복잡한 애플리케이션을 설계하고 재설계한 경험이 수년 또는 수십 년 있는 사람들이 작성합니다. 애플리케이션은 간단한 그리기 프로그램과 웹 기반 스프레드시트부터 컴파일러 툴킷과 수백만 줄의 시각화 패키지에 이르기까지 그 규모가 다양합니다. 출시된 지 몇 년 되지 않은 애플리케이션도 있고, 30주년을 맞이하는 애플리케이션도 있습니다. 이 모든 것의 공통점은 제작자가 디자인에 대해 오랫동안 열심히 고민했고, 그 생각을 여러분과 기꺼이 공유한다는 것입니다. 여러분도 이들의 작품을 즐겨보시기 바랍니다. This book is our attempt to change that. Each chapter describes the architecture of an open source application: how it is structured, how its parts interact, why it's built that way, and what lessons have been learned that can be applied to other big design problems. The descriptions are written by the people who know the software best, people with years or decades of experience designing and re-designing complex applications. The applications themselves range in scale from simple drawing programs and web-based spreadsheets to compiler toolkits and multi-million line visualization packages. Some are only a few years old, while others are approaching their thirtieth anniversary. What they have in common is that their creators have thought long and hard about their design, and are willing to share those thoughts with you. We hope you enjoy what they have written.

AOSA Vol 2. Preface

In the introduction to Volume 1 of this series, we wrote:

• Building architecture and software architecture have a lot in common, but there is one crucial difference. While architects study thousands of buildings in their training and during their careers, most software developers only ever get to know a handful of large programs well… As a result, they repeat one another's mistakes rather than building on one another's successes… This book is our attempt to change that.

In the year since that book appeared, over two dozen people have worked hard to create the sequel you have in your hands. They have done so because they believe, as we do, that software design can and should be taught by example—that the best way to learn how think like an expert is to study how experts think. From web servers and compilers through health record management systems to the infrastructure that Mozilla uses to get Firefox out the door, there are lessons all around us. We hope that by collecting some of them together in this book, we can help you become a better developer.

The Performance of Open Source Software Introduction. Preface

It’s commonplace to say that computer hardware is now so fast that most developers don’t have to worry about performance. In fact, Douglas Crockford declined to write a chapter for this book for that reason:

• If I were to write a chapter, it would be about anti-performance: most effort spent in pursuit of performance is wasted. I don’t think that is what you are looking for.

Donald Knuth made the same point thirty years ago:

• We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

but between mobile devices with limited power and memory, and data analysis projects that need to process terabytes, a growing number of developers do need to make their code faster, their data structures smaller, and their response times shorter. However, while hundreds of textbooks explain the basics of operating systems, networks, computer graphics, and databases, few (if any) explain how to find and fix things in real applications that are simply too damn slow.

This collection of case studies is our attempt to fill that gap. Each chapter is written by real developers who have had to make an existing system faster or who had to design something to be fast in the first place. They cover many different kinds of software and performance goals; what they have in common is a detailed understanding of what actually happens when, and how the different parts of large applications fit together. Our hope is that this book will—like its predecessor The Architecture of Open Source Applications—help you become a better developer by letting you look over these experts’ shoulders.

500 Lines or Less. Preface

This is the fourth volume in the Architecture of Open Source Applications series, and the first to not feature the words "open source applications" anywhere in the title.

The first three volumes in the series were about big problems that big programs have to solve. For an engineer who is early in their career, it may be a challenge to understand and build upon programs that are much bigger than a few thousand lines of code, so, while big problems can be interesting to read about, they can also be challenging to learn from.

500 Lines or Less focuses on the design decisions that programmers make in the small when they are building something new. The programs you will read about in this book were all written from scratch for this purpose (although several of them were inspired by larger projects that the authors had worked on previously).

Before reading each chapter, we encourage you to first think about how you might solve the problem. What design considerations or constraints do you think the author is going to consider important? What abstractions do you expect to see? How do you think the problem is going to be decomposed? Then, when reading the chapter, try to identify what surprised you. It is our hope that you will learn more by doing this than by simply reading through each chapter from beginning to end.

Writing a useful program in fewer than 500 lines of source code---without resorting to cheap tricks---is a challenging exercise in itself; writing one to be read for pedagogical purposes when neatly rendered in a printed book is even tougher. As such, the editors have occasionally taken liberties with some of the source formatting when porting it into the book. The original source for each chapter can be found in the code subdirectory of its project folder.

We hope that the experiences of the authors in this book will help you grow out of your comfort zone in your own programming practice.