팩워크 에피소드 II를 통한 Ruby on Rails 모듈화

니콜라스 니소리아

Packwerk와 함께하는 Ruby on Rails 모듈화의 두 번째 에피소드에서는 패키지로서의 애플리케이션 개념을 자세히 살펴봅니다.

패키지 애플리케이션

애플리케이션을 모듈화하는 접근 방식은 전체 애플리케이션을 패키지로 변환하는 것으로 구성됩니다.

구조 만들기

먼저, 다음을 만들어야 합니다. 앱/패키지 폴더에 모든 패키지를 저장합니다. 패키지를 분리하려면 모든 패키지를 분리해야 합니다. MVC 개념 를 하나의 폴더에 저장합니다. 폴더를 코드트리지 프로젝트 를 예로 들면 다음 그림과 같습니다.

서버를 실행하려고 하면 상수를 찾지 못합니다. 그렇기 때문에 설정 한 줄을 추가해야 합니다. application.rb

config.paths.add 'app/packages', glob: '*/{*,*/concerns}', eager_load:true

이제 애플리케이션은 작동하지만 뷰를 찾을 수 없으므로 구성에 다른 줄을 추가해야 합니다. application_controller.rb

append_view_path(Dir.glob(Rails.root.join('app/packages/*/views')))

패키지 만들기

구조가 준비되었으므로 이제 패키지 생성을 시작할 수 있습니다. 이를 위해서는 패키지를 생성하기 위해package.yml 를 다음 구성으로 모든 폴더에 추가합니다:

enforce_privacy: false
enforce_dependencies: true

enforce_privacy를 사용하면 패키지의 모든 상수를 분리하고 공용 API로 작업할 수 있습니다. 공개 상수를 노출하려면 예를 들어 다음과 같이 상수를 추가해야 합니다. 패키지/사용자/앱/공개.지금은 이 구성을 다음과 같이 설정하겠습니다. false.

enforce_dependencies 는 패키지의 종속성을 적용하고 모든 상수 참조를 확인합니다. 종속성이 명시적으로 정의되지 않은 경우 경계를 위반한 것입니다.

패키지 시스템 검증

Packwerk 는 유효한 패키지 시스템을 갖추기 위해 따라야 할 기준을 확립했습니다. 이제 실행을 시작할 수 있습니다. 팩워크 검증 를 클릭합니다.

이렇게 하면 폴더 구조를 확인할 수 있습니다, 패키지 구성및 자동 로드 경로 캐시.

지금은 애플리케이션이 유효하지 않으며 로드 경로를packwerk.yml. 이렇게 하려면 누락된 경로를 추가하기만 하면 됩니다.

# packwerk.yml

load_paths:
.
.
.

# 사용자
- 앱/패키지/사용자/컨트롤러
- 앱/패키지/사용자/모델
- 앱/패키지/사용자/패키지.yml
- 앱/패키지/사용자/뷰

이제 애플리케이션에서 경계 위반을 확인할 준비가 되었습니다. 위반 사항을 확인하려면 다음을 실행하면 됩니다.팩워크 업데이트-기능 저하 이 명령은 다음을 생성합니다. deprecated_references.yml 파일을 검색합니다. 모든 파일에서 패키지 이름, 위반 유형, 파일 경로를 확인할 수 있습니다. 이 모든 정보를 통해 위반이 어디서 발생하는지 파악하고 위반 해결을 위한 결정을 내릴 수 있습니다.

# deprecated_references.yml

.
.
.

앱/패키지/리포지:
  "::Repo":
    위반:
    - 의존성
    파일
    - 앱/패키지/사용자/모델/사용자.rb

생성된 정보의 모든 부분을 예로 들어 설명하겠습니다.
by Packwerk.

– 앱/패키지/리포지토리 - 상수 위반이 있는 패키지
발견되었습니다.

– ::Repo - 위반된 상수가 포함된 파일의 경로를 입력합니다.

– 종속성 - 종속성 또는 개인정보 보호와 같은 위반 유형입니다.

– 앱/패키지/사용자/모델/사용자.rb - 위반된 상수가 포함된 파일의 경로를 입력합니다.

이 섹션의 마지막 단계로, 새로 생성된 파일 경로를 다음 주소에 추가하는 것을 잊지 마세요. packwerk.ym를 클릭하고 유효성 검사를 다시 실행합니다.

종속성 시각화

package.yml의 모든 정보 및 deprecated_references.yml그러면 다음을 수행할 수 있습니다.
종속성 그래프를 시각화할 수 있습니다. 이를 위해 다른 젬을 추가해야 하는데, 이 경우 다음을 사용합니다. Pocky.

러닝 레이크 pocky:생성 라는 파일을 생성합니다. packwerk.png 에서 첫 번째 종속성 그래프를 시각화할 수 있습니다.

모든 패키지가 정의되면 그래프는 다음과 같이 표시됩니다.

종속성이 이미 존재한다고 해서 Packwerk. To
종속성을 수락하려면 종속성 구성을 추가해야 합니다. package.yml
모든 패키지에 포함되어 있습니다. 다음 사항에 집중할 것입니다. 메일 빌더 순환 종속성이 없는 패키지이기 때문입니다. 한 가지 언급할 가치가 있는 것은 Packwerk 순환 종속성을 허용하지 않습니다.

# 앱/패키지/메일_빌더/패키지.yml

