Почти полтора десятилетия назад Чарльз Дахигг, журналист The New York Times, начал исследовать одну из самых загадочных и одновременно повседневных тем — привычки. Почему люди делают одни и те же вещи снова и снова? Почему плохие привычки укореняются так быстро, а полезные требуют героических усилий? В поисках ответов он не только провел интервью с учеными и бизнесменами, но и изучил новейшие исследования в области нейробиологии.
Так появилась книга «Сила привычки» (The Power of Habit), которая стала международным бестселлером и изменила подход к продуктивности во многих сферах: от спорта до бизнеса. Компании вроде Starbucks и Alcoa использовали идеи Дахигга для повышения эффективности, спортсмены — для улучшения результатов, а маркетологи — чтобы заставить нас покупать больше товаров.
Но когда я прочитал эту книгу, меня осенило: а что, если применить её идеи не к утреннему бегу или отказу от сладкого, а к разработке на 1С? Ведь наши рабочие процессы тоже состоят из повторяющихся сценариев, а технический долг и вечные авралы – это во многом результат неправильных привычек.
Задумайтесь:
- Почему вы каждый раз исправляете один и тот же баг, вместо того чтобы разобраться в причине?
- Почему деплой в прод сопровождается потными ладонями и надеждой «Авось не сломается»?
- Почему заказчики пишут вам в три ночи, и вы уже воспринимаете это как норму?
Ответ прост: это петли привычек, и их можно изменить. В этой статье я разберу:
- Как работает механизм Cue → Routine → Reward, и почему ваш код — это отражение ваших рабочих паттернов.
- Почему «краеугольные привычки» могут навсегда изменить ваш подход к разработке.
- Как даже самый жуткий легаси-код можно приручить, если применять правильные ритуалы.
Примените эти принципы — и вместо ночных авралов у вас появятся свободные вечера. А заказчики будут писать не в 3:00, а в 6:00. Прогресс, как говорится, налицо!
Привычка — это петля: Cue → Routine → Reward
В своей книге Дахигг объясняет, что любая привычка состоит из трех элементов:
- Триггер (cue) — событие, запускающее действие.
- Действие (routine) — сама привычка, автоматический ответ на триггер.
- Награда (reward) — то, что закрепляет привычку.
Разработчики 1С сталкиваются с этим каждый день, даже не осознавая:
- Триггер: Заказчик пишет «СРОЧНО! Ничего не работает!!!»
- Действие: В панике открываем конфигурацию, правим на лету, выкатываем патч без тестов.
- Награда: Проблема (вроде бы) решена, заказчик доволен. Мы чувствуем облегчение, наливаем себе чай (или что покрепче).
Что не так?
Проблема в том, что такая привычка формирует технический долг. Быстрая правка спасает момент, но через месяц этот код превращается в минное поле, где одно исправление рождает три новых бага.
Как изменить петлю?
- Триггер и награду оставляем: задача срочная, решение нужно.
- Меняем действие: вместо хаотичного кодинга анализируем проблему. Возможно, ошибка не в вашем коде, а в конфигурации или данных. Используем отладку, журнал регистрации или тестовые сценарии, прежде чем вносить изменения.
Пример: Однажды в нашей команде коллега Вася увидел баг в отчете и собирался исправить его «на глазок». Но вместо этого он запустил журнал регистрации и выяснил, что данные были искажены сторонним обработчиком. Простая проверка сэкономила часы работы и предотвратила новые ошибки.
«Краеугольные привычки» (Keystone Habits) — макросы для вашего мозга
Дахигг вводит понятие краеугольных привычек — это такие привычки, которые запускают цепную реакцию улучшений.
Пример из бизнеса: когда в компании Alcoa CEO Пол О’Нил начал борьбу за безопасность сотрудников, производительность выросла. Почему? Потому что эта привычка подтянула и другие аспекты работы.
Какие краеугольные привычки могут изменить разработку на 1С?
- 15 минут анализа логов каждое утро. Позволяет выявлять потенциальные проблемы до того, как они станут пожарами.
- Автоматизация повторяющихся задач. Написали запрос вручную три раза? Пора делать шаблон.
- Документирование кода. Это кажется скучным, но через месяц коллеги (и вы сами) скажут вам спасибо.
Пример: Однажды мы внедрили ежедневную проверку логов обработок, и внезапно количество критических ошибок уменьшилось вдвое. Просто потому, что мы начали замечать их раньше.
Как изменить привычку: оставьте триггер и награду, замените действие
Допустим, после каждого релиза вас ждет ночной марафон исправления багов.
- Триггер: Завершение проекта.
- Действие: Срочный аврал, бессонная ночь, фиксы «на живую».
- Награда: Проект запущен, вас хвалят.
Как переписать привычку?
- Вместо героического ночного патча внедрите автотесты.
- Используйте хранилище, а лучше GIT, чтобы не терять версии кода.
- Делайте релизную документацию, чтобы каждый знал, что именно изменилось.
Пример: В одной компании начали запускать тестирование на боевых данных перед выкладкой. Результат: число экстренных вызовов снизилось на 70%, а заказчики перестали удивляться «непонятным изменениям».
«Золотое правило изменения привычек»
Дахигг говорит, что привычки нельзя просто удалить — их можно только заменить. Он приводит пример с курильщиками: чтобы бросить курить, недостаточно просто перестать покупать сигареты. Нужно заменить старую привычку новой (например, когда хочется курить — пить воду, жевать жвачку или делать упражнения).
Как это применимо к 1С?
Допустим, у вас в команде есть вредная привычка: после сдачи проекта не писать документацию. Каждый раз вы думаете: «Я и так всё помню, если что, разберусь». Но через месяц никто уже не помнит, как работает та самая «уникальная схема».
Как заменить привычку?
- Старая петля:
- Триггер: Завершение проекта.
- Действие: Радость, желание побыстрее забыть о проекте.
- Награда: Освобождение от «лишней» работы.
- Новая петля:
- Триггер: Завершение проекта.
- Действие: Ведение документации как последний шаг перед закрытием задачи.
- Награда: Команда может быстрее вникнуть в доработки, меньше экстренных вопросов.
Пример: В одной компании ввели правило: проект не считается завершённым, пока не написана документация. В итоге через пару месяцев это стало нормой, и больше никто не ныл «А кто писал этот код?!».
«Социальные привычки» и сила окружения
Дахигг рассказывает, что люди легче перенимают привычки, если находятся в среде, где эти привычки уже являются нормой. Например, он приводит случай, когда больницы снижали смертность, просто изменяя рабочие ритуалы (например, обязательное мытьё рук перед осмотром пациента).
Как это применимо к 1С?
Если команда привыкла работать в хаосе (горящие сроки, хаотичные фиксы, никакого контроля версий), то даже хороший разработчик быстро заразится этим стилем работы. Но если в коллективе строгие код-ревью, тестирование и документирование — даже новички быстро втягиваются.
Как внедрить?
- Ввести код-ревью в команду, где старшие разработчики задают стандарты.
- Использовать общие чаты и каналы для обсуждения багов и лучших практик.
- Создать «правило 5 минут» — если баг воспроизводится 5+ минут, его надо анализировать, а не сразу фиксить.
Пример: В одной команде начали обсуждать ошибки не в формате «Кто опять сломал код?!», а как совместный разбор «Как можно было избежать этого бага?». Через полгода баги стали в 2 раза реже.
«Краеугольные привычки» в личной продуктивности
Мы уже говорили о краеугольных привычках в бизнесе, но их можно применять и на личном уровне.
Как это применимо к 1С?
Есть одна важная привычка, которая часто отличает опытных разработчиков от новичков: планирование перед кодингом.
Как внедрить?
- Перед написанием кода формулировать решение в виде псевдокода.
- Использовать фиксацию даже для мелких изменений, чтобы не терять логику исправлений.
Пример: Один разработчик 1С жаловался, что часто пишет код, а потом понимает, что «пошёл не туда». Он попробовал перед каждым модулем делать 5-минутное «мысленное проектирование» — и это сократило его правки в 3 раза.
«Привычка выигрывать» — эффект маленьких побед
Дахигг рассказывает, что люди быстрее привыкают к хорошим изменениям, если начинают с небольших побед. Например, если человек хочет начать бегать, но пробегает всего 5 минут в день, ему легче продолжить, чем если бы он сразу поставил планку «10 км за неделю».
Как это применимо к 1С?
Если вам кажется, что проект слишком сложный, разделите его на маленькие шаги. Например:
- Написать текст запроса.
- Сделать тестовый отчёт.
- Проверить данные.
- Добавить вывод в форму.
- Доработать интерфейс.
Каждый маленький шаг даёт ощущение успеха, а это мотивирует двигаться дальше.
Пример: Один разработчик начал писать GIT-коммиты на каждый микро-шаг («Создал структуру», «Добавил обработчик»). Это помогло ему лучше понимать процесс и видеть прогресс.
Автоматизация решений — как убрать ненужный выбор
В книге Дахигг рассказывает, что чем больше решений мы принимаем в течение дня, тем сильнее устаёт мозг. Это называется «усталость от принятия решений». Например, если человек каждое утро мучается с выбором одежды, тратит время на раздумья, что приготовить на завтрак, а потом ещё решает, чем заняться на выходных — к обеду он уже истощён.
Люди, которые убирают ненужные решения, освобождают умственную энергию для важных задач. Например:
- Стив Джобс носил только чёрную водолазку и джинсы, чтобы не думать о выборе одежды.
- Илону Маску и Джеффу Безосу помощники планируют встречи так, чтобы не тратить время на координацию расписания.
Как это применимо к 1С?
В 1С-разработке мы часто тратим время на повторяющиеся мелкие решения, которые можно автоматизировать.
Как внедрить?
- Готовые шаблоны кода → вместо того чтобы каждый раз вспоминать, как писать стандартные обработки, можно завести заготовки в 1С (например, код для загрузки данных, формирования отчётов, работы с JSON).
- Автоматизация рутинных задач → написать обработку для очистки базы, экспорта данных, генерации тестовых записей.
- Готовые скрипты для развертывания → если приходится вручную вносить изменения, лучше сделать BAT-файл или PowerShell-скрипт, который всё сделает за пару секунд.
Пример: Один разработчик каждый раз тратил 5 минут на настройку прав пользователей в новой базе. Он написал обработку, которая загружает роли из шаблона за 10 секунд. В итоге за год он сэкономил 15+ часов рабочего времени!
Привычки, которые спасут ваш проект (и нервы)
- «Не повторяй себя» (DRY): Три раза скопировали код? Пора вносить в общий модуль.
- «Баги любят тишину»: Пишите тесты, даже если заказчик говорит «и так сойдет».
- «Всегда проверяйте данные»: 80% багов связаны не с кодом, а с некорректными входными данными.
Ваш код — это отражение ваших привычек
Как писал Дахигг: «Привычки — это вода, которая точит камень».
Что это значит для 1С-разработчика?
- Мелкие улучшения каждый день всегда лучше, чем героический подвиг раз в квартал.
- Легаси-код побеждается не магией, а системной работой.
Если после прочтения статьи вы задумались о своих привычках — это уже победа. А если еще и внедрили одно улучшение, вас ждет награда: новая задача с пометкой «СРОЧНО!». Но теперь-то вы готовы!
P.S. А если коллега снова зовет вас «тушить пожар», скажите: «Я не пожарный, я архитектор — строю систему, которая не горит». И добавьте автотест в его часть кода. Это будет ваша маленькая месть вселенной хаоса.
Удачи в переписывании привычек! И да пребудет с вами сила… логирования!
