От новичка до младшего инженера
Как изменились мои навыки программирования с начала моей карьеры
От новичка до младшего инженера. Это странная должность, которую я знаю. Эта статья является первой в серии статей об алгоритмах, структурах данных, продуктивности и языках программирования.
Ну кто я?
Я младший программист, работаю со стартапом здесь, в Индии. Я пытаюсь разобраться в программировании уже около восьми лет. Но, работая в стартапе, я быстро понял, что одних базовых знаний недостаточно для создания отличных решений. Изначально при обучении программированию. Мне не нужно было думать о том, смогут ли другие люди прочитать мой код или даже подумать о том, насколько оптимизировано мое решение. Если код сработал, не связывайтесь с ним. Это была моя политика. Вот кое-что из того, что я делал раньше, и какие изменения я внес
Всегда стремитесь стать мастером, как босс 😎
Для меня git был просто способом загрузки моего кода на Github. Так что я никогда не создавал реальный рабочий процесс вокруг этого. Какие бы изменения я ни вносил в код, единственные шаги для его фиксации всегда следовали этим простым командам.
git add . git commit -am "Made some changes" git push origin master
Я знаю, что git master будет думать, что этот дурак делает. В свою защиту скажу, что в то время это было все, что мне было нужно. Я не занимался открытым исходным кодом и не делился кодом с другими. Если вы никогда этого не делали, то вау!
Итак, какие изменения я сделал?
- Всякий раз, когда я планирую что-то протестировать или поэкспериментировать в одном из своих проектов, я создаю ветку с именем «EXP-название-ветки». Если бы я планировал добавить функцию, то имя было бы «FT-name-of-branch». Эта схема именования помогает мне отслеживать ветви и даже быстро понимать, к чему относится каждая ветвь. Без этой схемы я бы просто случайным образом назвал каждую ветку. Это позже приводит к аду, когда я пытаюсь найти что-то конкретное.
- Всегда добавляйте сообщение фиксации. Я делаю то же самое, что и со схемой именования веток. WIP: ‹msg› за работу, проделанную до момента фиксации этого кода. Ft: ‹msg›, чтобы указать завершенную функцию. Ошибка: ‹msg›, чтобы показать исправления ошибок. При слиянии окончательного кода я объединяю все незавершенные работы и коммиты функций в один и всегда оставляю коммиты ошибок как таковые. Позже это поможет мне узнать, где находятся исправления ошибок. Кроме того, никогда не исправляйте ошибки в ответвлениях функций. Наконец, когда функция развернута и не находится в активной разработке, ветвь функции удаляется.
- Не просто git добавьте все. Всегда проверяйте свой код и добавляйте в коммит только правильные файлы.
Если вышеизложенное кажется слишком сложным, оставьте две ветки для своих проектов, например, master и development/staging. Даже немного организации имеет большое значение.
Пишите код так, будто завтра не наступит. (ЙОЛО) 😎
Когда я сделал свой первый мерж-реквест в проект, я получил отзыв о рефакторинге кода. Измените стиль переменных, чтобы ваши функции были лучше. Я был как! Хм! какие? 😶 .
Всякий раз, когда мне нужно было написать функцию в коде, я добавлял ее туда, где только мог найти для нее место. Иногда над функцией, вызвавшей ее, иногда ниже или в любом другом месте, которое я считаю достойным в кодовой базе (я знаю). Это сработало для меня, «ctrl + щелчок» всегда использовало эту функцию, поэтому я никогда не беспокоился об этом. Когда вы пишете код, вы пишете роман. Вы можете написать это как в одной из тех книг «Мурашки по коже», где читатель выбирает следующую страницу для перехода к нижней части текущей страницы. Вы также можете сделать это так, как любой хороший роман расположил бы его в удобочитаемом порядке, глава за главой в точном порядке. Отдавайте предпочтение главе за порядком глав. Это поможет вам и вашей команде при чтении кода. Они не потеряют слишком много контекста при чтении кодовой базы. Позже, когда вы пытаетесь понять, что вы написали. Это имеет гораздо больше смысла, когда код организован. Конечно, подход «мурашки по коже» хорош, но не всем он нравится. TLDR: всегда пишите код в структурированном формате.
Когда вы видите ошибку, нанесите пластырь 🤕
Итак, приступим к исправлению ошибок. Всякий раз, когда я получаю исключение, первое, что нужно сделать, это добавить условие, в котором говорится, что если null, то вернуть false или выйти. Это то, что я называю пластырем. Повязки — это простое решение, и их добавление не требует больших усилий. Самое главное, что это решает проблему, но что, если бы под ней были сломанные кости. Повязка могла остановить кровотечение, но кости остались сломанными. (Я знаю, не очень хороший пример, но в этом есть смысл)
Когда вы сталкиваетесь с какой-либо ошибкой, прекратите применять условие if, сначала проследите немного назад и узнайте, что привело к исключению и какие функции были ответственны за то, что произойдет, если вы пропустите этот шаг. Я написал эту маленькую библиотечную функцию, которая считывает заголовок файла, а затем возвращает определенный флаг. Неизвестно мне, что байты данных, отправленные в мою функцию, были нулевыми. Я добавил простое исправление, возвращающее ноль в таком случае, но вызов функции на другом конце выполнял целую кучу обработки, если значение было равно нулю. Как только исправление было запущено, мы начали получать странные ошибки, и нам пришлось откатить выпуск. Около часа отладки позже выявили проблему. Если бы я только что сделал это раньше, это могло бы быть решено гораздо раньше. Такие ситуации случаются всегда. Исправление может работать, но в то же время создает непреднамеренные побочные эффекты в будущем. TLDR: Никогда не пишите исправление ошибки, не определив точную причину исключения.
If If If If… 💭
Если в конечном итоге вы добавите в свою программу много операторов if или условий, возможно, вы захотите немного перепроверить свою логику. Возможно, некоторые или все эти условия можно было бы объединить в пару базовых случаев и избежать добавления условий, которые, как вы знаете, никогда не произойдут. Раньше я делал это (в основном, начал делать это, когда у меня были большие проекты, просто испугался мысли о сбое). Иметь слишком много условных выражений нехорошо. Старайтесь не включать в условное выражение как можно больше кода, это облегчит его чтение.
Пишите от себя 😋
Допустим, вы работаете с ранее существовавшим проектом и начинаете писать код в змеиных случаях. Ни о чем не беспокоясь, вы фиксируете код. Позже старший зовет вас на звонок и начинает подробно объяснять, как форматировать код. (не то чтобы это было раньше). Да, у всех нас есть табы, пробелы, vim, emacs, { после строки или в конце строки. У проекта и вашей команды уже есть определенный стиль, который подходит всем. Никогда не пишите код, который его ломает. Конечно, переименовать переменную очень просто. Когда люди начинают придерживаться индивидуального стиля в коде, ориентироваться в нем становится сложнее. Всегда следуйте общему набору стандартов, с которыми соглашается ваша команда. Прочитайте код или обратитесь к нам, чтобы узнать о стандартах и методах кодирования.
Пишите сложный код как босс 💪🏼
Иногда этот синдром самозванца проявляется слишком сильно. Мы читаем или видим какой-то код, который делает что-то похожее на инопланетян и пытается создать что-то точно такое же. Единственная проблема в том, что мы в конечном итоге добавляем хаос к простой проблеме. Поверьте мне, у каждого младшего инженера есть немного синдрома самозванца. Простой следует обрабатывать как таковой. Да, вы можете сделать это сложнее, а затем заставить старшего отклонить запрос на слияние, просто нет никаких причин для этого. Код написан для решения проблемы, а не превращает ее в проблему.
Я верю только в код 🧑💻
Мы все склонны сначала прыгать за компьютер, даже не задумываясь о проблеме. Не приступайте к реализации решения, как только у вас возникнет проблема. Попытайтесь понять, как вы могли бы подойти к этому, даже если проблема проста. Пяти минут достаточно, чтобы подумать о подходе, который вы хотите реализовать, о структуре данных, которую вы хотите использовать, и, самое главное, о правильном решении. Однажды я потратил часы на реализацию этого сумасшедшего алгоритма, чтобы создать набор записей в кэше для получения более быстрых результатов. Проблема заключалась в том, чтобы вычислить часть предварительного кэша. Это заняло больше времени, чем фактическое создание вывода. Самое простое решение, которое я упустил из виду, заключалось в том, что мне не нужно было делать это каждый раз. Я мог вычислить предварительный кэш во время сборки и отправить его пользователю всего за дополнительные 5 КБ для приложения. и загрузка, которая заняла менее 3 мс. Я провожу целый день, пробуя быстрые алгоритмы для создания записей на стороне пользователя и игнорируя другие возможные решения. (там, где структура данных сыграла роль в этом, был файл в формате trie ) подумай дважды, прежде чем писать код всегда.
Прошел год работы младшим инженером, а я все еще не закончил учиться. Я еще о многом хочу поговорить. Вот я и планирую снимать эту серию. Я планирую продвигаться по карьерной лестнице и лучше думать и реализовывать решения. Я планирую выпускать 3 сообщения в блоге в месяц. если вы хотите следить за моим путем к тому, чтобы стать лучшим инженером, подписывайтесь на меня здесь, на Medium.
