Ne zaman bir çerçeve kullanmayacağım [kapalı]

Bugün, herhangi bir projeye uyacak şekilde hemen hemen herhangi bir dil için bir çerçeve bulunabilir. Modern çerçevelerin çoğu, saat başı test, eş gözden geçirme kodu ve mükemmel genişletilebilirlik ile oldukça sağlamdır (genel olarak konuşur).

Bununla birlikte, bir topluluk olarak programcıların seçtikleri çerçevelere o kadar güvenebilir hale gelebileceğini, temeldeki çalışmaları artık anlamadıklarını ya da daha yeni programcılar söz konusu olduğunda, altta yatan çalışmaları asla öğrenemeyeceklerini düşünüyorum. ile başlar. Artık bir 'PHP programcısı' (örneğin) değil, "Drupal programcısı" olmak üzere başka bir şeyin dışlanması konusunda uzmanlaşmak kolaydır.

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

(Bazen programcılar ölçüde temel becerilerin bu kaybı sonucu yok çerçeveler kullanmak "modası geçmiş" olarak görülüyor) buna gerekli veya uygun olmayan bir çerçeve kullanmak yaygın bir uygulama haline olmasıdır. Çerçevenin kolaylaşmasını sağlayan özellikler , temel dilin yapabilecekleri ile karıştırılıyor. Geliştiriciler, en temel görevleri yerine getirmek için çerçeveler kullanmaya başlarlar, böylece bir zamanlar ilkel bir süreç olarak kabul edilenler şimdi kendi tuhaflıkları, hataları ve bağımlılıkları olan büyük kütüphaneleri içerir. Bir zamanlar 20 satırda yapılan şey şimdi 20.000 satırlık çerçeve ekleyerek ve çerçeveyi kullanmak için 20 satır yazarak gerçekleştirilir.

Tersine, kimse tekerleği yeniden icat etmek istemez. Bazı temel, küçük ortak görevleri yerine getirmek için kod yazıyorsam, XYZ çerçevesinin peşimde olduğum tüm özellikleri ve daha fazlasını sunduğunu bildiğimde zamanımı boşa harcıyormuş gibi hissediyorum. "Çok daha fazlası" kısmı hala endişelendiriyor, ama çoğu kişi artık onu düşünmüyor bile.

Bir çerçeve kullanmanın ne zaman uygun olduğunu belirlemek için iyi bir ölçüm olmalıdır. Eşiği ne olarak görüyorsunuz , ne zaman bir çerçeve kullanacağınıza , ne zaman kullanmayacağınıza nasıl karar veriyorsunuz ?

“Bir çerçeveyi kullanmanın ne zaman uygun olduğunu belirlemek için iyi bir ölçüm olmalıdır.”

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

Hepsi ile çalıştığım gruplar aynı şeyi yapıyor - maliyet ve faydalara dair bir tahminde bulunun, en verimli rotayı seçin ve doğru olduklarını umun. Son derece bilimsel değil - bir bölüm sezgisi, üç bölüm deneyimi, bir bölüm pazarlamaya duyarlılık, bir bölüm kurnazlık ve beş bölüm rütbe görüşü.

Altyapılar sadece araçlardır. Aşırı kullanılıyorsa, bunun aşırı kullanan kişi için bir çerçevenin hatası olduğunu sanmıyorum. Eski, "eğer bir çekiçiniz varsa, her şey bir çiviye benziyor" deyişi, bilgisayarların bile çok daha önce bulunduğunu düşünmektedir.

Çok uzmanlaşmak uzun vadede gerçekten bir soruna dönüşebilir - bir geliştirici için olduğu kadar biyolojik türler için de. Uzun süreli hayatta kalabilmek için, becerilerini çeşitli alanlarda geliştirme çabası dikkatlice dengelenmelidir.

Özel sorunuza cevap vermek için bunun bir ölçü olduğunu sanmıyorum. Problem çözmeyi basitleştirirken bir çerçeve kullanmayı tercih ederim. Bir çerçeve kullanmak, 20 yerine 2 kod satırındaki bir sorunu çözmeme yardımcı olursa, açıkça kullanacağım. Ancak, 20'ye karşı 20 satırı olsa bile, bana daha iyi soyutlamalar verirse, sorun alanına daha yakın, kodun anlaşılmasını ve sürdürülmesini kolaylaştıracak bir çerçeve kullanmaya karar verebilirim.

Bence çerçeveler bazı bağlamlarda aşırı kullanılabilir, evet. Bir çerçeve sadece bir araçtır, evet. Bir çerçeve çok hızlı bir şekilde çalışan bir şey elde etmenizi sağlar ve bu yüzden mükemmel bir prototipleme aracıdır.

Hattınızın bir yerinde, uygulamanız bir miktar karmaşıklık seviyesine ulaştığında, bir çerçevedeki doğal kısıtlamalar daha da büyümeyi bastırmaya başlar, bana öyle geliyor. İşin püf noktası, böyle bir bahşiş noktasıyla ne zaman karşılaştığınızı tanımak ve daha sonra ne yapacağınıza karar vermektir.

Çoğu web uygulamasıyla çalışma eğilimindeyim ve genel olmaya çalışmama rağmen, cevabım programlama alanınız için geçerli olmayabilir .

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

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

# 1. Çerçeve zamandan ve emekten tasarruf sağlayacak mı?

Bu sorunun cevabı neredeyse her zaman evet . Özel problemleri çözmek ve bunları çok iyi çözmek için çerçeveler inşa edilir . Örneğin, EntityFramework gibi çerçeveler sizi tamamen SQL kodu yazmaktan kurtarabilir . Programlama ekibiniz SQL'de akıcı değilse, hangisi harika olabilir.

