Çerçeveler çok fazla soyutlama mı yapıyor? [kapalı]

Bir yıldan biraz az bir süredir programlama yapıyorum ve sistemler / uygulamalar, web uygulamaları ve işletmeler / kuruluşlar için komut dosyaları yazma konusunda biraz deneyimim var. Ancak, hiç yapmadığım bir şey Django, Rails veya Zend gibi bir çerçeveyle çalışmak.

Django çerçevesine baktığımda, çerçevelerde ne kadar soyutlandığını biraz hayal kırıklığına uğrattım. DRY'nin ve minimum kodun temel hedeflerini anlıyorum, ancak farklı modüllere bu aşırı bağımlılık ve çekirdek fonksiyonların yoğun soyutlanması şöyle hissettiriyor:

1. Modüllerin / çerçevelerin sürekli değişen yapısı nedeniyle programların çok hızlı bir şekilde tarihlenmesini sağlar,

2. Kullanılabilir çerçeve ve modüllerin bolluğu ve tüm özniteliklerinin nedeni ile kodun anlaşılmasını zorlaştırır,

3. Tüm belgeleri okumadığınız sürece kodu daha az mantıklı hale getirir; yani, bazı liste kavramalarını ve koşullu mantığı okuyabilir ve bir programın ne yaptığını anlayabilirim; verilen bir modül; ve:

4. Çerçeveler arasında geçiş yapmayı zor ve sıkıcı hale getirir. Diller arasında geçiş yapmak zaten bir zorluktur, ancak temel işlevleri / felsefesi hakkında yeterince güçlü bir anlayışa sahipseniz yönetilebilir. Çerçeveler arasında geçiş yapmak daha ziyade ezberleme meselesi gibi görünmektedir, ki bu bir şekilde bu çerçevelerin ortadan kaldırılması için tasarlanan verimsizliği teşvik etmektedir.

MySQL sorgusu kadar basit bir şeyin üstüne 50 katmanlık soyutlama koymamız gerekiyor mu? Neden hazırlanan ifadelerin / giriş testlerinin kullanıldığı PHP'nin PDO arayüzü gibi bir şey kullanmıyorsunuz ama evrensel olarak anlaşılabilir SQL sorgusu hala bu fonksiyonun bir parçası.

Bu soyutlamalar gerçekten yararlı mı? Özellik kabarcığı onları işe yaramaz hale getirmiyor, uygulamaları bir çerçeve kullanmadan yazılmış benzer uygulamalara göre daha zorlaştırıyor mu?

Altyapıları gerçekten zor olabilir. Bir çerçeve çok "düşünülmüş" olduğunda, yani belirli bir uygulama tarzını gerçekten tercih ettiğinde ve tüm parçalar bu belirli stili desteklemeye yönelik olduğunda problemler kolayca ortaya çıkabilir.

Örneğin, çerçeve yalnızca bir bileşen eklemenize izin vererek bir kullanıcının kimlik doğrulama işlemini tamamen soyutlarsa, bir yere bir giriş şablonu ekleyin ve işte, kullanıcı kimlik doğrulamasını ücretsiz alın. Bu, çerezler, oturum saklama, şifre karmaşası ve neyin sakıncası hakkında endişe duymanız için birçok tekrarlı çalışmadan tasarruf etmenizi sağlar.

Çerçevenin kimlik doğrulama kodunun varsayılan davranışının ihtiyacınız olan şey olmadığını fark ettiğinizde sorunlar başlar. Belki de en iyi güvenlik uygulamalarını takip etmiyordur. Belki bazı eylemleri tetiklemek için işlemde özel bir kancaya ihtiyacınız vardır, ancak çerçeve bir tane önermez. Belki ayarlanan çerezin ayrıntılarını değiştirmeniz gerekir, ancak çerçeve bunu özelleştirmek için bir yol sunmaz.

Çerçevenin sağladığı soyutlama, sitenize ilk günler yerine dakikalar içinde birkaç dakika içinde önemli bir özellik eklemenizi sağladı, ancak sonunda, yapmanız gerekenleri yapması için çerçeveye karşı mücadele etmeniz gerekebilir ya da ihtiyaçlarınızı karşılamak için yine de işlevselliği sıfırdan yeniden yaratmanız gerekir.

