Что нравится в коде на GitHub

Что проверяют

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

Как отвечать

Отвечайте признаками, заметными при чтении репозитория:

• границы: пакеты по смыслу, а не по слою, узкий публичный API, реализация спрятана;
• состояние: неизменяемые объекты там, где это возможно, поля final, конструктор оставляет объект валидным, а не наполовину собранным;
• исключения: свои типы для бизнес-ошибок вместо RuntimeException с текстом, нет пустых catch, понятно, кто оборачивает, а кто пробрасывает;
• тесты: читаются как спецификация, имя говорит про поведение, а не про метод, есть граничные случаи, а не только счастливый путь;
• сборка: проект собирается одной командой, зависимостей немного, версия языка объявлена явно.

В Java-проектах скажите, на что смотрите отдельно: не уехала ли логика в сущности JPA, как устроена конфигурация Spring (внедрение через конструктор вместо аннотации на поле), не создаётся ли пул потоков на каждый вызов, обрабатываются ли ошибки на границе сервиса.

Ответ сильно выигрывает от примера: назовите библиотеку, которую читали, и скажите, что именно забрали оттуда в свой код.

Где спотыкаются

Отвечают лозунгами. «Чистый код, всё по SOLID» без единого примера трактуется как заученная формула, и следом обычно просят показать, где именно нарушен принцип единственной ответственности.

Меряют качество процентом покрытия. Покрытие говорит только о том, что строки исполнялись: тест без проверок тоже даёт покрытие, а поведение при этом никто не зафиксировал.

Хвалят подробные комментарии к каждому методу. Комментарий, пересказывающий сигнатуру, расходится с кодом на первой же правке, а ценится обратное: пояснение там, где есть неочевидное ограничение.