Вот чему я научился за девять месяцев своей работы разработчиком программного обеспечения

1661461231 vot chemu ya nauchilsya za devyat mesyaczev svoej raboty razrabotchikom

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

Мои мысли о моей роли существенно изменились с тех пор как я начал. Я думал, что быть разработчиком – это как можно быстрее разгонять код. Это далеко от реальности. Быстрое удаление большого количества плохого кода не является масштабируемым способом построения бизнеса или карьеры в области разработки. К счастью, я нашел работодателя, который думал так же, и чей продукт программное обеспечение.

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

Задавайте много вопросов и документируйте ответы

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

Прежде чем обращаться за помощью к другим, я использую этот контрольный список:

  • Задавал ли этот вопрос раньше, и если да, где я задокументировал ответ?
  • Это то, что я могу погуглить?
  • Это где-то документировано кем-то из внутренних органов?
  • Что здесь происходит? Какова основная причина ошибки или неожиданного поведения, с которой я сталкиваюсь?
  • Действительно ли я понимаю вопрос, на который я пытаюсь ответить? Это нормально, если выделите немного времени и перечитаете проблему еще раз, а не дадите полуразговорный или поспешный ответ.

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

Если я прошел 90% пути к решению проблемы и нуждаюсь только в последних 10% помощи, старший разработчик будет рад помочь, зная, что я достиг максимально возможного самостоятельно. Искать кого-то другого, кто решит ваши проблемы, не замечательный способ укрепить доверие в вашей команде.

Умные люди любят хорошие вопросы – поэтому задавайте их.

Избегайте делать одни и те же ошибки и не задавать одни и те же вопросы снова и снова

Это легче сказать, чем сделать, и это может относиться к любой работе, а не только к программированию. Вам подбрасывают много новых концепций и информации и ошибки неизбежны. Помните об этом. Подумайте, прежде чем спрашивать. Кстати Google. Посмотрите документы. Они твои друзья. Если вы видите тенденцию, попытайтесь определить ее. Приложите активные усилия, чтобы поймать себя на том, что задаете один и тот же вопрос. Запишите это и задайте себе цель исправить это.

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

Всегда проверяйте свою работу

Никто не любит проходить через PR и говорить вам удалить console.logs и отладчики или говорить вам исправить ошибки linting. Я бы не опубликовал эту публикацию, не прочитав ее несколько раз и не попросив друга посмотреть.

Посмотрите на свой код и задайте себе следующие вопросы:

  • Я написал сложную логику. Есть ли в программе схожие функции, которые, возможно, делают это более ясным, гибким или общим способом?
  • Если нет, вспомню ли я, почему я написал этот код через неделю? Если ответа нет, я, вероятно, хочу изменить код или прокомментировать его. Человек, просматривающий PR, должен знать определенный контекст, почему я принял такое решение.
  • Убедитесь, что код прошел линтирование и тесты, прежде чем отдавать его кому-то другому.
  • Я повторяюсь? Могу ли я инкапсулировать логику, которую я повторяю в функцию?
  • Будь это чужой код, который я просматривал, какие комментарии я бы сделал? Что бы я хотел изменить, чтобы сделать это понятнее?

Посмотрите на свой код свежим взглядом (возможно, на следующий день). Существует ли конкретная логика, украдающаяся в компоненты, которых не должно быть? Или ваш компонент, обрабатывающий бизнес-логику, должен попасть в контейнер?

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

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

Это может показаться глупым, но большие кодовые базы сложны, и вы можете не отдавать себе отчет в том, что что-то сломали, пока не сделаете этого.

Серьезно, вы не хотите видеть первый черновик этого сообщения в блоге 🙂

Ничто не магия

Как правило, существует веская причина, почему код был подвергнут LGTM (одобрен и в базе кода). Если вы не понимаете, как это работает, потратите некоторое время, чтобы это понять. Зарегистрируйте информацию, сломайте информацию, просмотрите некоторую документацию относительно используемых функций и шаблонов.

1*0aWphq93q6n-iagD06Yizg
Изображение моей рабочей резиновой утки, которая знает больше о программировании, чем я

Не могли бы вы рассказать своему резиновому утенку, как он работает? Если вы все еще не уверены, задайте несколько вопросов относительно конкретных пробелов в вашем понимании.

Получите комфортную отладку, поскольку вы делаете это часто

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

Некоторые полезные ресурсы, которые я нашел:

Профессиональный совет: Выход console.log можно стилизовать с помощью CSS. Это упрощает идентификацию журнала, который вы хотите увидеть.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');
1*b2xJzCNke1kuLiSzmHyXGQ
консольный выход

Следите за данными

Это повторялось снова и снова, потому что, правда, я совершал ошибку. Это то, в чем я стал лучше, но еще нужно работать.

Значительная часть разработки программного обеспечения предполагает манипулирование данными в формате, чтобы пользователь мог извлечь из них практическую информацию или обновить их самостоятельно.

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

Выделите свои проблемы, а затем интегрируйте их в то, над чем работаете

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

Подумайте, как должна работать функциональность

Написание того, как что-то должно работать с высоты 30 000 футов, а затем с технического уровня, помогло мне понять, что я должен строить, как я должен это строить, и помогает смягчить падение из ямы. Если я не могу объяснить, как работает то, что я строю (с высокого и низкого уровня), я оказываю медвежью услугу. Без плана я собираюсь много крутить колесо в ближайшем будущем.

Кроме того, я могу вернуться к тому, что я написал или показать кому-то, что я думаю, что помогает уменьшить непонимание.

Принимайте борьбу

После 10 000 часов борьбы на работе вы станете лучше справляться с проблемами и решать их. Вам придется это делать, несмотря на это, так что наслаждение этим опытом сделает ваш изо дня в день намного, гораздо лучше. Немного посмейтесь над собой и попытайтесь по-настоящему разобраться в проблеме. Вы добьетесь этого, даже если вам нужна дополнительная помощь.

Воспринимайте конструктивную критику и постоянно повторяйте ее

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

Не спеши

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

Продолжайте обучение вне работы

Несмотря на то, что я учусь на работе, я все равно хочу продолжать изучать новые вещи, кроме простой работы над нашей кодовой базой. Это может быть изучение Python, создание бота, работа над серией видео или работа над личным проектом. Я создал доску с помощью Zenhub + Github, чтобы отслеживать, где я нахожусь и что я обязывался в течение месяца. Соблюдение общей цели в месяц заставило меня продолжать учиться, строить и, да, вести блог в свое свободное время.

Добавить комментарий

Ваш адрес email не будет опубликован.