Инженерная
культура
- Профессионалы с большим опытом и молодые перспективные разработчики
- Внимательные к деталям во всём: технологиях, подходах, коммуникациях, отношении к работе и коллегам
- Отличаемся стремлением к достижению поставленных целей и открытостью взаимодействий внутри и между командами
- Всегда рады новым коллегам, которые разделяют наши ценности и готовы развивать продукты r_keeper!
Мы делаем бизнес десятков тысяч предпринимателей успешнее: наши решения облегчают ежедневную работу официантов, поваров, кладовщиков и бухгалтеров, а подробная аналитика и отчетность помогают управляющим и менеджерам контролировать бизнес-процессы и принимать взвешенные решения.
работы
Используемая технология должна быть максимально прозрачна для разработчика. Мы поощряем поиск наиболее простых и понятных путей решения задачи.
Там, где это возможно, используем принятый в компании технологический стек, вместо того чтобы создавать изолированную область системы с высоким порогом входа и низким уровнем внесения изменений.
Для поиска подходящих технологий мы обращаемся к Tech Radar, опираясь на такие характеристики, как readability, simplicity, maintainability.
При проектировании новых систем не пытаемся использовать малопопулярные или малопонятные нам СУБД, делая выбор в пользу pg или sql server.
Мы понимаем что от них ждать, как их использовать и обслуживать.
В компании достаточно экспертизы в этих инструментах, чтобы быстро решать большинство типичных проблем. Для нас это – просто.
Любой код — это усложнение.
Добавление бизнес-логики в сервис или компонента в архитектуру должно быть взвешенным и обоснованным решением. Изменения в системе должны происходить исходя из нужд бизнеса, а не наоборот (когда бизнес меняется в ответ на изменения в IT).
Мы аргументируем, какую ценность несет в себе изменение и как это улучшит продукт.
Не пишем кучу кода без четкого понимания, как это поможет получить результат и достичь бизнесу своей цели.
Например, инженеры смогли договориться с дизайном о более дешевом и оптимальном дизайне, который позволит вывести продукт на рынок быстрее.
Мы используем готовые сторонние решения, которые удовлетворяют нашим требованиям и помогают решать задачи. Это могут быть платные или open source решения.
Мы аргументируем, какую ценность несет в себе изменение и как это улучшит продукт.
При разработке сервиса авторизации для одного из продуктов, мы не стали пытаться написать его самостоятельно. Тем более не пытались придумать свой протокол для этого. Вместо этого мы посмотрели на существующие и распространённые решения и выбрали IdentityServer, реализующий стандартные протоколы OpenID и OAuth. В итоге клиенты этого сервиса также смогли не придумывать велосипед, а использовать готовые инструменты для работы по этим протоколам.
Технология — всего лишь инструмент. С фреймворком или без мы решим поставленную задачу. Мы рассматриваем фреймворк к использованию, только если он позволяет сделать работу быстро, легко, качественно и без вреда системе.
Перед включением новой технологии в проект важно ответить на вопрос для чего это и что это нам даст.
Разрабатывая наши продукты, мы порой стараемся учесть все ситуации, которые «должны» произойти в будущем. Но предсказать будущее удается лишь в одном случае из десяти, а ценой ошибки становится решение, которое не на все сто отвечает требованиям «здесь и сейчас». Поэтому мы стремимся к балансу: прорабатываем возможности инкрементальных изменений и адаптации под изменяющиеся условия, но не забываем о том, что требуется от наших решений сегодня.
При проектировании API для одного конкретного клиента мы стараемся удержаться от крайностей. С одной стороны не спроектировать интерфейс один в один под первого пользователя, без понимания, как в будущем этот API будет развиваться. С другой – не спроектировать максимально гибкий и универсальный API, который в будущем может подойти любому другому клиенту. Обе крайности нам не подходят: либо нам будет неудобно вносить изменения в API, развивая его для новых клиентов, либо 80% гибкости API никогда никому не понадобится. Решая сегодняшнюю задачу, мы готовимся к будущим изменениям и будущему развитию, но не пытаемся их предсказать.
Мы стремимся проектировать компоненты системы со слабой связанностью. Для принятия решения о выделении части системы в отдельный сервис мы опираемся на два возможных пути решения:
- DDD (Domain driven design)
- Профиль нагрузки сервиса (баланс чтения/записи)
Мы предпочитаем небольшие сервисы, по возможности с минимальным количеством кода. Проектируемый сервис должен быть максимально автономен, а значит иметь целостную, единую зону ответственности. Под автономностью сервиса мы подразумеваем:
- у сервиса своя команда, он запускается в отдельном процессе
- независимый deployment
- инкапсулированный data storage внутри сервиса (подход share nothing).
Мы используем как проверенные и популярные решения, так и пробуем новые и перспективные технологии.
Полезность инструмента для нас определяется тем, насколько точно он реализует поставленную задачу, насколько может быть гибким и готовым соответствовать быстро развивающимся технологиям в бизнесе. Качество, стабильность и эффективность используемых инструментов — важнейшие критерии для нас. Мы всегда стремимся выбирать решения, которые уже используются в компании или зарекомендовали себя на рынке.
взаимодействия
Во всех видах коммуникаций мы стараемся ссылаться на данные, аналитику, цифры, оперируя фактами, а не гипотезами или личными догадками. Мы стремимся “покрыть” данными 98% всей внутренней разработки. Одно из важнейших правил — поддержка принятия решений и улучшение продуктов должна строится на основе непротиворечивых и объективных данных.
Долг каждого сотрудника — своевременное идентифицировать и сообщать обо всех проблемах, возникающих на пути к достижению наших целей. Для нас нормально открыто говорить о неудачах, проваленных целях и допущенные ошибках. Но мы не миримся с текущими ошибками, а делимся опытом с коллегами, делаем выводы и исправляем ситуацию. Только так мы сможем избежать повторения подобных ошибок в будущем.
Для нас крайне важна честность: мы всегда и обо всём говорим свободно и открыто, стараемся не утаивать как рабочие, так и личные конфликты. Но важный момент: мы принимаем и даем только конструктивную критику, опираясь на факты и рабочие результаты человека, а не на личность. Мы внимательно слушаем друг друга, ведь только прислушиваясь к обратной связи и конструктивной критике, можно сделать работу лучше и эффективнее.
Мы стараемся фокусировать свое внимание на решении проблемы, а не на самой проблеме. Мы должны думать о перспективах и успехе проекта, а не о провалах и причинах, почему что-то может не получиться. Обсуждая решения, мы стремимся учитывать потенциальные риски, вероятность их возникновения и способы минимизации.
Фокус на результате — один из наших главных принципов. Мы подбираем оптимальный баланс между сложностью задачи и её результатом. Упрощать сложные решения, использовать уже готовые инструменты, менять способы коммуникации и взаимодействия между командами — всё это позволяет нам достигать результатов гораздо быстрее. Если этот результат не достиг идеального состояния — не страшно, нам достаточно качественно проделанной работы и достойного результата, принесшего пользу компании и нашим клиентам.