Bu, çerçeve soyutlamaların kötü olduğunu söylemek değildir, aklınızda bulundurun. Bunun her zaman akılda tutulması gereken bir olasılık olduğunu söylemek. Bazı çerçeveler açıkça buna yöneliktir, çok sınırlı, belirli bir uygulama türü için prototip veya hatta üretim çerçevesi olarak çok hızlı bir şeyler elde etmenin bir yolunu sunarlar . Diğer çerçeveler daha fazla kullanabileceğiniz fakat daha sonra bunları değiştirebilmeniz için size çok fazla esneklik sağlayan gevşek bileşen koleksiyonları gibidir.

Bir soyutlama kullanırken, her zaman en azından kabaca ne soyutladığını anlamalısınız. Çerezleri ve kimlik doğrulama sistemlerini anlamıyorsanız, bir soyutlamadan başlamak iyi bir fikir değildir. Ne yapmaya çalıştığınızı anlıyorsanız ve sadece kendi sıkıntıyla kendiniz yazmak yerine zaten bunu yapan bir koda ihtiyacınız varsa, soyutlamalar çok iyi bir zaman tasarrufu sağlar. Kötü yazılmış soyutlamalar olsa daha sonra başını belaya sokabilir, bu yüzden iki ucu keskin bir kılıç.

