Pull to refresh
  • by relevance
  • by date
  • by rating

Одна особенность корпоративной культуры, необходимая для благополучия кодовой базы

Perfect codeDesigning and refactoringDevelopment ManagementProject managementProduct Management
Translation


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


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

Читать дальше →
Total votes 30: ↑30 and ↓0 +30
Views10.3K
Comments 20

Как не продолбать архитектуру в погоне за фичами

Miro corporate blogWebsite developmentDevelopment Management

Я работаю в Miro со дня основания, вначале как фронтенд инженер, сейчас как менеджер core-команд, которые разрабатывают внутреннее ядро канваса и realtime-коллаборации на нём.

Мы очень быстро растём: в пользователях, в размере команды, в количестве выпускаемых фич. Немного фактов за 2020 для контекста:

— Перешагнули рубеж в 10 миллионов регистраций;

— Пиковая онлайн-нагрузка за год выросла в 7 раз;

— Команда разработки выросла в 2 раза (инженеры, продакты, дизайнеры);

Выглядит круто! Но есть нюансы.

Наблюдая за компанией 9 лет, я вижу, что кратное увеличение количества инженеров приводит к падению скорости разработки. Задачи по созданию новой функциональности приводят к костылям. Текущая архитектура не позволяет сделать их правильно, а на рефакторинг времени не хватает. Непонятно кто именно должен брать на себя рефакторинг. Начинаемые архитектурные изменения не доводятся до конца из-за отсутствия фокуса. Порог входа  в код повышается, онбордить новичков становится сложнее. Time to market новых фичей падает. 

Это то, куда может завести разработка с фокусом на новую функциональность, но без выделения достаточного времени на архитектуру. На стадии роста новые фичи часто побеждают рефакторинг по приоритетам.

Так мы сталкиваемся с задачей “Как сохранить скорость разработки фичей и гибкость архитектуры на стадии роста?”. Откатимся назад в прошлое и будем пробовать разные подходы чтобы прийти к тому, что есть сейчас.

Читать далее
Total votes 29: ↑28 and ↓1 +27
Views9.1K
Comments 16