Buggy Rails 코드: Rails 개발자가 저지르는 가장 일반적인 실수 10가지

Ruby on Rails("Rails")는 웹 애플리케이션 개발 프로세스를 간소화하고 간소화하기 위해 노력하는 Ruby 프로그래밍 언어를 기반으로 하는 인기 있는 오픈 소스 프레임워크입니다.

Rails는 구성보다 관례의 원칙에 따라 구축되었습니다. 간단히 말해서, 기본적으로 Rails는 전문 개발자가 "표준" 모범 사례 규칙(이름 지정, 코드 구조 등)을 따를 것이라고 가정하고, 그렇게 하면 "자동 -magically" 이러한 세부 사항을 지정할 필요가 없습니다. 이 패러다임에는 장점이 있지만 함정이 있는 것도 아닙니다. 특히 프레임워크의 배후에서 발생하는 "마법"은 때때로 가짜, 혼란 및 "도대체 무슨 일이?"로 이어질 수 있습니다. 문제의 유형. 또한 보안 및 성능과 관련하여 바람직하지 않은 결과를 초래할 수 있습니다.

따라서 Rails는 사용하기 쉬우면서도 오용하기 어렵지 않습니다. 이 튜토리얼에서는 10가지 일반적인 Rails 문제를 살펴보고 이를 방지하는 방법과 그로 인해 발생하는 문제를 살펴봅니다.

일반적인 실수 #1: 컨트롤러에 너무 많은 논리를 넣는 것

Rails는 MVC 아키텍처를 기반으로 합니다. Rails 커뮤니티에서 우리는 지금까지 뚱뚱한 모델, 마른 컨트롤러에 대해 이야기해 왔지만 제가 상속받은 최근 몇 개의 Rails 애플리케이션이 이 원칙을 위반했습니다. 뷰 로직(헬퍼에 더 잘 보관됨) 또는 도메인/모델 로직을 컨트롤러로 옮기는 것은 너무 쉽습니다.

문제는 컨트롤러 개체가 단일 책임 원칙을 위반하기 시작하여 향후 코드 기반 변경이 어렵고 오류가 발생하기 쉽다는 것입니다. 일반적으로 컨트롤러에 있어야 하는 유일한 유형의 논리는 다음과 같습니다.

• 세션 및 쿠키 처리. 여기에는 인증/권한 부여 또는 수행해야 하는 추가 쿠키 처리도 포함될 수 있습니다.
• 모델 선택. 요청에서 전달된 매개변수가 주어지면 올바른 모델 객체를 찾기 위한 논리입니다. 이상적으로는 응답을 렌더링하기 위해 나중에 사용할 인스턴스 변수를 설정하는 단일 찾기 메서드에 대한 호출이어야 합니다.
• 매개변수 관리를 요청합니다. 요청 매개변수를 수집하고 이를 유지하기 위해 적절한 모델 메서드를 호출합니다.
• 렌더링/리디렉션. 결과를 렌더링(html, xml, json 등)하거나 적절하게 리디렉션합니다.

이것이 여전히 단일 책임 원칙의 한계를 밀어붙이기는 하지만, 이것은 Rails 프레임워크가 컨트롤러에 포함하도록 요구하는 최소한의 것입니다.

일반적인 실수 #2: 보기에 너무 많은 논리를 넣는 것

즉시 사용 가능한 Rails 템플릿 엔진인 ERB는 다양한 콘텐츠가 포함된 페이지를 구축하는 좋은 방법입니다. 그러나 주의하지 않으면 관리 및 유지 관리가 어려울 수 있는 HTML과 Ruby 코드가 혼합된 큰 파일로 곧 끝날 수 있습니다. 이것은 또한 DRY(자신을 반복하지 마십시오) 원칙을 위반하는 많은 반복으로 이어질 수 있는 영역입니다.

이것은 여러 가지 방법으로 나타날 수 있습니다. 하나는 보기에서 조건부 논리를 과도하게 사용하는 것입니다. 간단한 예로 현재 로그인한 사용자를 반환하는 current_user 메서드가 있는 경우를 생각해 보십시오. 종종 보기 파일에 다음과 같은 조건부 논리 구조가 생깁니다.

 <h3> Welcome, <% if current_user %> <%= current_user.name %> <% else %> Guest <% end %> </h3>

