Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

Кодекс команды .NET

5 принципов работы

  • Принимаем реальность и работаем с ней.
  • Нет ничего страшного в том, что мы допускаем ошибки; страшно, когда мы не учимся на них.
  • Мы выявляем проблемы и не миримся с ними. Мы исправляем их и делаем выводы.
  • Мы используем инструменты и утвержденные процедуры, чтобы регламентировать выполнение работы.
  • Явное лучше неявного

1. Принципы работы

1.1. Мы следуем принятым принципам, независимо от согласия с ними

Персональное несогласие — не причина отступать от принципов. Тем не менее, можно начать обсуждение любого принципа, если изменились обстоятельства или принцип перестал быть полезным. Выполняй или объясняй - мы можем отступать от установленных правил или процедур, только если мы можем дать объективную причину своим действиям.

1.2. Мы открыто говорим о проблемах и рисках

Не согласен с техническим решением или план невозможно выполнить — скажи. Сломал базу или профакапил сроки — скажи сразу. Тимлид пришел с дурацким предложением — не молчи. Часто кажется, что проще согласиться или промолчать. Помни, что это приведёт к ещё большим проблемам позже.

1.3. Мы не предубеждены

По-максимуму избавляемся от эго. Не доказываем, кто прав. Не думаем о личной выгоде. Не боимся выглядеть глупо. Помним, что часто мы неправы. Искренне стараемся понять оппонента. Не спорим впустую. Забываем о личном отношении. Цель — найти лучшее решение.

1.4. Мы не делаем ничего зря

Постоянно боремся с потраченным впустую временем: задача не принесет пользу, новый процесс нужен только менеджеру, бессмысленная встреча, ненужная кнопка. Мы — борцы с мудой. Увидел муду — уничтожь.

1.5. Не понимаешь суть - спроси

Лучше не стесняться и спросить, чем потом долго чинить и исправлять. Пока мы не понимаем суть и назначение тикета, мы не беремся его выполнять.

1.6. Мы общаемся культурно

Честный фидбек и открытость — не повод для хамства и оскорблений. Мы вежливо и культурно общаемся со всеми: друг с другом, с заказчиками, другими командами, персональными ассистентами.

1.7. Мы не оставляем белых пятен

Мы избегаем абстрактных и не до конца понятных формулировок. Задаём вопросы, ресёрчим, высказываем сомнения. Потратим время сейчас — сэкономим потом.

1.8. Мы даём друг другу честную обратную связь

Давать честный фидбек — трудно, получать — тоже. Мы осознаём пользу обратной связи, боремся с собой и учимся давать и принимать фидбек. Мы говорим прямо, не используем намёки и абстрактную критику. Если тиммейт сделал говно, то мы говорим об этом прямо.

1.9. Мы доверяем друг другу и можем положиться друг на друга

1.10. Наша цель — счастливые заказчики

Мы работаем, чтобы менеджеры могли управлять бюджетом проекта, а топы — бюджетом компании. Остальное вторично: задачи, графики, тикеты, обращения. Мы не зарываемся в коде ради кода, рефакторинге ради рефакторинга, планах ради планов и презентациях ради презентаций. Мы не делаем что-то, потому что “так правильно”, “так написано в книжке” или “я всегда так делал”. Помним о цели и делаем то, что максимально приближает к ней.

1.11. Хорошо бы, надо бы, было бы неплохо

Мы не произносим такие фразы впустую. Видишь возможное улучшение — впиши в план, создай тикет, найди ответственного, напиши TODO, а лучше — сделай сам.

1.12. Мы не меняем приоритеты спонтанно

Приоритеты не могу меняться внезапно. Требуются веские аргументы и согласования с заинтересованными сторонами.

1.13. Ошибиться - нестрашно. Страшно повторить ошибку

