Принципы работы
===

### 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 Мы не переписываем проекты с нуля
Шанс того, что это хорошая идея — минимален. Мы отгоняем от себя мысли написать что-то с нуля, выбросив работающий код, проверенный годами. Мы постоянно улучшаем и рефакторим, делая говнокод кодом мечты. Избавляемся от "двойных" систем, а не создаём их.