Кава-брейк #8: Як швидко навчитися читати чужий код Помилки під час створення профілю на GitHub

Як швидко навчитися читати чужий код

Джерело: Selftaughtcoders Напевно багато хто з вас знайомий із ситуацією, коли власний код ви вже більш-менш навчабося читати, але при спробі зазирнути в чужий відразу губитеся. Для вирішення цієї проблеми є перевірена методика. Повірте, якщо в ній розібратися, вона видасться вам дуже простою.

1. Знайдіть одну функцію, з якою ви вже знайомі, і відстежте всі її дії у зворотному порядку, починаючи з кінця

Для наочності візьмемо приклад. Ви знаєте, що код, який ви зараз читаєте, у результаті створює файл із переліком назв фільмів. Знайдіть, де в коді є рядки, які генерують цей файл. Якщо знайшли, зробіть крок назад і визначте, як код містить інформацію у файл. Після цього зробіть крок назад і знайдіть, звідки береться ця інформація. І так далі. Назвемо всі ці шматочки «ланцюжком дій». Використовуючи цей метод, ви зможете ознайомитися з різними елементами коду, що дозволить вам добре розібратися в таких речах, як:

1. Структура коду (куди вставлені змінні, де розташовані різні методи тощо).
Стиль написання коду, якого дотримувався автор.
2. Спосіб мислення творця коду та його підхід до вирішення проблем (так, це вже складніше, але з досвідом подібні речі починаєш розуміти інтуїтивно).
3. У процесі регулярного читання від кінця коду до його початку ви поступово покращуватимете розуміння коду в цілому.

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

Повторіть процес кілька разів. Це допоможе вам краще запам'ятовувати дедалі більшу кількість елементів структури коду. Уявіть, що ви освітлюєте ліхтариком темну кімнату. Саме так, поступово, вам відкриватимуться раніше невідомі частини коду. Зрештою, ви запам'ятаєте, де і що саме знаходиться у цій кімнаті. Сенс методу заснований на тому, що код завжди створюється для вирішення якоїсь однієї (або не однієї) складної задачі. Тому регулярне проходження «ланцюжка дій» вам забезпечене. Чим швидше ви зрозумієте, як пов'язані між собою різні частини коду, тим краще ви розумітимете його структуру в цілому. Відповідно, тим легше вам даватиметься читання чужого коду.

Помилки, яких можна уникнути при створенні профілю GitHub

Джерело: Dev.to При створенні профілю на GitHub новачки часто роблять помилки, яких можна було б легко уникнути. Якщо ви хочете, щоб ваш профіль на GitHub справив гарне враження на роботодавця, доведеться врахувати кілька важливих деталей.

Помилка №1. Включення до GitHub всіх написаних вами додатків

Дуже часто розробники необдумано включають до свого профілю всі створені ними додатки, вважаючи, що чим більше – тим краще. Насправді це має зворотний ефект. Кандидат може справити враження ненадійного і не має спеціалізації. Тому програми для свого GitHub-профілю потрібно ретельно відбирати відповідно до наступних принципів: Програми повинні демонструвати ваше зростання як розробника. Можна включити дві ітерації однієї програми: у першій буде код, написаний на початку вашої кар'єри програміста, а другий код міститиме всі покращення та проведений рефакторинг. Також у README покращеної версії напишіть, які зміни ви внесли та чому. Покажіть результати подолання труднощів, з якими ви зіткнулися під час навчання.Увімкніть у профіль програми, які вам було важко створювати, та опишіть у README труднощі, які вдалося подолати. Продемонструйте здатність об'єднати кілька функцій та змусити їх працювати разом. Розробники-початківці іноді припускаються помилки, показуючи додатки, які мають тільки одну основну функцію. Я рекомендую включити до GitHub-профілю програми, які реалізують кілька функцій. Зрозуміло, всі вони мають працювати без збоїв. Програми повинні демонструвати ваш інтерес до розробки. Якщо створений вами додаток поєднується з вашими захопленнями та характером – не соромтеся його показати.

Помилка №2. Напівпорожні README-файли

Коли хтось заходить у ваш GitHub-репозиторій, він бачить назву проекту та стовпець папок. Як правило, більшість прокручують сторінку вниз до розділу README. І якщо вони там знайдуть порожній файл або дефолтний README-текст від GitHub, всі ці люди можуть ніколи і не дізнатися, який приголомшливий код ховався у ваших папках. А все тому, що ваш README файл справив негативне враження. README-файл має розповісти історію, яка вразить кадровика/роботодавця та змусить вас запитити на особисте інтерв'ю. Тому README-файл на GitHub має містити такі пункти:

1. Причини створення програми.
2. Список функцій програми.
3. Виникли в процесі написання коду проблеми та спосіб їх вирішення.
4. Інструкції з локального розгортання програми.

Помилка №3. Увімкнення програм, не розгорнутих онлайн

У більшості випадків роботодавець не буде розгортати вашу програму локально. Але деякі з них все ж таки можуть протестувати вашу програму та її функціонал на предмет наявності багів. Якщо вашу програму не можна розгорнути, ви втрачаєте відмінну можливість продемонструвати свої чудові навички програміста. І навіть ваш додаток стосується бекенда, це не проблема! Реалізуйте найменший фронтенд, розгорніть додаток і поясніть у README, що в цьому додатку ви сфокусувалися виключно на бекенді, а його фронтенд не призначений для демонстрації ваших навичок і служить лише для доступу до функціонала бекенда.

Чи потрібно вказувати у профілі незакінчені або занедбані програми?

Так, але з обов'язковою позначкою In Progress. Це дасть вам можливість показати, над якими програмами ви працюєте, з поправками на їхню незавершеність.

Підсумки

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