Во время обучения программированию все сводится к тому, что вы берете откуда-то информацию, пробуете что-то сделать в соответствии с этой информацией и получаете какой-то результат. Дальше возникает вопрос — этот результат хороший или не очень. Можно судить исходя из результата: если написанный код выполняет то что нужно — значит ок, он хороший. Но это неправильный подход. Есть такие понятия, как качество кода, промышленные стандарты кода и пр.
Оценить свой код объективно действительно трудно. Вы даже можете понимать, что с ним что-то не так, но что именно не так — понять не можете. Поэтому лучший вариант обучения — обучения с ментором, который и даст обратную связь по качеству вашего кода. Поделюсь с вами чек-листом, в соответствии с которым можно проверить себя самостоятельно.
Чек-лист для проверки качества кода
Структура
Проверяется расположение пекеджей и папок, насколько понятно все построено. Откройте Git или IDE и смотрите, как по папочкам разбит код, как все сложено и пр. Если разобраться в этой структуре сложно или из названий package не сразу понятно, что там находится — это основной признак, что у вас плохой код. Если по названиям пекеджей и каталогов сразу понятно, что в них находится — код хороший. По крайней мере на данном этапе проверки.
Название классов
Они должны быть говорящими и разложенными в соответствующих пекеджах, дабы не возникало двусмысленности в трактовках — почему этот класс лежит здесь и что он делает.
Самые важные пункты — названия, т.е слова. Программирование — это про слова. Названия должны говорить сами за себя и быть понятны даже начинающему программисту. Плохо структурированный код с правильными названиями будет читаться и с ним можно работать. Хорошо структурированный код с непонятными названиями — это нечитабельный код.
Длина классов
Посмотрите на длину класса. Есть идеальная пропорция — в классе не больше десяти методов, в каждом из которых не больше десяти строчек. Т.е примерно 100 строк на класс. Конечно, это пуризм. Если у вас длинные методы igls (например, в классе 30 полей), то только одних геттеров и сеттеров будет 60. Но в любом случае, если в методе больше 10 строк — стоит задуматься, почему. Если этого нельзя избежать — ок. Но метод в 1000 строк — это однозначно плохо. Его обязательно нужно какими-то способами разносить.
Структура кода в самих методах
Структура кода должна быть осмысленной и описательной. Программист, который будет читать ваш код, должен понимать, что, собственно, вы хотели сказать. У вас не должно быть смешивания концепций. В одном методе должен быть один уровень абстракций, т.е. в одном методе говорим о бизнес-логике, во втором — про драйвер базы данных и пр.
Имена методов и переменных
Это снова про названия, то, о чем я говорил выше, не будем к этому возвращаться.
Да, список можно продолжать. Есть еще количество связей между классами, описания интерфейсов, солид-принципы и т.д. Это все действительно важно, но не для джунов. А вообще очень рекомендую посмотреть видео «Как помыть кота» или же прочитать книгу Роберта Мартина «Clean Code» (видео именно по книге). Там как раз в деталях разобрано, какой код хороший, а какой не очень.
