Когда задача считается решенной

К задачам предъявляется следующий нехитрый набор требований:

  • Код на Гитхабе, в форкнутом оригинальном репозитории. Ссылку на него можно найти на странице задачи, справа сбоку.
  • Только Питон 3.5.
  • Соблюдение PEP 8.
  • Все сторонние пакеты должны быть перечислены в файле requirements.txt в корне репозитория. Это позволяет собрать зависимости в одном месте. Называть файл иначе – ошибка. Устанавливаться должны по команде pip install -r requirements.txt.

  • В README.md должно быть написано что, как и для чего запускать. Файл должен быть в кодировке ЮТФ-8, чтобы все могли его прочитать. Файл должен быть назван именно так, read_me.txt – ошибка. Это хорошо для единообразия и проверять проще.

  • Официальная ОС – Ubuntu 16.04. Легче всего до неё добраться, установив себе на компьютер. Например, с помощью VirtualBox. Если есть опыт работы с Linux или хочется острых ощущений – можно сразу ставить вместо/рядом с Windows.
  • В репозитории не должно быть лишних данных.

Код достаточно хорош?

Курс Devman готовит к работе над коммерческими проектами в командах из нескольких человек. В такой ситуации недостаточно писать работающий код. Важно выбирать решения эффективные с точки зрения бизнеса, с высоким ROI ― отношением полученной выгоды к затратами времени и денег. На практике это значит следующее:

  1. Задача должна быть решена быстро;
  2. Код легко поддается доработке и исправлению ошибок;
  3. Пользователю удобно, заказчик доволен.

Это универсальные критерии. Старайся им следовать во всем. С той лишь поправкой, что задачи учебные, а значит важно разобраться в теории, не скатываться к бездумной копипасте со Stack Overflow.

Не удивляйся когда проверяющий вернет задачу на доработку с такими комментариями:

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

Дело вовсе не в капризах проверяющего. Это — то, что определяет ценность программиста на проекте, его вклад в общее дело.

Напрягись и прыгни выше! Другие смогли, и ты сможешь.