group-telegram.com/reactify_IT/1331
Last Update:
В YeaHub работают новички, и я замечаю одни и те же ошибки, которые, если и не критичны, то точно неприятны. Повторение их может привести к тому, что с человеком просто попрощаются на испытательном сроке. В основном проблемы связаны с тем, что ребята не проверяют свой код перед отправкой, не тестируют его и не вникают в бизнес-требования.
На пет-проектах многие привыкают работать без четких стандартов: если текст не выровняли, то "потом как-нибудь". Ведь заказчика нет, никто не будет настаивать на исправлениях. Но это не норма. В продакшн-разработке у вас есть макет, и вы обязаны реализовать его точно до пикселя.
1. Невнимательность к качеству верстки
Представьте, что вы — мидл-разработчик в компании с зарплатой 200к. Если на проверку вы отправите верстку, не соответствующую макету, вас не только неоднократно отправят на доработку, но и запомнят как ненадежного сотрудника. Поверьте, никто не захочет тратить дни на тестирование вашего кода, если вы каждый раз правите только одно замечание, а следом появляются новые. Это загружает тестировщика, который гоняет вас с правками 4-5 дней, и раздражает коллег, вынужденных ревьюить один и тот же код снова и снова.
- Проверяйте верстку на соответствие макету с помощью Pixel Perfect.
- Старайтесь устранять все замечания разом, чтобы не засыпать коллег бессмысленными коммитами.
2. Отправка неаккуратных Pull Request
Задача — отправлять чистый, аккуратный коммит с минимальным количеством файлов и изменений. Если в файле не было задачи или необходимости в правках, не вносите туда изменения, даже если это просто пробел, кавычка или отступ. Изменение структуры, не связанной с задачей, отвлекает и создает беспорядок в истории проекта.
- Добавляйте в PR только те файлы, которые реально были затронуты задачей.
- Не меняйте стили и форматирование файлов, если это не связано с вашей задачей.
3. Отправка нерабочей функциональности
Если вы сделали кнопку для открытия меню, убедитесь, что меню действительно открывается. Когда тестировщик запускает ваше приложение и видит, что оно не работает, это считается серьезной ошибкой. Подобные ошибки сразу попадают в "черный список". Ошибки функциональности — это прямой показатель недоработки перед сдачей.
- Тестируйте каждую функцию локально перед отправкой на ревью.
- Проверяйте на разных разрешениях экрана и в разных браузерах, чтобы избежать багов.
4. Игнорирование пограничных случаев
Ваш код должен обрабатывать все возможные случаи, в том числе и пограничные. Например, пустые данные, необычные пользовательские вводы, нестандартные разрешения экранов. Это позволяет избежать "неожиданных" ошибок на продакшене и сохранить положительную репутацию кода.
- Обдумайте все сценарии, в которых может использоваться функциональность, и протестируйте их.
- Чаще перезагружайте страницу, чтобы понять, возникнет ли ошибка, если данные придут пустыми, или нужного поля не будет
Ваша задача — сдавать код, который не вызовет ни единого замечания. Это стандарты работы, и никто не будет терпеть халатное отношение к задаче. Те, кто постоянно делает одни и те же ошибки, будут выгнаны с испытательного срока.
Учитесь работать над ошибками и доводить каждую задачу до идеала.
#frontend #work