이와 같은 것을 처리하는 더 좋은 방법은 누군가가 로그인했는지 여부에 관계없이 current_user 가 반환한 객체가 항상 설정되어 있는지 확인하고 뷰에서 사용된 메서드에 합리적인 방식으로 응답하도록 하는 것입니다(때로는 null이라고도 함 물체). 예를 들어 다음과 같이 app/controllers/application_controller 에 current_user 도우미를 정의할 수 있습니다.

 require 'ostruct' helper_method :current_user def current_user @current_user ||= User.find session[:user_id] if session[:user_id] if @current_user @current_user else OpenStruct.new(name: 'Guest') end end

그러면 이전 보기 코드 예제를 다음과 같은 간단한 코드 줄로 바꿀 수 있습니다.

 <h3>Welcome, <%= current_user.name -%></h3>

몇 가지 추가 권장되는 Rails 모범 사례:

• 보기 레이아웃과 부분을 적절하게 사용하여 페이지에서 반복되는 내용을 캡슐화하십시오.
• Draper gem과 같은 프리젠터/데코레이터를 사용하여 Ruby 객체에 뷰 구축 로직을 캡슐화합니다. 그런 다음 이 개체에 메서드를 추가하여 보기 코드에 넣었을 수도 있는 논리적 작업을 수행할 수 있습니다.

일반적인 실수 #3: 모델에 너무 많은 논리를 넣는 것

보기와 컨트롤러에서 논리를 최소화하라는 지침이 주어지면 MVC 아키텍처에서 모든 논리를 넣을 수 있는 유일한 장소는 모델에 있지 않을까요?

글쎄요.

많은 Rails 개발자는 실제로 이러한 실수를 저지르고 결국 단일 책임 원칙을 위반할 뿐만 아니라 유지 관리의 악몽이 되는 몽고 파일로 이어지는 ActiveRecord 모델 클래스의 모든 것을 고수합니다.

이메일 알림 생성, 외부 서비스에 대한 인터페이스, 다른 데이터 형식으로의 변환 등과 같은 기능은 데이터베이스에서 데이터를 찾고 유지하는 것 이상을 수행해야 하는 ActiveRecord 모델의 핵심 책임과 별로 관련이 없습니다.

따라서 논리가 보기에 들어가지 않아야 하고 컨트롤러에도 들어가지 않아야 하고 모델에도 들어가지 않아야 한다면 어디로 가야 할까요?

PORO(Plain Old Ruby Objects)를 입력합니다. Rails와 같은 포괄적인 프레임워크를 사용하는 새로운 개발자는 프레임워크 외부에서 자체 클래스를 만드는 것을 꺼리는 경우가 많습니다. 그러나 논리를 모델에서 PORO로 옮기는 것은 종종 의사가 지나치게 복잡한 모델을 피하기 위해 지시한 것입니다. PORO를 사용하면 이메일 알림 또는 API 상호 작용과 같은 것을 ActiveRecord 모델에 고정하지 않고 자체 클래스로 캡슐화할 수 있습니다.

따라서 이를 염두에 두고 일반적으로 모델에 남아 있어야 하는 유일한 논리는 다음과 같습니다.

• ActiveRecord 구성 (즉, 관계 및 유효성 검사)
• 소수의 속성 업데이트를 캡슐화하고 데이터베이스에 저장하는 간단한 변형 방법
• 내부 모델 정보를 숨기기 위한 액세스 래퍼 (예: 데이터베이스의 first_name 및 last_name 필드를 결합하는 full_name 메소드)
• 정교한 쿼리 (즉, 단순한 find 보다 더 복잡함); 일반적으로 모델 클래스 외부에서 where 메서드 또는 이와 유사한 다른 쿼리 작성 메서드를 사용해서는 안 됩니다.

일반적인 실수 #4: 일반 도우미 클래스를 덤핑 장소로 사용

