Çerçevelerin bolluğu programcıları engelliyor mu? [kapalı]

Bugünlerde mevcut tüm çerçeveler ile ORM'ler , bağımlılık enjeksiyonu (DI), Kontrolün Tersine çevrilmesi (IoC), vb., Birçok programcının zor sorunları çözmek için gereken problem çözme becerilerini kaybettiğini veya kaybetmediğini görüyorum. Çoğu zaman, beklenmedik bir davranışın uygulamalara kaydığını ve geliştiricilerin gerçekten kazamadıklarını ve sorunları bulamadıklarını gördüm. Bana öyle geliyor ki, başlık altında neler olup bittiğine dair derin bir anlayış kayboluyor.

Beni yanlış anlama , bu çerçevelerin iyi olmadığını ve sektörü ilerletmediğini öne sürüyorum, yalnızca istenmeyen bir sonuç olarak geliştiricilerin derinlemesine anlamak için gereken bilgi ve becerileri kazanıp kazanmadığını soruyorum. sistemleri.

Kabul. Şu anda, çerçevelerle çevrelenmiş bir yazılım paketi üzerinde çalışıyorum, bu da işi anlamayı neredeyse imkansız hale getiriyor. Çerçeveler sizi yalnızca MVC'yi çözmek yerine işle ilgili sorunları çözmekten alıkoyduktan sonra, çok ileri gitti. Sizin de belirttiğiniz gibi, IMO'nun çoğu programcısı ORM ve MVC'yi çözmek için dener ve mimarlık eder / programlar ve bunun aslında yazılımın ilk başta olduğu sorunu çözmesine yardımcı olup olmadığını nadiren soruyorlar.

Evet, JSP sayfasındaki bazı ham SQL'leri görmek "hayır-hayır" dır, ancak bir saha danışmanıysanız, bu özel bir çözüme nerede uyuyor? Ve hayır, bu çerçevenin doğru olmadığı anlamına gelmez, tüm müşterilerin sayfaya küçük bir veri noktasının yansıtıldığından emin olmak için her dönüşte 20 bin dolar harcadığı anlamına gelmez.

Bu, düzenli olarak, birçok alanda ve birçok biçimde açılan bir argümandır.

Bu argümanın genel şekli:

[X: tool / technology] 'ye sahip olmak insanları [y: x]' den etkilenen fonksiyonlarda daha da kötüleştirir mi?

Örneğin:

• CAD yazılımı daha kötü mühendisler için yapar mı?
• Lisedeki hesap makineleri öğrencileri matematikte daha da kötüleştiriyor mu?
• Sosyal yazılım, insanların kişisel sosyal becerilerini engeller mi?
• Muhasebe yazılımı daha kötü muhasebeciler üretiyor mu?

Bellekten, her yerde cevap neredeyse her zaman: gerçekten değil. Her zaman [y] yaparken iyi ve kötü insanlara sahip olacaksınız ama şimdi onlar farklı bir yetenek yönünden çok kötüler.

Herhangi bir işin temellerini daha iyi anlayabilmeniz, ne yaparsanız yapın - 'düzeltici' olarak kabul edilen işlerde bile yardımcı olacaktır. Bilgi her zaman yardımcı olur.

Soyutlama, bilgisayar programlamanın temel bir konseptidir ve çerçeveler, programcıların bunu başarmasına yardımcı olur. Bu iyi birşey. Meclis dilinde karmaşık sistemler geliştirmek istediğimizden şüpheliyim! Problem gelir, bence programcılar soyutlama katmanının maskeleme hakkında ne olduğu hakkında çok az fikir sahibi olduklarında. Başka bir deyişle, doğrudan etkileşime girmese veya onunla etkileşime girmeseniz bile, kaputun altında neler olup bittiğine dair bir fikre sahip olmanız gerekir.

İlk dinamik web sitelerinden bazılarını 90'lı yılların ortalarında, C ve CGI kullanarak (web sitelerinin çoğunun hala statik HTML olduğu bir zamanda) geliştirdiğimi hatırlıyorum . Hiçbir olgun sunucu tarafı komut dosyası dili (PHP veya ASP gibi) ve çok az kitaplık yoktu, bu nedenle tüm HTTP yanıt akışını sunucuya her sayfada yazmanız gerekiyordu. Kendi kütüphanenizi yazarken GET ve POST parametrelerinin ayrıştırılması gerekiyor. Can sıkıcı, yavaş, çalışkan ve hataya açıktı. Biraz özlemiyorum!

