Ruby on Rails의 이점은 무엇입니까? 20년의 프로그래밍 끝에 나는 Rails를 사용한다

때때로 나는 사람들이 그들의 클라이언트에 대해 불평하는 것을 듣습니다. 그들이 Rails를 사용하기를 고집 하며, 너무 많은 Kool Aid를 가지고 있다고 말합니다. 채용 담당자라면 또 다른 Ruby on Rails 'primadona' 개발자를 찾아야 한다는 사실에 속이 메스껍습니다. 그런 다음 그들은 자신의 요점을 증명하기 위해 Git과 PHP 사이의 놀랍도록 무지한 비교와 유사한 것을 꺼냅니다. “그들은 그들이 무엇을 요구하는지조차 모릅니다.”라고 그들은 말합니다.

프로그래머인 우리에게는 때때로 클라이언트가 실마리가 없는 것처럼 보일 때가 있습니다. 우리는 이와 같은 경우를 과장하는 것을 좋아합니다. 조금만 생각해보면 물건을 지을 돈을 주는 사람이 어쩐지 한계가 있고 '그냥 이해가 안 된다'고 생각하는 것은 옳지 않은 것 같다. 사실, 대부분의 고객이 자신의 옵션을 잘 알고 있지만 여전히 Rails를 사용하기로 결정한다고 믿습니다.

제 생각에는 Rails가 수많은 프로젝트와 요구 사항에 대해 진지하게 고려하기에 충분히 유익한 이유를 설명하려고 노력할 것입니다.

루비의 장점

Rails 자체가 없었다면 아무도 Ruby의 이점에 대해 알지 못할 수도 있습니다. 어떤 사람들은 "Rails라고 불리는 빛나는 갑옷을 입은 기사"가 있는 "Ruby에게는 너무 쉽고", Rails가 없으면 "Ruby는 관련이 없을 것"이라고 Ruby를 얕잡아보고 싶어합니다. 그것이 사실인지 아닌지 확실히 말할 수는 없지만, 세상이 그런 훌륭한 언어를 놓친다면 큰 부끄러움이 될 것이라는 것을 압니다. 사실은: Rails의 저자는 의도적으로 Ruby를 선택했고 그의 '야생적인' 내기는 큰 관심으로 보상을 받았습니다. 그가 그때 본 것을 오늘날에도 많은 사람들이 볼 수 있습니다. Ruby는 '세척되지 않은 대중'에게 설명하기 어려운 특별한 방식으로 프로그래머를 어떻게든 가능하게 합니다. 그렇다면 Ruby on Rails를 사용하는 이유는 무엇입니까? Ruby는 광고된 대로 프로그래머를 행복하게 만듭니다.

대부분의 개발자는 Ruby가 편리하다는 데 동의하지만 일부 개발자는 너무 많이 사용합니다. 그들은 Ruby가 허용하는 모든 자유와 오용 가능성에 대해 걱정합니다. 원숭이 패치로 설명하겠습니다.

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

정말 쉽습니다. 단 5줄의 코드로 기존 클래스를 가져와서 해당 동작을 재정의했습니다. 노팅(Nohting)은 성스러운 것입니다. 이 특정 오류는 쉽게 발견할 수 있지만 상황이 훨씬 더 심각해질 수 있습니다.

 class String def to_i self.to_f - 1.13 end end "2".to_i #=> 0.8700000000000001

그와 마찬가지로 우리는 복잡도의 계층에 따라 감쌀 수 있고 가려질 수 있는 오류를 String 클래스에 도입했습니다.

그래서, 당신은 생각할 수도 있습니다. 모든 사람과 그들의 어머니가 내 소중한 신청서를 망칠 수 있습니까? 이 동작은 실제로 무섭게 보이지만 실제로는 그렇지 않습니다. Ruby를 사용한지 5년 동안 저는 이 동작과 관련된 문제가 전혀 없었습니다. 직관에 어긋나는 것처럼 보일 수 있지만 도로 한가운데에 가는 흰색 선으로 구분된 반대 방향으로 60MPH로 자동차를 운전하는 것도 마찬가지입니다. 실제로 둘 다 매우 잘 작동합니다.

또 다른 이점은 Ruby가 다재다능한 도구라는 것입니다. 따라서 날카로운 칼날과 같은 모서리가 있습니다. 나는 어른들이 칼을 잘 다룰 수 있다고 생각하고 싶습니다. 어린이 교정은 어린이를위한 것입니다 (Tweet). 그리고 IT 분야에서 어린아이 취급을 받는 것은 Paul Graham의 Blub 역설의 희생자가 됩니다. 이해하지 못하거나 누군가가 너무 위험하다고 말한 특정 기능이 없는 것이 낫다고 생각합니다. 물론 오늘날 우리는 "Ruby on Rails를 사용하는 이유"를 묻고 있습니다. 따라서 이것은 다른 시간에 대한 토론입니다. 분명히 Ruby는 다른 언어에 있는 일부 기능을 놓치고 있습니다(Lisp hmm, hmm). 전반적으로 Ruby는 '언어 능력 연속체'의 상단에 가깝습니다.