이 실수는 위의 3번 실수에 대한 일종의 필연적인 결과입니다. 논의된 바와 같이 Rails 프레임워크는 MVC 프레임워크의 명명된 구성요소(즉, 모델, 뷰 및 컨트롤러)에 중점을 둡니다. 이러한 각 구성 요소의 클래스에 속하는 항목의 종류에 대한 꽤 좋은 정의가 있지만 때로는 세 가지 중 어느 것에도 맞지 않는 것처럼 보이는 메서드가 필요할 수 있습니다.

Rails 생성기는 우리가 생성하는 각각의 새로운 리소스와 함께 사용할 도우미 디렉토리와 새로운 도우미 클래스를 편리하게 구축합니다. 그러나 모델, 보기 또는 컨트롤러에 공식적으로 맞지 않는 기능을 이러한 도우미 클래스에 채우는 것은 너무 유혹적입니다.

Rails는 확실히 MVC 중심적이지만, 자신만의 클래스 유형을 만들고 해당 클래스에 대한 코드를 보관할 적절한 디렉토리를 추가하는 것을 방해하는 것은 없습니다. 추가 기능이 있는 경우 함께 그룹화할 메서드에 대해 생각하고 해당 메서드를 보유하는 클래스에 대한 좋은 이름을 찾으십시오. Rails와 같은 포괄적인 프레임워크를 사용하는 것은 좋은 객체 지향 설계 모범 사례를 방치하는 변명이 아닙니다.

흔한 실수 #5: 보석을 너무 많이 사용하기

Ruby와 Rails는 개발자가 생각할 수 있는 거의 모든 기능을 집합적으로 제공하는 풍부한 보석 생태계의 지원을 받습니다. 이것은 복잡한 응용 프로그램을 빠르게 구축하는 데 유용하지만 응용 프로그램의 Gemfile 에 있는 gem의 수가 제공된 기능과 비교할 때 불균형적으로 많은 부풀려진 응용 프로그램도 많이 보았습니다.

이로 인해 여러 Rails 문제가 발생합니다. gem을 과도하게 사용하면 Rails 프로세스의 크기가 필요 이상으로 커집니다. 이로 인해 프로덕션 성능이 저하될 수 있습니다. 사용자의 불만 외에도 더 큰 서버 메모리 구성이 필요하고 운영 비용이 증가할 수 있습니다. 또한 더 큰 Rails 애플리케이션을 시작하는 데 시간이 오래 걸리므로 개발 속도가 느려지고 자동화된 테스트가 더 오래 걸립니다(일반적으로 느린 테스트는 자주 실행되지 않습니다).

애플리케이션에 가져온 각 gem은 차례로 다른 gem에 대한 종속성을 가질 수 있고 다른 gem에 대한 종속성을 가질 수 있다는 점을 명심하십시오. 따라서 다른 보석을 추가하면 복합 효과가 나타날 수 있습니다. 예를 들어 rails_admin gem을 추가하면 기본 Rails 설치보다 10% 이상 증가한 총 11개의 보석이 추가됩니다.

이 글을 쓰는 시점에서 새로운 Rails 4.1.0 설치에는 Gemfile.lock 파일에 43개의 gem이 포함되어 있습니다. 이것은 분명히 Gemfile 에 포함된 것 이상이며 소수의 표준 Rails gem이 종속성으로 가져오는 모든 gem을 나타냅니다.

각 보석을 추가할 때 추가 오버헤드가 가치가 있는지 신중하게 고려하십시오. 예를 들어 개발자는 기본적으로 모델 구조에 멋진 웹 프론트엔드를 제공하지만 실제로는 멋진 데이터베이스 탐색 도구에 불과하기 때문에 자연스럽게 rails_admin gem을 추가합니다. 애플리케이션에 추가 권한이 있는 관리자 사용자가 필요하더라도 원시 데이터베이스 액세스 권한을 부여하고 싶지 않을 수 있으며 이 gem을 추가하는 것보다 더 간소화된 자체 관리 기능을 개발하는 것이 더 나을 것입니다.

일반적인 실수 #6: 로그 파일 무시

