Гайд на тестовое задание

Перед вами список критериев, выполнение которых поможет вам написать и оформить качественное тестовое задание, а также выгодно отличит его от заданий конкурентов:

0 Убедитесь, что вы поняли, что от вас хотят видеть.

Как говорится: "понимание проблемы - это уже половина решения". Если у вас есть любые вопросы по заданию - не стесняйтесь, пишите hr'у и уточняйте все, что нужно. Спросите нейронку, что от вас требуется в задании и соотнесите это со своим пониманием. Если что-то не сходится - формулируйте вопросы и задайте их hr'у.

Без полного понимания задания вы можете потратить значительное время и в итоге получите фидбэк: "мы вас просили погладить котика, а вы его побрили налысо".

1 Самое важное - это стопроцентное следование заданию.

Требования в задании могут быть разные, но их объединяют 2 большие группы. Функциональные и/или нефункциональные. То есть "что должен делать код?" и "как он это должен делать?". Обратите особое внимание на нефункциональнальные требования, потому что они определяют качество кода, что намного важнее того, что код делает(а делает он обычно всякую фигню велосипедную).

В тексте задания по сути дано пошаговое руководство о том, что проверяющий хочет видеть в вашем решении. Так вот нужно добиться того, что КАЖДЫЙ пункт задания был отражен в коде. 

А то бывает, что присылают задание, а там не до конца функциональность даже реализована. И свое время зря потратили, и время проверяющего.

И да. Если вас просят что-то не делать - не делайте этого. 

2 Функциональная корректность решения.

Вот вы написали код и отправили его на проверку. Как проверяющему понять, что он вообще работает? Только с помощью тестов.

На ваш код обязательно должны быть написаны unit тесты, желательно с использованием фреймворка gtests. Если не знаете, что это, то почитайте и узнайте, ничего сложного нет. Тесты должны проверять не только корректные сценарии использования, но и некорректные. 

Если есть нефункциональные требования по производительности, то нужно писать перформанс или нагрузочные тесты на производительность. Возможно здесь будет уместно использовать фреймворк google benchmark.

Можно дипсик попросить накидать тесткейсов, этот пункт почти весь решается с помощью нейронок.

Без этого я бы вообще не принимал тестовые. Если вы декларируете, что сделали задание и предоставили рабочий код, соответствующий требованиям, то будьте добры это подтвердить.

Это были самые важные и базовые пункты. Без этого никуда. Дальше будут идти критерии, выполнив которые вы будете очень выгодно смотреться на фоне других кандидатов.

3 Самое важное в корректно работающем коде - это его архитектура и понятные названия сущностей.

SOLID, DRY, KISS - вот ваши программистские друзья навеки. Обязательно их изучите и применяйте эти подходы в своем коде.

Если коротко:

- Выделены отдельные сущности, которые отвечают за одну активность. Сложные куски кода тоже выделяются в отдельные функции, чтобы в месте их вызова можно было в общем понять, что там происходит. Используйте разбиение по файлам.

- Чтобы понимать, что происходит в коде, для всего нужны хорошие говорящие названия. Было дело в молодости, я называл переменные `x`, `xx`, `xxx` и тд. Вот так не нужно, это ошибки молодости. Должно быть понятно, для чего предназначен класс, что конкретно делает функция и какой объект хранит переменная.

- Отсутствует повторение кода. Даже в тестах.

По итогу ваш код должен настолько легко читаться, чтобы Снежана Глубокославовна, ваш учитель английского, поняла, что там происходит. Основные детали решения должны быть похожи на текст на английском.

По-классике можно попросить нейронку поревьюить ваш код и с ее помощью исправить мажорные недостатки.

4 Современные практики С++. 

• По-максимуму используйте умные указатели для безопасности.
• Используйте стандартные RAII обертки.
• Используйте мув-семантику для избежания лишних копий.
• Подбирайте правильные контейнеры, подходящие вашей конкретной задаче.
• Определяйте пространства имен для синтаксического разделения имен сущностей.
• Добавьте обработку ошибок. Базово хватит исключений, но возможно стоит прибегнуть к std::optional, std::expected(но это скорее для более опытных).
• Добавьте валидацию входных данных.
• Если пишите библиотеку, то используйте sfinae или концепты. Но это для более продвинутых перцев.

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

В ином случае лучше использовать обычные подходы, чтобы не показаться чуваком, который выпендривается и использует новые фичи лишь для галочки.

4 Cборка и запуск проекта

Плюсы - это вам не питон, просто "c++ main.cpp" сделать не получится. Особенно, если проект использует какое-то библиотеки.

Поэтому рядом с проектом обязательно должен идти CMakeLists.txt, чтобы иметь возможность более менее общепринятым способом собирать проект.

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

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

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

Даже если просят завернуть в какой-нибудь архив, то сделайте как говорят, заверните в архив требуемого формата и рядышком прикрепите ссылку на гитхаб. Лишним не будет.

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

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

Желаю всем писать как можно меньше неоплачиваемых тестовых. А если уже пишите, то делайте это качественно.