Выделитесь как младший разработчик с этим планом из 5 шагов
Уважаемый младший фронтенд-разработчик!
Умение решать проблемы напрямую влияет на вашу способность писать код.
Структурированный подход не только поможет вам выполнять работу быстрее, но и означает, что у вас всегда есть план, когда люди об этом просят. А когда вы просто прикидываетесь, восприятие так же важно, как и реальность.
Я разработчик Frontend и, узнав о роли, записал то, что хотел бы знать, когда начинал.
Здесь мы начинаем с основ, но эти статьи призваны помочь вам в реальной рабочей среде, возможно, даже в вашей первой роли.
Что мы расскажем
- Понимание того, чего мы пытаемся достичь
- Знакомство с нашей существующей кодовой базой
- Разбиваем проблему на управляемые куски
- Генерация идей для решений
- Общение со своей командой
1. Перво-наперво - что мы пытаемся построить?
Наша цель как разработчика - решать проблемы. Это может быть новая функция, исправление ошибки или исследование новых технологий и подходов.
Как бы то ни было, мы всегда ищем решения.
Это звучит просто и почти слишком просто, но прежде чем мы коснемся строчки кода, нам нужно четко понять, чего мы пытаемся достичь.
Если вам повезло, вы работаете в команде с менеджером по продукту, который отвечает за написание билетов (также называемых историями / карточками / задачами), над которыми вы можете работать.
Если вам очень повезет, они напишут в заявке «Критерии приемлемости», объясняя контрольный список того, чего должна достичь реализация, чтобы ее можно было классифицировать как завершенную.
Тем, у кого нет такой роскоши, мы должны написать, как будет выглядеть конечная цель и какие требования мы должны удовлетворить.
Это наша конечная цель.
Обязательно думайте о пользователе
То, чего вы пытаетесь достичь, должно вращаться вокруг вашего пользователя. Постарайтесь подумать о проблеме с их точки зрения и понять, как они будут использовать ваше приложение.
В конечном итоге мы заботимся о решении проблем для нашего пользователя. Обычно это человек, который оплачивает счета, решив использовать наш продукт.
Дополнительный квест: По мере того, как мы начинаем изучать этот ориентированный на пользователя подход, мы можем писать истории пользователей, чтобы попытаться понять проблемы с их точки зрения. Это может помочь нам понять их путь через приложение.
А пока давайте просто будем держать их в голове, когда записываем нашу цель.
2. Узнайте, что в настоящее время делает код
У нас есть представление о том, куда мы идем, и следующее, что нужно сделать, это понять, где мы находимся сейчас.
Если вы новичок в компании, вы работаете с незнакомой кодовой базой. Если вы создаете свой собственный проект, это немного проще, поскольку вы уже знаете, как выглядит код. В конце концов, вы все это написали.
Каким бы ни был проект, найдите время, чтобы понять, как в настоящее время работает код и какие механизмы уже используются в тех частях, в которые вы собираетесь вносить изменения.
Это наше текущее состояние.
3. Разбейте проблему на части и заполните пробелы.
У нас есть представление о том, куда мы идем, конечное состояние, которого мы пытаемся достичь, и понимание того, как в настоящее время работает код.
Следующим шагом будет заполнение пробелов. Опять же, мы запишем их, может быть, в виде простого контрольного списка. (Я использую приложение для заметок на своем Mac)
Составим список грубых шагов, которые помогут нам пройти от А до Я?
Давайте посмотрим на пример
Мы работаем над веб-приложением. Пользователи могут удалять большие списки данных за один раз, и это изменение необратимо. Мы получили отзывы о том, что пользователи не всегда хотят вносить изменения, и было решено, что вы внедрите модальное окно подтверждения, прежде чем мы завершим действие удаления.
Мы можем начать разбирать проблему, и некоторые грубые шаги могут быть следующими:
- нам нужен триггер для открытия нашего модального окна, когда пользователь пытается удалить список
- нам нужно отобразить модальное окно поверх нашего приложения, оно, вероятно, должно иметь некоторую «закрывающую» функцию, если пользователь щелкает или нажимает X
- модальное окно должно содержать какое-то сообщение, оно может быть динамическим в зависимости от удаленных данных
- нам нужны кнопки действий, скажем, кнопка подтверждения и кнопка отмены
- нам нужны функции для завершения действия как для подтверждения, так и для отмены
Теперь у нас есть контрольный список задач, над которыми нужно работать.
Этот пример не очень сложный, но его легко переполнить более сложными тикетами. Наличие списка, к которому можно вернуться, позволяет нам сосредоточиться и дает нам ориентир, если мы немного заблудились.
4. Где взять идеи для реализации?
У нас есть список фрагментов, которые нужно заполнить, теперь мы должны построить его.
У меня есть несколько тактик для понимания того, как выполнить задачу:
Решалась ли эта (или аналогичная) проблема в нашей кодовой базе раньше?
Если мы сделаем шаг от нашего примера, скажем, добавим новый модальный код, весьма вероятно, что модальный компонент уже есть в нашей базе кода.
Найдите время, чтобы осмотреть наш существующий код и проверить подход. Даже если реализация не совсем такая же, она может дать вам представление о том, как другие подошли к чему-то похожему.
Согласованность в нашем приложении важна, мы не хотим иметь множество разных подходов к одной и той же задаче или, что еще хуже, несколько реализаций одного и того же.
Очевидно, что это работает не для всех, но старайтесь не изобретать колесо заново, где это возможно.
Google - ваш друг
Часто шутят, что учиться на разработчика - значит просто учиться искать в Google.
Хотя это может быть не на 100% точным, умение искать ответы вам очень поможет.
Допустим, мы реализуем наш пример модального окна с нуля и хотим закрыть его, когда пользователь щелкнет мышью.
Возможно, вы раньше не писали корневую функцию закрытия. Вы даже не можете называть это корневым закрытием. Но поиск чего-то вроде закрыть модальное окно, когда пользователь щелкнет в React, вероятно, даст вам хороший ответ.
Иногда ответ включает добавление библиотеки для быстрой реализации решения, будьте осторожны. Хотя у них есть свое место, и большинство интерфейсных приложений возможно только с библиотеками, они не должны быть вашим первым портом для решения всех проблем.
Прочтите документацию
Еще одна очень простая идея, которую иногда упускают из виду, - это посмотреть документацию.
Это будет верно на каждом этапе вашей карьеры программиста. Фронтенд-разработка - это постоянно меняющийся ландшафт, и документация обычно является местом, где можно понять последние обновления или подходы.
В документации по разным технологиям так много полезной информации, и если чего-то не хватает, скорее всего, у других возникнет такая же проблема, вернитесь к шагу № 2.
Примечание. Если это общий запрос, связанный с JavaScript или веб-сайтом, документы MDN просто великолепны.
5. Попросите внести свой вклад, прежде чем начать.
Как только у нас будет план, давайте рассмотрим его с другим человеком в команде.
Это помогает более чем одним способом.
Сначала вы можете взглянуть на проблему с другой точки зрения. Может быть, есть более простой подход, который мы упустили, может быть, в вашем приложении есть что-то особенное, о чем вы не знали.
Во-вторых, это позволит вашим коллегам узнать, что вы пытаетесь разобраться в проблеме, прежде чем переходить к ним.
Просить о помощи - это нормально. На самом деле это рекомендуется.
Но мы все заняты, так что баланс.
Как юниоры, мы хотим сначала попробовать себя, а затем либо спросить, потому что мы застряли, либо подтвердить свой подход.
Легко потратить часы на отработку подхода, который либо не работает, либо просто не лучший вариант для нашего приложения.
Заключение
Это всего лишь мой мыслительный процесс, как вы структурируете свой подход? Я хотел бы услышать больше в комментариях.
Спасибо за прочтение!
Китсон
