Ruby on Rails dezavantajları ve uyarıları [kapalı]

Bu, RoR bashing için açılış oyunu değil - dürüst!

Ruby ve Rails çerçevesini öğreniyorum. Prima facie, oldukça serin ve PHP ile karşılaştırıldığında harika bir deneyim gibi görünüyor. (Aslında, bana C # ve .NET ile daha mutlu günleri hatırlatıyor.)

Ancak, bu konuya girerken, bu çerçeve veya dille ilgili hiçbir deneyimim yok ve merak ediyorum - başladığınızda bilinmesini istediğiniz mevcut olumsuzluklar veya şeyler nelerdir?

(Belki bu topluluk wiki yapmalı?)

Bu deneyim deneyiminden, öğrenmeye devam etmekten ve Rails'de nispeten basit bir uygulama yazmaktan kaynaklanmaktadır.

1) Öğrenme Eğrisi

Raylar aldatıcı bir şekilde basittir. Dersler, videolar ve kitapların tümü, ne kadar hızlı bir şekilde çalışırsanız (çirkin) bir uygulama elde edebileceğinizi gösterir, ancak bunlar gerçekten yüzeyi çizer. Kod üretmeye ve “iskele” ye büyük ölçüde güvenmeye meyillidirler, bu da öğrenirken iyi bir araçtır;

Hata yapma, Rails'in ustalaşması zor. Temel bilgileri geçtikten sonra (bundan sonra daha fazlası), lanse ettiğiniz son derece basit "demo uygulaması" işlevinden daha fazlasını yapmanız gerekiyorsa, baştan sona bir duvara koşacaksınız. Öğrenirken basit bir Ruby bilgisine sahip olabilirsiniz, ancak hızlı bir şekilde Ruby'yi DRYalmanız gerekir veya Rails kısıtlamalarının dışına çıkmanız gerekiyorsa yüksek ve kuru kalırsınız (ve iyi olanı değil ).

Raylar, sevgi dolu bir şekilde adlandırmayı sevdiğim gibi, sayı programlamasına göre boyamaktır . Sözleşmelere% 100 bağlı kalırsanız (yani, çizgilerin arasında kalın ve kullanmanız söylenen renkleri kullanın) hızlı ve kolay bir şekilde iyi uygulamalar yapabilirsiniz. Gerçi ve ne zaman sapmak zorunda kalırsanız, Rails en iyi arkadaşınızdan en kötü düşmanınıza gidebilir.

2) Elinizde Tüm Çekiç Olduğunda ...

Raylar basit CRUD uygulamalarını çok iyi yapar. Sorun, uygulamanızın bir veritabanından okumak / yazmaktan daha fazlasını yapması gerektiğinde ortaya çıkar. Şimdi, kayıt için kullandığım son Rails sürümü 2.3.4 idi, bu yüzden işler o zamandan beri değişmiş olabilirdi, ancak iş gereksinimleri değiştiğinde büyük bir sorunla karşılaştım, böylece uygulamanın içine küçük bir iş akışı sistemi yerleştirilmesi ve tümleştirilmesi gerekiyordu. eski bir PHP uygulaması. "Bir form, bir model" in Rails sözleşmesi, önemsiz uygulamalar ve veri girişi uygulamaları için iyi çalışır, ancak işleme mantığını yapmanız veya iş akışlarınız olduğunda veya tipik olmayan "Kullanıcı verileri girdiğinde çok fazla değil birkaç metin alanı, "Gönder" türünü gösterir. Bu olabilir yapıldığını, ancak "kolay" hiçbir şekilde var, daha doğrusu o değildi edilecek

Ayrıca, Rails, tercih ettiği veri erişimi yöntemlerini kullanmayan diğer uygulamalarla iyi oynamayı sevmez; "Web 2.0" tarzı bir API içermeyen bir uygulama ile arayüz oluşturmak zorundaysanız, bunun yerine Rails ile çalışmak zorundasınız; yine burada olanlardan bahsettiğim için başıma gelen şey bu.

3) Yeni

Son olarak, Rails hala birçok alanda "bloktaki yeni çocuk" dur. Bu kişisel kullanım için önemli değil veya “bence güzel ve öğrenmek istiyorum” türünden senaryolar değil, Rails’in bulunduğu bir yerde değilseniz, günlük işimde Rails’i kullanmayı tercih eden biri olarak konuşmak yaygın, bir Rails geliştiricisi olarak tam zamanlı iş bulmak çok zor olabilir. Hala büyük ölçüde "büyük, yeni girişimler" in etki alanıdır ve çoğu metropol bölgesinde önemli bir oyuncu değildir. Kilometreniz bu açıdan değişebilir, ancak alanımın (Tampa) Raylarının aslında bulunmadığını biliyorum.