Мы люди и мы ошибаемся. Мы ошибаемся вследствие незнания, невнимательности или плохого настроения. Любая ошибка простительна, если она совершается впервые. Главное - разобрать причины ошибки и сделать из них вывод.

1.14. Мы обсуждаем решения вместе. Но не всегда

Мы следуем принципам демократии. Любому крупному изменению в системе должно предшествовать общекомандное обсуждение. При этом мы понимаем, что тимлид несет ответственность за качество системы, а проектный менеджер - за сроки поставки. Поэтому за ними остается последнее слово и они обязаны его обосновать.

1.15. Упавший продакшн - не время для демократии

Когда упал боевой сервер системы, то режим демократии сменяется автократией. Никаких обсуждений причин, пока не поднят сервер и не исправлена проблема.

1.16. Увидел баг - оформи багрепорт

Не оставляй "как есть" и не разбирайся с причинами - это занимает время. Оформи багрепорт с шагами для воспроизведения и описанием ожидаемого результата и того результата, который проявляется в системе.

2. Технические принципы

2.1. Мы думаем о последствиях

Перед сложной выкаткой или миграцией мы думаем, что будем делать, если всё пойдет не так. Делаем бэкапы, скрипты отката, оцениваем риски падения. Отгоняем мысли “ай, пронесёт, всё будет ок”.

2.2. У нас не должно быть мест, которые знает только один человек

Мы стремимся избегать “белых пятен” в коде и поддерживать высокий бас-фактор.

2.3. Целостность данных

При написании кода, который манипулирует со множеством данных из разных таблиц, мы делаем эти изменения атомарными. Если мы меняем структуру хранения или массово изменяем данные, делаем изменения обратимыми.

2.4. Простые решения лучше сложных

Качество и стабильность != сложные универсальные решения. Мы против оверинжиринга в пользу простых и понятных решений.

2.5. Мы кодим осознанно, а не наугад

Мы разбираемся детально, почему что-то так работает и выясняем причины, если что-то работает не так. Не добавляем строки с мыслью “это может помочь” и не удаляем строки с мыслью “кажется, это не нужно”.

2.6. Качество важнее скорости

Наши приоритеты: стабильность и масштабируемость. “Быстро поднятое не считается упавшим” — не о нашем проекте. Мы не идём на риск ради скорости.

2.7. Мы пишем код так, как будто у нас нет отдела QA

Мы стараемся самостоятельно протестировать код. Если не знаем как его вызвать — узнаем. Если тестировать тяжело или долго — подробно в комментариях к задаче пишем инструкцию для QA. Это увеличит время “in development”, но время до production уменьшится: задача не зависнет в непонятных статусах.

2.8. Мы тестируем код

Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage. Юниттестов никогда не бывает много. Мы пишем тесты как на кейсы успешного выполнения, так и на кейсы неуспешного выполнения кода.

2.9. Мы с осторожностью удаляем данные

Просто так ничего не удаляем: ни поля, ни данные.

2.10. Делаем валидацию на всех уровнях

Проставляем уникальные ключи в БД, правильные типы данных в моделях. Лучше:

  • пользователь увидит ошибку о нарушении уникального ключа
  • провалидировать модель 2+ раз в бизнес-уровне
  • провалидировать модель 2+ раз в уровне БД

... чем мы потом будем исправлять "руками" в базе неконсистентные/некорректные данные.

2.11. Валидация в бэкенде первична

Фронтент - это клиент, которому никогда нельзя доверять. Полученной модели на стороне бэкенда мы не доверяем и валидируем ее по-максимуму. Много валидации не бывает.

2.12. В любой непонятной ситуации кидай исключение

Тикеты не всегда проработаны так, чтобы покрыть все случаи в продакшене. Жизнь сложная, и ее не описать в одном тикете. Если мы во время кодинга наталкиваемся на ситуацию, которую никто не знает как разрешить, мы кидаем исключение (Exception). Лучше пользователь ничего не сможет сделать с системой, чем мы потом будем руками исправлять некорректные/неконсистентные/нецелостные данные в базе.

