Кава-брейк #43. 6 помилок у програмуванні, які заважають отримати роботу мрії. Як вперше зробити свій внесок у розробку програмного забезпечення з відкритим вихідним кодом

6 помилок у програмуванні, які заважають отримати роботу мрії

Джерело: Medium Щоб знайти роботу програміста, вам необхідно мати Git-репозиторій. Це одна з перших речей, на яку звертатимуть увагу рекрутери. Щоб ваш репозиторій справив позитивне враження, у ньому мають бути проекти з нещодавно внесеними змінами. Показуйте лише ті проекти, якими ви пишаєтеся, а не кожен рядок коду, який ви коли-небудь писали. Це основи роботи із репозиторієм. Пам'ятайте, що рано чи пізно хтось обов'язково вивчить ваш код, щоб перевірити, чи підходить ви для компанії. Вам це стане вирішальним моментом. За кілька хвабон рекрутер вирішить, чи варто запрошувати вас на співбесіду. І ось тут є як добрі новини, так і погані. Погана новина полягає в тому, що проста помилка може знизити ваші шанси на роботу. Хороша новина у тому, що люди зазвичай не хочуть глибоко вивчати код. Їм потрібне загальне розуміння вашого коду та архітектури. Тож вам не обов'язково бути геніальним — вам достатньо бути добрим програмістом. Ось кілька найпоширеніших помилок, які роблять новачки. Уникайте їх, і ваші шанси на співбесіді різко зростуть.

Застарілі коментарі

У програмістів різні думки щодо коментарів. Одні їх люблять, інші ненавидять. Ми не можемо дійти єдиного висновку про те, чи варто коментувати код і в яких випадках це робити. Але всі одностайні в одному: якщо у вас є коментарі, вони мають відповідати вашому коду. Коментарі є для пояснення коду. Коли у вас складний чи незрозумілий код, читачам потрібно допомогти його зрозуміти. Також вам потрібно змінювати свій коментар при зміні коду. Якщо ви цього не зробите, ваш коментар не буде корисним. Поганий коментар набагато гірший, ніж його відсутність. Що ще гірше, коментарі виділяються у коді. Сучасні IDE виділяють коментарі іншим кольором, щоб легко читалися. Додаючи коментар, ви поміщаєте в код знак прочитай мене. Таким чином, будь-яка розбіжність між коментарем та кодом буде легко виявлена. Вибирайте коментарі обдумано та не забувайте оновлювати їх разом із кодом. Так вони будуть вам гарну службу.

Поєднання бібліотек та мов з однаковими сценаріями використання

Перед першою співбесідою мені потрібно було вирішити завдання щодо підбору персоналу. Це був простий веб-додаток, тому я написав код, пошукав відповіді на кілька складних питань у Google, і програма була готова. На співбесіді рекрутер спитав мене, чому я змішав код jQuery з простим JavaScript у всьому коді. Моя відповідь? «Емм…» По правді кажучи, я вставив кілька фрагментів коду зі Stack Overflow. Я особливо не думав про це. Код спрацював, тож я рушив далі. Ця помилка дуже поширена серед розробників-початківців. Ми настільки зосереджені на вирішенні проблем у роботі, що не приділяємо уваги тому, яким способом ми це робимо. Не ставайте одним із новачків, які потрапабо в цю пастку. Вивчіть кожний рядок коду та переконайтеся, що ви знаєте, навіщо ви його туди помістабо.

Повторення коду

