it-swarm.asia

Bir çerçeve ne zaman KULLANILMAZ

Bugün, hemen hemen her dil için bir projeye uyacak bir çerçeve bulunabilir. Modern çerçevelerin çoğu, saatlerce test, hakemli kod ve mükemmel genişletilebilirlik ile oldukça sağlamdır (genel olarak konuşur).

Bununla birlikte, programcıların, bir topluluk olarak, seçtikleri çerçevelere o kadar bağımlı hale gelebileceğinden HERHANGİ bir çerçevenin bir dezavantajı olduğunu düşünüyorum, artık altta yatan çalışmaları artık anlamadılar veya daha yeni programcılar söz konusu olduğunda, ile başlar. Artık bir 'PHP programcısı' (örneğin) değil, başka bir şeyin dışlanması için bir "Drupal programcısı" olduğunuz bir dereceye kadar uzmanlaşmak kolaydır.

Kimin umrunda, değil mi? Çerçevemiz var! "Nasıl elle yapılacağını" bilmemize gerek yok! Sağ?

Bu temel beceri kaybının sonucu (bazen yok çerçeveleri kullanan programcılar "modası geçmiş" olarak görülüyorsa), bir çerçeveyi olduğu yerde kullanmak yaygın bir uygulamadır. gerekli veya uygun değil. özellikler çerçeve, temel dilin yetenekleri ile karıştırılmayı kolaylaştırır. Geliştiriciler, en temel görevleri bile gerçekleştirmek için çerçeveleri kullanmaya başlarlar, böylece bir zamanlar ilkel bir süreç olarak kabul edilen şey artık kendi tuhaflıkları, hataları ve bağımlılıkları olan büyük kütüphaneleri içerir. Bir zamanlar 20 satırda gerçekleştirilen şey, şimdi 20.000 satır çerçevesini dahil ederek VE çerçeveyi kullanmak için 20 satır yazarak başarıldı.

Tersine, tekerlek yeniden icat etmek istemiyor. Bazı temel, ortak küçük işleri gerçekleştirmek için kod yazıyorsam, XYZ çerçevesinin peşimde olduğum tüm özellikleri ve çok daha fazlasını sunduğunu bildiğimde zamanımı boşa harcıyor gibi hissediyorum. "Çok daha fazlası" kısmı hala beni endişelendiriyor, ama artık pek çok kişi bunu düşünmüyor bile.

Bir çerçevenin ne zaman kullanılmasının uygun olduğunu belirlemek için iyi bir metrik olmalıdır. Eşiğin ne olduğunu düşünüyorsunuz, siz ne zaman bir çerçeve kullanılacağına veya ne zaman kullanılamayacağına nasıl karar veriyorsunuz? .

38
Chris

"Bir çerçevenin ne zaman kullanılmasının uygun olduğunu belirlemek için iyi bir metrik olmalıdır."

Pek sayılmaz. Herhangi bir teknolojinin uygun kullanımını belirlemek için iyi metrikler olsaydı, dil, editör ve metodoloji kutsal savaşlarını göremezdiniz.

Birlikte çalıştığım gruplar aynı şeyi yapıyorlar - maliyet ve faydaları tahmin et, en verimli rotayı seç ve umarım haklılar. Çok bilimsel değil - bir bölüm sezgi, üç bölüm deneyimi, bir bölüm pazarlamaya yatkınlık, bir bölüm kurnazlık ve beş bölüm rütbesi.

27
Corbin March

Çerçeveler sadece araçlardır. Aşırı kullanıldığında bir çerçevenin hatası olduğunu düşünmüyorum, onu aşırı kullanan kişinin hatası değil. Eski "bir çekiçiniz varsa, her şey çiviye benziyor" diyen bu düşünce şekli bilgisayarlardan bile çok önce var olduğunu gösteriyor.

Çok uzmanlaşmak gerçekten uzun vadede bir soruna dönüşebilir - bir geliştirici ve biyolojik türler için. Uzun vadede hayatta kalabilmek için, birçok alanda becerilerini geliştirme çabasını dikkatle dengelemek gerekir.

Özel sorunuza cevap vermek için bunun bir ölçüsü olduğunu düşünmüyorum. Sorun çözmeyi basitleştirdiğinde bir çerçeve kullanmayı tercih ederim. Bir çerçeve kullanmak bana 20 yerine 2 satır kod ile bir sorunu çözmek yardımcı olursa, ben açıkça kullanacağım. Ancak 20'ye karşı 20 çizgisi olsa bile, bana daha iyi soyutlamalar verirse, sorun alanına daha yakın, bir kodun anlaşılmasını ve bakımını kolaylaştırırsa bir çerçeve kullanmaya karar verebilirim.

