Oluşturduğunuz programın nasıl çalıştığını bilmeden yaşamak uygun mudur?

Yani, sıkışıp kaldığınızda ve bunu nasıl çözeceğinizi bilmediğinizde problemleri çözebilecek gerçekten kullanışlı kütüphaneler var ... Örneğin, kullandığınız programlama dili bilginizle ... Örneğin, JavaScript için C ++ veya JQuery veya Spring için Java ... Saniyeler içinde problemleri çözüyorlar ve gerçekten nasıl yaptıklarıyla ilgilenmiyorsunuz (programladığınız dilde yazılmış olmalarına rağmen) ... Bu yüzden merak etmiyorken libs kullanmakta yalnızım sorunlarım için sıfırdan çözüm yazabiliyor mu yoksa standart bir uygulama mı?

Sorunları kendiniz nasıl çözeceğinizi ve bunun yerine kütüphaneleri nasıl kullanacağınızı anlamamak uygun mudur?

Genel olarak, hayır, değil.

Bir kütüphane, bir sorunun nasıl çözüleceğini bulma ve ardından çözümde hata ayıklama ve bakımını yapma (zor!) Çalışmalarını kurtarabilir. Ancak, onu kullanacaksanız, nasıl çalıştığını anladığınızdan emin olmanız gerekir - çözüm neden sorunu gerçekten çözer. Eğer bir tamirci olarak çalışıyorsanız, araba, motor ve araba motoru yapan robotları nasıl icat edeceğinizi bilmek zorunda değilsiniz - ancak parçaların nasıl çalıştığını, hepsinin ne yaptığını ve nasıl çalıştığını daha iyi anlarsınız birbirine uygun!

Birçok insanın çok uzmanlaştığını görmenizin nedeni budur - çoğu zaman sadece tek bir dil, tek bir platform, tek bir çerçeve ve bir dizi kütüphane ile çalışmayı öğrenmek.

Bununla birlikte, öğrenecek çok zamanınız olacak . Bazen kısayollar almak zorundasınız - onları alın, ancak bunların kısayol olduğunu bilin. Belki sadece zamanınız olsaydı, anlayabileceğinizi bilecek bir kütüphane hakkında yeterince okudunuz. Ya da sadece gerçekten aramanız gereken iki işlevi anlarsınız ve sadece aramaları doğru yapmak için yeterlidir. Bu bir fiyatla gelecek bir kısayol - genellikle daha sonra, birisi (belki daha yaşlı ve daha deneyimli bir kişi) kodu düzeltmek zorunda kaldığında.

Bir kez computerworld.com.au istedi Bjarne Stroustrup "yukarı ve gelecek programcılar için herhangi bir tavsiye var mı?"
Ve cevapladı"Bilgisayar biliminin temellerini bilin: algoritmalar, makine mimarileri, veri yapıları, vb. Teknikleri uygulamadan uygulamaya körü körüne kopyalamayın. Ne yaptığınızı, çalıştığını ve neden çalıştığını bilin. endüstrinin beş yıl içinde ne olacağını ya da o zaman ne yapacağınızı bilirsiniz, bu yüzden genel ve kullanışlı becerilerden oluşan bir portföy toplayın Daha iyi, daha ilkeli kod yazmaya çalışın. düşük seviyeli "hackleme" etkinliğinden daha az (programlama sadece bir zanaat değil, aynı zamanda bir zanaattır) Alandaki klasiklerden ve daha gelişmiş ders kitaplarından öğrenin; kolayca sindirilen "nasıl yapılır" dan memnun kalmayın kılavuzları ve çevrimiçi dokümantasyon - sığ. "
Umarım bir şey için neyin gerekli olduğu konusunda şüphelerinizi netleştirir.Gerçek Programcı ve herkesin biri olması için gerekli olan şey.

Evet - ve hepimiz yapıyoruz!

Örneğin, Mac ile ilgili bazı grafik kodlarında düzelttiğim çok basit bir hatayı ele alalım. Hatanın etrafındaki kod birkaç adımdan oluşuyordu:

1. İlk olarak, bir Objective C yöntemi malloc () kullanarak bir piksel tamponu tahsis eder ve bunu Objective C nesnesine ekler.
2. Daha sonra bir şey olur ve bir C rutini Objective C nesnesine bir mesaj gönderir ve piksel arabelleğini alır.
3. C yordamı piksel arabellek içeriğini jpeglib kullanarak sıkıştırır ve TCP / IP bağlantısı üzerinden gönderir.

Orada çok şey oluyor! İşte birkaç şey:

• Belleğin fiziksel olarak bitişik ve doğrusal olarak adreslenebileceğini varsayan malloc () 'u uygulamak için dinamik bir bellek ayırıcısı.
• Hem parçalanmış fiziksel RAM'i hem de disk alanını (RAM'den farklı bir fiziksel cihaz) eşleştirmek için temeldeki Darwin çekirdek sanal bellek sistemi, fiziksel bellek bitişik ve doğrusal olarak adreslenebilir RAM gibi dinamik bellek ayırıcıya görünen bir şeye eşler.
• Amaç C'nin nesne sistemi
• Mac OS çalışma zamanı mesajlaşma sistemi ve Objective C nesneleriyle etkileşim şekli
• JPEGglib kütüphanesinin ayrı bir kosinüs dönüşüm algoritması kullanan JPEG kayıplı raster görüntü sıkıştırma standardını uygulaması
• Çeşitli TCP ve IP protokolü uygulamalarını çağıran ve daha sonra OS çekirdeğine çağrı yapan verileri göndermek için kullanıcı alanı ağ rutini. Daha sonra ağınız için neleri açtığınıza bağlı olarak, Ethernet portu, wi-fi yongası veya daha alışılmadık bir USB veya Firewire sürücüsü için bir sürücü çağırabilir.

Tüm bu şeylerin gerçekte nasıl uygulandığının tüm ayrıntılarını anlıyor musunuz? Emin değilim! Gezegende çok fazla insan olduğundan şüpheliyim - belki de hiç yok. Bu yüzden endişelenmiyorum.

Ancak meraklı olmak ve en azından kullandığınız kütüphaneler ve araçlar hakkında biraz bilgi edinmek iyi bir şeydir. Programlamaya ilk başladığımda, derleyicilerin ve işletim sistemlerinin sihir olamayacağını biliyordum, ama bana öyle geliyorlardı. Bu şeyler hakkındaki merakımı şımartarak, çok şey öğrendim ve şimdiye kadar harika bir kariyerim oldu.

Kütüphaneleri kullanmamızın temel sebebinin her zaman “tekerleği yeniden icat etmemek” ve çözmek istedikleri sorunları soyutlamak olduğunu görüyorum. Sorunları kendiniz çözmeye çalışabilirsiniz, ancak bu daha uzun zaman alacaktır.

Ancak sorunun kütüphane tarafından nasıl çözüldüğünü de bilmemiz veya tahmin etmemiz gerektiğini hissediyorum. Bu genellikle kütüphanenin kullanıcı belgelerinde belgelenir ve açık kaynak kodlu bir yazılımla, koda her zaman kendiniz bakabilirsiniz.

Ayrıca genellikle zor kısımları soyutlayarak sorunları çözüyoruz, o zaman neden iyi değil?

Kütüphaneler ortak sorunlara çözümler sunmak için oradalar. Çözmekte olduğunuz sorunu çözüp çözmediklerine karar vermelisiniz. Bir sorunun nasıl çözüleceğini bilmemek yerine DEĞİLDİR. Örneğin, uygulamanızın bir karma tablo gerektirdiğini varsayalım, bir karma tablonun hangi sorunu çözdüğünü anlamak için yeterli bilgiye sahip olmalısınız. Uygulamanızda çalışıp çalışmayacağına karar vermek için kullandığınız kütüphanenin performansını değerlendirebilmeniz gerekir. Yetersiz teknik bilgiyi kapsamak için bir kütüphane kullanmak doğru kullanım örneği değildir. Bir kütüphane kullanma kararı, kütüphaneyi kullanmanın gelişmeyi hızlandıracağı ve test edilmiş ve güvenilir bir çözüm sunup sunmayacağı etrafında dönmelidir. Bir kütüphane kullanma kararı, programcıların belirli bir sorunu çözememesi etrafında dönmemelidir.