Не повторюйся (Don't Repeat Yourself – DRY) – це догма програмування. Створення абстракцій для коду, що повторюється - це суть програмування. Так, спочатку може бути складно. Коли ви хочете вирішити проблему, ви робите це у будь-який можливий спосіб. Потім ви переходите до інших завдань, і код, що повторюється, залишається з вами. Позбутися подібної звички можна, створивши собі набір правил. Щоразу, коли ви допрацьовуєте функцію, прочитайте код ще раз і подумайте, чи є можливість змінити щось. Пам'ятайте, що перша версія коду зазвичай помилкова, і ви можете її поліпшити. Коли ви помітабо у себе код, що повторюється, виділіть час на його вивчення. Так ви зможете знайти найкращий спосіб, як його можна переписати (наприклад, використовуючи цикл або створивши нову функцію). Якщо ви будете робити таку чистку щоразу, то отримаєте надійніший і елегантніший код.

Необроблені помилки

Практично неможливо створити будь-який значущий додаток, який завжди працюватиме бездоганно. Незалежно від того, чи ви заповнюєте базу даних або виконуєте виклики API, виникають помилки. Необроблені помилки можуть не тільки зупинити виконання окремих функцій, але навіть призвести до збою всієї програми. Передбачення можливих помилок – ознака грамотного програміста. Щоразу, коли ви звертаєтесь до будь-яких зовнішніх даних або оновлюєте їх, вам потрібно бути готовим до найгіршого сценарію. Позначайте потенційні проблеми таким чином, щоб не робити програму громіздкою. Це дозволить читачам вашого коду (і, можливо, вам) швидко знаходити помилки. Крім того, це покаже рекрутеру, що ви вмієте створювати цілісний код.

Відсутність послідовності

Послідовність – відмінна риса якісного програмного забезпечення. Вона спрощує читання та обслуговування коду. Код, створений в єдиному стилі, більш передбачуваний, і легше оцінювати роботу програми. На вищому рівні абстракції домогтися узгодженості складно. Щоб оволодіти нею, знадобляться роки, тому розпочинати вивчення цієї методики потрібно якомога раніше. Не забувайте створювати назви, використовуючи лише одну мову. Ймовірно, це має бути англійська, але в особистих проектах ви можете називати змінні та функції будь-якою мовою, якщо це завжди та сама мова. Якщо ви послідовні, то неважливо, чи використовуєте ви табуляцію чи прогалини. Створіть або виберіть посібник із стилю і завжди дотримуйтесь його. Ви також повинні використовувати такий інструмент, як Prettier . Він дуже допомагає дотримуватись форматування коду за єдиним образом. Які б інструменти та стилі ви не використовували, застосовуйте їх постійно. Навіть якщо ви пишете поганий код у єдиному стилі, це зазвичай краще, ніж непослідовно хороший код, тому що його набагато легше виправити.

Нерозуміння інструментів

У звичайному проекті вам, напевно, доведеться використовувати якусь зовнішню бібліотеку. Багато програмістів встановлюють бібліотеки майже автоматично, оскільки вони використовуються у кожному проекті. Зовнішні бібліотеки чудові, тому що вони є перевіреним способом вирішення проблем, що повторюються. Однак розробники-початківці часто не розуміють, які бібліотеки вони використовують, і в кінцевому підсумку додають одну бібліотеку поверх іншої або заново реалізують деякі існуючі можливості. Щоразу, коли ви встановлюєте бібліотеку у свій проект, читайте чи хоча б переглядайте документацію. Перевірте методи та властивості, які ви можете використовувати, та переконайтеся, що ви розумієте, які проблеми має вирішувати бібліотека, а які вимагають використання іншого інструменту. Таким чином, ви зможете вибрати відповідні інструменти для роботи та пояснити свій вибір.

Як вперше зробити свій внесок у розробку програмного забезпечення з відкритим вихідним кодом

Джерело: Jamestucker.dev Днями я побачив твіт Евана Ю (творця Vue.js ) про новий репозиторій, над яким він працював, і мене це зацікавило. Я вирішив, що хочу зробити свій внесок у нього! Загвоздка в тому, що раніше я ніколи не брав участі в проектах з відкритим кодом і не знав, з чого почати. Але це не може бути так складно, правда? Потрапивши до репозиторію, я відразу завмер. «Що, чорт забирай, мені робити?», — подумав я про себе. Якщо я зроблю PR (пулл реквест, запит на злиття), фахівці, ймовірно, рознесуть мій код на шматки. Я завжди буду відомий у світі розробки як хлопець, котрий не вміє працювати з open source належним чином. І моя кар'єра закінчиться. На щастя, я прочитав статтю (вже не пам'ятаю де), автор якої радив, щоб ваш перший внесок у чужий репозиторій був максимально стриманим. Це може бути щось просте, наприклад, виправлення друкарської помилки. І я так і вчинив. Я прочитав документацію репозиторію, знайшов кілька друкарських помилок, відкрив PR — і про диво, Еван затвердив мої зміни. Я офіційно став співавтором Vue! Може, мені варто помістити це у свою біографію у Твіттері?

"Це чудово, але як я можу почати?"

