Senior Frontend - javascript, html, css

​Отрицание, торг и принятие работы над проектом без документации

В мире разработки программного обеспечения существует множество вызовов, и одним из них является столкновение с проектами, лишенными должной документации. Это часто вызывает чувство потерянности и озадаченности, подобно тому как путник оказывается в темном лесу без карты и компаса. В таких моментах первая мысль, которая приходит в голову, - "Может, лучше свернуть назад?"

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

С таким мощным стимулом автор статьи и решила приступить к делу:

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

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

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

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

5. Описание сценариев использования (use case): Представим себя в роли пользователя и опишем типичные сценарии использования нашего продукта. Это поможет нам лучше понять его функционал и потребности пользователей, а также выявить возможные улучшения и дополнительные функциональные требования.

6. Документация API с использованием Swagger: Документация API - это неотъемлемая часть любого современного проекта. Она позволяет другим разработчикам легко и эффективно взаимодействовать с нашим продуктом, используя наши API.

👉 @seniorFront

​Как провести первую ретроспективу и не облажаться?

Ретроспектива - взгляд в прошлое, это активность, в рамках которой, команда проводит анализ своей работы за определенный период времени: спринт, квартал, год. Также важно сказать, что ретроспектива может быть посвящена не только спринтам, но и задачам, процессам, подведению итогов года/проекта или просто, как активность для сближения команды.

С чего стоит начать подготовку и о чем необходимо задуматься заранее?

1. Определитесь с целью проведения ретроспективы. Что вы хотите обсудить с командой? К примеру: проанализировать спринт, подвести итоги года? Или же вы хотите выявить причины проблем, которые происходили в течении определенного периода времени.

2. Подготовьте презентацию, в которой отобразите вводную информацию для участников ретро: пояснение, что такое ретроспектива; цели; правила, повестку. Это буквально несколько слайдов, но благодаря этой презентации команда будет понимать, что ее ждет. Также, не мало, важно донести ценность мероприятия.

3. Важно определиться с форматом ретроспективы онлайн или оффлайн, а также предусмотреть соответствующие инструменты для комфортного проведения ретро. Если онлайн, то рекомендую популярную платформу Miro, в которой вы найдете шаблоны для ретроспективы на любой вкус, начиная от классических шаблонов Agile ретроспективы заканчивая тематическими (в стиле: стартрека; мультиков, путешествия) Есть и другие платформы: trello, confluence, retrius.

4. Мне очень помогает смоделировать возможные варианты введения мероприятия. Конечно, Вы не сможете предусмотреть все ситуации и кейсы, НО вы проработаете свой формат введения. Заранее продумайте введение ретроспективы; проблемы, которые Вы видите, используйте правильные вопросы: Что у нас получилось хорошо? Что Вас демотивировало? Что мы могли бы улучшить или сделать для более успешного результата?

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

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

7. Еще одно не менее важное действие – это сбор обратной связи: проведите опрос или просто спросите у коллег в Вашем чате команды: Понравилось ли эта активность и чего не хватило? Так скажем на будущее, чтобы развивать свои навыки по проведению ретроспективы.

👉 @seniorFront

​И снова о useCallback

Во время собеседования, когда меня спросили про хук useCallback, я ответил, что его использование имеет смысл только тогда, когда функция передаётся из родителя в дочерний компонент, а сам дочерний компонент обёрнут в memo. В таком случае ссылка на функцию из пропсов, обёрнутую в useCallback, останется неизменной, если родитель был перерисован, и мы избежим лишней перерисовки дочернего компонента. Собственно, данный вопрос даже на Хабре разбирался неоднократно, в том числе с залезанием в исходники (например, вот). Здесь следует понимать, что даже если мы всё сделали так, как написано выше, но дочерний компонент принимает прочие аргументы (помимо мемоизированной функции), и эти прочие аргументы изменились - всё, ваш useCallback из родителя официально бесполезен. Уже на таком этапе. И вроде бы двое собеседующих со мной согласились, но следом прозвучал вопрос "а вы использовали useCallback в проектах?", что говорит о том, что моя трактовка посчиталась ошибочной. Как оказалось, с пониманием использования этого хука проблемы куда глубже.

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

👉 @seniorFront