Оформление Github 🐱

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

1. Чистый код

Первое и самое очевидное. Обратите внимание на название переменных, методов, классов. Лучше пусть метод будет называться длинно, но понятно, чем коротко и не ясно.

Не пишите длинные методы, метод на 1000 строк – это плохо).

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

Начинать лучше всегда с классики, поэтому, конечно же, могу посоветовать Роберта «Наше всё» Мартина «Чистый код».

Про важность правильной структуры файлов / классов можно даже не говорить – это очевидно)

2. Стек

Второй важный момент. Если у Вас нет опыта работы или он минимален, то особенно важно уделить внимание актуальному стеку. Работодатель посмотрит на то, что используете и решит – «он знает только это».

Так что посмотрите требования в вакансиях и постарайтесь работать именно с этими технологиями.

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

Помните. Лучше 3 «хороших» репозиториев, чем 10 с гавнокодом)

3. Пет проект

Третий пункт. Пет проект – это всегда прекрасно. Опять-так, помните про предыдущие рекомендации.

Как придумать идею? Тут все просто.

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

Второй вариант. Подумайте о решении актуальной проблемы и, собственно, решите ее)

Третий вариант. Присоединиться у уже готовому проекту.

Только помните, что не нужно замахиваться сразу на огромный проект и ставить себе цель создание аналога гугла. Делайте MVP (минимально-жизнеспособный продукт). Идите от простого к сложному. Если говорить совсем просто, то нужно сделать с начала самый – самый минимум и потом идти маленькими шажками постепенно улучшая его. Только так.

‌

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

Подводя итог этого пункта рекомендаций. Хороший большой проект на гитхабе – это просто замечательно. Но есть важный момент, он у нас будет идти под номером четыре.

4. Документация

Четвертый пункт. У Вас есть большой проект. В нем все идеально. Если бы его увидел Стивен Возняк, то расплакался от умиления и назвал бы Вас братом, а еще поделился бы акциями Apple на пару десятков миллионов. Только есть одно «но». Не понятно, что код, собственно, делает.

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

Ух, про это можно говорить очень долго, но обозначим некоторые моменты.

Первое. Readme. Напишите, что делает приложение, какие решения используются. Опять-таки постарайтесь разбить Ваше повествование на логические части. Помните, что читать полотно сложно и нудно. Ну и, конечно, краткость сестра таланта.

‌

Второе. Вам нужны комментарии в самом тексте кода. Это очень важно. Если говорить про API и DTO, то тут, конечно, Swagger must have.

Открывая Ваш класс в идеале должно быть понятно, что именно он делает не только по его названию (это безусловно, важно), но и по комментарию. Никто долго копаться в коде пет-проекта не будет. Вам нужно максимально облегчить задачу понимая, ведь, это в Ваших же интересах.

Заключение

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