Добре, давайте почнемо: я покажу вам кроки, які ви можете зробити, щоб зробити свій внесок.

1. Знайдіть проект

Для натхнення подумайте про свою улюблену технологію або інструмент. Скажімо, ви працюєте з JavaScript часто використовуєте Gatsby ? Подивіться їх репозиторій ! Ви також можете зробити свій внесок в один з моїх репозиторіїв. Тут є список моїх фронтенд-проектів. Якщо у вас є щось, що ви любите або вважаєте за корисне, я б хотів, щоб ви це додали! І, нарешті, Awesome First PR Opportunities – це гігантський репозиторій проектів із відкритим вихідним кодом для початківців. Є проекти 22 різними мовами!

2. Визначтеся з тим, який ви можете зробити внесок

Ознайомтеся із проектом. Прочитайте Readme. Проскануйте різні папки та файли. Отримайте уявлення про структуру кодової бази. Виконавши це, ви зможете легко знайти та виправити друкарську помилку! Як тільки ви це зробите, погляньте на розділ «Проблеми» у проекті. Там ви знайдете список раніше знайдених помилок або пропонованих функцій. На щастя, багато проектів пов'язані з проблемами, орієнтованими на новачків. Я вважаю, що ваш перший внесок має бути якомога непомітнішим, але якщо ви хочете швидко завоювати визнання, то вирішувати вам. Як тільки ви знайдете щось, що можете додати до проекту, вам потрібно буде створити його форк.

3. Створення форку проекту

Форк (розгалуження проекту) створює його точну копію у вашому власному репозиторії Github.

4. Клонуйте проект локально

Потім клонуйте проект до локальної папки за допомогою URL-адресаи проекту.

git clone <project-url>

Тут ви знайдете URL-адресау. Тепер, коли проект знаходиться на комп'ютері, відкрийте його в редакторі. Якщо ви вважаєте, що на внесення змін потрібно час, обов'язково синхронізуйте копію проекту з оригіналом, щоб ви завжди були в курсі змін. Ви можете знайти точні команди Git для цього тут .

5. Створіть нову гілку для ваших змін

Настав час внести свої зміни/виправлення! Створіть нову гілку, в якій діятимуть ваші зміни.

git branch <branch-name>

Ви можете назвати її як хочете, але на мій досвід ви зможете побачити шаблон для іменування гілок у вихідному проекті. У такому разі рекомендую слідувати існуючому шаблону. Хорошою назвою гілки для виправлення друкарської помилки було б patch/typo-fix . Ви можете перейти на цю гілку за допомогою git checkout <branch-name> . А тепер внесіть зміни!

6. Відкрийте PR (запит на злиття)

Отже, ви виправабо кричущій друкарську помилку або оновабо непрацююче посилання. Ви пишаєтесь своєю роботою. Ви хочете, щоб весь світ знав, що ви один із тих міфічних розробників, які можуть програмувати, прати та дивитися Netflix одночасно. Відправляйте свої зміни до розгалуженого репозиторію Github за допомогою git push -u origin <branch-name> . Перейдіть до свого розгалуженого репозиторію Github і відкрийте PR (запит на злиття). Примітка: якщо ви ніколи раніше не робабо пул-реквест, перегляньте це відео Кента Доддса, щоб дізнатися, як це зробити. Переконайтеся, що ваша гілка вказує на основну гілку репозиторію. Тепер ви готові додати деталі до свого PR. Переконайтеся, що ваш заголовок чітко передає зміст PR. Додайте опис: якщо ви виправляєте проблему, обов'язково вкажіть посилання на неї. Як тільки ви закінчите зі своїм описом, надішліть PR на розгляд. Той, хто має повноваження затверджувати PR, швидше за все, розгляне вашу заявку протягом декількох днів і зробить одну з наступних дій:

1. Негайно поєднає зміни.
2. Попросить внести зміни.
3. Закриє ваш PR.

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

Ви зробабо це!

Тепер ви є учасником проекту з відкритим вихідним кодом! Як це? Чи готові створити свого власного конкурента Node.js? Я сподіваюся, що, зробивши простий внесок, перспективи майбутньої роботи над open source стануть менш страшними. Щоб отримати додаткову інформацію про внесок у open source, перегляньте посібники з відкритих вихідних кодів.