Рассказываем о чем следует помнить начинающим (и не очень) разработчикам выполняя тестовое задание при устройстве на работу.
Делайте решения универсальными
Часто решения пишутся строго под задачу, да еще и так, как ее понял разработчик. Это касается, например входных данных. Предположим, вы решили, что у загружаемого/обрабатываемого файла всегда есть расширение и оно всегда состоит из трех символов. Такой формат входных данных может быть логичным для тестового задания, но в работе он будет не слишком полезен, хотя бы потому, что его будет трудно повторно использовать в другой похожей задаче.
К тому же, часто, написание универсального решения не занимает больше времени, чем решение для частного случая и смотрится оно всегда более уместно.
Меньше – не значит хуже
Иногда разработчик уже в тестовом задании хочет показать насколько хорошо он разбирается в своей области и для простого задания начинает громоздить гору объектов и классов (для задания на ООП языке), тогда как более короткое решение в процедурном стиле оказалось бы куда более приемлемым. Не забывайте, краткость – сестра таланта.
Избегайте магических чисел
Как и другие неочевидные места в коде, магические числа – потенциальный источник ошибок. А для проверяющего ваше решение это еще и помеха при чтении кода. Так что, даже если вы используете всего одну-единственную константу, не поленитесь записать ее в переменную.
Не оптимизируйте раньше времени
Если вам кажется, что ваш код недостаточно лаконичен, красив и что он может работать быстрее – скорее всего вам лучше оставить все как есть. Если задача оптимизации решения явно не прописана в задании, вам лучше позаботиться в первую очередь о тех, кто будет читать ваш код. А простые конструкции и отсутствие излишних абстракций в этом случае только сыграют в вашу пользу.
Высокоуровневые инструменты – это хорошо
Здесь речь идет даже не о каких-то низкоуровневых системных API, а просто о своеместном использовании библиотек. Если вас мучает совесть за то, что вы и так пишете не на ассамблере и вам хочется показать работодателю, что вы отлично знакомы с, например, WinAPI, лучше воспользуйтесь сторонней библиотекой, а то и встроенными средствами языка.
Продумывайте имена переменных и функций
Исключите из названий переменных и функций односложные (или вообще, однобуквенные) именования, так же как и слишком длинные поясняющие заголовки. Все хорошо в меру. Давайте именам осмысленные значения – вряд ли проверяющий с ностальгией улыбнется, увидев нечто, вроде mystring.
Организуйте логирование правильно
Если вы пишите функцию, которая кроме основной работы еще и сама обрабатывает ошибки и пишет в лог, подумайте как этого можно избежать. Лучше выносить обработку ошибок на уровень выше и не засорять функции лишним кодом.
Соблюдайте единый стиль
Компания не всегда может указать какие-то требования к стилю кода на этапе тестового задания, но это совершенно не значит, что единой стилистики быть не должно. Просто, она остается на усмотрение автора решения и должна быть одинакова во всех частях решения.
Не забывайте о RAII
Если язык, на котором вы пишите код поддерживает автоматическое освобождение ресурсов, нужно этим пользоваться. К примеру, если рабочий язык C++, вместо new и delete лучше использовать умные указатели, а вместо fopen и fclose — std::fstream.
Не изобретайте велосипед
Первым в глаза проверяющему бросится именно это – игнорирование (сознательное или по незнанию) решений, которые уже существуют и которые можно было использовать повторно. Частично этот пункт и про использование библиотек в проекте – если в задании есть что-то, что можно более элегантно решить с помощью готового кода – далайте это. Вы не только сэкономите время проверяющему, но и продемонстрируете знание инструментов.
Комментарии