Bununla birlikte, ASP.NET web formları gibi çerçevelerin de, web'in bütün vatansız yapısını, pek çok yeni web geliştiricisinin, başlığın altında neler olup bittiğinin çok az ipucu olduğu bir noktaya kadar soyutladığını hissediyorum. Bu, geliştiricinin HTTP düzeyinde olup bitenleri anlamadan bir "drag'n'drop" metodolojisi kullanarak bileşenleri bir araya getirdiği için düşük performans gösteren verimsiz, şişirilmiş bir kod oluşturur.

Bu yüzden, çerçevelerin üst seviye yazılımlar geliştirmek için gerekli olduğuna inanıyorum, ancak geliştiricilerin soyutlanmış olanın ne olduğu hakkında bir anlayışa sahip olmalarını şart koşmuyorlar. Evet, çerçeveler sizi aptallaştırabilir, ancak yalnızca onları anlayamazsanız.

Otomatik şanzıman veya yağmur algılamalı ön cam silecekleri bizi daha kötü sürücüler yapar mı?

Çerçevesiz kodlamanın zorunlu olarak altta yatan sistemleri daha iyi anlamalarını gerektirdiğini sanmıyorum. Bu, adayların tutarlı bir yöntemi bir araya getirebildiklerinden emin olmak için görüşmelerde basit kodlama soruları sormak zorunda oldukları işverenler tarafından kanıtlanmaktadır.

Sonuçta öğrenmek için geliştirici kalmış. İyi olanlar yapar, kötü olanlar olmaz.

Ve benzer şekilde, sadece yeteneklerini analiz etmeden orada olduğu için bir çerçeve seçmek ve artılarını / eksilerini de zayıf gelişme uygulamalarının bir işaretidir.

Bence sorun, yeni programcıların daha yüksek ve daha yüksek soyutlama seviyelerinde başlıyor olması ve bu nedenle de “başlık altındaki” şeylerin bitlerine ve baytlarına maruz kalmamasıdır. Bu yüzden, geçmiş yıllarda öğrenilen ilk şeyler olacak gerçekten temel kodlama temellerinden bazılarını öğrenmiyorlar.

Burada her seferinde kafamı sallıyorum, belli ki yeni bir programcı biraz veri depolamak hakkında bir şeyler soruyor, ve herkes derhal bir ORM aracı kullanmalarını söylüyor . Hayır, hayır, hayır, hayır, hayır ... önce kendi başlarına nasıl yapacaklarını öğrenmeleri gerekir.

Belki de "aptallığın" dağılımı gerçekten değişmedi ve biz bunun yerine geliştiricilerin kendilerini ayağından vurmaları için daha büyük ve daha karmaşık yöntemler kullanıyoruz.

Programcıları saran çerçeveler değil. Aptal programcılar çerçeveleri kullanıp kullanmamaları aptalca olacaktır.

Bir araç ya da çerçevenin düzene koymanıza yardımcı olduğu düşük seviyeli çalışmayı anlamanız, araç ve çerçeveler konusunda daha iyi bir kullanıcı olmanıza neden olduğu için kesinlikle doğrudur. Ayrıca sorunları daha kolay hata ayıklayabilir ve araçların işlevsellikteki kaçınılmaz boşluklarını çözebilirsiniz.

Örneğin, Lex ve yacc gibi ayrıştırıcı üreteçlerini kullanmayı öğrenmeden önce, Kolej'deki bir LR ayrıştırıcısını kodladığımız kolejdeki Compiler Design'da ders aldım. Çok eğiticiydi ve o zamandan beri kullandığım tüm programlama dilleri için daha iyi bir anlayışa ve takdirime sahip oldum.

Ancak, her programcının yüksek düzeyde çalışmasına izin verilmeden önce, Bay Miyagi'nin arabasını yıllarca ve yıllarca cilalamaktan kaçınması gerektiğini söylemiyorum. Belirli bir dilde veya araçta kodlamanın mekanik çalışmasına değil, yazılımın ne yapması gerektiğine karar veren birçok programlama işi entelektüeldir .

Bu entelektüel çalışma, zekâ ve sersemliğin daha da önemli olduğu yerdir.

James Larus'un mükemmel "Harcama Moore'un Kar Payını " ndan alıntı (vurgulandı):

Otuz yıl önce, Bill Gates Altair Basic’te 5 byte hafıza tasarrufu isteğini “HAZIR” olarak “Tamam” olarak değiştirdi. Günümüzde, geliştiricilerin programlarının bu ayrıntı seviyesinden haberdar olmaları, bu konuda endişelenmelerine rağmen ve haklı olarak, bu büyüklükteki bir değişiklik bugün farkedilmez olduğu için farkında olmayacaklar ... Bugünün sistemlerini üretmemize imkan yoktu. zanaatkâr kullanarak, 4K hafızalı makinelerde (gerekli) mümkün olan el yapımı uygulamalar.

