User Эллеонора Керри
Эллеонора Керри
41 уровень

Кофе-брейк #8: Как быстро научиться читать чужой код. Ошибки при создании профиля на GitHub

Статья из группы Random

Как быстро научиться читать чужой код

Источник: Selftaughtcoders Наверняка многие из вас знакомы с ситуацией, когда собственный код вы уже более-менее научились читать, но при попытке заглянуть в чужой сразу теряетесь. Для решения этой проблемы есть проверенная методика. Поверьте, если в ней разобраться, она покажется вам очень простой. Кофе-брейк #7: Как быстро научиться читать чужой код. Ошибки при создании профиля на GitHub - 1

1. Найдите одну функцию, с которой вы уже знакомы, и отследите все ее действия в обратном порядке, начиная с конца

Для наглядности возьмем пример. Вы знаете, что код, который вы сейчас читаете, в итоге создает файл с перечнем названий фильмов. Найдите, где в коде находятся строки, которые генерируют этот файл. Если нашли, сделайте шаг назад и определите, как код помещает информацию в файл. После этого сделайте еще шаг назад и найдите, откуда берется эта информация. И так далее. Назовем все эти кусочки «цепочкой действий». Используя этот метод, вы сможете ознакомиться с разными элементами кода, что позволит вам хорошо разобраться в таких вещах, как:
  1. Структура кода (куда вставлены переменные, где расположены разные методы и т.д.).
  2. Стиль написания кода, которого придерживался автор.
  3. Образ мышления создателя кода и его подход к решению проблем (да, это уже сложнее, но с опытом подобные вещи начинаешь понимать интуитивно).
  4. В процессе регулярного чтения от конца кода к его началу вы будете постепенно улучшать понимание кода в целом.

2. «Промыть и повторить»

Повторите весь процесс несколько раз. Это поможет вам лучше запоминать всё большее количество элементов структуры кода. Представьте, что вы освещаете фонариком темную комнату. Именно так, постепенно, вам будут открываться ранее неизвестные части кода. В конце концов, вы запомните, где и что именно находится в этой комнате. Смысл метода основан на том, что код всегда создается для решения какой-то одной (или не одной) сложной задачи. Поэтому регулярное прохождение «цепочки действий» вам обеспечено. Чем быстрее вы поймете, как связаны между собой разные части кода, тем лучше вы будете понимать его структуру в целом. Соответственно, тем легче вам будет даваться чтение чужого кода.

Ошибки, которых можно избежать при создании профиля на GitHub

Источник: Dev.to При создании профиля на GitHub новички часто совершают ошибки, которых можно было бы легко избежать. Если вы хотите, чтобы ваш профиль на GitHub произвел хорошее впечатление на работодателя, придется учесть несколько важных деталей.

Ошибка №1. Включение в профиль GitHub всех написанных вами приложений

Очень часто разработчики необдуманно включают в свой профиль все созданные ими приложения, полагая, что чем больше – тем лучше. В реальности это имеет обратный эффект. Кандидат может произвести впечатление ненадежного и не имеющего специализации. Поэтому приложения для своего GitHub-профиля нужно тщательно отбирать согласно следующим принципам: Кофе-брейк #7: Как быстро научиться читать чужой код. Ошибки при создании профиля на GitHub - 2Приложения должны демонстрировать ваш рост как разработчика. Можно включить две итерации одного приложения: в первой будет код, написанный в начале вашей карьеры программиста, а второй код будет содержать все улучшения и проведенный рефакторинг. Также в README улучшенной версии напишите, какие изменения вы внесли и почему. Покажите результаты преодоления трудностей, с которыми вы столкнулись во время обучения. Включите в профиль приложения, которые вам было трудно создавать, и опишите в README сложности, которые удалось преодолеть. Продемонстрируйте способность объединить несколько функций и заставить их работать вместе. Начинающие разработчики иногда допускают ошибку, показывая приложения, которые имеют только одну основную функцию. Я рекомендую включить в GitHub-профиль приложения, которые реализуют несколько функций. Разумеется, все они должны работать без сбоев. Приложения должны демонстрировать ваш интерес к разработке. Если созданное вами приложение сочетается с вашими увлечениями и характером – не стесняйтесь его показать.

Ошибка №2. Полупустые README-файлы

Когда кто-то заходит в ваш GitHub-репозиторий, он видит название проекта и столбец папок. Как правило, большинство прокручивают страницу вниз до раздела README. И если они там найдут пустой файл или дефолтный README-текст от GitHub, тогда все эти люди могут никогда и не узнать, какой потрясающий код скрывался в ваших папках. А все потому, что ваш README-файл произвел негативное впечатление. README-файл должен рассказать историю, которая поразит кадровика/работодателя и заставит пригласить вас на личное интервью. Поэтому README-файл на GitHub должен содержать следующие пункты:
  1. Причины создания приложения.
  2. Список функций приложения.
  3. Возникшие в процессе написания кода проблемы и способ их решения.
  4. Инструкции по локальному развертыванию приложения.

Ошибка №3. Включение приложений, не развернутых онлайн

В большинстве случаев работодатель не будет развертывать ваше приложение локально. Но некоторые из них все же могут протестировать вашу программу и ее функционал на предмет наличия багов. Если ваше приложение нельзя развернуть, вы упускаете отличную возможность продемонстрировать свои великолепные навыки программиста. И даже ваше приложение касается бэкенда, это не проблема! Реализуйте самый минимальный фронтенд, разверните приложение и поясните в README, что в этом приложении вы сфокусировались исключительно на бэкенде, а его фронтенд не предназначен для демонстрации ваших навыков и служит лишь для доступа к функционалу бэкенда.

Нужно ли указывать в профиле незаконченные или заброшенные приложения?

Да, но с обязательной пометкой «In Progress». Это даст вам возможность показать, над какими приложениями вы работаете, с поправками на их незавершенность.

Итоги

Выбор приложений для GitHub-профиля должен отражать историю вашего развития, показывать навыки, которые вы хотели бы продемонстрировать. Ваша цель – убедить работодателя, что вы являетесь ценным приобретением для его команды. Поэтому выбирайте те приложения, которые способны доказать вашу способность самостоятельно и эффективно решать технические задачи разного уровня сложности.
Комментарии (2)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
ディマ_オゾリン Уровень 33, Киев, Украина
23 января 2020
1) быстро научиться читать чужой код...можно не быстро, тут хотя бы просто научится читать чужой код... ...отслеживать по одной функции/переменной, как-то не очень... часто только ещё больше запутываюсь, когда этот объект в проекте швыряет от класса к классу, что-то ему передаёт, что-то у него забирает... зачем... почему... ...изучая чужой проект, понимаешь насколько хорошо, когда его максимально дроблят, делая слабое связывание между классами. Так чтобы разные части кода были максимально автономные. Тогда и какую-то часть можно взять, понять и легко реализовать в другом месте. Когда подается чужой код, где всё слеплено в кучу, то иногда пытаюсь по-отделять то что можно куда-то в отдельные классы... распутать клубок так сказать... ...ещё я слышал что UML-схемы это круто... но что-то я не могу их прочувствовать... когда классов становится овер 20 в проекте... ...UML-схема превращается в какую-то паутину... 2) GitHub, я так понимаю лучше иметь тогда два аккаунта: один портфолио для hr-ов, а другой чернетка-репозиторий-бекап для себя...
Volodymyr Shtoda Уровень 40, Украина
23 января 2020
Элли, Вы Лучшая!