Пожаловаться

Тестовое задание: 10 советов, которые сделают решение лучше

7495
Пожаловаться

Рассказываем о чем следует помнить начинающим (и не очень) разработчикам выполняя тестовое задание при устройстве на работу.

Делайте решения универсальными

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

К тому же, часто, написание универсального решения не занимает больше времени, чем решение для частного случая и смотрится оно всегда более уместно.

Меньше – не значит хуже

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

Избегайте магических чисел

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

Не оптимизируйте раньше времени

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

Высокоуровневые инструменты – это хорошо

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

Продумывайте имена переменных и функций

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

Давайте именам осмысленные значения – вряд ли проверяющий с ностальгией улыбнется, увидев нечто, вроде mystring.

Организуйте логирование правильно

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

Соблюдайте единый стиль

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

Не забывайте о RAII

Если язык, на котором вы пишите код поддерживает автоматическое освобождение ресурсов, нужно этим пользоваться. К примеру, если рабочий язык C++, вместо new и delete лучше использовать умные указатели, а вместо fopen и fclose — std::fstream.

Не изобретайте велосипед

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

Другие статьи по теме

Каверзные вопросы и задачи по JavaScript из собеседований

Как научиться решать алгоритмические задачи?

7495

Комментарии

BUG!