HackMD
Принципы работы
1.1 Мы следуем принятым принципам, независимо от согласия с ними
Персональное несогласие — не причина отступать от принципов. Тем не менее, можно начать обсуждение любого принципа, если изменились обстоятельства и он перестал быть полезным.
1.2 Мы открыто говорим о проблемах и рисках
Не согласен с техническим решением или план невозможно выполнить — скажи. Сломал базу или профакапил сроки — скажи сразу. Тимлид пришел с дурацким предложением — не молчи. Часто кажется, что проще согласиться или промолчать. Помни, что это приведёт к ещё большим проблемам позже.
1.3 Мы непредубеждены
По-максимуму избавляемся от эго. Не доказываем, кто прав. Не думаем о личной выгоде. Не боимся выглядеть глупо. Помним, что часто мы неправы. Искренне стараемся понять оппонента. Не спорим впустую. Забываем о личном отношении. Цель — найти лучшее решение.
1.4 Мы не делаем ничего зря
Постоянно боремся с потраченным впустую временем: задача не принесет пользу, новый процесс нужен только менеджеру, бессмысленная встреча, ненужная кнопка. Мы — борцы с мудой. Увидел муду — уничтожь.
1.5 Лучше не стесняться и спросить, чем потом долго чинить
1.6 Мы общаемся культурно
Честный фидбек и открытость — не повод для хамства и оскорблений. Мы вежливо и культурно общаемся со всеми: друг с другом, заказчиками, другими командами, персональными ассистентами.
1.7 Мы не оставляем белых пятен
Мы избегаем абстрактных и не до конца понятных формулировок. Задаём вопросы, ресёрчим, высказываем сомнения. Потратим время сейчас — сэкономим потом.
1.8 Мы даём друг другу честную обратную связь
Давать честный фидбек — трудно, получать — тоже. Мы осознаём пользу обратной связи, боремся с собой и учимся давать и принимать фидбек. Мы говорим прямо, не используем намёки и абстрактную критику.
1.9 Мы доверяем друг другу и можем положиться друг на друга
1.10 Наша цель — счастливые заказчики
Мы работаем, чтобы ученики получили свои уроки, преподаватели — зарплаты, компания — прибыль. Остальное вторично: задачи, графики, тикеты, обращения. Мы не зарываемся в коде ради кода, рефакторинге ради рефакторинга, планах ради планов и презентациях ради презентаций. Мы не делаем что-то, потому что "так правильно", "так написано в книжке" или "я всегда так делал". Помним о цели и делаем то, что максимально приближает к ней.
1.11 Хорошо бы, надо бы, было бы неплохо
Мы не произносим такие фразы впустую. Видишь возможное улучшение — впиши в план, создай карточку, найди ответственного, а лучше — сделай сам.
1.12 Мы не меняем приоритеты спонтанно
Приоритеты не могу меняться внезапно. Требуются веские аргументы и согласования с заинтересованными сторонами.
Технические принципы
2.1 Мы думаем о последствиях
Перед сложной выкаткой или миграцией мы думаем, что будем делать, если всё пойдет не так. Делаем бекапы, скрипты отката, оцениваем риски падения. Отгоняем мысли "ай, пронесёт, всё будет ок"
2.2 У нас не должно быть мест, которые знает только один человек
Мы стремимся избегать "белых пятен" в коде и поддерживать высокий бас-фактор.
2.3 Целостность данных
При написании кода, который манипулирует с данными биллинга, особенно балансом или деньгами, мы делаем эти изменения атомарными. Если мы меняем структуру хранения или массово изменяем данные, делаем изменения обратимыми.
2.4 Простые решения лучше сложных
Качество и стабильность != сложные универсальные решения. Мы против оверинжиринга в пользу простых и понятных решений.
2.5 Мы знаем, что биллинг — не пуп земли
Биллинг — это проект который используется многими поздразделениями в Skyeng. Внося изменения в его работу, мы задумываемся о командах, работающих с биллингом или данными биллинга.
2.6 Мы кодим осознанно, а не наугад
Мы разбираемся детально, почему что-то так работает и выясняем причины, если что-то работает не так. Не добавляем строки с мыслью "это может помочь" и не удаляем строки с мыслью "кажется, это не нужно".
2.7 У нас есть список обязательных знаний
Каждый должен потратить время и выучить вещи, которые нам важны:
- Основы работы с RabbitMQ: обменники и их типы, очереди
- БД: транзакции и уровни изоляции, блокировки
- Двойная запись в бухгалтерии
- SOLID, DI, IoC
2.8 Качество важнее скорости
Биллинг — инфраструктурная команда, а не хипстерский продукт. Наши приоритеты: стабильность и масштабируемость. "Быстро поднятое не считается упавшим" — не о биллинге. В нашем случае падение может повлечь существенную потерю денег и мы не идём на риск ради скорости.
2.9 Мы пишем код так, как будто у нас нет отдела QA
Стараемся самостоятельно протестировать код. Если не знаем как его вызвать — узнаем. Если тестировать тяжело или долго — подробно в комментариях к задаче пишем инструкцию для QA. Это увеличит время "in development", но время до production уменьшится: задача не зависнет в непонятных статусах.
2.10 Мы тестируем код
Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage.
2.11 Мы не аутсорсим разработку биллинга
Это увеличивает технический долг и небезопасно.
2.12 Мы с осторожностью удаляем данные
Просто так ничего не удаляем: ни поля, ни данные.
2.13 Делаем ограничения на уровне БД
Проставляем уникальные ключи, правильные типы данных. Лучше ошибка о нарушении уникального ключа, чем двойные выплаты.
2.14 Читаемость важнее скорости и краткости
Код гораздо чаще читают, чем пишут. Уделяем внимание форматированию, phpdoc, описанию, README.
2.15 Мы не переписываем проекты с нуля
Шанс того, что это хорошая идея — минимален. Мы отгоняем от себя мысли написать что-то с нуля, выбросив работающий код, проверенный годами. Мы постоянно улучшаем и рефакторим, делая говнокод кодом мечты. Избавляемся от "двойных" систем, а не создаём их.