14
Péter Török

Bence bazı bağlamlarda çerçeveler aşırı kullanılabilir. Bir çerçeve sadece bir araçtır, evet. Bir çerçeve, bir şeyin çok hızlı bir şekilde çalışmasını sağlar ve bu nedenle mükemmel bir prototipleme aracıdır.

Hat boyunca bir yerde, uygulamanız bir miktar karmaşıklığa ulaştığında, bir çerçevede bulunan kısıtlamalar daha fazla büyümeyi engellemeye başlar, öyle görünüyor. İşin püf noktası, böyle bir devrilme noktasıyla karşılaştığınızda bunu tanımak ve daha sonra bu konuda ne yapacağınıza karar vermektir.

6
leed25d

En çok web uygulamalarıyla çalışma eğilimindeyim ve genel olmaya çalışsam da, yanıtım olmayabilir programlama alanınıza uygulanabilir.

Ayrıca "kütüphane" ile eşanlamlı "çerçeve" kullanacağım.


Bir çerçeveyi uygulamadan önce, birkaç şey düşünülmelidir, işte birkaç genel örnek.

# 1. Çerçeve zaman ve emek tasarrufu sağlayacak mı?

Bu sorunun cevabı neredeyse her zaman yes . spesifik sorunları ve çok iyi çözmek için çerçeveler oluşturulma eğilimindedir. Örneğin, EntityFramework gibi çerçeveler tamamen SQL kodunu yazmanızı engelleyebilir. Programlama ekibiniz SQL'de akıcı değilse bu harika olabilir.

Çerçeveler, a), aksi takdirde karmaşık bileşenlere programcı dostu bir arabirim eklemek veya b) zaten bilinen (veya yerleşik) bileşenlere soyutlama eklemek .

İkincisi (hatta bazı durumlarda eski) aslında gelişim yoluna girebilir. Bu, siz veya programlama ekibiniz daha önce hiç çalışmadığı yeni bir çerçeve uygulayacağınız zaman özellikle geçerlidir.

Bu, potansiyel olarak maliyetli olabilecek geliştirme sürecinizi yavaşlatabilir.

# 2 Başvurunuzun ölçeği

"yapmaya değer her şeyin aşırıya kaçmaya değer olduğu söylenir" , ancak genellikle durum böyle değildir. Uygulamanızın amacı "potato" yazdırmaksa, büyük boyutlu bir çerçeve uygulamak için muhtemelen iyi bir neden yoktur.

Bir uygulama geliştirirken (web, masaüstü, mobil veya akla gelebilecek başka herhangi bir uygulama türü) - çerçevenizin boyutunun (belki de gelecekteki) uygulamanızı "cüce" ​​ettiğini düşünüyorsanız, bu büyük olabilir uyarısı, çerçevenizin uygulamanızı şişirebileceğini gösteriyor. JQuery'yi eklediyseniz, belge hazır olduğunda gövde etiketinize "yüklü" bir sınıf eklemeniz iyi bir fıkra olacaktır. Bunu sadece yerel JavaScript ile yapmak küçük bit zor olabilir, ancak uygulamanızı şişirmez.

Öte yandan bir çerçeve içeride kirli iş yaparsa çok yaparsa (yani veritabanı çerçeveleri), sadece "kısmen" çerçeveyi kullanıyor olsanız bile bunu uygulamak için uygundur. İyi bir fıkra, not , tüm kütüphaneyi kullanmanız gerekmediği için kendi ADO.NET veya MongoDB sürücünüzü oluşturmaya çalışmak olacaktır.

Bazen çerçeveler açık kaynak kodlu olarak gelir (ve 'ne istersen yap' lisansları ile). Bu, bir programlama ekibinin yalnızca çerçevenin bazı bölümlerini seçebileceği yeni bir olasılık açar.

Bu sonuçta 1. ve 3. sorulara geri dönüyor.

# 3 Etki.

Bazen bir çerçeve uygulamak son kullanıcıyı doğrudan etkileyebilir olabilir. Bu, özellikle web uygulamaları için geçerlidir, çünkü büyük istemci tarafı çerçevelerine sahip olmak son kullanıcının deneyimini olumsuz etkileyebilir. Daha yavaş makineleri olan kullanıcılar yavaş işleme, javascript ile performans sorunları veya alt par makinelerin neden olduğu benzer sorunlarla karşılaşabilir. Yavaş bağlantıları olan kullanıcı yavaş (en azından ilk) yükleme süreleriyle karşılaşabilir.