대부분의 Rails 개발자는 개발 및 프로덕션 단계에서 사용할 수 있는 기본 로그 파일을 알고 있지만 해당 파일의 정보에 충분한 주의를 기울이지 않는 경우가 많습니다. 많은 애플리케이션이 프로덕션에서 Honeybadger 또는 New Relic과 같은 로그 모니터링 도구에 의존하지만 애플리케이션을 개발하고 테스트하는 프로세스 전반에 걸쳐 로그 파일을 주시하는 것도 중요합니다.

이 튜토리얼의 앞부분에서 언급했듯이 Rails 프레임워크는 특히 모델에서 많은 "마법"을 수행합니다. 모델에서 연관을 정의하면 매우 쉽게 관계를 끌어오고 모든 것을 보기에 사용할 수 있습니다. 모델 개체를 채우는 데 필요한 모든 SQL이 자동으로 생성됩니다. 대단해. 그러나 생성 중인 SQL이 효율적인지 어떻게 알 수 있습니까?

자주 접하게 되는 한 가지 예를 N+1 쿼리 문제라고 합니다. 문제를 잘 이해하고 있지만 실제로 발생하는 문제를 관찰할 수 있는 유일한 방법은 로그 파일에서 SQL 쿼리를 검토하는 것입니다.

예를 들어 선택한 게시물 집합에 대한 모든 댓글을 표시하는 일반적인 블로그 응용 프로그램에 다음 쿼리가 있다고 가정해 보겠습니다.

 def comments_for_top_three_posts posts = Post.limit(3) posts.flat_map do |post| post.comments.to_a end end

이 메서드를 호출하는 요청의 로그 파일을 보면 다음과 같은 내용을 볼 수 있습니다. 여기서 세 개의 게시물 개체를 가져오기 위해 단일 쿼리가 만들어진 다음 해당 개체의 각 주석을 가져오기 위해 세 번 더 쿼리가 수행됩니다.

 Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:13 -0700 Processing by PostsController#some_comments as HTML Post Load (0.4ms) SELECT "posts".* FROM "posts" LIMIT 3 Comment Load (5.6ms) ELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 1]] Comment Load (0.4ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 2]] Comment Load (1.5ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 3]] Rendered posts/some_comments.html.erb within layouts/application (12.5ms) Completed 200 OK in 581ms (Views: 225.8ms | ActiveRecord: 10.0ms)

Rails에 있는 ActiveRecord 의 즉시 로드 기능을 사용하면 로드할 모든 연결을 미리 지정할 수 있으므로 쿼리 수를 크게 줄일 수 있습니다. 이것은 빌드 중인 Arel( ActiveRecord::Relation ) 객체에서 includes (또는 preload ) 메서드를 호출하여 수행됩니다. Include 를 사용하면 ActiveRecord includes 가능한 최소 쿼리 수를 사용하여 지정된 모든 연결이 로드되도록 합니다. 예:

 def comments_for_top_three_posts posts = Post.includes(:comments).limit(3) posts.flat_map do |post| post.comments.to_a end end

위의 수정된 코드가 실행되면 로그 파일에서 모든 주석이 3개가 아닌 단일 쿼리로 수집되었음을 알 수 있습니다.

 Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:18 -0700 Processing by PostsController#some_comments as HTML Post Load (0.5ms) SELECT "posts".* FROM "posts" LIMIT 3 Comment Load (4.4ms) SELECT "comments".* FROM "comments" WHERE"comments "."post_id" IN (1, 2, 3) Rendered posts/some_comments.html.erb within layouts/application (12.2ms) Completed 200 OK in 560ms (Views: 219.3ms | ActiveRecord: 5.0ms)

훨씬 더 효율적입니다.

N+1 문제에 대한 이 솔루션은 적절한 주의를 기울이지 않을 경우 애플리케이션에 "내부"에 존재할 수 있는 일종의 비효율성에 대한 예일 뿐입니다. 여기서 요점은 응답을 빌드하는 코드의 비효율성을 확인(및 해결!)하기 위해 개발 중에 개발 및 테스트 로그 파일을 확인해야 한다는 것입니다.