Ruby와 함께한 처음 몇 년은 겸손했습니다. 나는 다른 사람들의 코드를 읽는 것만으로도 많은 것을 배웠다. 때때로 나는 놀랐다. 때때로 나는 화를 냈다. 그러나 결국 이 지식을 통해 이전보다 훨씬 더 효과적으로 컴퓨터와 통신할 수 있게 되었습니다. 나는 단지 당신에게 "나는 당신에게 가장 좋은 것을 하고 있을 뿐, 당신 자신을 위한 것입니다!"

프래그머티즘

가장 낮은 수준에서 Rails의 DNA에 짜여진 실용주의에 대한 깊은 존경심이 있습니다. Ruby의 이점과 함께 이 실용주의는 우아한 솔루션을 생성하고 Ruby on Rails 개발 커뮤니티가 동일한 작업을 수행하도록 장려/고취합니다. 실용주의는 종종 Rails의 텐트로 광고되기 때문에 이 주장은 새로운 것이 아니지만, 내 친구가 Hibernate가 실제로 얼마나 "멋진"지 보여주려고 했을 때 꽤 최근에 그것이 진실임을 상기했습니다. 그는 고군분투하고 있었다. 처음부터 프레임워크 기본값이 되어야 하는 수많은 옵션과 구성 매개변수를 설정할 수 없었기 때문에 그의 고통을 느낄 수 있었습니다.

