Как прошел день?
Потрясающий! 😆
Что мы сделали?
Мы создали новый простой реактивный проект с нуля! 💻
Учение дня:
Имейте в виду общую картину, прежде чем начинать вводить коды
Перед тем, как начать печатать коды, особенно для новичков, стоит потратить несколько минут, чтобы сначала нарисовать структуру, чтобы убедиться, что мы полностью понимаем, чего мы пытаемся достичь с помощью кодов, которые мы создаем, и что они делают. нам нужно сделать, чтобы коды работали. Когда мы теряемся во время кодирования, мы всегда можем взглянуть на структуру, которую рисуем, и вернуться на правильный путь.
Создайте проект с нуля вместо «копирования и вставки» с нуля
В рамках обучения мы иногда обращаемся к существующему примеру и пытаемся сами создать очень похожий проект.
В предыдущие несколько дней, когда я создавал новый проект, я начал с просмотра каждого файла в папке примера. Я старался не копировать и вставлять коды, вместо этого я продолжал ссылаться на пример, печатал сам и пытался задавать вопросы, когда ничего не понимал. Однако было несколько проблем:
- Я создал файлы в нелогичном порядке, поэтому не понял, зачем мне эти файлы.
- Я импортировал файлы, когда их еще не было, поэтому я не понял, зачем мне эти файлы в текущем файле.
- Мне удалось понять, что делают функции или значение некоторых строк кода, но я не был уверен, чего я пытался добиться, потому что я не создавал их в логическом порядке.
- В конце концов, даже несмотря на то, что я заставил проект работать, мне все равно было неудобно создавать еще один новый простой проект с нуля самостоятельно.
Сегодня вместо «копирования и вставки» с нуля мы создали папки и файлы и написали коды в логическом порядке (т. е. создали их или набрали коды только тогда, когда они нам нужны). Таким образом, я смог понять, чего я пытался достичь на каждом этапе и почему каждый файл или часть кода необходимы для работы всего проекта. В конце сегодняшнего дня я почувствовал себя более комфортно, создав простой проект самостоятельно.
Начните с «худшей» практики, рефакторинг позже
На работе мы часто слышим термин «лучшая практика». Разработчикам всегда важно применять «лучшие практики» к кодам. Однако, как новичку, при изучении программирования мне лучше начать с «худшей практики» (т.е. использовать самый простой способ добиться чего-то и записать все коды в один файл). Делая это, я могу убедиться, что изучаю одну вещь за раз. Когда я полностью понимаю «самую простую» версию проекта и чувствую себя в ней комфортно, я могу сделать шаг вперед, сделать некоторый рефакторинг. Это может быть использование «более умного» способа для достижения того же самого, перенос некоторых частей кода в разные файлы, чтобы сделать их повторно используемыми, или создание разных слоев для проекта и т. д.
Старайтесь объяснять, управляя клавиатурой
При парном программировании, когда штурман гораздо опытнее меня, как новичок, я легко теряюсь. Обычно, когда опытные разработчики управляют клавиатурой, у них есть четкое представление о том, чего они пытаются достичь. Они могут продолжать пробовать разные вещи, чтобы заставить их работать, менять связанные коды в нескольких местах после того, как изменили что-то одно, и двигаться довольно быстро. Проблемы для меня следующие:
- Когда они пробуют разные вещи, я понятия не имею, чего они пытаются достичь в этот момент и почему они думают, что эти разные вещи могут сработать.
- Когда они быстро меняют все связанные коды в разных местах, многие предыдущие коды меняются, но я не мог уследить за этим. Я мог бы понять предыдущие коды, но после их быстрого изменения я не мог понять, как они достигают некоторых из предыдущих шагов, используя текущие коды.
- Когда они быстро набирают код, даже если я пытаюсь сосредоточиться и продолжать задавать вопросы, моя скорость задавания вопросов не может сравниться с их скоростью набора кода.
Было бы здорово, если бы опытные разработчики могли продолжать объяснять новичкам, когда они набирают код. Это немного замедлит их скорость набора текста, даст другому человеку четкое представление о том, чего он пытается достичь в каждой точке, а также поможет другому человеку лучше следить за процессом.
«Оцените» уровень аудитории, прежде чем объяснять
Сколько раз я задавал разным людям один и тот же вопрос, я заметил, что некоторые объяснения мне понятны, а некоторые нет. После обсуждения с некоторыми другими людьми я понял, что это произошло из-за слов, которые они используют для объяснения.
Например, когда я спрашиваю значение технического термина, у меня в голове возникает один вопросительный знак, но когда некоторые разработчики пытаются объяснить значение одного технического термина, они используют больше технических терминов! Затем у меня в голове появляется больше вопросительных знаков, и я понятия не имею, какой из них мне следует задать.
Хороший способ решить эту проблему: опытные разработчики могут попытаться «оценить» уровень аудитории, прежде чем объяснять, и использовать для объяснения подходящие слова вместо «правильных слов». Это может помочь аудитории легче понять объяснение. В то же время это может улучшить навыки наставничества спикеров и заставить самих спикеров полностью понять некоторые технические концепции.
Думайте нестандартно — думайте об обработке ошибок при разработке
Счастливый путь хорош! Обработка потенциальных ошибок во время разработки лучше!
Используйте существующие общие функции из библиотеки вместо их создания
Для некоторых очень распространенных функций может быть много людей, которые должны их использовать. Так что вполне вероятно, что они уже существуют в библиотеке. Это может сэкономить нам много времени, используя существующие функции из библиотеки.