Diğer tür uygulamalarda bile, son kullanıcılar uygulama bağımlılıklarınızdan olumsuz etkilenebilir. Çerçeveler en azından her zaman some disk alanı kaplar ve bir mobil uygulama (veya hatta bir masaüstü uygulaması) geliştiriyorsanız bunun dikkate alınması gerekebilir.

Sunucu tarafı çerçeveleri (daha da fazla web'e özgü) büyük olasılıkla son kullanıcılarınızı etkilemez, ancak altyapısı öğenizi etkiler. Bazı çerçeveler kendileri bağımlılıklarına sahiptir, bu da web sunucunuzu yalnızca hizmeti veya sunucuyu tamamen yeniden başlatmanızı gerektirebilir.

Bazı çerçeveler ayrıca very kaynak ağırlıklı olabilir.

Bu elbette # 1 ve # 2 noktalarına geri dönüyor.


Her şey sadece büyük bir "dikkat çemberi" dir ve bir çerçeve uygulayıp uygulamayacağınıza karar vermek için gerçek bir bilimsel yöntem yoktur.

Corbin March bunu çok iyi özetledi:

Birlikte çalıştığım gruplar aynı şeyi yapıyorlar - maliyet ve faydaları tahmin et, en verimli rotayı seç ve umarım haklılar. Çok bilimsel değil - bir bölüm sezgi, üç bölüm deneyimi, bir bölüm pazarlamaya yatkınlık, bir bölüm kurnazlık ve beş bölüm rütbesi.

Ayrıca seçkin olmamak önemlidir. Çerçeveler, kullanılması amaçlanan araçlardır. Her iki uçtaki insanları tanıyorum; bir tarafta yaşamı kendisi için çok zorlaştıran bir adam var, diğer tarafta yavaş, şişirilmiş uygulamalar yapan adam var.

Tüm çerçevelerin kullanım örnekleri vardır, bu sadece onları doğru amaçlar için uygulamakla ilgilidir.

6
die maus

Diğer geliştiriciler çerçeveyi biliyor mu?

Tüm geliştiriciler X çerçevesini biliyorsa, çerçeveyi kullanmak için diğer tüm nedenler göz önüne alındığında, geçerli olsun! Bana göre, geliştirme zamanının büyük bir kısmı çerçevenin inceliklerini öğrenmek için harcanacaksa, belirli bir çerçeveyi öğrenmeyi zorlamak mantıklı değildir.

Yeni programcıların temel bilgileri bilmediği konusundaki açıklamanızla ilgili olarak, benden çok daha şefkatlisiniz! Evet, bu bir utanç, ama zamanımı başkasının beceriksizliği hakkında endişelenerek mi geçireceğim? Nup. (Topluluğun bu yeni üyelerinin hemen sizinle çalışmadığı varsayımına dayanarak.)

4
J.K.

Aşağıdaki koşullar doğruysa (ve SADECE eğer) bir çerçeve kullanırdım:

Çerçevenin bir süre desteklenmesi muhtemel görünüyor. Daha önce hayatlarımın sonuna kadar gitmiştim ve gerçekten sinir bozucu. Özellikle projenize 9 ay kaldığınızda geçiş yapmak artık bir seçenek değil. Ve çerçeve ZATEN artık desteklenmiyorsa, o çerçeveyi kullanarak yeni bir şey yazmadan önce üç kez düşünün. Ne kadar iyi biliyor olursanız olun.

Proje aslında çerçeveyle eşleşiyor. Oldukça eski bir örnek olarak, MFC'nin yaptığı şeyleri gördünüz mü? İnsanlar, bunun mantıklı olmadığı uygulama türlerinde çalışmasını sağlamak için garip şeylerin sonu yoktu. Genellikle MFC'de dövmek istedikleri uygulamayı yazmaktan daha fazla zaman harcarlar.

Proje ekibi, çerçeve içerisinde çalışabilir. Bazı insanlar, bir uygulamanın belirli bir çerçevede nasıl yazılması gerektiğini anlamak için zaman ayırmaz veya yapamaz ve bunun yerine, çerçevenin ihtiyaç duyduğu yol yerine, işleri genellikle yaptıkları gibi yazarlar. Kod ve çerçeve arasındaki bu yanlış eşleşme genellikle herkese çok fazla zaman ve çaba harcıyor.

4
Michael Kohne