나이가 들면서 인공적인 복잡성에 대한 나의 기준은 점점 더 높아졌습니다. 1989년 11세에 프로덕션 코드를 작성하기 시작했다는 점을 고려하면(Clipper Summer '87에서 이웃을 위한 프로젝트로 시작), 저는 불필요한 합병증을 거의 용납하지 않습니다. 그리고 Rails는 그 부서에서 정말 높은 점수를 받았습니다. 이것은 단순한 '구성에 대한 관례' 그 이상입니다. 저는 Rails 커뮤니티 내에서 높이 평가되고 이를 통해 스며드는 전체적인 실용주의적 사고방식에 대해 이야기하고 있습니다.

표현력

Rails는 (COBOL을 사용하지 않는 한) 영어에 가깝습니다. 내부 DSL이라고 하는 것을 사용하여 자체 의미로 Ruby를 확장합니다. DSL을 구성하는 것은 새로운 언어를 효과적으로 개발하기 때문에 항상 위험합니다. 내부적이기 때문에 외부 파서를 사용할 필요가 없지만 어떤 의미에서는 새로운 언어처럼 느껴진다. Rails 팀은 DSL과 균형을 잘 잡았습니다. 합리적인 곳에 사용하고 과도하게 사용하지 않아 탁월한 자제력을 보여주었습니다. 저는 Rails 경험에 관계없이 모든 프로그래머(그리고 심지어 일부 비 프로그래머도)가 이것을 이해할 수 있다고 생각합니다.

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

사실 Ruby에 익숙하지 않은 경우 이상하게 보일 수 있습니다. 마치 프로그래밍 언어가 아닌 것처럼 보입니다. 괄호가 없는 메서드 호출이라는 것을 알게 되면 계속 진행해도 됩니다. 그래도 Rails DSL은 요구 사항을 설명하기 위한 이 특별한 언어인 것처럼 느껴집니다. 실제로는 Ruby의 뛰어난 구문을 고유하게 사용하고 똑똑한 이름을 지정하는 것뿐입니다.

지역 사회

Rails에는 최상의 상태를 유지하는 커미터 군대가 있습니다. 많은 프로젝트가 시간이 지남에 따라 잠잠해 지지만 Rails를 사용하면 결정을 내려야 할 때 여전히 불꽃이 튀깁니다. 유지 관리자가 (여전히) 사람들이 Ruby on Rails를 사용하고 그 이점을 이해하기를 진정으로 돌보고 원하는 것처럼 느껴집니다.

Rails 자체 아래에는 가장 위에 있는 체리처럼 패키지 수 면에서 CPAN에 필적하는 강력한 패키지 관리자 RubyGems와 함께 Ruby가 있습니다. Rails는 자체 "Rails 플러그인"을 만들려고 할 때 잠시 탈선했습니다. 다행히도 이것은 고수되지 않았기 때문에 RubyGems는 매우 똑똑한 사람들이 프로그래밍한 코드를 위한 통합되고 뛰어난 소스로 남아 있습니다.

멋진 언어, 실용적인 웹 프레임워크, 훌륭한 커뮤니티 간의 시너지 효과로 Rails는 각 부분을 합친 것보다 훨씬 더 나은 결과를 얻을 수 있습니다.

성숙함

Rails는 블록 주변에 있었습니다. 어떤 면에서 힙스터는 더 이상 그렇게 멋지지 않습니다. 이것은 기술 스택을 선택할 때 좋은 점입니다. 입증된 것을 원합니다. 그리고 Rails가 바로 그것입니다. 우리는 최근에 현재 사용 가능한 다양한 Ruby 인터프리터와 런타임에 대해 이야기하는 글을 작성했습니다.

마케팅

내가 알지. IT 전문가로서 나는 '진지한' 것을 정말로 소중하게 여기고 '반짝임' 을 무시해야 합니다. 얕아 보일 수 있지만 직면합시다.

1. 경쟁에 비해 Rails 사이트는 좋아 보입니다.
2. Rails의 첫 스크린 캐스트는 당시에 그저 숨이 막힐 정도였습니다. 오늘날에는 그다지 인상적이지 않을 수도 있지만, 우리 모두가 자바에 대해 알고 있는 유일한 이유는 브라우저에서 자바 애플릿을 실행할 가능성에 대해 모두가 흥분했기 때문이라는 것을 기억하십시오. 이것은 결국 그렇게 중요하지 않은 것으로 밝혀졌지만 여전히 이것은 Java를 레이더에 넣었습니다. 마찬가지로, 이 15분 분량의 블로그 엔진 스크린캐스트는 많은 사람들을 흥분시킨 대히트였습니다.

이것은 허영심에 관한 것이 아닙니다. 그것은 방앗간에 물을 담기 위해 가능한 한 많은 똑똑한 사람들을 참여시키는 것입니다. 프레임워크를 고려할 때 가장 좋은 위치는 군중 속에 있습니다. 이 똑똑한 사람들이 집중하고 있는 프레임워크를 선택한다는 것은 단순히 더 많은 기반이 이미 여러분을 위해 다루어졌다는 것을 의미합니다. 그리고 이것은 나를 다음 요점으로 이끕니다.

(아니) 바퀴의 재발명

나는 작은 프레임워크에 대한 소프트 스폿이 있습니다. 나는 특정 프레임워크가 무엇을 하고 있고 왜 하는지 이해할 수 있을 때를 좋아합니다. 이런 의미에서 Rails는 다소 부풀려지고 때로는 압도적입니다.

딜레마: 몇 번이나 같은 것을 계속해서 쓰고 싶습니까? 그 중 일부는 더 잘 다시 작성할 수 있지만 시간이 많이 걸립니다. Rails가 더 많은 일을 하도록 허용할수록 기능을 다시 작성하거나 다시 구현하는 것에 대해 걱정할 필요가 줄어듭니다.

Rails는 (그들이 말했듯이) '배터리 포함'입니다. 희소성에 관심이 있거나 모든 것이 어떻게 작동하는지에 대한 광범위한 지식이 필요하다고 느낀다면 이것은 좋은 방법이 아닙니다. 실제로 두려움을 떨쳐 버리면 효과가 있는 것 같습니다. Rails는 당신이 필요로 하는 거의 모든 것에 대해 합리적인 기본값을 가지고 있으며 당신을 곤경에 빠뜨리지 않도록 충분히 모듈화되어 있습니다.

결론

Ruby on Rails를 사용하는 이유는 무엇입니까? Rails는 단일 페이지 JavaScript 애플리케이션과 경쟁하는 최신 공개 웹사이트와 일반적으로 약간 '못생긴'(보다 일반적이고 충실도가 낮은 UI) 복잡한 엔터프라이즈 핵심 시스템 애플리케이션 모두에 적합하지만 이를 보완합니다. 수많은 복잡한 비즈니스 규칙과 논리로 흠집을 내야 합니다. 장점은 다재다능하고 세련되고 강력한 제품과 경쟁할 수 있다는 것입니다.

대부분의 일반적인 문제에 대해 Rails는 일관되게 평균보다 높은 문서와 함께 거의 즉시 사용할 수 있는 구성 요소를 가지고 있습니다(어쨌든 Rails 핵심 팀은 문서 작성이 훌륭하다고 기여자들을 설득했습니다(우리 모두는 그것이 좋다는 것을 알고 있음에도 불구하고). 하지 않음), 잘 쓰여지고 간결하며 시간을 절약할 수 있는 문서로 이어집니다).

유니콘과 금요일 포옹을 제쳐두고 미래의 게임 체인저와 다음 중간 비즈니스 사이트 모두에 사용할 수 있는 강력한 프레임워크를 갖게 됩니다. 그리고 최고의 보석 풀과 함께 컴퓨터 프로그래밍에서 가장 기발한 아이디어를 구현하는 무기고를 손끝에 갖게 됩니다. 소란없이.