로그 파일을 검토하는 것은 코드의 비효율성을 알려주고 애플리케이션이 프로덕션에 들어가기 전에 수정할 수 있는 좋은 방법입니다. 그렇지 않으면 개발 및 테스트에서 작업하는 데이터 세트가 프로덕션에서보다 훨씬 작을 가능성이 높기 때문에 시스템이 가동될 때까지 결과적인 Rails 성능 문제를 인식하지 못할 수 있습니다. 새 앱에서 작업하는 경우 프로덕션 데이터 세트도 작게 시작할 수 있으며 앱이 제대로 실행되는 것처럼 보일 수 있습니다. 그러나 프로덕션 데이터 세트가 증가함에 따라 이와 같은 Rails 문제로 인해 애플리케이션이 점점 더 느리게 실행됩니다.

로그 파일이 필요하지 않은 정보로 가득 차 있으면 정리할 수 있는 몇 가지 방법이 있습니다(개발 및 프로덕션 로그에 사용할 수 있는 기술).

일반적인 실수 #7: 자동화된 테스트의 부재

Ruby와 Rails는 기본적으로 강력한 자동화 테스트 기능을 제공합니다. 많은 Rails 개발자는 TDD 및 BDD 스타일을 사용하여 매우 정교한 테스트를 작성하고 rspec 및 cucumber와 같은 보석으로 훨씬 더 강력한 테스트 프레임워크를 사용합니다.

Rails 애플리케이션에 자동화된 테스트를 추가하는 것이 얼마나 쉬운 일인지에도 불구하고, 이전에 작성한 테스트가 전혀 없는 (또는 기껏해야 아주 적은 수의) 테스트가 없는 곳에서 내가 상속하거나 합류한 프로젝트의 수에 매우 불쾌하게 놀랐습니다. 개발팀. 테스트가 얼마나 포괄적이어야 하는지에 대해 많은 논쟁이 있지만 모든 애플리케이션에 대해 최소한 일부 자동화된 테스트가 있어야 한다는 것은 분명합니다.

일반적으로 컨트롤러의 각 작업에 대해 작성된 상위 수준 통합 테스트가 하나 이상 있어야 합니다. 미래의 어느 시점에서 다른 Rails 개발자는 코드를 확장 또는 수정하거나 Ruby 또는 Rails 버전을 업그레이드하기를 원할 가능성이 큽니다. 이 테스트 프레임워크는 애플리케이션의 기본 기능이 다음과 같은지 확인하는 명확한 방법을 제공할 것입니다. 일하고있는. 이 접근 방식의 추가 이점은 향후 개발자에게 응용 프로그램에서 제공하는 전체 기능 모음에 대한 명확한 설명을 제공한다는 것입니다.

일반적인 실수 #8: 외부 서비스 호출 차단

Rails 서비스의 타사 제공자는 일반적으로 API를 래핑하는 gem을 통해 서비스를 애플리케이션에 매우 쉽게 통합할 수 있도록 합니다. 그러나 외부 서비스가 중단되거나 매우 느리게 실행되기 시작하면 어떻게 될까요?

이러한 호출에 대한 차단을 방지하려면 요청을 정상적으로 처리하는 동안 Rails 애플리케이션에서 이러한 서비스를 직접 호출하는 대신 가능한 경우 일종의 백그라운드 작업 대기열 서비스로 이동해야 합니다. 이러한 목적으로 Rails 애플리케이션에서 사용되는 몇 가지 인기 있는 gem은 다음과 같습니다.

• 지연된 작업
• 요청
• 사이드키크

백그라운드 작업 대기열에 처리를 위임하는 것이 비현실적이거나 실행 불가능한 경우, 외부 서비스가 다운되거나 문제가 발생하는 불가피한 상황에 대해 애플리케이션에 충분한 오류 처리 및 장애 조치 규정이 있는지 확인해야 합니다. . 또한 외부 서비스 없이(아마도 네트워크에서 애플리케이션이 있는 서버를 제거하여) 애플리케이션을 테스트하여 예상치 못한 결과가 발생하지 않는지 확인해야 합니다.

일반적인 실수 #9: 기존 데이터베이스 마이그레이션과 결합하기

