더 나은 파이썬(Python) 프로젝트 설정을 위한 5가지 도구 및 기술

더 나은 파이썬(Python) 프로젝트 설정을 위한 5가지 도구 및 기술

 

잘 설계된 Python 프로젝트를 만들어 봅시다.

Unsplash에 있는 Octavian Dan의 사진

때로는 애플리케이션에 새로운 기능을 추가할 때 기존 코드에 영향을 미치거나 기능이 중단될 수 있습니다.

이러한 상황을 피하기 위해 우리는 우리가 추가한 새로운 기능이 애플리케이션에 해롭지 않은지 확인하기 위해 단위 테스트를 작성하고 매번 실행합니다.

따라서 테스트에 관해서는 Pytest 및 tox와 같이 더 나은 테스트를 작성하고 쉽게 실행할 수 있는 라이브러리와 프레임워크가 있습니다.

Pytest는 테스트를 실행하는 것뿐만 아니라 테스트를 실행하는 방법, 실행할 파일 등을 구성하는 데 도움을 줄 수 있습니다. Pytest에는 구성 파일 pytest.ini가 있습니다. 여기서 Pytest 버전 또는 다음과 같은 테스트 파일의 구성을 설명할 수 있습니다. 다음과 같은.

# pytet.ini
[pytest]
minversion = 6.0
addopts = -ra -q — cov=src — cov-report=html
python_files = test_*.py

또한, 그 중 하나가 Pytest와 커버리지를 통합하는 pytest-cov와 통합되어 있으며, 커버리지는 앱의 어느 부분이 테스트에 의해 커버되고 어느 부분이 그렇지 않은지에 대한 정보를 제공하여 우리를 도울 수 있으며 다양한 형식의 커버리지 보고서도 제공합니다. XML, JSON, HTML 및 테스트에 포함된 코드의 비율을 보여줍니다.

https://coverage.readthedocs.io/en/6.3.2/의 스크린샷

톡스는 제네릭 virtualenv 관리 및 테스트 명령줄 도구.
패키지가 다른 Python 버전 및 인터프리터와 함께 올바르게 설치되었는지 확인
각 환경에서 테스트 실행, 선택한 테스트 도구 구성
연속 통합 서버의 프런트엔드 역할을 하여 상용구를 크게 줄이고 CI 및 셸 기반 테스트를 병합합니다.
Tox에는 구성 파일도 있습니다.

[tox]
isolated_build = True

envlist =
py{38}

[testenv]
usedevelop = true
deps =
-r src/requirements_dev.txt

이러한 종류의 도구는 수행한 변경 사항이 이전에 수행한 기능에 영향을 미치지 않도록 하는 데 도움이 될 수 있습니다.

때때로 코드에 사용되지 않는 변수가 있거나 작성된 코드 스타일이 PEP8 규칙에 해당하지 않을 수 있습니다. 여기서 정적 코드 분석기가 우리를 도와줍니다.
다음은 구성 예제와 함께 몇 가지 정적 코드 분석기입니다.
Pylint, Flake8, MyPy.
이러한 도구는 죽은 코드, PEP-8 규칙 위반과 같은 적용 가능한 코드 없음, 코드에서 사용하지 않는 변수 등과 같은 것을 방지하는 데 도움이 될 수 있습니다.
Pylint 구성: 생성 .pylintrc 파일

[MESSAGES CONTROL]
disable=
missing-docstring,
too-few-public-methods[REPORTS]
output-format=colorized
files-output=no
reports=no
evaluation=10.0 - ((float(5 * error + warning + refactor + convention) / statement) * 10)

Flake8 구성: 생성 .flake8 파일

[flake8]
ignore = E203, E266, E501, W503, F403, F401, E402
max-line-length = 120
max-complexity = 18
select = B,C,E,F,W,T4,B9
exclude =
.git,
tests

이러한 종류의 도구는 전체 응용 프로그램에 대한 코드 스타일을 정의하는 데 도움이 되며 개발자는 이를 유지할 것입니다!

누군가가 모든 테스트와 정적 코드 분석기를 실행하지 않고 코드를 푸시하여 기존 기능에 영향을 미칠 수 있는 상황을 상상해 보십시오.
그래서 이런 상황을 피하기 위해 pre-commit이 도움이 되었습니다.
사전 커밋은 코드가 정의된 코드 스타일과 일치하도록 작성되었는지 확인하기 위해 git hook을 생성하는 프레임워크입니다.
소스 코드를 스캔하고 사전 커밋 구성 파일에서 정의할 모든 검사기를 실행합니다. .pre-commit-config.yaml

repos:
- repo: 'https://gitlab.com/pycqa/flake8'
rev: 3.8.2
hooks:
- id: flake8
name: Style Guide Enforcement (flake8)
args:
- '--max-line-length=120'
- repo: 'https://github.com/pre-commit/mirrors-mypy'
rev: v0.720
hooks:
- id: mypy
name: Optional Static Typing for Python (mypy)

이러한 종류의 도구는 git 리포지토리에서 유해한 코드를 방지하는 데 도움이 될 수 있습니다.

모든 응용 프로그램은 해킹될 수 있으며 데이터 침해 또는 소스 코드 침해, 데이터 암호화, 응용 프로그램 고장 또는 기타 유해한 위험이 있습니다.
취약점 스캔을 위한 도구가 많이 있지만 Sonarqube를 살펴보겠습니다. Sonarqube는 코드 품질 및 보안 스캐닝을 위한 강력한 오픈 소스 도구이며 이 업계를 선도하는 도구 중 하나입니다.
공식 문서에서 자세히 알아보십시오.
Docker 이미지를 사용하여 로컬 Sonarqube 서버를 설정하고 다음을 정의할 수 있습니다. sonar-project.properties

# must be unique in a given SonarQube instancesonar.projectKey=python_app_blueprint# --- optional properties ---# defaults to project key#sonar.projectName=My project# defaults to 'not provided'#sonar.projectVersion=1.0# Path is relative to the sonar-project.properties file. Defaults to .#sonar.sources=.
# Encoding of the source code. Default is default system encoding#sonar.sourceEncoding=UTF-8

SRP - 단일 책임 원칙 및 변수 명명에 대해 읽었을 것입니다. 따라서 이는 Python, Java, C# 또는 기타 언어로 프로그래밍하는 것에 관한 것일 뿐만 아니라 범용 원칙이며 폴더 생성에서도 거의 모든 곳에서 작동합니다.

따라서 응용 프로그램을 다른 폴더로 분할하고 해당 이름을 지정하고 데이터를 별도로 저장하는 것이 좋습니다.
예를 들어:

├── LICENSE
├── Makefile
├── project.toml
├── pytest.ini
├── README.md
├── setup.cfg
├── setup.py
├── sonar-project.properties
├── .ci
│ ├── some_pipeline.yaml
│ ├── scripts
├── src
│ ├── app
│ ├── requirements_dev.txt
│ └── requirements.txt
├── tests
│ ├── integration
│ │ └── __inti__.py
│ └── unit
│ └── __init__.py
└── tox.ini