# Не бойтесь что-нибудь сломать!

(В оригинале - Don't Be Afraid to Break Things)

Каждому, работающему в ИТ, приходилось работать на проекте, чей код был, мягко говоря, ненадежным. Любое изменение приводило к отказу в какой-нибудь другой, вообще независимой, части. Каждый раз при добавлении чего-нибудь основной целью было внести как можно меньше изменений, каждый раз затаив дыхание. Работать с таким ПО – все равно что играть в Дженгу в настоящем небоскребе, вытаскивая из конструкции несущие балки – рано или поздно такая игра закончится катастрофой.

Причина, по которой внесение изменений столь болезненно – то, что больна вся система. Системе нужен доктор, иначе ее состояние будет только ухудшаться. Вы уже знаете, что не так с вашей системой, но вы боитесь разбить яйцо, чтобы сделать яичницу. Опытный хирург знает, что при операции нужно будет резать по живому, но он также знает, что разрезы – это временно. Сразу после операции будет больно, но потом пациенту станет лучше, чем было до операции.

Не бойтесь своего кода. Кого интересует то, что какие-то части не будут работать, пока вы будете вносить изменения? Страх изменений и привел проект к столь запущеному состоянию. Инвестиции в рефакторинг окупятся многократно в течении жизни проекта. Ваша команда, поработав с «больной» системой, получила ценный опыт с точки зрения того, как система должна была быть написана правильно. Так возьмите и примените эти знания. Работать с системой, которую вы ненавидите – это не то, на что стоит тратить свое время.

Переопределите внутренние интерфейсы, переструктурируйте модули, переделайте копи-паст код и упростите дизайн, убрав ненужные зависимости. Вы можете серьезно снизить сложность, устраняя проблемные граничные случаи, часто являющиеся результатом некорректной комбинации параметров. Постепенно меняйте старую структуру на новую, постоянно тестируя результат. Попытка сделать сразу весь рефакторинг может принести достаточно проблем, чтобы вы бросили это гиблое дело на полпути до конца.

Будьте хирургом, который не боится отрезать больную часть, чтобы освободить место для здоровой. Такая позиция заразна и вскоре остальная команда присоединится к вашей инициативе по оздоровлению проекта. Список «гигиенических» процедур, которые ваша команда считает необходимыми, тоже хорошая практика в долгосрочной перспективе. Убедите руководство в том, что хотя эти процедуры и не дают сразу видимых результатов, они приведут к снижению расходов и облегчат будущие релизы. Никогда не прекращайте поддерживать код в «здоровом» состоянии.

Автор оригинала - [Mike Lewis](http://programmer.97things.oreilly.com/wiki/index.php/Mike_Lewis)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_35.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.