2.13. Мы не делаем веб-запросы зря

Если есть возможность не делать запрос на бэкенд, то мы его не делаем. Клиентов много, а бэкенд один. Например, мы не отправляем с фронта заведомо невалидную модель из формы.

2.14. Мы показываем только необходимую информацию

Мы придерживаемся политики "экономии внимания". Мы их не показываем "просто так" никакие поля моделей или блоки информации, у всего показанного должна быть цель.

2.15. Мы отправляем только дозволенную информацию

Всегда есть конфиденциальные поля моделей, которые видеть должны не все. В том числе и через "инструменты разработчика" в браузере. Бэкенд уже отправляет только ту информацию, которую пользователю дозволено видеть. Мы всегда рассчитываем, какие данные каким пользователям должны быть доступны, а какие - скрыты. Если мы сомневаемся, то мы спрашиваем аналитиков, тимлида или проектного менеджера.

2.16. Мы отправляем только ту информацию, которая необходима.

Запрос всех вложенных сущностей модели из базы и маппинг стоят дорого для производительности сервера. Мы это понимаем и стараемся взять с бэкенда только ту информацию, которую необходимо показать. Если какое-то поле не будет отображено на фронтенде, то мы его не отправляем с бэкенда.

2.17. Читаемость важнее скорости и краткости

Код гораздо чаще читают, чем пишут. Уделяем внимание форматированию, summary, описанию, README, понятным именам методов, переменных и классов.

2.18. Мы не переписываем модули и проекты с нуля

Шанс того, что это хорошая идея — минимален. Мы отгоняем от себя мысли написать что-то с нуля, выбросив работающий код, проверенный годами. Мы постоянно улучшаем и рефакторим, делая говнокод кодом мечты. Избавляемся от “двойных” систем, а не создаём их.

2.19. Мы пишем самодокументируемый код

Мы не ведем вики-портал с объяснением бизнес-логики приложения. Вместо этого мы закладываем описание бизнес-логики в сам код и дополняем его комментариями. Для этого нам помогают в том числе конкретные имена переменных, методов, классов, ссылки на тикеты в джире.

2.20. Пасхалки приветствуются

Пасхалки в системе - это весело. Мы добавляем их с радостью, но любая пасхалка должна быть одобрена проектным менеджером и заказчиком/продактом. Автор пасхалки не будет забыт.

3. Общекомадная работа

3.1. Мы общаемся через Jira

Если есть вопрос по тикету, то напиши его комментарием к тикету в Jira. Если тебе задали вопрос в Jira, то отвечай там же в комментариях. Так мы сохраним историю обсуждений, которая будет лучше объяснять историю изменений бизнес-логики.

3.2. Если пишут по работе в выходные или после работы - можешь смело игнорировать

Это нормально, если мы не отвечаем на сообщения в свои выходные дни или после окончания рабочего дня. Иногда автор даже и не ждет ответа, потому что письменное общение - это асинхронное общение. Мы имеем право ответить по таким вопросам в следующий рабочий день.

3.3. Мы можем работать откуда угодно и когда угодно. Главное - результат

У нас нет Core hours и мы можем работать вне офиса. Если в тикете есть дэдлайн, значит мы коммитаемся под него и делаем максимально возможное, чтобы выполнить к сроку задачу. Если мы не успеваем, то сообщаем команде об этом как можно раньше.

3.4. Мы пишем дейли-статусы каждый день

Мы работаем асинхронно, но мы должны понимать, как идут дела на проекте. У нас может быть зависимость тикетов и участников между собой. Поэтому мы каждый свой рабочий день утром пишем статус в слак, где отвечаем на три вопроса:

  • Что я сделал вчера;
  • Что я буду делать сегодня;
  • Вижу ли я факты, которые мешают закончить задачи в срок.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment