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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

• Принятие решений
  • Любое техническое решение должно быть обосновано
  • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
  • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
  • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
  • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
  • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
  • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
  • Гибкость технических решений крайне желательна, а универсальность не обязательна
• Качество исходного кода
  • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
  • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
  • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
  • Писать TODO и FIXME в коде
  • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
  • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
  • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
  • Применять повторное использование своего и чужого кода
  • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
• Производительность
  • Производительность разработки кода имеет приоритет над производительностью исполнения кода
  • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
  • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
  • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

Далее дано развернутое пояснение каждому из перечисленных принципов. Для некоторых принципов в круглых скобках указанны постулаты Zen of Python, которые на мой взгляд имеют отношение к данным принципам, либо их частям.

Начать, видимо, следует с того, что речь пойдет об интерпретаторе CPython версии 2.7.x (примеры проверялись на версии 2.7.3).

На официальном сайте имеются описания инструкции import и модулей в Python:

• docs.python.org/2/reference/simple_stmts.html#import
• docs.python.org/2/tutorial/modules.html

Из них следует, что в Python имеются пакеты (package), модули (module) и имена, определенные в модулях (names). Также следует отметить, что в некоторых частях документации модули называются подмодулями (submodule), если они размещены внутри пакета.

В языке Python инструкция import позволяет импортировать пакеты, модули и имена в пространство имен, в котором инструкция import выполняется. При это существует две интересные особенности:

1. Из синтаксиса инструкции import не всегда явно следует, что именно должно быть импортированно: пакет, модуль или имя
2. Синтаксисом инструкции import невозможно явно указать, что путь к модулю является абсолютным путем (хотя явно указать, что путь является относительным можно, а также возможно изменение семантики инструкции, в части использования абсолютного пути по умолчанию, см. www.python.org/dev/peps/pep-0328 )

Из этих двух особенностей следуют такие неоднозначности для записи import abcd:

1. Импортировать ПАКЕТ abcd, либо импортировать МОДУЛЬ abcd
2. Импортировать пакет/модуль abcd из ТЕКУЩЕГО ПАКЕТА (из пакета того модуля, в котором исполняется import abcd), либо ИЗ ПАКЕТА в соответствии с перечнем каталогов, указанных в sys.path

Еще примеры неоднозначностей:

• from abcd import defg: (импортировать модуль defg из пакета abcd, либо импортировать пакет defg из пакета abcd, либо импортировать имя defg из пакета abcd, либо импортировать имя defg из модуля abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)
• import abcd.defg: (импортировать пакет defg из пакета abcd, импортировать модуль defg из пакета abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)

Для разрешения эти декларативных неоднозначностей должен существовать императивный алгоритм. Такой алгоритм в некотором виде описан в официальной документации Python.