Teknik soyutlamalar ile "iş kuralı" soyutlamaları arasında da ayrım yapmanız gerekir . Daha yüksek düzeyde bir dilde programlama, muhtemelen kaçırmak istemediğiniz bir soyutlamadır (Python, PHP, C # vs. C - Assembler; Daha Az - CSS); ihtiyaçlarınızı tam olarak karşılayın (tek tıklamayla kimlik doğrulaması ve elle kodlama tanımlama bilgileri).

Bunun nedeni teknik soyutlamaların nadiren "sızıntı" olması, yani Python'da uygulama yazarken makine kodunda hata ayıklamanız gerekmeyecek. İş kuralı soyutlamaları yine de aynı teknik seviyede çalışır ve gerçekten sadece "kod paketleri" dir. Muhtemelen olacak ayarlanır çerez ya da 3. parti kod sürü aracılığıyla dalış olacağım anlamına belli noktada oluşturulan şifre karma hata ayıklamak gerekir.

Bana öyle geliyor ki, soyutlamaları yanlış anlıyorsunuz ve kodun tekrar kullanımı.

Tüm yazılım geliştirme endüstrisi soyutlamalar üzerine kuruludur. Sırf bunları kullanmamak, yani çerçeveler, kütüphaneler kullanmaktan kaçınmak ve kurum içinde yazılı olmayan genel kodlardan kaçınmak, bir yazılım parçası üretmek için gereken maliyeti yüz bin, hatta daha da fazla artıracaktır.

Sıfırdan jumbo jet üretmediğiniz gibi, başka uçaklar inşa ederken yıllarca geliştirilen hiçbir mühendislik bilgisini kullanmadan iş yazılımını sıfırdan yazmazsınız.

PHP veya Ruby kullanarak ilk etapta, zaten çok sayıda soyutlamaya sahip olduğunuzu anlıyorsunuz, değil mi? En belirgin olanlar:

1. İşletim sistemi, programlama dili ve derleyici Assembler ve donanım üzerinden büyük bir soyutlama sağlar,

2. Web sunucusu soket, yük devretme, HTTP protokolü vb. Soyutlama sağlar.

3. SQL, verilerin kalıcı bir depolama desteğinde nasıl depolandığı ve daha hızlı erişim için bellekte tutulduğu hakkında bir özet sağlar, ACID, yansıtma vb. Sağlar.

Bir işletim sistemini, bir web sunucusunu, bir veritabanını veya yüksek seviye bir programlama dilini kullanmadan her zaman bir web uygulaması oluşturmayı deneyebilirsiniz. Hızlı bir şekilde, yani yeniden, tekerleği yeniden yıl geçirdi olduğunu göreceksiniz sizin programlama dili, sizin web sunucusu ve sizin kendi kalite aslında kullanmak ürünlerin kalitesi uzak olacağını verilen veritabanını.

Çerçeveler bundan farklı değil. Ne yaparlarsa yapabilirsin. Sadece aynı işlevselliği tekrar yaparak zamanınızı boşa harcayacağınız zaman, bu çerçevelerin bunu daha iyi yapacağını fark ederek ve kodları sizinkinden daha iyi şekilde test edilecek ve belgelenecektir.

Bir e-ticaret web sitesi için bir araba örneği alın. Kendinizinkini icat edip onu geliştirmek için birkaç hafta harcayabilir ya da birkaç yıl boyunca bir çerçeve içinde geliştirilmiş olanı alabilirsiniz. Bunların, birkaç yıl boyunca, geliştiricilerin kendi sepetinizi geliştirirken hayal edemeyeceğiniz bir sürü hata keşfettiği ve yattığı gerçeğini saymazsak, test edilmeleri bekleniyor.

Kullanıcıların durumları daha fazla olduğu için, onların daha karmaşık olduğunu cevaplayabilirsiniz. Örneğin, web sitenizde indirimleriniz olmasa da alışveriş sepetinde bu özelliğe ihtiyaç duymazken, indirimlerle ilgilenmeleri gerekir. Bu özelliği kullanmak zorunda değilsiniz ve web uygulamanızın performansını düşürecek gibi değil.

Var olanı kullanmak yerine kendi sepetinizi geliştirmek gerçekten daha kolay olduğunda çok basit bir senaryo olabilir. Aynı şekilde, uygulamanızın ihtiyaç duyduğu tek şey bir numara listesini depolamaksa, hiçbir şey yapmazsanız, bir veritabanına ihtiyacınız olmaz: basit bir metin dolgusu yeterli olacaktır. Bu gibi durumlarda, uygulamanızı aşırı mühendislik yapmayın: basit senaryolar basit çözümler gerektirir.

Diğer bir faktör, kodunuzun okunabilirliğidir. Bir e-ticaret web sitesi oluşturduğunuzu düşünün. Daha sonra projeyi terk ettiniz ve başka bir geliştirici de sürdürmeli.

• Bir çerçeve tarafından sağlanan bir el arabası kullanmış olsaydınız, iş arkadaşınız rahatlardı: Güvenilir, ağır bir şekilde belgelenmiş bir çerçeveye dayanan küçük bir kod parçasına sahip olması gerekir. Daha da iyisi: Bu geliştirici, bu çerçeve ile çalışmak için kullanılmış olabilir ve buna aşinadır. Eğer değilse, Yığın Taşması ile ilgili sorular sorabilir: elbette, birileri zaten çerçeveyi kullandı.

• Kendi arabanız olsaydı, meslektaşınız herhangi bir yerde yardım almadan, belki de belgelenmemiş bazı özel kodlar saklamak zorunda kalırdı.

Bir çerçeve kullanarak, aşağıdaki kodları kullanırsınız:

• Deneyimli geliştiriciler tarafından yazılmış,

• Genellikle çift yorumlu,

• Birim test edilmiş,

• Yaygın olarak belgelenmiş

• Binlerce geliştirici tarafından yıllarca kullanılır,

• Genellikle desteklenir, böylelikle bir hatayı rapor edebilir ve gerçekte düzeldiğini görebilirsiniz.

• Olası uyarıları ve sorunları bilen ve Stack Overflow gibi sitelere yardımcı olabilecek birçok geliştirici tarafından bilinmektedir.

• Şu anda sizin için uygun, ücretsiz.

Katılıyorum - çoğu çerçeve şişirilmiş diktatörler haline geliyor. Özgürlük vaat ediyorlar ama sonunda hizmette kalacaksınız. bu nedenle bir araç gibi bir çerçeveye bakın - en iyi araç, yolunuzdan çıkan araçtır. PHP'de, Codeigniter çerçevesini incelemeyi öneririm, çünkü sözleşmelerle özgürlük arasında zarif bir denge ve harika bir topluma sahiptir. Ve bir e-ticaret sepetinin örneğini kullanan poster için - Keşke sizinle aynı fikirde olabilseydim. ancak birçok e-ticaret çözümünün koduna baktığımda - ve birkaçını tasarladığımda - örneğinize saygıyla katılmıyorum.

Hmmm LedgerSMB'in çok çalıştığımız bir yönü çerçeve yaklaşımımızdı. Yine de bu soyutlama ile gelen iki temel sorun var. Bunlar:

1. Bağımlılık patlaması ve

2. Yanlış soyutlama

İlki, tekerleği yeniden icat eden alternatiften daha iyidir. İkincisi, etiketlemesi zor olan bir parçadır, çünkü kötü tanımlanmış bir problem durumundan veya daha sık olarak, amaçlanan kullanımı dışında bir şey kullanan kişilerden gelebilir.

Örneğin ORM'lere bakalım. ORM'leri kullanmaktan kaçınıyorum çünkü db, uygulamanın nesne modeline göre tasarlandığı için sık sık ortaya çıkıyor, çünkü en iyi şekilde sızan soyutlama katmanlarıdır. Bu mutlaka durum böyle değil. ORM'leri kullanırken iyi DB tasarımını ve iyi uygulamayı korumayı başaran geliştiricilerle tanıştım, ancak db'nin ilişkisel API'sini güncellenebilir görünümlerin arkasına yerleştirmek gibi, orm hype'ına gerek duyulmaması gerektiğini söylediği birçok şeye başvurdular.

Elbette büyük bir sorun, kodu daha yüksek oranda otomatik hale getirmesidir, özellikle de donuk olduğunda, neyin yanlış gittiğini görmek zorlaşır. Bu, jhewlett'in yukarıda yaptığı ORM'lerle ilgili bir noktadır (bkz. Https://softwareengineering.stackexchange.com/a/190807/63722 ).

İyi bir paralel, bir uçağı yönlendirmek için bir çerçeve olarak gelişmiş aviyonik olabilir. Bunlar güvenilirlik için yüksek derecede tasarlanmıştır ve uçuş güvenliğindeki artışta bir faktördür. Ancak, IEEE Spektrumu'ndaki pek çok makalenin işaret ettiği gibi, bu, otomasyon perspektifinden kabul edilebilir sayılan sınırların dışındaki hatalardan kurtarılabilirlik maliyetine sahiptir. Aynı hata ayıklama için de geçerli. Programınızdaki SQL kodunu hata ayıklamak için bir şey. Programınızın kullanımı için SQL kodu yazan bir bölümünüzde hata ayıklamak çok farklı bir şey.

LedgerSMB çerçevesini sıfırdan yazdık, çünkü başladığımız zaman istediklerimizi yapan gerçekten iyi bir çerçeve yoktu. Bu aslında çok mutlu olduğum bir şey ve projedeki yeni bir geliştiriciye göre, uygulamanın özelleştirilmesini oldukça basit hale getiriyor. (Aslında SQL kodu üretimini minimumda tutarız ve bunun yerine elle yazılmış kullanıcı tanımlı fonksiyonlara odaklanırız, yani sql yazma bölümleri çok ince bir yapıştırıcıdır). Evet, bazı yerlerde çok fazla soyutlama sağlar, bazı programcıların rahat etmelerinden daha çok (özellikle "bu saklı yordamlardaki argümanlara eşleme özellikleri") zaman zaman geri çekmemize neden olur). Bununla birlikte, her şeyin basit ve tutarlı olmasını sağlamaya çalışırız, böylece neyin yanlış gittiğini tespit etmenin yalındır. Bu oldukça iyi çalışıyor.

Sonunda "çok fazla" biraz özneldir, ancak nesnel bir düzeyde, ne yaptığınıza da bağlıdır. Çerçevenin tam olarak ne yapmak istediğini yapıyorsanız, iyi tasarlanmış bir çerçeve mükemmel bir soyutlama sağlayacaktır. Biraz daha az uygun bir şey yapıyorsanız, soyutlama hem çok fazla hem de çok sızdıracaktır.

Evet, faydalılar. Çözmeniz gereken bir sorunu çözmek için çalışan birçok deneyimli geliştiricinin yararını, test etmenin ek faydalarıyla, endişelenmenize gerek olmayan zorlu sorunlara çözüm sunar çerçeveyi kullanarak kendiniz.

Fazla şişirilmiş olabilirler mi? Emin. Tüm bunlar neye ihtiyacınız olduğuna ve çerçevenin masaya ne getirdiğine bağlıdır. Basit bir web uygulamanız varsa, belki de Rails sizin için çok azdır ve Sinatra gibi basit bir şeye bir çözüm olarak bakmalısınız.

Kesinlikle tüm çerçevelerde bir öğrenme eğrisi var ve sizin için biriktirdiği çalışmalarla daha dik. Bununla birlikte, çerçeveyi öğrenmek, zamandan tasarruf ettiğiniz anlamına gelir ve uygulamanızı sıfırdan yeniden yazmak yerine, bir sonraki projedeki tüm bu bilgilerden yararlanabilirsiniz.

Ancak, kodumu eski projeden kopyalayacağım ve bunu yeni projem için bir başlangıç ​​noktası olarak kullanabilirim! Sadece farklı olanı değiştireceğim ve belki de nesnelerimin / işlevlerimin bazılarını daha genel yapacağım ve bu zor kod parçasını çözmenin daha iyi bir yolunu düşüneceğim! Tebrikler, az önce bir çerçeve oluşturdunuz. Bunu birkaç bin kez daha yapın ve Django, Rails veya Zend gibi bir şeye sahip olun.

Altyapılar genellikle daha fazla üretkenlikle sonuçlanır (belki de hafif bir öğrenme eğrisinden sonra), ancak genellikle bir takas vardır. Bazı durumlarda, örneğin, düşük performans pahasına programcı üretkenliği elde edersiniz.

Nesne-İlişkisel Eşleştiricileri (ORM'ler) göz önünde bulundurun. Onlar sizin için sıkıcı harita koduna çok dikkat etmeleri konusunda harikalar. Nesnelerini sizin için bile yaratabilirler. Bununla birlikte, SQL'i soyutlamakta performans hakkında düşünmek ve darboğazlarınızı optimize etmek çok daha zordur.

Çok fazla veri veya karmaşık sorgular içermeyen bir uygulama oluşturuyorsanız, performans sizin için sorun olmayabilir. Gerçekten de, programcı zamanı birçok projenin darboğazıdır ve çerçeveler, kütüphaneler ve üst düzey diller bunu hafifletmeye yardımcı olmaktadır.

"Kütüphaneleri kullanıyorsunuz, ancak çerçeveler sizi kullanıyor" kabul ediyorum. Bunu koymak için çok temiz bir yol. Kodu yeniden kullanmaya başlar başlamaz bir çerçeve oluşturmaya başladığınızdan emin değilim, çünkü genellikle kodunuzu tekrar kullanmak için hızlı bir kopyalayıp yapıştırmadan daha fazlasını yapmanız gerekmez - bu bir inşa ettiğiniz kütüphane; Kodu sitenize veya uygulamanıza nasıl getireceğiniz konusunda garip olmaya gerek yok.

Benim için en önemli nokta, yatırım yapmam için gerekenden daha fazla bir kaynaktan çıkmam gerektiğidir. Veya, başka bir açıdan, bir çerçevenin ihtiyaçları mevcut olan ödüllerden daha büyük olursa, tüm avantajların bulunmadığını söyleyebilirim. Yani 'Evet! Lütfen! Ve teşekkür ederim!' kendi html / CSS / PHP ve SQL'im dahilinde gerektiği gibi dümdüz düşecek ve işlev görecek varlıkları yapan herkese.

Anlaşılmaz bulduğum bir şey, çerçevelerin bakımı kolaylaştırdığı söyleniyor. Birlikte çalışan parçaların karmaşık ağı amaçlanan şekilde performans göstermiyorsa, söz konusu çerçeve hakkında bilmeniz gereken her şeyi daha iyi bilirsiniz. Ya da yeni bir sözdizimi girişi için hazır olun.

Bazı insanlar bunun Hollywood'un Çerçeve İlkesi olduğunu söylüyor : "Bizi arama, sizi ararız". Buna karşılık, bir kitaplık kullandığınızda, kodunuz kitaplığı çağırır, tam tersi olmaz.

Gördüğünüz gibi, önemli olan nokta kimin kontrol altında olduğu - yani kontrol akışının kontrolü. Hangi ifadenin hangisinden sonra yayınlanacağına kim karar veriyor?

Pro ve contra argümanları var ve ne zaman böyle sonsuz tartışmalar görsem, bunun nesnel olarak reddedilebilir bir sorudan ziyade bir zevk meselesi olduğunu düşünme eğilimindeyim. Aksi takdirde, zaten karar verilecekti.

Benim görüşüme göre, çerçevelerden mi yoksa kütüphanelerden mi yararlanacağınız, ne tür bir geliştirici olduğunuzu ve her iki yaklaşımdan birinin de üstün olup olmadığını ve eninde sonunda geçerli olup olmayacağını anlatır.

Çerçeveleri tercih ederseniz, güvenlik için özgürlük değiş tokuş etmeyi tercih edersiniz: muhtemelen daha pragmatiksiniz ve başkalarının işlerini doğru şekilde yapma konusunda güvenme eğilimindesiniz. Kütüphaneleri tercih ederseniz, güvenlik için değiş tokuş yapmayı tercih edersiniz: Muhtemelen daha çok idealistsiniz ve başkalarının fikirlerini ve iddialarını sorguluyorsunuz.

Eski veya ikincisi gibi olmanın daha iyi olduğuna karar vermenin akıllıca olacağını sanmıyorum.

Sorunuza cevap vermek: Çerçeveler çok fazla soyutlama yapar mı? Bu, kim olduğunuza ve özellikle ilk prensiplerden ne kadar uzakta olduğunuza güvendiğinize bağlı.

...

Ve daha da özel olarak, eğer Django gibi çerçeveleri sevmiyorsanız, Flask gibi "microframeworks" ifadelerini arayın :)