Messy code is a nuisance. "Tidying" code, to make it more readable, requires breaking it up into manageable sections. In this practical guide, author Kent Beck, creator of Extreme Programming and pioneer of software patterns, suggests when and where you might apply tidyings to improve your code while keeping the overall structure of the system in mind. Instead of trying to master tidying all at once, this book lets you try out a few examples that make sense for your problem. If you have a big function containing many lines of code, you'll learn how to logically divide it into smaller chunks. Along the way, you'll learn the theory behind software design: coupling, cohesion, discounted cash flows, and optionality.
This book helps you:
- Understand the basic theory of how software design works and the forces that act on it
- Explore the difference between changes to a system's behavior and changes to its structure
- Improve your programming experience by sometimes tidying first and sometimes tidying after
- Learn how to make large changes in small, safe steps
- Approach software design as an exercise in human relationships
Конспект
Software design is an exercise in human relationships.
Таким образом, человеческие отношения - это неотъемлемая часть проектирования ПО. А поскольку непосредственное кодирование - это тоже дизайн/проектирование, то и каждый самый маленький фрагмент кода поддерживает какие-то человеческие отношения.
Проектирование ПО - это “выгодное связывание элементов”. Элементы - это составные части, могут сами включать подэлементы (физическая вложенность систем). Связывание - это возможные отношения между элементами: наследование, вызов, подписка, публикация. Выгода определяет качество выбранных элементов и созданных для них отношений.
С этой точки зрения проектировщики ПО могут делать только три вещи:
- Изменять набор элементов
- Изменять набор отношений
- Изменять выгоду существующих отношений
Поскольку все это обязательно изменяет структуру (но не обязательно поведение) ПО, то ценность от дизайна - всегда отложенная, т.е. будет реализована спустя некоторое время.
Две ценности ПО - поведение и структура - составляющие ценности фундаментально разные. Исходя из природы денег есть два основных совета:
- Доллар сегодня стоит больше, чем доллар завтра, так что стремись зарабатывать раньше, а тратить позже. Это означает релизить функциональность/поведение как можно раньше.
- В хаосе и неопределенности возможности стоят больше, чем вещи, поэтому в таких ситуациях нужно вкладываться в структуру ПО.
Связанность (coupling) определяет стоимость изменений ПО за счет двух векторов: проблема “один-ко-многим” (изменение одного влечет изменение многих, как пример - точки вызова) и каскадные изменения.
Необходимо уменьшать связанность за счет повышения связности (cohesion).
Вопрос “А не прибраться ли мне в коде перед реализацией поведения?” нужно задавать себе снова и снова, на масштабе минут и часов. Каждый раз ответ на этот вопрос будет определен актуальной комбинацией действующих сил:
- Затраты - приборка уменьшит или отложит затраты? Сделает их менее вероятными?
- Выручка - приборка увеличит или ускорит выручку? Сделает ее более вероятной?
- Связанность - приборка снизит количество одновременно изменяемых элементов?
- Связность - приборка сведет изменяемые элементы в маленький обозримый скоуп?
Связи
Упоминает и использует:
- Grokking Simplicity - Normand, Eric - многие рассматривают ООП и ФП как взаимоисключающие парадигмы. Кент согласен с Эриком в том, что “функции внутри объектов” - это более ценный взгляд. Книга о том, как изменяется стоимость разработки при использовании функционального программирования.
- Эффективная работа с унаследованным кодом - книга, вдохновляющая на непрерывное улучшение дизайна несмотря на ограничения, наложенные унаследованным кодом.
- Software Design for Flexibility - представлены подходы к дизайну небольшого масштаба, способные поддержать непрерывное развитие и изменение.
- Code that fits in your head - человеческий мозг поставляется без инструкции по эксплуатации. Эта книга способна стать такой инструкцией для мозга программистов.