Gerçekten size kalmış .

Birlikte çalıştığınız araçları en iyi anlarsanız onlardan daha iyi yararlanabilirsiniz.

Örneğin, nadiren jQuery kullanıyorum, ancak bundan ne faydalanacağımı ve Mootools gibi diğer çerçevelerle nasıl bir arada bulunabileceğimi bilmem gerektiğinde.

Ayrıca, yakında UDK ile gamedev'e maceraya gireceğim ve eminim, bu konuda ne kadar çok anladımsa, kötü niyetime daha fazla bükebileceğimden emin olabilirim, ama sadece beyinsiz eğiticileri de takip edebilirim. İlkini seçiyorum, sadece biraz daha fazla zaman ve beyin döngüsü ve daha iyi ve daha kolay sonuçlar alacağım .

Aleminizi ve sürecin bir parçası olduğunuzu bilmek önemlidir.

Örneğin, bir görüntü işleme kütüphanesi kullandığınızı varsayalım. Gauss bulanıklıkları, dönüşümleri ve renk uzayları hakkında gerçekten her şeyi bilmeniz mi gerekiyor? Hayır. Ama öncelikle kütüphaneyi neden kullandığınızı bilmeniz gerekiyor . Ya da bir çerçevenin sıralama işlevi. Kullanılan gerçek sıralama algoritmasını bilmeniz mi gerekiyor? Çoğu durumda, hayır. Ancak neden sıralanan verilere ihtiyacınız olduğunu bilmeniz gerekir.

Eğer bir derleyici yazıyorsanız Öte yandan, sen de iyi bilirsiniz lanetlemek nasıl bir derleyici çalışır, şu beri senin parçası sürecinde.

JQuery gibi bazı çerçeveler çok soyutlaşıyor. Tam olarak nasıl çalıştıklarını bilmeniz mi gerekiyor ? Hayır. Ancak, kod yazarken kütüphanenin ne yaptığına dair güçlü ve temel bir anlayışa sahip olmak sizin için çok yararlı olacaktır çünkü çerçevenin neden bu şekilde yapıldığını daha iyi anlayacak ve tam potansiyeline kullanabileceksiniz. .

Deneyimlerime göre: Kütüphane bağımlılığını ortadan kaldıramayacağınız için, siz ve ekibiniz sorunu çözmek için yeterli bilgiye sahip olmalısınız.

Programcılar olarak çok az zamanımız var, bu yüzden en yüksek önceliğe sahip olanı seçmeliyiz. Sorun mümkün olduğunca hızlı ve yumuşak bir şekilde çözülmelidir. Sadece bu sebep, "her şeyin işleyişini öğrenmeyi" biraz gereksiz kılar.

Buraya eklemek istediğim şeyler "bağımlılık". Bir topluluk olarak hepimiz başkalarına bağımlıyız. Uygulamamızı oluşturmak için Devler üzerinde duruyoruz: Java, .NET, API ... Ve Devler'e çalışmaları hakkında güveniyoruz; çünkü pek çok insan için çalışıyor. Çerçeve veya API ile ilgili bir sorununuz varsa, başkalarının bir yerlerde bununla karşılaşma şansı vardır ve bir çözüm / çözüm vardır.

Buradaki tek sorun: belki, bir yerlerde, kısıtlı bir kriterde Devler çöktü. Örneğin, flaş bazı işletim sistemlerinde desteklenmez ve onsuz yapamayacağımız birçok şey vardır. Bu olasılık sıfırdan fazladır, ancak bu durumda yapabileceğimiz çok az şeyimiz var. Sadece bu durumlarda, "davlumbazların arkasında ne var" hakkındaki bilgi, sorunun gerçekten nerede olduğunu ve büyük bir çözüm oluşturabileceğini gösterdiğinden faydalı olur; ama yatırım yaptığımız zamanın gerçekten buna değer olduğundan emin değilim.

