Artyom Karpov

This book attempts to compile the best practices for software construction accumulated over the years. With approximately 450 bibliographic references to the most important publications at the time (second edition published in 2004), the book aims to elevate the development process to an entirely new level. Essentially, it interprets the most significant publications and provides guidelines for building software. It takes recommendations from field experts and scientists and presents practical rules for effectively creating quality software, thus bridging the gap between production and research. Hence the title, which implies a comprehensive set of laws.

The book is divided into seven parts. Starting with basic terms and ideas in Part I, the author progresses from the fundamental level of the construction process—the code itself (Parts II, III, IV)—to higher-level processes. Part V focuses on working with existing code. Part VI covers system development control. The final part, Part VII, addresses requirements for the creator themselves. For quick reference, the book includes checklists for all construction stages, along with numerous figures, tables, and key terms.

Below are some of my notes from the book.

This great book, written by D. Esposito & A. Saltarello, collects recipes for creating solutions for enterprise applications. It is not a typical cookbook but provides guiding principles for creating a ‘dish’. The book is based on the authors’ experience and common practices from other books. The second edition, published in January 2015, seems to be a good summation of best practices with a brief history of their development in the .NET world.

The authors begin by answering questions such as: What is the architecture of applications? Who are software architects? How do modern apps differ from past developments? The book can be divided into two parts (though the authors divide it into four parts). The first part provides answers to questions like: What is needed for successful work? What is required from a team? What is code quality and how to achieve it? The second part offers practical recommendations for developers, including types of architecture, their components, and main advantages and disadvantages.

In my opinion, practical experience in software development is required to fully understand the book; it is not intended for beginners.

Below are notes and mind maps of the book.

This is the book you need if you wish to develop an application for quickly evolving, complex enterprise systems. Though it has some outdated parts, probably every serious programmer should read it. The book is about patterns for building enterprise applications that are ordered for specific users, with the main limitation being development time and intended for long-term use. The authors compiled many years of top professional developers’ wisdom. They do not need an introduction, I guess (especially Martin Fowler).

The book is large and divided into two parts. The first part provides a tutorial on applying patterns. The second part serves as a reference.

Below are my very short notes on some key chapters.

This is a popular book from 1999 that has not lost its value, even now. It was created by coders who developed their applications in the 1980s and 1990s. It seems the authors gained more success as writers or speakers than as actual programmers. As the title suggests, it is about how to become a productive programmer and the rules for doing so. These rules range from general principles (like fixing a ‘broken window’) to specific techniques (like using postconditions).

Most of the time, it is better to think through your own examples to connect the dots and remember the concepts, but the book’s examples can also be helpful. The book offers some enlightening thoughts about programming philosophy, such as the idea that the primary material we work with is plain text, and therefore we must master the right tools.

I use the rules from this book in my everyday work and strongly recommend it to any programmer, regardless of their programming language or platform. Below are my notes from the book.

(Прим. Оригинал статьи на http://dannorth.net/introducing-bdd. Дэн Норт — преподаватель agile методологий разработки. Разрабатывает ПО и учит этому около 20 лет. Создатель собственного агентства по консультированию и разработке ПО. Ввел понятие разработка через поведение (BDD). Опубликовал этот перевод на Хабре здесь.)

История: Эта статья впервые появилась в журнале Better Software в марте 2006. Она была переведена на несколько языков.

Однажды я столкнулся с проблемой. Обучая разработчиков практикам agile программирования, таким как TDD в различных проектах, я часто встречал непонимание и растерянность. Они хотели знать, где начать, что тестировать, а что не тестировать, как много тестировать за раз, как называть тесты и как понять, почему тесты падают.

Чем больше я пользовался TDD, тем больше я понимал, что не столько оттачиваю своё мастерство, достигая новых его вершин, сколько то, что это было движение в слепую. Я помню, как мне все чаще приходила мысль: “Эх, вот бы мне кто-нибудь сказал это раньше!”, чем мысль: “Отлично, дорога ясна”. Я решил, что нужно найти способ обучать TDD, показывающий, как верно работать с ним сразу и без ошибок.

И этот способ — это программирование через поведение. Оно выросло из выработанных agile практик и призвано сделать их доступнее и эффективнее для команд, незнакомых с ними. Со временем, BDD стало включать в себя agile анализ и автоматическое приемочное (прим. acceptance) тестирование.