Rails의 데이터베이스 마이그레이션 메커니즘을 사용하면 데이터베이스 테이블과 행을 자동으로 추가 및 제거하는 명령을 생성할 수 있습니다. 이러한 마이그레이션이 포함된 파일은 순차적 방식으로 이름이 지정되므로 처음부터 파일을 재생하여 프로덕션과 동일한 스키마로 빈 데이터베이스를 가져올 수 있습니다. 따라서 이것은 애플리케이션의 데이터베이스 스키마에 대한 세부적인 변경을 관리하고 Rails 문제를 방지하는 좋은 방법입니다.

이것은 확실히 프로젝트 초기에 잘 작동하지만 시간이 지남에 따라 데이터베이스 생성 프로세스에 상당한 시간이 걸릴 수 있으며 때로는 마이그레이션이 잘못 배치되거나 순서가 잘못 삽입되거나 동일한 데이터베이스 서버를 사용하는 다른 Rails 애플리케이션에서 도입될 수 있습니다.

Rails는 데이터베이스 마이그레이션이 실행될 때 일반적으로 업데이트되는 db/schema.rb (기본값)라는 파일에 현재 스키마의 표현을 생성합니다. rake db:schema:dump 작업을 실행하여 마이그레이션이 없는 경우에도 schema.rb 파일을 생성할 수 있습니다. 일반적인 Rails 실수는 소스 저장소로의 새로운 마이그레이션을 확인하지만 그에 따라 업데이트된 schema.rb 파일은 확인하지 않는 것입니다.

마이그레이션이 손에 잡히지 않고 실행하는 데 너무 오래 걸리거나 더 이상 데이터베이스를 제대로 생성하지 못하는 경우 개발자는 이전 마이그레이션 디렉터리를 지우고 새 스키마를 덤프한 다음 계속 진행하는 것을 두려워해서는 안 됩니다. 새 개발 환경을 설정하려면 대부분의 개발자가 의존하는 rake db:migrate 대신 rake db:schema:load 가 필요합니다.

이러한 문제 중 일부는 Rails Guide에서도 논의됩니다.

일반적인 실수 #10: 민감한 정보를 소스 코드 저장소로 확인하기

Rails 프레임워크를 사용하면 다양한 유형의 공격에 영향을 받지 않는 안전한 애플리케이션을 쉽게 만들 수 있습니다. 이 중 일부는 브라우저와의 세션을 보호하기 위해 비밀 토큰을 사용하여 수행됩니다. 이 토큰이 이제 config/secrets.yml 에 저장되고 해당 파일이 프로덕션 서버의 환경 변수에서 토큰을 읽지만 이전 버전의 Rails에는 config/initializers/secret_token.rb 에 토큰이 포함되었습니다. 이 파일은 종종 실수로 나머지 애플리케이션과 함께 소스 코드 리포지토리에 체크인되며, 이런 일이 발생 하면 리포지토리에 액세스할 수 있는 모든 사람이 이제 애플리케이션의 모든 사용자를 쉽게 손상시킬 수 있습니다 .

따라서 저장소 구성 파일(예: git 사용자의 경우 .gitignore )에서 토큰이 있는 파일을 제외해야 합니다. 그런 다음 프로덕션 서버는 환경 변수 또는 dotenv gem이 제공하는 것과 같은 메커니즘에서 토큰을 선택할 수 있습니다.

튜토리얼 요약

Rails는 강력한 웹 애플리케이션을 구축하는 데 필요한 많은 못생긴 세부 사항을 숨기는 강력한 프레임워크입니다. 이렇게 하면 Rails 웹 애플리케이션 개발 속도가 훨씬 빨라지지만 개발자는 애플리케이션이 성장함에 따라 쉽게 확장 가능하고 유지 관리할 수 있도록 잠재적인 설계 및 코딩 오류에 주의를 기울여야 합니다.

개발자는 또한 애플리케이션을 느리게 만들고 덜 안정적이며 덜 안전하게 만들 수 있는 문제를 인식해야 합니다. 프레임워크를 연구하고 개발 프로세스 전반에 걸쳐 아키텍처, 디자인 및 코딩 트레이드오프를 완전히 이해하여 고품질 및 고성능 애플리케이션을 보장하는 것이 중요합니다.