Sanırım, çerçevelerin zor sorunları çözmek için gerekli becerilerden kaçınmanıza ya da derinlemesine anlayıştan kaçmanıza izin verdiğini söylemek yanıltıcı olabilir. Bunun yerine, günümüzün karmaşık sistemlerini kurabilmemizin tek nedeni (karmaşıklığı zor meseleler yaratabilecek ve derinlemesine anlamaya meydan okuyabilecektir), çerçevelere (ve üst düzey OO çöp toplayan dillere ve bağlama duyarlı dillere sahip IDE'lere ve on-the-fly sözdizimi kontrolü ve diğer tüm yazılım geliştirme ilerlemeleri, bazen programcıları aptallaştırmakla eleştirilir.

Altyapılar harika. Ama kaputun altında ne olduğunu bilmek zorundasın. Öyleyse sorun, programcıların temel sistem hakkında yeterli bilgiye sahip olmadan, çerçevelere çok fazla güvenmeleridir.

Biraz modası geçmiş bir örnek MFC'dir. : bir programcı, Windows API yerine MFC kullanarak çok fazla zaman kazandırabilir, ancak API bilgisi olmadan (ham API ile gerçek bir çalışma geçmişine sahip olmak anlamına gelir), sık sık sıkışmış olurlar. . Neredeyse hiç olmadı, çünkü tipik bir MFC programcısı Windows API bilgisine sahipti.

Ancak, .NET üzerindeki Windows Formları ile daha iyi bir kapsülleme ve daha iyi nesne modeli sayesinde sayesinde, bir programcı, başka bir Windows API paketleyicisini kullandığını neredeyse hiç görmezden gelebilir. Dolayısıyla sıkışıp kalma şansı daha azdır, ancak bu gerçekleştiğinde, acı verebilir.

Ne yazık ki, piyasaya sürülme süresi her zaman kısalır ve projeler gittikçe karmaşıklaşır, bu nedenle programcıların derine gidecek zamanları yoktur. Bu, yazılım endüstrisinin üzücü hali ...

Olması gerektiği yere akıllıları koyar. Bir topun binanın tepesinden düşmesini sağlayan bir mekanizma oluşturmak için kuantum mekaniğini ve Newton fiziğini anlamak gerekmez. Yazılımda Her yeni katman gereken son üzerine inşa ve klişe çıkarmak kullanışlı uygulamaların inşaat.

Çerçevenin arkasındaki "şeyleri" bilmek veya bilmek isteyenler kanca veya sahtekarlarla çalışacak ve araştıracaklardır.

Kesinlikle değil. Altyapılar, özünde, bir alt program kütüphanesinin ve bir şablonun, denenmiş ve gerçek iki programcı aracının birleşimidir. Zavallı bir işçi aletlerini suçluyor.

... ve çerçeveleri kullanan ve suçlayan birçok fakir işçi var.

Yazılım oluştururken, çerçeveler zaman kazandırır. Yazılım inşa etmeyi öğrenirken, çerçeveler anlama yoluna gider.

Bence sorun temelde fazla güçlenen bilgisayarlardan biri. Çoğu programcı için artık “temellere inmek” için mantıklı bir neden yoktur. Aynı şeyleri yapmak sadece daha fazla zaman alır ve çalışma zamanında anlamlı bir fark yoktur. Bunu çözmenin tek yolu, yapay kısıtlamaları, js1k gibi yarışmaların yapmasını sağlamaktır.

Belki de okullar, güçlü alan ve zaman kısıtlamaları altında programlar oluşturmanız gereken özel bir konuya "optimize edilmiş tasarım" vermeli midir?

Hayır, çerçeveleri öğrenmek bir programcının becerilerini geliştirir. Çerçeve, bir programlama dilinin uzantısıdır. Bazı diller zaten çerçeve tabanlı. Hem PHP hem de Java ile çalışıyorum. PHP, şablon motoru gibi bir çerçeveye ihtiyaç duyar (bazen). Java bir çerçeveye ihtiyaç duymaz (çoğu zaman), zaten birçok yöntem ve kütüphaneye sahiptir.

Çoğu Altyapı, programcıların tekrar tekrar kullandığı fonksiyonlara sahip olacaktır.

Görünüşe göre şeytanın avukatını burada oynamak için, çerçevelerin ("iyi" olanlar, yine de) aslında bir programcının eğitimini ilerletmek için uzun bir yol alabileceğini düşünüyorum . İyi tasarlanmış bir çerçeve birçok problemi çözecektir ve çerçeveyi kullanarak programcı hangi problemlerin çözüldüğünü ve nasıl olduğunu anlayabilir. Aklımda, bir çerçeve en iyi uygulamaların programlanmasının bir kristalleşmesidir (/ olması gerekir) ve bir programcıya örnek olarak öğretebilir.