```ruby
enforce_privacy: false
enforce_dependencies: true
의존성
- app/packages/docs
- 앱/패키지/이슈
- 앱/패키지/리포지토리

이 구성을 추가한 후 Pocky 는 허용된 종속성을 녹색으로 표시합니다.

삭제할 수 있습니다. deprecated_references.yml 에서 앱/패키지/메일 빌더 를 클릭하고
팩워크 업데이트-기능 저하 를 다시 클릭합니다. 파일은 다시 생성되지 않습니다.
위반이 이 패키지에 대해 수정되었습니다. 허용된 종속성을 사용하여 그래프를 작성하지 않더라도 다음과 같이 언급하는 것이 중요합니다.

Ruby on Rails 모듈화를 통한 Packwerk의 모듈화 종속성을 허용하면 애플리케이션은 이전처럼 계속 작동하지만 이제 더 많은 기능이 있습니다.
결정을 내리고 리팩터링하는 데 필요한 정보를 제공합니다.

순환 종속성 제거

이전 그래프에서는 어떻게든 해결해야 하는 순환 종속성이 많이 있었습니다. 이를 해결하기 위한 다양한 전략이 있습니다:

- 아무것도 하지 않습니다,

- 종속성 수락, 패키지 병합,

- 이동 코드 패키지와 패키지 사이,

- 기능을 복제합니다,

- 종속성 주입 또는 입력으로 종속성 주입을 수행합니다.

여기서 한 가지 문제는 제대로 된 리팩터링을 하려면 코드베이스를 알아야 한다는 것입니다. 저는 이 프로젝트를 예로 들었기 때문에 코드베이스에 대해 잘 알지 못하므로 현실적인 이유로 첫 번째 전략인 아무것도 하지 않는 방법을 사용하겠습니다. 대부분의 리팩터링을 피하더라도 프로젝트의 root 패키지입니다.

루트 패키지에는 다음과 같은 모든 접착제가 포함되어 있습니다. 레일즈 프레임워크에서 상속하고 모든 클래스가 함께 작동하도록 만들었습니다. 따라서 순환 종속성을 해결하기 위해 다음 단계에서 레일스라는 새 패키지를 만들 것입니다:

앱의 모든 application_ 파일 및 폴더를 다음 위치로 이동합니다. 앱/패키지/레일.
만들기package.yml 를 사용하여 이전 패키지와 동일한 구성의 패키지를 만들 수 있습니다.
새 파일 경로를 모두 다음 주소에 추가합니다. packwerk.yml.
추가 앱/패키지/레일 를 나머지 패키지의 종속성으로 추가합니다.

패키지를 생성하면 재구조화할 수 있는 파일이 많이 눈에 띄기 시작합니다. 모든 파일을 해당 패키지로 이동한 후
종속성을 제거하면 새로운 구조와 깔끔한 그래프를 갖게 됩니다.

루트 패키지에서 종속성 제거

이제 루트 패키지에서 모든 종속성을 제거할 수 있다면 그래프가 훨씬 더 좋아 보일 것입니다. 루트 패키지에서 deprecated_references.yml을 확인하면 대부분의 종속 요소가 테스트 , 라이브러리/작업 , db 그리고 구성
폴더로 이동합니다. 이러한 종속성을 해결하기 위해 모든 패키지 내에 테스트 폴더를 만들려고 합니다. 다음과 같은 앱/패키지/사용자/테스트. 다음으로, 다음을 제외하겠습니다. 라이브러리/작업 , db 그리고 구성의 다른 폴더 중에서 Packwerk 분석에서 이러한 종속성은 실제로 중요하지 않고 쉽게 해결할 수 있는 방법이 없기 때문입니다. 다음 내용을 packwerk.yml.

제외합니다:
- "{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}/**/*"
- "lib/tasks/**/*.rake"

루트 패키지에서 모든 테스트를 이동하고 분석에서 폴더를 제외하면 루트 종속성이 없는 새 그래프가 나타납니다.

보시다시피, 여전히 다음과 같은 순환 종속성이 있습니다.사용자 , repos 및 문서 . 비록 해결하지는 못했지만 지금 전달해야 할 중요한 정보가 있습니다. 저희는 모든 팀 패키지 중 하나에서 변경을 수행하는 팀은 순환 종속성이 있는 패키지에서도 변경을 수행해야 할 것입니다. 반면에 팀에서 다음과 같은 작업을 수행할 수 있습니다. github_fetchers 패키지가 무엇인지 아는 것만으로
매 순간 변화의 영향을 받습니다.

프로젝트의 최종 결과물을 확인할 수 있습니다. 여기.

다음 단계

다음 단계로 모든 패키지에 지속적인 개인정보 보호를 적용하고 다른 패키지에서 액세스할 수 있는 공개 API만 노출할 수 있습니다. API를 어디에 배치할지 쉽게 구성할 수 있습니다. package.yml.

enforce_privacy: true
enforce_dependencies: true
public_path: my/custom/path/

결론

Packwerk 는 애플리케이션에 대한 많은 정보를 제공하며, 이러한 정보를 바탕으로 팀의 워크플로우를 개선하기 위한 결정을 내릴 수 있습니다. 프로세스가 길고 구성이 많은 것처럼 보였지만 항상 그럴 필요는 없습니다. 애플리케이션에 추가된 새 코드에 대해서만 패키지를 만든 다음 점진적으로 모듈화할 수 있습니다. 이제 점진적 모듈화에 대해 이야기할 수 있는데, 이것이 바로 Stephan Hagemann이 소개한 개념입니다. "처음으로 열망적인 방식으로 코드의 일부를 모듈화하기로 결정할 수 있습니다... 이를 통해 더 나은 애플리케이션 구조를 향해 점진적으로 확장되는 지원 시스템을 만들 수 있습니다."