Altyapılardan herhangi biri, a) aksi takdirde karmaşık bileşenlere programcı dostu bir arabirim eklemek veya b) zaten iyi bilinen (veya kurulmuş) bileşenlere soyutlama eklemek.

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

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

# 2 Uygulamanızın ölçeği

"Yapmaya değer her şeyin abartmaya değer olduğu " söylenir , ancak genellikle durum böyle değildir. Uygulamanızın amacı "patates" yazdırmaksa, büyük boyutlu bir çerçeve uygulamak için muhtemelen hiçbir neden yoktur .

Bir uygulama geliştirirken (web, masaüstü, mobil veya akla gelebilecek herhangi bir uygulama türü olabilir) - çerçevenizin büyüklüğünün sizin (belki gelecekteki) uygulamanızı "caydırdığını" düşünüyorsanız, o zaman bu büyük Çerçevenizin yalnızca başvurunuzu şişirebileceğini belirten uyarı işareti. JQuery'yi eklerseniz, doküman hazır olduğunda sadece body-tag'inize "yüklü" bir sınıf eklemek için iyi bir anekdot olacaktır. Bunu sadece yerel JavaScript ile yapmak biraz zor olabilir , ancak başvurunuzu şişirmez.

Öte yandan, eğer bir çerçeve iç kısımda çok kirli işler yaparsa (yani veritabanı çerçeveleri), o zaman çerçeveyi yalnızca “kısmen” kullanıyor olsanız bile, bunu uygulamak uygun olabilir. İyi bir fıkra , kendi ADO.NET'inizi veya MongoDB sürücünüzü oluşturmaya çalışmak değildir , çünkü tüm kütüphaneyi kullanmanıza gerek yoktur.

Bazen çerçeveler açık kaynaklıdır (ve 'ne istersen yap' lisansı ile). Bu, bir programlama ekibinin yalnızca bir çerçevenin bölümlerini seçebileceği yeni bir olasılık açar.

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

# 3 Etki.

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

Diğer tip uygulamalarda bile, son kullanıcılar uygulama bağımlılıklarınızdan olumsuz yönde etkilenebilir. Altyapılar en azından her zaman biraz disk alanı kaplar ve bir mobil uygulama (veya bir masaüstü uygulaması) geliştiriyorsanız, bunun dikkate alınması gerekebilir.

Sunucu tarafı çerçeveler (daha da web'e özel) büyük olasılıkla son kullanıcılarınızı etkilemeyecek, ancak altyapınızı etkileyecektir . Bazı çerçeveler bağımlılıkları kendilerini web sunucusu, ya sadece hizmet veya tamamen sunucuyu yeniden başlatmak için gerektirebilir.

Bazı çerçeveler de kaynak bakımından çok ağır olabilir.

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

Her şey sadece büyük bir "değerlendirme çemberi" ve bir çerçeve uygulayıp uygulamamaya karar vermeniz için gerçek bir bilimsel yöntem yok.

Corbin March bunu çok iyi özetledi:

Hepsi ile çalıştığım gruplar aynı şeyi yapıyor - maliyet ve faydalara dair bir tahminde bulunun, en verimli rotayı seçin ve doğru olduklarını umun. Son derece bilimsel değil - bir bölüm sezgisi, üç bölüm deneyimi, bir bölüm pazarlamaya duyarlılık, bir bölüm kurnazlık ve beş bölüm rütbe görüşü.

Seçkin olmamak da önemlidir . Çerçeveler, kullanılması amaçlanan araçlardır. Her iki ucundan da insanları tanıyorum; Bir tarafta hayatı kendisi için zorlaştıran bir adam var, diğer tarafta yavaş, şişirilmiş uygulamalar yapan bir adam.

Tüm çerçevelerin kullanım durumları vardır, bu onları doğru amaçlarla uygulama meselesidir.

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

Tüm geliştiriciler X çerçevesini bilirse, çerçeveyi kullanmak için diğer tüm sebepler geçerliyse, bunun için gidin! 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 öğrenmeye zorlamak mantıklı gelmiyor.

Temelleri bilmeden yeni programcılar hakkındaki ifadenizle ilgili olarak, benden çok daha merhametlisiniz! Evet, çok yazık ama zamanımı başkasının yetersizliği hakkında endişelenerek geçirecek miyim? Nup. (Topluluğun bu yeni üyelerinin hemen sizinle çalışmadığı varsayımına dayanarak.)

Aşağıdaki koşullar geçerliyse (ve SADECE) ise bir çerçeve kullanırdım:

Çerçeve bir süre için desteklenmiş gibi görünüyor. Onları daha önce üzerimde yaşamın sonuna kadar götürdüm ve bu gerçekten sinir bozucu. Özellikle de projenize 9 ay kaldığında ve geçiş yapmak artık bir seçenek değil. Çerçeve artık Zaten 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, mantıklı gelmediği uygulamalar için işe yaraması için tuhaf şeyler yapmadılar. Genellikle MFC'yi dövmek için harcadıklarından daha fazla zaman harcıyorlardı.

Proje ekibi çerçevede çalışabilir. Bazı insanlar bir uygulamanın belirli bir çerçevede nasıl yazılması gerektiğini anlamak için zaman harcamaz ya da zamanını alamazlar ve bunun yerine çerçevenin ihtiyaç duyduğu yerine genellikle kendileri gibi yazarlar. Kod ve çerçeve arasındaki bu yanlış eşleşme genellikle herkese çok fazla zaman ve emek harcamasına neden olur.