4) Ateş ve Hareket

Raylar sürekli değişiyor. Bu hem iyi hem de kötü bir şeydir; Bu iyi çünkü topluluk yeni konseptler geliştiriyor ve benimsiyor. Kötü çünkü topluluk gelişti ve yeni konseptleri benimsedi. Bir Rails acemi için çok ezici olabilir, çünkü genellikle bir sorunla karşılaştığınızda ve etrafa baktığınızda, insanlara sorunu gidermek için böyle ve böyle değerli taşları önerdiklerini ya da bu şekilde kötü olduğunu söyleyerek görmeniz gerekir. kullanmayın, işte size daha iyi bir yol ... ve Rails cognoscenti'ye ayak uydurabilmek için Rails ile birlikte öğreneceğiniz ek araçlar listesine sahip olacaksınız. Yapılacaklar gibi Git, BDD/RSpec, Cucumber,Haml/Sassve etrafta dolaşan ve Rails ülkesinde "doğru şeyler yapmanın" doğru yolu olarak itilen ve başka şeylerden oluşan bir bereket ve Rails'e ek olarak bir düzine veya daha fazla teknolojiyi öğrenmeye çalışırken bataklığa maruz kalabilirsiniz. çünkü standart Rails araç setini kullanmak "yanlış" hissediyor.