Bu olasılığın üstesinden gelmek için bir çözüm olduğunu düşünüyorum: çünkü programcıların çoğu bir kütüphanenin "yüzey işleyişini" kolayca yakalayabilir ve sadece bazen gerçekten çok iyi anlayan birine ihtiyacımız vardır: bunu yapmak için takımı bölelim. Her birinin dahil olduğu yaklaşık 1,2 yararlı kütüphane / araç / "beceri seti" deneyimlediği bir ekip oluşturmaya çalışmak : biri jQuery hakkında iyi bir deneyime sahiptir, biri veritabanı ile uzmanlaşmıştır, ... Bu riskleri en aza indirmeye çok yardımcı olacaktır.

Başka bir bakış açısı güvenliktir. Tam iç işleyişini bilmediğiniz bir kütüphane kullandığınızda, tam olarak neler olduğu hakkında varsayımlar yaparsınız. Her başarısız varsayım, kötü niyetli bir saldırgan için bir saldırı vektörü açabilir.

Bir Quicksort'u ararken, en kötü durum davranışının farkında olmalısınız. Başka bir saldırgan en kötü durum verilerini enjekte edebilir ve bir DoS gerçekleştirebilir.

Bir sıkıştırma kütüphanesini çağırırken, bazı veriler daha az bayta sıkıştırıldığında, orijinalinden daha fazla bayta "sıkışan" veriler olması gerektiğini bilmelisiniz. Bu nedenle varsayımınız, çıktı tamponunun yalnızca [daha az bayta] sıkıştırdığı için giriş verilerinin boyutuna ihtiyaç duyması durumunda, bir tampon taşması olur.

Varsayımlarınızı doğrulayabilmek için, yapacağınız şeyler hakkında yeterli temelleri bilmelisiniz. Başka bir şekilde kütüphane buna dikkat etmelidir, örneğin sağlanan çıktı tamponu yeterince büyük olmadığında bir istisna atmak.

Kullandığınızdan emin olduğunuz sürece kullandığınız her şeyi anlamamakta bir sakınca yoktur. Lib'deki bir böcek tarafından ısırıldıktan sonra, nasıl çalıştığını, neden çalıştığını ve neden çalışmadığını görmek için zaman var. Tabii ki her zaman memnuniyetle karşılanıyorsunuz ve ihtiyacınız olmasa bile kaputun altına bakmanız teşvik ediliyor.

Programlamadaki zor şeylerden biri, tüm sorunları kendiniz çözmenin cazibesini aşmaktır.

Tamam ama tehlikeli. Genel bir uygulama olarak, ne geliştirdiğini bilmek gerekir.

Tür...

Kütüphane veya çerçevenin ne yapmaya çalıştığının genel özünü elde ettiğiniz sürece sorun değil. İç kısımlara gelince ve o zaman değil, hayır. Pragmatik yaklaşımı benimseyin. İşe yarıyor, yapmasını istediğim şeyi yaptı, tamam.

Mesele, küçük detaylarla boğuşmak ve sadece lanet fikrinizi uygulamaktır.

Sanýrým, mesele, her ţeyi bilemeyeceksin. Cidden, her şeyi araştırmak için çok az zamanınız var, çünkü sizi bu fikrinizi yaratma ana hedefinizden uzaklaştırır. Belki yavaş yavaş, haftasonu konu hakkında bir bölüm okumak için biraz boş zaman ayarlayabilirsiniz.

Ama boş vaktiniz olmadığı sürece her şeyi anlamaya çalışmayın ... Şuna bir bak. Programlama dillerinin nedeni bizi montaj kodu yapmaktan korumak, montaj kodunun nedeni bizi 1 ve 0 yapmaktan korumaktır. Arkasındaki mekanizmanın her ince ayrıntısını bilmeniz gerektiğini düşünmüyorum, ama sadece bunun genel özünü bilin. Bir çöp toplayıcı gibi, işaretçilerimle / hafızamla ilgileneceğini biliyorum, ne kadar sihirli bir algoritma kullandığını umursamıyorum, sadece çalıştığını biliyorum (ihtiyacım olan şey için) ve başka bir şey yapmıyor. Belki de dođrusu ama meh. Tabii ki onunla uğraşmak zorunda olduğunuz alanda değilseniz. O zaman bu soruyu sormak istemezsiniz çünkü bu işinizin bir parçası haha.