Пришло время проверки кода. Некоторые из вас предпочли бы избегать процесса проверки кода. Независимо от того, являетесь ли вы новичком в программировании или опытным программистом, проверка кода - это общий учебный опыт для всех участников. Вместо того, чтобы говорить о «передовых методах процесса проверки кода», я поделюсь с вами методами кодирования, которые я использую для изменения проверки кода с WTF (Что T hat F или?) в WOW s (W onderful! O h ! Ура! ).
Мой подход к процессу проверки кода
Ожидание процесса проверки кода заставляет нас поднимать нашу игру, потому что мы открываем наш код для просмотра (критики) других программистов. Он может выглядеть, ощущаться и лаять как критика. А может быть, это так. Но, как и бой в баре, это шанс вырасти и сблизиться со своими товарищами по команде. (шутки в сторону)
У меня есть контрольный список Проверки кода, который я использую и для проверки своего кода, когда я на другой стороне как рецензент кода. Контрольный список проверки кода является основой для техник, которыми я делюсь с вами в этой статье.
Стать лучшим программистом - это непрерывный процесс. Чем больше кода вы напишете, тем лучше станете. Хорошие способы стать лучше программистом:
- Просматривайте как минимум два разных кода и стиля в неделю. Просто бегло по коду, чтобы найти шаблоны, хитрости и новые языковые функции. Погрузитесь глубже, если увидите что-то, что вас тянет.
- Присоединяйтесь к компании с опытными программистами, которые могут вас наставлять. См. №1 выше.
- Сотрудничать с другими программистами в проекте с открытым исходным кодом; См. №1 выше.
- Экспериментируйте с новыми функциями и стилями; См. №1 выше.
- Отслеживайте эволюцию новых выпусков языка и поддерживающих пакетов, библиотек и API.
Я не думаю, что сделаю вас великим программистом. (Хотя я искренне надеюсь, что вы это сделаете.) Вместо этого я сосредотачиваюсь на методах кодирования, которые я обнаружил за годы, которые помогли мне написать лучший код и стать лучшим рецензентом кода. (ИМХО!)
В своих примерах я сосредотачиваюсь на что вам нужно сделать, чтобы создать код на Python и PyCharm в наилучшем положении. в моем контрольном списке проверки кода.
Примечание. Эти методы «приготовьтесь к полезной проверке кода» обычно не зависят от IDE и языка. Большинство из них - это советы по методам, которые могут помочь вам на любом языке.
Я надеюсь показать в этой статье, что вы можете превратить боль в выгоду. Вместо этого обзор кода - это возможность поделиться новыми методами кодирования или повернуть стол против рецензентов. Я рекомендую первый курс действий.
Эти методы Проверка кода Контрольный список дополняют ранее обсуждавшуюся 21 методику кодирования; Я писал ранее. Они взяты из моего личного Контрольного списка проверки кода.
Что такое Фотонай?
Я делюсь семнадцатью методами, которые использую перед проверкой кода моих изменений в Photonai. Для некоторых из этих методов есть примеры кода Python. Я также покажу, как персонализировать Pycharm для некоторых из этих методов в ваших проектах.
В Photonai уже есть код , который сокращает количество ручного кодирования и ошибок за счет преобразования контролируемых алгоритмов до и после обучения в элементы. со своей подписью аргумента. Примерами элементов являются несколько вариантов очистителей данных, масштабаторов, импортеров, балансировщиков классов, кросс-валидаторов, настройщиков гиперпараметров и ансамблей.
Почему именно PyCharm?
Почему, мотивация для выбора вашей команды в PyCharm или любой другой IDE (Я интегрированная D среда разработки E), зависит от ваших предпочтений. знакомство и, в меньшей степени, подход, стратегия и тактика.
Примечание. Я никоим образом не пытаюсь заменить документацию JetBrain на Pycharm. Например, я сосредоточусь на небольшом подмножестве расширенной команды Pycharm . набор , который я использую для проверки кода.
Примечание. Я использую Pycharm 2020.1 Professional Edition в macOS. PyCharm опирается на свою виртуальную машину, чтобы не зависеть от платформы, оборудования и операционной системы. Это может быть иначе в Windows или Linux. В бесплатной версии не будет некоторых из показанных функций.
ПРИМЕЧАНИЕ. Все инструменты тестирования, документации и проверки кода можно использовать независимо от (без) Pycharm.
Некоторые из этих анимаций могут не отображаться в вашем приложении Medium на вашем iPhone или iPad устройстве. Android может иметь ту же проблему. Если вы перенаправите эту статью в Safari или Chrome, проблем не будет. Я подозреваю, что это связано с тегом HTML5 ‹animate› и ограничениями памяти. -автор
Создание контрольного списка проверки кода для проекта
Метод №1: Контрольный список проверки кода
- Создайте Контрольный список проверки кода для этого проекта;
Некоторые из этого контрольного списка должно быть легко составить. Он должен соответствовать схеме документа стандартов кодирования. Поскольку это ваш контрольный список, вы можете сосредоточиться на том, с чем вы боретесь, и пропустить то, с чем у вас редко, если вообще когда-либо, возникают проблемы. ссылка: smartbear.com
2. Просмотрите и обновите свой Контрольный список проверки кода при выполнении проверки кода.
Проверка кода - это возможность поучиться с обеих сторон. Ваш контрольный список должен включать ваши сильные и слабые стороны. Когда вы просматриваете код, дайте себе возможность узнать и получить момент WoW. По мере продвижения в качестве программиста вы обнаружите, что постоянно обновляете свой Контрольный список проверки кода.
# My code review checklist - Create a Code Review Checklist . . .
Метод 2: Создать проект
Создание проекта не является частью процесса проверки кода. Однако это первый шаг в жизненном цикле кода вашего проекта - проект, в котором вы применяете Контрольный список проверки кода.
На анимации показано добавление нового проекта Photonai из локального каталога в PyCharm.
PyCharm Animation
Создайте воспроизводимую среду или избегайте коварных ошибок (из) ошибки упаковки
В двух предыдущих статьях я подробно рассмотрел создание образа Docker (виртуальной среды) для вашего предприятия. Из этих статей мы извлекаем два метода Контрольный список проверки кода.
Сначала я детализирую шаблон структуры каталогов для любого проекта Python и код Docker. Мы обнаружили большую гибкость при использовании решения Docker - Составить.
Также я показал, что файл requirements.txt играет ключевую роль.
Затем я показал, как поместить расширения Jupyter IDE и Jupyter в образ Docker.
Метод № 3: создайте requirements.txt файл
###### Requirements for project: Photonai ###### numpy matplotlib progressbar2 Pillow scikit-learn keras nilearn==0.5.0 pandas nibabel six h5py xlrd plotly imblearn pymodm==0.4.1 scipy==1.2 statsmodels flask prettytable seaborn joblib dask distributed scikit-optimize scikit-image pytest photonai pixiedust pylint
Метод № 4: создание виртуальной среды
Я покажу, как настроить виртуальную среду PyCharm для использования образа Docker (улучшенного с помощью J upyter).
PyCharm Animation
Контроль версий
Метод № 5: Используйте контроль версий в локальной файловой структуре проекта.
Метод № 5: Используйте контроль версий в локальной файловой структуре проекта.
Отсутствие контроля версий - это один из двух недостатков, который немедленно останавливает любую проверку кода, в которой я участвую. Не проходите Go (буквально). Сразу же начинающему программисту показывают, как использовать Git и как успешно поместить свой проект в исходный код. Проверка кода перенесена.
Примечание. Я сразу перехожу к использованию VCS git и GitHub / GitLab с небольшими пояснениями. Если вам неудобно пользоваться основными командами GIT, воспользуйтесь ссылками на GIT в разделе ресурсов этой статьи.
Все, кого я знаю (включая меня), используют Git. Раньше я использовал другие системы контроля версий (VCS), но последние десять лет я использовал Git.
В одном месте, где я работал, было предусмотрено открытие нового местного отделения не реже одного раза в неделю, а в других - один раз в день.
Я использовал ветвление, когда начиналась разработка тестового модуля для нового файла или класса. Теперь я использую историю PyCharm и создаю новую ветку в конце рабочего дня.
PyCharm имеет local history. право щелчка в любом файле, а Pycharm подтягивает изменения файла с момента запуска Pycharm. local history - это очень легкая система контроля версий, которая спасла многих разработчиков.
PyCharm Animation
Метод № 6: разместите свой код в общем репо.
Большинство организаций (публичные проекты с открытым исходным кодом или частные предприятия) имеют репозиторий разработки и производства (репозиторий). Я заметил, что более крупные многопроектные предприятия могут иметь репозитории Alpha и Stage. Я без исключения нажимаю в облачные репозитории GitHub или GitLab.
Примечание. После того, как код разработчика прошел свои модульные тесты, он git push отправляется в репозиторий development. Код передается и может быть подвергнут проверке кода. Если в коде есть ошибки, разработчик уведомляется об ошибках и тестах, которые не прошли проверку.
Что хорошо, разработчики, коммиттеры и другие заинтересованные стороны получают обновления от действий GitHub / Gitlab.
Какие действия? Ух! Рассказ для другого раза. Думайте о действиях GitHub / Gitlab как о callbacks.. О них можно прочитать по адресу:
Думайте о действиях GitHub / Gitlab как о
Если изменения кода проходят проверку, назначенный коммиттер пытается перейти на объединить изменения. В случае возникновения конфликтов,
- коммиттер пытается разрешить;
- Любые оставшиеся конфликты определяются командой, состоящей из коммиттера и конфликтующих (извините, не смог устоять) авторов кода.
Выбор стилей для проекта
Метод no 7: выбор стиля документации для проекта
Для Python существует множество стилей документации. Numpy, Google и Pandas - одни из самых известных стилей. Ваша команда, вероятно, уже стандартизировала один. Не идите ковбоем и не используйте другой стиль. Я уверен, что вы будете подвергнуты резкой критике (и принижению) во время вашего анализа кода. Не позволяйте этому случиться с вами!
PyCharm представляет список из пяти поддерживаемых стилей. Люди, с которыми я работаю, используют стиль Numpy для строк документации, потому что он подходит для подробной документации классов, методов, функций и параметров.
PyCharm Animation
Техника № 8: Используйте шаблон документации
Вы получаете ВАУ! от меня, если вы используете генератор шаблонов строк документации IDE . PyCharm сгенерирует шаблон строки документации с ключевыми словами выбранного стиля строки документации, а также аргументами метода / функции, а также атрибутами класса, перечисленными в _self_.
PyCharm Animation
Техника №9. Добавьте подсказки типа для каждой функции и метода класса.
Подсказки типа вводить относительно недавно. Доступно только с версии Python 3.5 и более поздних версий, включающих подсказки типа (PEP 484). (два года назад?).
Если вы введете подсказки типа, вы все равно можете заработать ВАУ! от меня. Лучше поторопитесь, у меня такое чувство, что размещение подсказок по типу станет частью базового уровня необходимых практик в вашей организации.
Python - это язык с динамической типизацией. Я подчеркиваю слово подсказки, потому что подсказки типа не влияют на интерпретатор Python . Насколько вам известно, интерпретатор Python игнорирует подсказки типа.
Примечание. Строке документации больше не требуется документировать каждый аргумент и возвращаемый тип данных. Подпись становится самодокументированной.
Примечание. Повышена удобочитаемость, а также информация для инструментов проверки типов.
def __init__(self,
mongodb_connect_url: str = None,
save_output: bool = True,
plots: bool = True,
overwrite_results: bool = False,
project_folder: str = '',
user_id: str = '',
wizard_object_id: str = '',
wizard_project_name: str = ''):
Техника № 10: Используйте инструменты Python Sphinx и Sphinx-apidoc
Хорошо, использование Sphinx не зависит от языка, однако в большинстве языков есть инструментальные средства документации. Используйте это в своем коде.
Подобно модульному тестированию вашего кода, вы тестируете свои строки документации. Это оставит файлы HTML, которые я буду искать. Вы получаете пару WTFs и остановку обзора от меня, если их там нет.
Примечание. Вероятно, вы будете генерировать много ошибок и предупреждений от Sphinx. Вы приобретаете опыт, используя Sphinx, на какие предупреждения следует игнорировать. Например, Sphinx может жаловаться, когда вы используете **kwargs.
Примечание. Поместите строки документации для каждого класса, метода или функции. Вы можете сделать это однострочным. Это принесет значительную пользу любому, кто позже прочитает ваш код. Известные примеры будущих читателей:
- ты;
- любые рецензенты кода.
Контрольный список для модульного тестирования
Метод no 11: выбор среды тестирования
Вы выберете платформу тестирования, которая не зависит от языка. Однако у большинства языков есть тестовая среда. Используйте его для своих модульных тестов. Вы получаете пару WTF и отзыв от меня, если они не являются (или недостаточны) модульными тестами.
Фреймворк тестирования по умолчанию PyCharm - Unittests.. В анимации я установил тестовый фреймворк на pytest.
PyCharm Animation
Метод №12: все модульные тесты пройдены
Убедитесь, что вы запускаете свои модульные тесты, и все они проходят до проверки кода.
Примечание. pytest позволяет тестировать классы и тестовые функции.
# 1
def test_Hyperpipe_Data_XEqNone():
assert Hyperpipe.Data().X == None
# 2
def test_Hyperpipe_Data_Xarray():
test_value = np.ndarray((3,), buffer=np.array([0, 1, 2, 3]), dtype=int)
test_value = np.vstack([test_value, test_value])
assert (Hyperpipe.Data(X=test_value).X == test_value).all()
Метод # 13: сбой модульного теста и исключения
Включите модульные тесты на предмет ошибок пользователя, особенно при вызове плохой подписи. Если вы вызываете исключения, обязательно запускайте их с помощью модульных тестов.
#0
def test_Hyperpipe_pos_arg_erroe():
name = "myhype"
with pytest.raises(ValueError):
assert Hyperpipe(name).name == ""
Метод № 14: Модульные тесты охватывают всю подпись
Для каждого аргумента должен быть юнит-тест. PyCharm сгенерирует шаблон для всей подписи аргумента.
Подсказки типа позволяют выполнять поиск ошибок, обнаружение дыр в безопасности и статическую проверку типов после первого прохода кодирования и модульного тестирования.
# pyCharm generates signature unit test boilerplate for you
class test_Optimization:
def test_best_config_metric(self):
assert False
def test_best_config_metric(self):
assert False
def test_optimizer_input_str(self):
assert False
def test_optimizer_input_str(self):
assert False
def test_sanity_check_metrics(self):
assert False
def test_get_optimizer(self):
assert False
def test_get_optimum_config(self):
assert False
def test_get_optimum_config_outer_folds(self):
assert False
Техника №15: Поместите общие структуры данных на уровне проекта для модульного тестирования в общий файл (необязательно)
pytest.in разделяет функции и функции, которые возвращают объект данных при помещении в верхнюю тестовую папку. Вы создаете ВАУ! от меня, если он у вас есть. Я должен вас предупредить; другие рецензенты ставят WTF, если у вас его нет.
@pytest.fixture()
def Housing():
dataset = fetch_california_housing()
return pd.DataFrame(dataset.data, columns=dataset.feature_names)
Метод №16: отчет об охвате показывает 70% или выше
Запустите coverage перед проверкой кода. Я ожидаю, что все модульные тесты пройдут успешно. Если вы покажете мне отчет о покрытии более 70%, вы получите ВАУ! от меня.
Однако, если вы покажете отчет о покрытии более 85%, я расскажу, как вы проводите свое время. Ваш тайм-менеджмент может быть в порядке; Я просто не хочу, чтобы ты переборщил. Тем более что я думаю, что скоро будет хорошая генерация тестов на семантическом уровне. (Отличная идея проекта НЛП!) (Опять же ИМХО)
Анимация PyCharm: выполнение отдельного модульного теста с использованием pytest.
Кроме того, с помощью PyCharm вы можете запустить всю тестовую папку с помощью pytest.
PyCharm Animation:
Метод № 17: интеграционные тесты
От разработчика не требуется создавать интеграционные тесты. Если они это сделают, разработчик рискует получить один или несколько WOWS! от меня, в зависимости от того, сколько вы создали. Однако вы получите WTF, если они не пройдут.
Если разработчик является старшим и у его задания есть общедоступный API, я ожидаю одного или двух интеграционных тестов. В будущем я не удивлюсь, если ответственность за интеграционное тестирование будет переложена на разработчика. Я видел довольно много организаций, делающих это. Это довольно распространено в сообществе разработчиков ПО с открытым исходным кодом.
Ресурсы
Резюме
Это мой первый взнос по элементам из моего Контрольного списка проверки кода.
Вы можете получить более обновленный Photonai код со всеми актуальными изменениями в общедоступной репозитории GitHub. Я рекомендую ежемесячные обновления, так как Photonai - это постоянный проект.
Примечание. Если вы не можете сказать, мне нравится PyCharm. Я не пытаюсь продать вам использование PyCharm. Что мне нравится в PyCharm, так это то, что он почти полностью автоматизирует мой конвейер разработки с помощью нескольких щелчков мышью.
Если вы используете PyCharm, то, надеюсь, некоторые анимации помогут вам в настройке и использовании PyCharm.
Я пытаюсь документировать все (акцент на попытке), используя вставленный щелчком мыши PyCharm шаблон стиля Numpy.
Я пишу модульные тесты с помощью pytest. PyCharm генерирует большую часть шаблона сигнатуры для класса или функции, подлежащей модульному тестированию. Я запускаю модульные тесты индивидуально, по файлам или для всего проекта.
Я использую инструмент покрытие, чтобы сообщить о том, сколько единиц покрытия для отдельного класса, метода, функции или проекта.
В этой статье вы найдете мой основной контрольный список для проверки кода. В следующей статье я расскажу о расширенных методах проверки кода для проверки инструментов качества кода, методах повышения производительности, безопасности и средствах автоматической проверки кода.
Помните, пожалуйста, поделитесь любой из ваших техник для обзора кода, оставив комментарий или отправив мне электронное письмо. У вас может быть дополнительное улучшение техники (s0) для данной техники (ов) или вы не согласны с некоторыми из них. Пришлите, пожалуйста, любые методы кодирования, которыми вы хотели бы поделиться. Пожалуйста, также опубликуйте свое несогласие (я).