Bu şimdi daha da Rails 3.1 ile daha da artmaktadır, bu da Sass ve CoffeeScript'i varsayılan kılar, bu nedenle toplam Rails acemi sadece Ruby ve Rails'i değil Sass (CSS'yi biliyorsanız muhtemelen basit) ve CoffeeScript'i (çılgınca zor değil, kesinlikle de) öğrenmek zorundadır. çiğ JavaScript'ten yeterince farklı) başlamak için tamamen minimumda , ayrıca Git olarak kabul edilebilir. RSpec ve arkadaşlarınızı ve tipik olarak elde edeceğiniz bir düzine veya daha fazla kıymetli faktörü olmadan bile, Rails uygulamalarını ciddiye almaya başlamadan önce öğrenmeniz gereken 4 farklı şey var. Bunu, C #, Java, hatta hatta HTML / CSS / JavaScript / SQL bilgilerinizin değişmeyeceği ve hatta dilin kendisini ve belki de çerçeve nüanslarını öğrenmek zorunda olduğunuz PHP gibi bir dille karşılaştırın.

Belgeler.

Süre Raylar Kılavuzları (genellikle ve Yakut,) Büyük bir öğrenme kaynağı, Raylar olan kütüphane referans gezindiğini kolay değildir. Diyelim ki, belongs_toyöntem hakkında daha fazla bilgi edinmek istiyorsunuz . Her ne kadar ActiveRecord::Basealt sınıflarda kullanılsa da (birinin modelleri), belgelerde belgelenmemiş ActiveRecord::Base, ancak sınıfın ithal ettiği bir karışım halinde belgelenmiştir . Temel olarak, tek bir yerde bir nesnede kullanabileceğiniz tüm yöntemlerin kapsamlı bir listesini göremezsiniz ( irbnesnenin ateşlenip kontrol edilmediği durumlar hariç ).

Ruby olarak oldukça dinamik bir dille, kullandığınız bir yöntemin nereden geldiğini söylemek kolay değildir. Özellikle yeni bir teknoloji yığınını kavramaya çalışan programcılar için bir problem olabilir.

Ruby on Rails'de önemli bir öğrenme eğrisi var. İlk önce dilin tuhaflıklarını öğrenmeli, daha sonra çerçeveyi öğrenmeli, daha sonra Rails Way'i yapmalı, daha sonra yaygın olarak kullanılan birçok taş hakkında bilgi edinmelisiniz.

Ancak, bu şeyleri öğrendiğinizde, inanılmaz derecede doğal olarak gelir. Aslında başka çerçeveler bir yük gibi hissetmeye başlar.

Rails çok TDD / BDD-yönelimlidir, bu yüzden eğer o zaman değilseniz, yetkili Rails programcısı olmadan önce öğrenmeniz gereken iki şey daha var. Sizi desteklemek için bir derleyiciniz ve IDE'niz yok, bu nedenle test kapsamı geri dönüşünüz çok fazla.

Kendim dahil, birçok TDD savunucusu bunun, RoR'un ve bunun lanetinin güçlü yanlarından biri olduğunu düşünecektir. TDD yazmaya başladığınızda, test kapsamı tarafından sunulan güvenliğin bir derleyici tarafından sunulan güvenlikten daha iyi olduğunu görürsünüz. Sonra bir derleyiciyi memnun etmek için SADECE kod yazmak zorunda kalmak zorlaşıyor.

TDD, RoR'da ek bir görev gibi görünmüyor, çalışmanın tek yolu gibi geliyor.

Rails'in ciddi bir performans sorunu vardır: her istek, çoğu çerçevede olduğu gibi işlenmesi veya engelleme olaylarının Node.js ve Twister'ın yaptığı gibi diğer istekleri serbest bırakmasına izin verme yerine, etkin olanın arkasında sıraya alınır. Bu, yanıt sürelerini hızlı hale getirmek için kodlamanız gerektiği anlamına gelir ancak bu çoğu durumda yapılması oldukça kolaydır.

Raylar, içerik sistemlerinin çok iyi bir şekilde ele alınması için de oldukça tasarlanmıştır, ki bu sayede adalet çoktur. Bir web oyunu ya da bir e-ticaret sistemi gibi biraz daha karmaşık bir şey yapmak, yeni taşlar öğrenmek anlamına gelir. Tüm mücevherlerin orada olduğunu çabucak öğreniyorsunuz, ancak yapmak istediğiniz şey ne kadar belirsiz olursa, iyi belgeler bulmak o kadar zor olacaktır.

Benim kişisel tecrübeme göre, ana baş ağrısı uyumluluk etrafında .

Ne zaman:

• xkonuşlandırılmış ray projeleri var ,
• Her proje ytaşlar kullanır .
• nray versiyonları varken ,
• artı myüklü mücevher versiyonları,
• ile severalyakut sürümleri,
• üretim makinesi olarak tek bir Linux kutusunda.
• programcı başka bir OS X geliştirme dizüstü bilgisayarında çalışıyor.

/ Güncellemesine lüksüne sahip şeylerin çoğunu yükseltmek, bir sürü karşı karşıya gelecek olmayan bir çevirmen olarak uyumluluk sorunları ederken ... Yukarıdaki değişkenlerden rails, gemsve rubytutmak gelişen / değişen.

Hız kesinlikle bir konudur. Ruby'nin aşırı esnekliği, önemli bir performans vuruşuyla birlikte geliyor.

Yatay olarak ölçeklendirme, genellikle iyi ölçeklendirmek için basitlikle işlem yapan, bu görev için özel olarak tasarlanmış teknolojiler dışında, açık olmayan bir işlemdir.
A teknolojisine sahip makine başına B teknolojisine göre 100 kat daha fazla istek karşılayabiliyorsanız, verilerinizi tek bir sunucudan eklemenizi sağlayan bir zaman dilimi için sunabileceğinizi düşünmenizin bir nedeni varsa A teknolojisini kullanmaya değer sonradan paralelleştirme.
2009 yılında stackoverflow hala tek bir web sunucusundan sunuldu . Elbette bu artık bir seçenek değil. Ancak, ölçeklendirme konusunda endişelenmeden önce, tek bir örnekte çok fazla kullanıcıya ölçeklenebilecek bir teknolojiyle başladıkları iyi oldu.

Buna kıyasla, RoR gerçekten yavaştır. Basit talepleri yerine getirme zamanı önemlidir ve bu nedenle birçok müşteriyle ilgilenmek bir problemdir (bunların hepsi daha hızlı alternatiflerle ilişkili olarak görülür).

Belirsiz oryantasyon uğruna, web geliştirmeye uygun çeşitli diğer dilleri Ruby ile karşılaştıran bazı rakamlar:

• Gitmek
• Clojure
• JavaScript V8 ( node.js )
• JRuby (unutulmaması gereken bir alternatif - sorunlu bölgenize bağlı olarak JRuby, raylar uygulamasından biraz hız almak için daha iyi veya daha kötü bir seçim olabilir)
• Scala
• Java
• C #

Bunun Java için X çerçevesini kullanırsanız, RoR'dan tam 200 kat daha hızlı olacağı anlamına gelmediğini unutmayın. Ancak bu kriterlerde ölçülen hız farkının, uygulamanızın genel performansı üzerinde önemli bir etkisi vardır.

Rails'in ciddi bir performans sorunu vardır: her istek, çoğu çerçevede olduğu gibi işlenmesi veya engelleme olaylarının Node.js ve Twister'ın yaptığı gibi diğer istekleri serbest bırakmasına izin verme yerine, etkin olanın arkasında sıraya alınır. Bu, yanıt sürelerini hızlı hale getirmek için kodlamanız gerektiği anlamına gelir ancak bu çoğu durumda yapılması oldukça kolaydır.

Bence bu çok yanlış yönlendirilmiş. Rails'i çok iş parçacıklı modda çalıştırabilirsiniz. Çok iş parçacıklı modda çalışırken, yalnızca GIL'yi (örneğin, 'mysql2' gem) serbest bırakan IO kitaplıklarını kullanmanız gerekir, aksi takdirde anlamsız hale gelir.

JRuby kullanıyorsanız, sadece çok iş parçacıklı modda tek bir ray işlemini çalıştırabilir ve mevcut tüm CPU gücünü kullanabilirsiniz. Bununla birlikte, eğer MRI kullanıyorsanız (Ruby 1.8.x veya 1.9.x), node.js için de geçerli olan CPU'ları tam olarak kullanabilmek için birden fazla işlemi çalıştırmanız gerekir.

• Rails sizden karmaşıklığı gizleyen birçok güzelliğe sahiptir. (ActiveRecord ilişkilendirmeleri, tüm doğrulama / tasarruf yaşam döngüsü, sağlanan başlıklara dayalı istek verilerinin yorumlanması) Yeni başladığınızda, bu harika. Büyüdükçe, uygulamanızı işleri işlemenin “Rails yolu” na sığdırmaya başladığınızı göreceksiniz - bazen bu iyidir, bazen bu zararsızdır, ve bazen aslında yapmaya çalıştığınız şeye karşı sezgiseldir. Tüm veritabanı tabloları nesne olarak modellenmemelidir, doğrulama basamağının başka bir yerde yapılması gerekebilir, vb. Pek çok Rails programcısı çerçeveyle mücadele etmekten kaçınır (genellikle akıllıcadır), ancak bunun uzun vadeli etkisi ... Rails'in alışkanlıklarını mutlaka aranmadıkları yerlere taşıyacaklar.

• Topluluğun "sihirli" olarak faturalandırılan bir yazılım yazma alışkanlığı var - sihirle çalışan lib'leri önbelleğe alıyor! Büyülü bir şekilde sizi daha hızlı yapan gelişmiş I / O Sihirli sihir! Buradaki durum genellikle, eksik olan teknik bir çözüm için çok cazip bir API'nin sağlanmış olmasıdır, ve sizin istediğinizi yapan çok güzel örnekler tarafından kandırılırsınız ve ancak daha sonra tamamlanmamış bir çözümü kapsadığını görürsünüz. Bunun döngüsü oldukça sabittir ve onunla birlikte yuvarlanmayı öğrenirsiniz, ancak güvendiğiniz çok sayıda ve çok sayıda kodu okuma fikrine kesinlikle aşina olmalısınız (iyi bir şey!). Rails topluluk sihir çözümleri neredeyse README'nin önerebileceği kadar sihir değil diyorum.

• Yukarıdakilere nazaran sonuç: Rails'i ne kadar çok kullanırsanız, kaynağını o kadar fazla okumanız gerekir. İç yapıları daha iyi anlarsanız, ne kadar mutlu olursanız uzun vadede o kadar mutlu olursunuz. Bu konuda özel Rails değil, ama sadece size buradaki deneyimden bahsetiyorum. Metot isimleri bazen almadığınız bir şey için size söz verir.

• Yük külteciliği, Rails ile ilgili bir konudur, ancak bu muhtemelen tüm çerçeve / lang toplulukları için de geçerlidir. Rails'de (bana) daha belirgin gözüküyor ve Rails koduna garip bir nesiller gibi bakma eğiliminde - farklı Rails projeleri üzerinde çalışırken, yaratıldıkları süreye ihanet etme eğiliminde olduklarını fark edeceksiniz. . Bu ifadeden tahmin edebileceğiniz gibi, topluluk yeni çözümler benimseme ve eskileri onaylamama konusunda oldukça hızlı hareket etme eğilimindedir. Sadece günlük olarak deneyimleyeceğiniz bazı kodları anlamak için Ruby haberlerinin başında gelmelisin.

• Genel olarak konuşursak, veri eşzamanlılığı meselesinin toplum tarafından genellikle iyi bir şekilde ele alınmadığını düşünüyorum - bir uygulama büyüdükçe, verileri parçalamanız, fiziksel olarak uzaktan değişiklikleri geri almak ve verilere erişimi kilitlemek için ihtiyaç duyduğunuz noktaya geldiğinizde, çözümler biraz daha fazla elle ayarlanmış, bu da bazı güzel görünüşlü kılar. Yaptığınız her şeyi karıştırırsınız. Rails, bir web uygulamasıyla yaşayacağınız her sorunu çözmüyor, sanırım diyorum ve yaratıcılar kesinlikle bu mesajı vaaz etmiyorlarsa, ima edildiğini düşünmek için kandırılmaları kolaydır.

Nasıl baktığınıza bağlı olarak, Rails'in değişme hızı sizin için bir uyarı olabilir veya olmayabilir. Çözümler neyin berbat olduğunu ve neye ihtiyaç duyulduğunu ortaya çıkardığından, işler yıldan yıla radikal bir şekilde değişir.

Aktif gelişim içindeyseniz, bunun nabzında parmağınızı görürsünüz.