- Принимаем реальность и работаем с ней.
- Нет ничего страшного в том, что мы допускаем ошибки; страшно, когда мы не учимся на них.
- Мы выявляем проблемы и не миримся с ними. Мы исправляем их и делаем выводы.
- Мы используем инструменты и утвержденные процедуры, чтобы регламентировать выполнение работы.
- Явное лучше неявного
Персональное несогласие — не причина отступать от принципов. Тем не менее, можно начать обсуждение любого принципа, если изменились обстоятельства или принцип перестал быть полезным. Выполняй или объясняй - мы можем отступать от установленных правил или процедур, только если мы можем дать объективную причину своим действиям.
Не согласен с техническим решением или план невозможно выполнить — скажи. Сломал базу или профакапил сроки — скажи сразу. Тимлид пришел с дурацким предложением — не молчи. Часто кажется, что проще согласиться или промолчать. Помни, что это приведёт к ещё большим проблемам позже.
По-максимуму избавляемся от эго. Не доказываем, кто прав. Не думаем о личной выгоде. Не боимся выглядеть глупо. Помним, что часто мы неправы. Искренне стараемся понять оппонента. Не спорим впустую. Забываем о личном отношении. Цель — найти лучшее решение.
Постоянно боремся с потраченным впустую временем: задача не принесет пользу, новый процесс нужен только менеджеру, бессмысленная встреча, ненужная кнопка. Мы — борцы с мудой. Увидел муду — уничтожь.
Лучше не стесняться и спросить, чем потом долго чинить и исправлять. Пока мы не понимаем суть и назначение тикета, мы не беремся его выполнять.
Честный фидбек и открытость — не повод для хамства и оскорблений. Мы вежливо и культурно общаемся со всеми: друг с другом, с заказчиками, другими командами, персональными ассистентами.
Мы избегаем абстрактных и не до конца понятных формулировок. Задаём вопросы, ресёрчим, высказываем сомнения. Потратим время сейчас — сэкономим потом.
Давать честный фидбек — трудно, получать — тоже. Мы осознаём пользу обратной связи, боремся с собой и учимся давать и принимать фидбек. Мы говорим прямо, не используем намёки и абстрактную критику. Если тиммейт сделал говно, то мы говорим об этом прямо.
Мы работаем, чтобы менеджеры могли управлять бюджетом проекта, а топы — бюджетом компании. Остальное вторично: задачи, графики, тикеты, обращения. Мы не зарываемся в коде ради кода, рефакторинге ради рефакторинга, планах ради планов и презентациях ради презентаций. Мы не делаем что-то, потому что “так правильно”, “так написано в книжке” или “я всегда так делал”. Помним о цели и делаем то, что максимально приближает к ней.
Мы не произносим такие фразы впустую. Видишь возможное улучшение — впиши в план, создай тикет, найди ответственного, напиши TODO, а лучше — сделай сам.
Приоритеты не могу меняться внезапно. Требуются веские аргументы и согласования с заинтересованными сторонами.
Мы люди и мы ошибаемся. Мы ошибаемся вследствие незнания, невнимательности или плохого настроения. Любая ошибка простительна, если она совершается впервые. Главное - разобрать причины ошибки и сделать из них вывод.
Мы следуем принципам демократии. Любому крупному изменению в системе должно предшествовать общекомандное обсуждение. При этом мы понимаем, что тимлид несет ответственность за качество системы, а проектный менеджер - за сроки поставки. Поэтому за ними остается последнее слово и они обязаны его обосновать.
Когда упал боевой сервер системы, то режим демократии сменяется автократией. Никаких обсуждений причин, пока не поднят сервер и не исправлена проблема.
Не оставляй "как есть" и не разбирайся с причинами - это занимает время. Оформи багрепорт с шагами для воспроизведения и описанием ожидаемого результата и того результата, который проявляется в системе.
Перед сложной выкаткой или миграцией мы думаем, что будем делать, если всё пойдет не так. Делаем бэкапы, скрипты отката, оцениваем риски падения. Отгоняем мысли “ай, пронесёт, всё будет ок”.
Мы стремимся избегать “белых пятен” в коде и поддерживать высокий бас-фактор.
При написании кода, который манипулирует со множеством данных из разных таблиц, мы делаем эти изменения атомарными. Если мы меняем структуру хранения или массово изменяем данные, делаем изменения обратимыми.
Качество и стабильность != сложные универсальные решения. Мы против оверинжиринга в пользу простых и понятных решений.
Мы разбираемся детально, почему что-то так работает и выясняем причины, если что-то работает не так. Не добавляем строки с мыслью “это может помочь” и не удаляем строки с мыслью “кажется, это не нужно”.
Наши приоритеты: стабильность и масштабируемость. “Быстро поднятое не считается упавшим” — не о нашем проекте. Мы не идём на риск ради скорости.
Мы стараемся самостоятельно протестировать код. Если не знаем как его вызвать — узнаем. Если тестировать тяжело или долго — подробно в комментариях к задаче пишем инструкцию для QA. Это увеличит время “in development”, но время до production уменьшится: задача не зависнет в непонятных статусах.
Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage. Юниттестов никогда не бывает много. Мы пишем тесты как на кейсы успешного выполнения, так и на кейсы неуспешного выполнения кода.
Просто так ничего не удаляем: ни поля, ни данные.
Проставляем уникальные ключи в БД, правильные типы данных в моделях. Лучше:
- пользователь увидит ошибку о нарушении уникального ключа
- провалидировать модель 2+ раз в бизнес-уровне
- провалидировать модель 2+ раз в уровне БД
... чем мы потом будем исправлять "руками" в базе неконсистентные/некорректные данные.
Фронтент - это клиент, которому никогда нельзя доверять. Полученной модели на стороне бэкенда мы не доверяем и валидируем ее по-максимуму. Много валидации не бывает.
Тикеты не всегда проработаны так, чтобы покрыть все случаи в продакшене. Жизнь сложная, и ее не описать в одном тикете. Если мы во время кодинга наталкиваемся на ситуацию, которую никто не знает как разрешить, мы кидаем исключение (Exception). Лучше пользователь ничего не сможет сделать с системой, чем мы потом будем руками исправлять некорректные/неконсистентные/нецелостные данные в базе.
Если есть возможность не делать запрос на бэкенд, то мы его не делаем. Клиентов много, а бэкенд один. Например, мы не отправляем с фронта заведомо невалидную модель из формы.
Мы придерживаемся политики "экономии внимания". Мы их не показываем "просто так" никакие поля моделей или блоки информации, у всего показанного должна быть цель.
Всегда есть конфиденциальные поля моделей, которые видеть должны не все. В том числе и через "инструменты разработчика" в браузере. Бэкенд уже отправляет только ту информацию, которую пользователю дозволено видеть. Мы всегда рассчитываем, какие данные каким пользователям должны быть доступны, а какие - скрыты. Если мы сомневаемся, то мы спрашиваем аналитиков, тимлида или проектного менеджера.
Запрос всех вложенных сущностей модели из базы и маппинг стоят дорого для производительности сервера. Мы это понимаем и стараемся взять с бэкенда только ту информацию, которую необходимо показать. Если какое-то поле не будет отображено на фронтенде, то мы его не отправляем с бэкенда.
Код гораздо чаще читают, чем пишут. Уделяем внимание форматированию, summary, описанию, README, понятным именам методов, переменных и классов.
Шанс того, что это хорошая идея — минимален. Мы отгоняем от себя мысли написать что-то с нуля, выбросив работающий код, проверенный годами. Мы постоянно улучшаем и рефакторим, делая говнокод кодом мечты. Избавляемся от “двойных” систем, а не создаём их.
Мы не ведем вики-портал с объяснением бизнес-логики приложения. Вместо этого мы закладываем описание бизнес-логики в сам код и дополняем его комментариями. Для этого нам помогают в том числе конкретные имена переменных, методов, классов, ссылки на тикеты в джире.
Пасхалки в системе - это весело. Мы добавляем их с радостью, но любая пасхалка должна быть одобрена проектным менеджером и заказчиком/продактом. Автор пасхалки не будет забыт.
Если есть вопрос по тикету, то напиши его комментарием к тикету в Jira. Если тебе задали вопрос в Jira, то отвечай там же в комментариях. Так мы сохраним историю обсуждений, которая будет лучше объяснять историю изменений бизнес-логики.
Это нормально, если мы не отвечаем на сообщения в свои выходные дни или после окончания рабочего дня. Иногда автор даже и не ждет ответа, потому что письменное общение - это асинхронное общение. Мы имеем право ответить по таким вопросам в следующий рабочий день.
У нас нет Core hours и мы можем работать вне офиса. Если в тикете есть дэдлайн, значит мы коммитаемся под него и делаем максимально возможное, чтобы выполнить к сроку задачу. Если мы не успеваем, то сообщаем команде об этом как можно раньше.
Мы работаем асинхронно, но мы должны понимать, как идут дела на проекте. У нас может быть зависимость тикетов и участников между собой. Поэтому мы каждый свой рабочий день утром пишем статус в слак, где отвечаем на три вопроса:
- Что я сделал вчера;
- Что я буду делать сегодня;
- Вижу ли я факты, которые мешают закончить задачи в срок.