Когда проект написан хорошо

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

• Код на Гитхабе, в форкнутом оригинальном репозитории. Ссылку на него можно найти на странице задачи, справа сбоку.

• Актуальная версия Python3 (никаких Python 2.7).

• Соблюдение PEP 8.

• Все сторонние пакеты должны быть перечислены в файле requirements.txt в корне репозитория. Это позволяет собрать зависимости в одном месте. Называть файл иначе – ошибка. Устанавливаться должны по команде pip install -r requirements.txt.

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

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

• В репозитории не должно быть лишних данных.

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

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

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

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

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

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

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

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