Работает - не трогай
Friday, 10 June 2011 08:07![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrzejnВсякий опытный программист, приступая к поддержке сложной системы, помнит эти правила:
1. Работает - не трогай.
2. Выглядит ошибкой, неоптимальностью, непонятен смысл операций, но клиенты на это место не жалуются - не трогай.
3. Исправляй только то, на что жалуются клиенты, даже если можно заодно без лишних усилий улучшить что-нибудь ещё. Если очень хочется улучшить - сначала переспроси у клиентов, хотят ли они этого.
4. Исправляя баг, не ставь формальную заплатку на заявленный симптом, а разберись в глубинных причинах его возникновения и исправляй там.
5. Если истинной причиной бага является полный пиздец в целом модуле, от которого зависит половина системы, и надо его переписывать заново - не бросайся переписывать сразу. Вот в этом случае лучше поставь быструю заплатку и сообщи подробности менеджеру проекта, пускай они с клиентами планируют долгую масштабную переделку к следующей версии.
6. Не торопись. Не бросайся исправлять найденную причину сразу, как только ты её нашёл: ты нашёл ещё не всё. Пересмотри и подумай.
7. Не работай над нефатальными проблемами сверхурочно. Трудовое расписание не зря придумали.
8. Вот если система сдохла совсем, а у клиента из-за неё рушится бизнес и гибнут люди - тогда работай срочно, невзирая на время суток.
9. Перед каждым этапом изменений всегда делай резервные копии всего.
10. Никогда не правь баги прямо на живой рабочей системе. Всегда только на рабоче-тестовой копии, а потом деплой изменения. Даже если очень срочно.
11. Заботься о тех, кто придут исправлять этот кусок после тебя. Оставляй всё ясным, доступным, подписанным и удобным к переделке в любом месте.
12. Перед тем как закрыть баг, перетестируй не только своё исправление, но и все его окрестности, о которых ты знаешь: не поломал ли ты где-нибудь что-нибудь ещё?
Так вот: все эти правила полностью применимы и к работе психотерапевта. За очевидным исключением девятого и десятого. Именно поэтому психотерапевты работают бережнее и осторожнее программистов.
1. Работает - не трогай.
2. Выглядит ошибкой, неоптимальностью, непонятен смысл операций, но клиенты на это место не жалуются - не трогай.
3. Исправляй только то, на что жалуются клиенты, даже если можно заодно без лишних усилий улучшить что-нибудь ещё. Если очень хочется улучшить - сначала переспроси у клиентов, хотят ли они этого.
4. Исправляя баг, не ставь формальную заплатку на заявленный симптом, а разберись в глубинных причинах его возникновения и исправляй там.
5. Если истинной причиной бага является полный пиздец в целом модуле, от которого зависит половина системы, и надо его переписывать заново - не бросайся переписывать сразу. Вот в этом случае лучше поставь быструю заплатку и сообщи подробности менеджеру проекта, пускай они с клиентами планируют долгую масштабную переделку к следующей версии.
6. Не торопись. Не бросайся исправлять найденную причину сразу, как только ты её нашёл: ты нашёл ещё не всё. Пересмотри и подумай.
7. Не работай над нефатальными проблемами сверхурочно. Трудовое расписание не зря придумали.
8. Вот если система сдохла совсем, а у клиента из-за неё рушится бизнес и гибнут люди - тогда работай срочно, невзирая на время суток.
9. Перед каждым этапом изменений всегда делай резервные копии всего.
10. Никогда не правь баги прямо на живой рабочей системе. Всегда только на рабоче-тестовой копии, а потом деплой изменения. Даже если очень срочно.
11. Заботься о тех, кто придут исправлять этот кусок после тебя. Оставляй всё ясным, доступным, подписанным и удобным к переделке в любом месте.
12. Перед тем как закрыть баг, перетестируй не только своё исправление, но и все его окрестности, о которых ты знаешь: не поломал ли ты где-нибудь что-нибудь ещё?
Так вот: все эти правила полностью применимы и к работе психотерапевта. За очевидным исключением девятого и десятого. Именно поэтому психотерапевты работают бережнее и осторожнее программистов.
