«А если мы просто возьмём больше разработчиков, уложимся к концу месяца?»

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

Крутые компании хотят не только ваших знаний. Им нужны продуктовые разработчики. Но кто это вообще такие? Где заканчивается разработчик обычный и начинается продуктовый? Или они вообще существуют отдельно друг от друга и пересекаются только в фантазиях нанимателей? Попробуем ответить на эти вопросы, составить портрет продуктового разработчика и разобраться, как же им стать. 

Как определить, насколько глубоко на старте проекта надо продумывать его архитектуру? И на чем стоит сфокусироваться сразу, чтобы ее пришлось переделывать в процессе? В своё время, вдохновленный книгой «Принципы» Рэя Далио, я попробовал вывести основные подходы к IT-архитектуре, которые теперь сам активно применяю в работе на старте проектов. О них сегодня и расскажу, чтобы помочь начинающим архитекторам ПО.

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

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

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

Когда мы постепенно переводим легаси систему на новые рельсы, возникает множество случаев, когда само легаси и то, чем мы его заменяем должны взаимодействовать. Поскольку внесение изменений в легаси — это всегда долго, дорого и сложно, нам нужен механизм, который сможет интегрировать возможности новой системы, минимизируя при этом воздействие на легаси. Разбираемся, как можно использовать паттерн «Перехват Событий», чтобы пересылать их в новую систему.

Если вам интересно, какие инструменты не любят инженеры в бигтехе, почему проджекты там скорее не нужны, для чего на самом деле Scrum, и как стоит подходить к ведению проектов, если есть цель вырастить хорошую инженерную культуру и регулярно добиваться необходимых компании результатов, залетайте под кат и давайте разбираться вместе!

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

Есть множество практик проведения демо. Некоторые очень распространены. Другие используются редко. Демо — вообще весьма индивидуальный процесс для каждой команды (особенно при отсутствии зафиксированных регламентов проведения демо). 

Я расскажу о нашем опыте. Что-то в нем универсально и подойдет многим командам. Что-то — очень специфично. Просто берите на вооружение то, что кажется вам полезным, а остальное смело пропускайте.

Продолжаем говорить о производительности и оптимизации кода. Сегодня поговорим о том, как и зачем оценивать сложность алгоритмов,  а также наглядно покажем, как эта сложность влияет на производительность кода.

Поговорим о бенчмаркинге кода: о том, что это такое и для чего нужно. А также покажем, как на основе результатов бенчмаркинга оценить производительность кода в проекте, написанном на C#.

Performance review для сотрудников мы проводим давно, и проходили мы этот путь не без ошибок. Хорошо, что на ошибках можно учиться — из них мы сложили анти-топ и описали его в этой статье.  

Chrome DevTools — это консоль разработчика, набор инструментов в браузере для создания и отладки сайтов и приложений. С их помощью можно в том числе тестировать уже разработанную функциональность.

В этой статье будет подборка полезных инструментов внутри DevTools, которые не очень распространены в QA, но при этом могут значительно упростить и ускорить тестирование сайтов и приложений. К каждому инструменту я сделал небольшой пошаговый туториал.

Отмечу, что говорить мы будем именно о Chrome DevTools, хотя и в других браузерах есть аналогичные консоли разработчиков. Сам их частенько использую — это удобно. Поскольку инструменты неочевидные, рекомендую заглянуть под кат и начинающим, и опытным тестировщикам — точно почерпнёте для себя что-то новое.

Между идеей и готовой для использования разработкой лежит долгий путь из продумывания концепции, формирования продукта, организации разработки и способов продвижения, развития проекта. IT-продукт невозможно создать в два щелчка. Сократить время на разработку и упростить поддержку и масштабирование продукта помогает Headless CMS – инструмент, о котором поговорим в этой статье.

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

Разрабатывая на TypeScript, можно столкнуться с ситуациями, в которых код будет работать не так, как ожидается. В статье разберем несколько таких моментов. Часть просто придется иметь ввиду, часть решается обновлением, а часть исправляется – обо всем по порядку.

Если вам будет удобно сразу же проверять каждый пример, читая статью, можно это делать в редакторе. Он удобен тем, что версию TypeScript в нем можно переключать.

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

В мире Digital Experience платформ (DXP) понимание процессов работы с данными – ключ к достижению успеха. В этом материале – реальный сценарий внедрения продвинутого трекинга и аналитики с использованием Kentico Xperience 13 DXP. Не важно, работаете вы с Xperience by Kentico или с Kentico Xperience 13, принципы мониторинга активности остаются неизменными. Поэтому статья актуальна для обоих случаев.

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

Асинхронность – это способ координации поведения программы на протяжении какого-то временного отрезка. Разбираем, как в синхронном JavaScript вынести операции за рамки единого потока, чтобы не блокировать действие кода после тяжёлых операций.