it-swarm.dev

Tekerleği yeniden keşfetmek gerçekten o kadar kötü mü?

Tekerleği yeniden icat etmenin programdaki yaygın bilgisi kötü veya kötü .

Ama neden böyle?

İyi olduğunu söylemiyorum. Yanlış olduğuna inanıyorum. Ancak, bir keresinde, birisi yanlış bir şey yapıyorsa (programlama akıllıca) neden yanlış olduğunu açıklayan, yapamıyorsanız, belki de kendinize gerçekten yanlış olup olmadığını sormanız gerektiğini söyleyen bir makaleyi okudum.

Bu beni bu soruya götürüyor:

Birisi daha önce dil/çerçeve içine yerleştirilmiş bir şey kendi yöntemini inşa ederek tekerleği açıkça yeniden icat ettiğini görürsem. İlk olarak, argümanlar uğruna, yöntemlerinin yerleşik yöntem kadar verimli olduğunu varsayalım. Ayrıca yerleşik yöntemin farkında olan geliştirici kendi yöntemini tercih ediyor.

Yapılmış olanı neden kendi başına kullanmalı?

104
JD Isaacks

Bir keresinde StackOverflow'da yayınladığım gibi, tekerleği yeniden icat etmek genellikle çok iyi bir seçim, yaygın inanışın aksine. Ana avantajı, tam kontrol genellikle gerekli olan yazılım üzerinde. Tam bir tartışma için orijinal yazıma bakın .

73
Dimitri C.

Bağlı olmak..

Her şeyde olduğu gibi, bağlamla ilgili:

Ne zaman iyi:

  • Çerçeve veya kitaplık çok ağır ve yalnızca sınırlı işlevselliğe ihtiyacınız var. İhtiyacınıza uygun kendi son derece hafif sürümünüzü yuvarlamak daha iyi bir yaklaşımdır.
  • Karmaşık bir şeyi anlamak ve öğrenmek istediğinizde, kendi haddelemeniz mantıklıdır.
  • Sunabileceğiniz farklı bir şey var, başkalarının uygulamalarında olmayan bir şey var. Yeni bir bükülme, yeni özellik vb.

Ne zaman kötü:

  • İşlevsellik halihazırda mevcuttur ve kararlı ve iyi bilinmektedir (popüler).
  • Sürümünüz yeni bir şey eklemiyor.
  • Sürümünüz hatalar veya kısıtlamalar getiriyor (örneğin sürümünüz iş parçacığı için güvenli değil).
  • Sürümünüzde özellik eksik.
  • Sürümünüzde daha kötü belgeler var.
  • Sürümünüz, değiştirdiklerine kıyasla birim testlerinden yoksun.
83
Darknight

Sanırım tekerleği bilerek yeniden icat eden "kendi yöntemini tercih ettiği için" durumu oldukça nadir. Çoğunlukla cehaletten, bazen de inatçılıktan yapılır.

Hepsi bu kadar kötü mü? Evet. Neden? Çünkü mevcut tekerlek büyük olasılıkla zaman içinde üretilmiştir ve zaten birçok durumda ve birçok farklı veri türüne karşı test edilmiştir. Mevcut tekerleğin geliştirici (ler) i, reventörün henüz hayal bile edemediği Edge vakaları ve zorluklarıyla zaten karşılaştı.

56
Dan Ray

Kare tekerlekler yeniden keşfedilmelidir. Emen çabalar tekrarlanmalıdır. Belki de yöntem için bir dokümantasyon eksikliği vardır ve diğer programcı anlamaya çalışmak yerine sadece kendi yazmayı daha kolay hisseder. Belki de yöntemin çağrılması gariptir ve programlama dilinin deyimine uymaz.

Sadece ona eksikliğin ne olduğunu sor.

22
user8865

Genel olarak, kullandığım dilin standart kütüphanesinde arzu ettiğim işlevsellik veya ona yaklaşan bir şey varsa tekerleği yeniden icat etmekten kaçınırım.

Ancak, üçüncü taraf kütüphaneleri birleştirmem gerekirse, kütüphanenin ne kadar yaygın ve saygın olduğuna bağlı olarak bir karar çağrısı. Yani, Boost veya Bob'un Kick-ass String-Parsing Tools 1.0'dan mı bahsediyoruz?

Kütüphane genel olarak iyi biliniyor ve sektör genelinde saygın olsa da, yine de üçüncü taraf bağımlılığı . Programcılar genellikle kodların yeniden kullanımının erdemlerine büyük önem verirken, genellikle bağımlılık tehlikesi üzerinde dururlar. Çok fazla üçüncü taraf bağımlılığı olan bir projenin, yavaş yavaş bir bakım kabusu haline geldiğinden uzun vadede dağılması muhtemeldir.

Dolayısıyla mevcut koddan yararlanmak iyi - ama bağımlılıklar kötü . Ne yazık ki, bu iki ifade birbiriyle çelişiyor, bu yüzden hile doğru dengeyi bulmaya çalışıyor. Bu nedenle kabul edilebilir bağımlılıkları tanımlamanız gerekir. Dediğim gibi, dilin Standart Kütüphanesi'ndeki herhangi bir şey büyük olasılıkla kabul edilebilir bir bağımlılıktır. Oradan devam ederken, endüstri genelinde oldukça saygın olan kütüphaneler de genel olarak kabul edilebilir (C++ için Boost veya Javascript için jQuery gibi) - ancak yine de daha az Standart Kütüphane'den istenir, çünkü yaparlar standart kütüphanelerden daha az kararlı olma eğilimindedirler.

Nispeten bilinmeyen kütüphanelere gelince, (örneğin SourceForge'a en son yükleme) bunlar son derece riskli bağımlılıklardır ve bunları kendiniz korumak için kaynak koduna yeterince aşina değilseniz, genellikle üretim kodunda bunlardan kaçınmanızı öneririm.

Yani bu tamamen dengeleyici bir hareket. Ama mesele şu ki, körü körüne "Kodun tekrar kullanımı iyi! Tekerleği kötü yeniden icat etmek!" tehlikeli bir tutumdur. Üçüncü taraf kodundan yararlanmanın yararları bağımlılık getirmenin dezavantajlarına göre değerlendirilmelidir.

17
Charles Salvia

İnsanlar tekerlekleri yeniden icat etmeselerdi, dünya bunlarla doluydu. enter image description here

İşte işyerimden bir diyalog:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

İki seçenek vardır: ya tekerleği yeniden icat OR Colorama'yı kullanın.

Colorama'yı kullanma

  • Çalıştırmak için belki biraz daha hızlı
  • Önemsiz bir şeye üçüncü taraf bağımlılığı ekleme
  • Colorama'yı kullanmadan önceki kadar aptal olmaya devam ediyorsun

Tekerleği yeniden icat etmek

  • Bazı programların nasıl renk gösterebildiğini anlıyorsunuz
  • Herhangi bir terminalde renklendirmek için özel karakterlerin kullanılabileceğini öğrenirsiniz
  • İleride kullanabileceğiniz herhangi bir programlama dilinde renklendirebilirsiniz
  • Projenizin kırılma olasılığı daha az

Gördüğünüz gibi, hepsi bağlama bağlı. Tekerleği yeniden icat etmek çok sık yaptığım bir şey çünkü kendim için düşünüp düşünmek ve benim için düşünen diğer insanlara güvenmek istemiyorum. Ancak bir son tarihte çalışıyorsanız veya uygulamaya çalıştığınız şey çok büyükse ve zaten varsa, orada olanı kullanmaktan daha iyi olursunuz.

14
Pithikos

Tekerleği yeniden icat etmenin yararlı bir nedeni öğrenme amaçlıdır - ancak kendi zamanında yapmanızı tavsiye ederim. Daha önceden hazır çözümler üretildikçe ve daha fazla soyutlama düzeyi sağlandıkça, çok daha üretken hale geliriz. Tekrar tekrar yapılan genel şeyler yerine iş sorununa odaklanabiliriz. AMA, bu nedenle, bir çözümü kendi başınıza yeniden uygulamaya çalışarak becerilerinizi keskinleştirebilir ve çok şey öğrenebilirsiniz. Sadece üretim kullanımı için değil.

Başka bir şey - endişe, bir şirketin kaybolabilecek bir üçüncü taraf kütüphanesine bağımlılık ise, kaynak kodunu alma seçeneğinin veya en azından orada geri dönmek için en az birkaç seçenek olduğundan emin olun.

Bu arada, kendiniz uygulamayı seçerseniz, bunu şifreleme veya güvenlikle ilgili diğer işlevler için yapmaktan kaçının. Bunun için kurulmuş (ve tam olarak test edilmiş) araçlar mevcuttur ve bu gün ve yaşta, kendinize sarılmak için çok risklidir. Asla buna değmez ve bunu yapan takımları hala duymak korkutucu.

13
Mark Freedman

İki tür verimlilik vardır - işleme/hız (yani ne kadar hızlı yürütülür) ve neredeyse kesinlikle yapmayacağı hız ve geliştirme hızı. Bu birinci neden - mevcut çözümlerin mevcut olduğu herhangi bir makul karmaşıklık problemi için, mevcut bir kütüphaneyi araştırmak ve uygulamak kendi kodunuzu yazmaktan daha hızlı olacaktır.

İkinci neden, mevcut kütüphanenin (olgun olduğu varsayılarak) test edildiğini ve çalıştığı kanıtlanmıştır - muhtemelen bir geliştiriciden çok daha geniş bir senaryo aralığında ve bir test ekibi yeni bir rutin aracılığıyla yazdı ve bu sıfır çaba ile geliyor.

Üçüncüsü, desteklemesi çok daha kolay. Sadece başkası destekliyor ve geliştiriyor (kütüphaneyi/bileşeni kim yazıyorsa), aynı zamanda diğer geliştiricilerin buna aşina olması ve onu anlayabilmesi ve sürdürmesi daha olasıdır. kod devam ediyor, bunların tümü devam eden maliyetleri en aza indirir.

Ve tüm bunlar işlevsel denkliği varsayar, bu normalde durum böyle değildir. Çoğu zaman kütüphaneler, yararlı bulacağınız, ancak binayı hiçbir zaman haklı çıkaramayacak, hepsi birdenbire ücretsiz olarak kullanılabilecek işlevler sunar.

Kendinizi - büyük ölçüde yerleşik işlevin yapamayacağı bir şey yapmak istediğiniz yerde ve bunu yaparak kazanılacak gerçek bir avantajın olduğu veya hazır seçeneklerin olgun olmadığı yerlerde - nedenleri vardır. birçok geliştiricinin inandığınızdan daha az yaygındır.

Ayrıca neden daha önce çözülmüş problemleri çözmek için zaman harcamak istesin ki? Evet, öğrenmek için harika bir yol ama bunu üretim kodu için doğru çözüm pahasına yapmamalısınız.

9
Jon Hopkins

Tabii ki çarkı bir kapris üzerinde yeniden icat etmek, cehalet ve kibirden kurtulmak kötü bir şey olabilir, ancak IMHO sarkaç çok uzağa sallandı. Tam olarak ne istediğinizi ve daha fazlası yok yapan bir tekerleğe sahip olmanın muazzam bir avantajı var.

Genellikle mevcut bir tekerleğe baktığımda, gerekenden çok daha fazlasını yapar, iç platform etkisi, muzdariptir ve bu nedenle gereksiz yere karmaşıktır veya yaptığım bazı önemli özelliklerden yoksundur ihtiyaç var ve zaten orada olanların üstüne uygulamak zor olurdu.

Dahası, mevcut tekerlekleri kullanmak, projeme genellikle istemediğim kısıtlamalar ekler. Örneğin:

  • Mevcut tekerlek, aksi takdirde kullanmayı tercih ettiğimden farklı bir dil ve/veya programlama stili gerektiriyor.
  • Mevcut tekerlek yalnızca bir dilin eski sürümüyle çalışır (örneğin, Python 3 yerine Python 2).
  • Verimlilik, esneklik ve basitlik arasında dengesizlikler olduğunda, mevcut tekerlek kullanım durumum için en düşük seçimleri yapar. (Bu durumlarda başlangıçta yazdığım kütüphanelerden işlevselliği bile yeniden keşfettiğim biliniyor. Genellikle bunun nedeni, şu anda spesifikasyonumda çok hızlı bir şeye ihtiyaç duyduğumda, fonksiyonun kütüphane versiyonunu genel ve makul verimli olacak şekilde yazdım. durum.)
  • Mevcut tekerlek, yeni kod durumunda tamamen işe yaramayan tonlarca eski hammaddeye sahip, ancak yine de hayatı zorlaştırıyor (örneğin, kullandığım için crappy konteyner sınıflarını kullanmaya zorlayan bir Java kütüphanesi jeneriklerden önce, vb.).
  • Mevcut tekerleğin sorunu modelleme şekli, benim kullanım durumum için uygun olandan tamamen farklı. (Örneğin, düğüm nesneleri ve referansları tarafından temsil edilen yönlendirilmiş bir grafiğe sahip olmak benim için uygun olabilir, ancak mevcut tekerlek bir bitişiklik matrisi kullanır veya tam tersi. Belki de verilerimi sütun ana düzenine yerleştirmek benim için uygundur, ancak mevcut tekerlek, ana hat üzerinde ısrar ediyor veya tam tersi.)
  • Kütüphane, tek ihtiyacım olan özelliklerinin küçük bir alt kümesi olduğunda, kodumu dağıtmak istediğim her yerde kalkmak ve çalıştırmak için büyük bir güçlük olacak büyük, kırılgan bir bağımlılık ekler. Öte yandan, bu durumda bazen istediğim özelliği yeni, daha küçük bir kütüphaneye çıkarırım veya kütüphane açık kaynaksa ve kod tabanı bunu yeterince basit hale getirirse kopyala/yapıştır. (Bunu sadece diğer insanların değil, kendim yazdığım nispeten büyük kütüphanelerle bile yaptım.)
  • Mevcut tekerlek kullanım durumum için hem rahatsızlık verici hem de önemsiz bazı standartlarla bilgiçlikle uyumlu olmaya çalışır.
9
dsimcha

Genellikle kendimi kullanıyorum çünkü önceden var olanı keşfetmeden önce inşa ettim ve her örneği bulup değiştirmek için çok tembelim. Ayrıca, önceden var olanı anlayamayabilirken kendi yöntemimi tam olarak anlıyorum. Ve son olarak, önceden var olanı tam olarak anlamadığım için, şimdiki zamanımın yaptığı her şeyi kesinlikle yaptığını doğrulayamıyorum.

Kodlanacak çok şey var ve üretimi etkilemediği sürece geri dönüp bir şeyi yeniden kodlamak için çok fazla zamanım yok.

Aslında, bugün hala kullanılan bir asp web uygulaması, verileri tablo biçiminde görüntüleyen ve sıralama/düzenlemeye izin veren tamamen işlevsel bir grafiğe sahiptir, ancak bir veri ızgarası değildir. Birkaç yıl önce ilk asp.net öğrenirken inşa edildi ve veri ızgaralarını bilmiyordum. O zamanlar ne yaptığımla ilgili hiçbir fikrim olmadığı için koddan korkuyorum, ama çalışıyor, doğru, değiştirilmesi kolay, çökmüyor ve kullanıcılar bunu seviyor

5
Rachel

Tekerleği yeniden icat edip etmeme bir maliyet/faydadır. Maliyetler oldukça açık ...

  • Yeniden keşfi yapmak çok zaman alıyor.
  • Ne icat ettiğinizi belgelemek daha da zaman alıyor.
  • Ne icat ettiğinizi zaten anlayan insanları işe alamazsınız.
  • Bir şeyi kötü bir şekilde yeniden keşfetmek çok kolaydır, bu da kötü tasarımın neden olduğu sorunların devam eden maliyetlerine neden olur.
  • Yeni kod, yeni hatalar anlamına gelir. Eski kod genellikle hataların çoğunu zaten kaldırmıştır ve farkında olmadığınız sorunlar için küçük geçici çözümlere sahip olabilir ve bu nedenle yeni tasarımda çözülemez.

Sonuncusu önemli - bir yerde, eski kodu atmak ve sıfırdan başlamak eğilimi hakkında bir blog yazısı var, anlamadığınız eski hamlelerin çoğu aslında temel hata düzeltmeleri temelinde. Netscape, IIRC hakkında uyarıcı bir hikaye var.

Avantajları olabilir ...

  • Mevcut kitaplıkların sahip olmadığı özellikler ekleme yeteneği. Örneğin, yineleyici/imleç örneklerini "koruyan" kaplarım var. Ekleme ve silme işlemleri yineleyicileri geçersiz kılmaz. Bir vektöre işaret eden bir yineleyici, vektörde daha önce eklenen ve sildiğinden bağımsız olarak aynı öğeyi (aynı indeksi değil) göstermeye devam eder. Bunu standart C++ kapsayıcılarıyla yapamazsınız.
  • Özel gereksinimlerinizi hedefleyen ve önceliklerinize saygı gösteren daha özel bir tasarım (ancak iç platform etkisine olan eğilime dikkat edin).
  • Tam kontrol - bazı üçüncü taraflar, API'yı uygulamanızın yarısını yeniden yazmanız gerektiği anlamına gelecek şekilde yeniden tasarlamaya karar veremez.
  • Tam anlayış - bunu bu şekilde tasarladınız, umarım nasıl ve neden yaptığınızı tam olarak anlarsınız.
  • EDIT Diğer kütüphanelerden dersleri, aynı tuzaklara takılmadan, onları taklit etme konusunda seçici olarak öğrenebilirsiniz.

Bir şey - üçüncü taraf bir kütüphane kullanmak tekerleği yeniden icat etmek olarak sayılabilir. Zaten kendi eski, iyi kullanılmış, iyi test edilmiş bir kütüphaneniz varsa, bunun yerine üçüncü taraf bir kütüphane kullanmak için atmadan önce dikkatlice düşünün. Uzun vadede iyi bir fikir olabilir - ama oraya varmadan önce çok miktarda çalışma ve çok sayıda kötü sürpriz (kütüphaneler arasındaki ince anlamsal farklılıklardan) olabilir. Örneğin, kendi kaplarımdan standart kütüphane olanlarına geçmemin etkisini düşünün. Arama kodunun saf bir çevirisi, standart kütüphane kaplarının yineleyicilerini korumamasına izin vermez. Daha sonra bir "yer imi" olarak yineleyiciyi kaydettiğim durumlar hiç basit bir çeviri kullanılarak uygulanamadı - yer imi konumlarını belirtmek için önemsiz olmayan alternatif araçlara ihtiyacım var.

4
Steve314

Tekerleği yeniden icat etmek, bir tekerleğin nasıl çalıştığını öğrenmek için harika bir yoldur, ancak bir araba yapmak için iyi bir yol değildir.

4
Dima

Şu anda bir sürü cheapskates için çalışıyorum.

Karar "inşa veya satın al" arasında verildiğinde, ekonomiye dayalı rasyonel bir karar vermek yerine, yöneticiler "inşa etmeyi" seçti. Bu, bir bileşen veya araç için birkaç bin dolar ödemek yerine, insan aylarını kendimiz inşa etmek için harcadığımız anlamına gelir. Başka bir şirketten bir tekerlek satın almak, bütçeden çıkan paraya mal olur - bu da kötü yönetim yıl sonu bonuslarına karşılık gelir. Programcıların zamanı ücretsizdir ve bu nedenle yıl sonu bonuslarına karşı sayılmaz (programcıların her şeyi "zamanında" yapmadıkları için canlandırmanın ek yararı ile), bu nedenle yeniden keşfedilen bir tekerlek serbest tekerlek .

Akılcı bir şirkette, başkalarının kendi jantlarını yeniden icat etmesine karşı başkaları tarafından yapılan tekerlekleri satın almanın maliyetine karşı avantajı, kısa vadeli ve uzun vadeli maliyetlerin yanı sıra kaybedilen fırsat maliyetlerine dayanır, çünkü biri yeni widget'lar yapamaz. yeniden icat tekerlekler. Her gün tekerleği yeniden icat etmek için harcadığınız her gün yeni bir şey yazamazsınız.

Yapıya karşı satın alma sunum .
Derleme ve satın alma hakkında makale .

Birisinin, zaten dil/çerçeve içine yerleştirilmiş bir şey için kendi yöntemini oluşturarak tekerleği açıkça yeniden icat ettiğini görürsem. İlk olarak, argümanlar uğruna, yöntemlerinin yerleşik yöntem kadar verimli olduğunu varsayalım. Ayrıca, yerleşik yöntemin farkında olan geliştirici kendi yöntemini tercih ediyor.

Dahili olanı neden kendi başına kullanmalı?

Yerleşik sürümün üzerinde çok daha fazla insan vuracak - böylece homebrew kodunuzdan daha fazla hata bulmak ve düzeltmek.

Son olarak, yerel geliştiriciniz ayrıldığında ve bir başkası yazdığı kodu korumak zorunda kaldığında, tamamen yeniden düzenlenir ve yerine ne olur? çerçeve içinde. Bunun olacağını biliyorum çünkü mevcut işverenimin yıllar içinde VB (en eski ürün yaklaşık 20 yıldır piyasada)) sürümlerine geçirilmiş bir kod var ve bu ne olur Ofisimde en uzun istihdamı olan geliştirici 17 yıldır burada.

4
Tangurena

Tekerleği yeniden icat etmeyle ilgili şey, bazen ihtiyacınız olanı yapacak standart, hazır bir tekerleğin olmamasıdır. Dışarıda, birçok boyut, renk, malzeme ve yapım tarzında çok iyi tekerlekler var. Ancak bazı günler yeşil eloksallı alüminyumdan gerçekten hafif bir tekerleğe sahip olmalısınız ve hiç kimse bir tane yapmaz. Bu durumda, kendinizinkini yapmak zorundasınız.

Şimdi bu, her proje için kendi tekerleklerinizi yapmanız gerektiğini söylemez - çoğu şey standart parçaları kullanabilir ve bunun için daha iyi olabilir. Ama arada sırada, standart parçaların işe yaramadığını görüyorsunuz, bu yüzden kendinizinkini yaratıyorsunuz.

En önemli şey ne zaman kendi yapacağınızı bilmektir. Kendi parçalarınızı tasarlamaya başlamadan önce standart parçaların neler yapabileceği ve yapamayacakları hakkında iyi bir fikriniz olmalıdır.

4
Michael Kohne

"Kötü" ve hatta "kötü" olmak oldukça güçlü kelimelerdir.

Her zaman olduğu gibi, yerleşik bir uygulama üzerinde kişisel bir uygulama seçmenin nedenleri vardır. Eski günlerde bir C programı çalışma zamanı kitaplığındaki hatalarla karşılaşabilir ve bu nedenle basitçe kendi uygulamasını sağlamalıdır.

Bu, Java JVM çok kesin olarak tanımlandığı için programlar için geçerli değildir, ancak bazı algoritmaların doğru olması hala çok zordur.Örneğin Joshua Bloch, aldatıcı şekilde basit ikili arama algoritmasının Java çalışma zamanı kitaplığı, dokuz yıl süren bir hata içeriyordu:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Gelecekte bulundu, düzeltildi ve dağıtıldı Java dağıtımlar.

Yerleşik ikili aramayı kullanırsanız, Sun'ın bu hata düzeltmesini bulma, düzeltme ve dağıtma zor işini yaparak zaman ve paradan tasarruf ettiniz. "En azından Java 6 güncelleme 10'a ihtiyacınız var" diyerek çalışmalarından yararlanabilirsiniz.

Büyük olasılıkla bu hatayı da içerecek şekilde kendi uygulamanızı kullanırsanız, önce kendini göstermesi için hataya ihtiyacınız vardır. Bu özel olanın sadece BÜYÜK veri kümelerinde gösterildiği göz önüne alındığında, bir yerde üretimde olması gerekir, yani bugfix'i bulup düzeltir ve dağıtırken müşterilerinizden en az biri etkilenir ve büyük olasılıkla gerçek para kaybeder.

Bu nedenle, kendi uygulamanızı tercih etmek mükemmel bir şekilde geçerlidir, ancak başkalarının çalışmalarından yararlanmaktan daha pahalı olması gerektiğinden, neden daha iyi olmanız daha iyidir.

3
user1249

İhtiyacınız olanı yapan bir çalışma bileşeni varsa Neden kendi sürümünüzü yazmaya ve hata ayıklamaya zaman harcıyorsunuz? Benzer şekilde, daha önce benzer bir işlevi yerine getirmek için kod yazdıysanız, neden yeniden yazmalısınız?

Joel, kodun ve yazılımın yeniden yazılmasının ne zaman yararlı olmadığını ve ne zaman yararlı olmadığını anlatan, icat edilmemiş-burada bir makale yazdı.

3
Dave

Tekerleği yeniden icat etmek, bir şeyin nasıl çalıştığını öğrenmek için harika bir yol olabilir - ve sadece bu amaç için kendi zamanınızda yeniden icat etmenizi öneririm - ama bir uygulama yazarken, aynı şeyi zaten yapan iyi kurulmuş çözümler varsa neden yeniden keşfediyorsunuz?

Örneğin, JavaScript kodunu asla sıfırdan yazmam; bunun yerine jQuery ile başlayıp uygulamalarımı bu çerçevenin üzerine inşa ederdim.

3
Justin Ethier

Kişisel kuralım:

Sadece öğrenirken tekerleği yeniden icat etmek iyidir. Son teslim tarihiniz varsa, mevcut tekerlekleri kullanmak isteyebilirsiniz.

3
John

Son zamanlarda bu konuda düşüncelerimi blogladım . Özetlemek:

  1. hemen hemen her zaman kendi inşa etmek kötü, özellikle de bu dil içine inşa edilmiş bir işlev ise doğrudur. Ancak, İnternet'te bulduğunuz olgunlaşmamış/şüpheli bir şekilde bakımı yapılmış/kötü belgelenmiş bir çerçeveyi kendiniz yazma olasılığına karşı değerlendiriyorsanız, bu beyinsiz olabilir.

  2. Bence tekerleği yeniden icat etmek bir yazılım anti-paterni için oldukça korkunç bir benzetme. Orijinal çözümün asla geliştirilemeyeceği anlamına gelir. Bu saçmalık. Sözde tekerlek bir gecede eskimiş olabilir veya sahipleri onu korumayı bırakabilir. Tekerleğin kullanıldığı her sistemde farklı bir değeri vardır. Bu nedenle, daha iyi bir tekerlek icat etmek tamamen mümkündür.

  3. Kendi çerçevenizi oluşturmanın en büyük yararı, başkasının böcekleri için sorumluluk almak zorunda kalmamanızdır. (Bu Amazon'un felsefesi .) Bunu şu şekilde düşünün: Bunlardan hangisini müşteriye söylemek daha iyidir? -

    "Web sitemiz bozuldu. Başkasının hatasıydı ve yaratıcısıyla ilgili bir hata kaydettik. Beklemek dışında yapabileceğimiz hiçbir şey yok. Sizi güncel tutacağız."

    "Web sitemiz bozuldu ve hemen çözebildik."

3
realworldcoder

Belki de aynı derecede verimlidir, ama sağlam mıdır? Kendi kütüphane üzerinde bir kütüphane kullanmak için en zorlayıcı neden çerçeve kullanarak hataları hızla bulmak ve düzeltmek o kadar çok insan var olduğunu düşünüyorum. Kurum içi geliştirilmiş kütüphane, çok fazla (veya daha fazla) işlevsellik sunabilirken, hemen hemen her kullanım durumunda test sağlamak için milyonlarca kullanıcılı bir kütüphaneyle rekabet edemez. Bu tür testleri şirket içinde yenemezsiniz.

0
Michael K

Kendi yönteminin çerçeve kadar verimli olması oldukça nadirdir çünkü çoğu çerçevenin hala hataları vardır ve hiçbir çerçeve size kutudan çözüm getiremez. Düşünemeyen çoğu programcı asla çerçeve düzeyinde bir şey yazmaya çalışmaz; Google'da yalnızca hazır bir çözüm ararlar. Herhangi bir bilge programcı ilk olarak ihtiyaç duyduğu işlevselliğe sahip ücretsiz bir çerçeve olup olmadığını görecek ve daha sonra çözümü kendi başına yazacaktır. Bazen mevcut proje durumunu açıklamak çok zordur ve geliştirici en iyi yargıçtır.

Tekerleği yeniden keşfetmek kötü değil, tembel insanlar tarafından çok çalışmaktan kaçınmak için yapılan bir açıklama. Çerçeve yazarları bile yeniden icat eder; .Net çerçevesinin tamamı COM'un sunduklarını yapmak için yeniden keşfedildi.

0
Akash Kava

Bazıları için rahatsız edici olduğu gibi, bu terimi her zaman herhangi bir mühendis tarafından kullanıldığında veya bir şeyler yaratma veya tasarlama konusuna atıfta amca olarak buldum. Aslında, bugünün hızlı tempolu dünyasında yenilik yapmaya yönelik baskıları göz önünde bulundururken, bunu ihtiyatlı olarak görmekten başka bir şey yapamam. Kendinizi tekrarlamak (veya yeterli, önceden var olan çözümleri görmezden gelmek) asla akıllıca değildir, ancak gerçekten, hepimizin hala yeşil harflerle dolu siyah ekranlara bakmamamızın bir nedeni vardır.

"Eğer kırılmazsa düzeltmeyin" anlıyorum, ancak böyle bir ifade bazılarına cahil gelebilir. Yine de uzay yolculuğu, yarış, nakliye vb. İhtiyaçları için tekerleği yeniden icat etme çabasıyla, "tekerleği yeniden icat etmeyin" de oldukça cahil ve göründüğü kadar akıllı bir yere yakın değil.

Arka planım birçok projeye öncülük ediyor ve birçok stajyer ve diğer yeşil geliştirici formlarıyla çalışmak zorunda kaldım ve bazılarının 'aptal' olarak adlandırdığı birçok naif soruyu ele almak zorunda kaldım ve ayrıca insanları tavşan kovalamaktan saptırmak zorunda kaldım görevlerinin kapsamı dışında kalanlar. Bununla birlikte, asla yeniliği veya yaratıcılığı caydırırdım ve 'tekerleği yeniden icat etmekten' harika şeyler gördüm.

Soruya gerçek cevabım: Tekerleği yeniden icat etmenin sadece iki durum var:

  1. Gerçekten gerekli değilse
  2. Eğer yapabileceğin zaman bunu yapan diğer adamsa

Düzenleme: Ben sürdüğünü aşağı oyla göre bazı rahatsız olmalı. Eklemek istediğim tek şey, bu ifadenin her zaman büyük bir evcil hayvanım olduğu. İki sentimin oldukça trol gibi göründüğünü anlıyorum, ancak troll etmek, yangınlara neden olmak veya kırmak gibi bir niyetim yok.

0
JSON

"Tekerleği yeniden icat etmek" hakkındaki tartışmalar genellikle yanlış bir kitaplık kullanmayı seçmek bağlamında kullanılır, ancak buna pek benzemez.

Diyelim ki son zamanlarda popüler olan ve formlarla başa çıkmaya yardımcı olan bir 'form artı' kütüphanesi değerlendiriyorum. Güzel bir açılış sayfası, modern havalı grafikler ve etrafında formlar oluşturmayı nasıl harika kıldığına yemin eden bir -cult- (yani demek istediğim topluluk) vardır. Ancak "formlar artı", "formlar" ın üstünde bir soyutlamadır. "formlar" mümkün ama başa çıkmak zahmetli, bu yüzden kolaylaştırıcı soyutlama popüler hale geliyor.

Her zaman yeni soyutlamalar oluyor. Onları tekerleklerle karşılaştırmak zor. Daha çok yeni bir kontrol cihazı ve çalıştırmanız gereken çok karmaşık cihaz için yeni bir el kitabı gibidir.

Bu yeni cihazın "form-plus" değeri kişisel deneyime bağlı olarak farklı görünecektir. Daha önce hiç form oluşturmamışsam, "form-plus" çok cazip olacaktır çünkü başlamak daha kolaydır. Dezavantajı, eğer "formlar artı" sızdıran soyutlama ortaya çıkıyorsa yine de yine de "formları" öğrenmek gerekir. Eğer "form artı" içermeyen formlar oluşturuyorsam, o zaman yeni bir araç öğrenmem gereken zamanı dikkate almam gerekecek. Upside, zaten "formları" bildiğimden, üstündeki soyutlamalardan korkmuyorum. Kısa vadeli faydalar genellikle yeni başlayanlar için daha büyük olacaktır, çünkü bir şey üzerinde gelişmezse muhtemelen yeni kütüphane olmazdı. Uzun vadeli faydalar, soyutlama kalitesi, benimsenme oranı ve diğer cevaplarda zaten tartışılan diğer faktörlere göre büyük ölçüde değişecektir.

Dikkatle değerlendirdikten sonra yeni bir soyutlama kullanmanın yararları ve negatifleri "form-plus" vs çıplak kemik "formları kullanma" şeklinde karar veriyorum. Karar kişisel deneyimlerime dayanıyor ve farklı insanlar farklı kararlar verecek. Çıplak kemik "formları" kullanmayı seçmiş olabilirdim. Belki daha sonra zaman formları artı artı arkasında daha fazla hareket kazanmış ve bir defacto standardı haline gelmişti. Ve belki de zaman içinde kendi uygulamam kıllılaştı ve formların artı şimdi ne yaptığını örtmeye başladı. Şu anda gelenler, tekerleği yeniden icat etmeye hevesli olduğumu ve bunun yerine mevcut kütüphaneyi kullanmam gerektiğini eleştirmek için çekilecekler. Ama aynı zamanda, "formlar artı" hakkında karar vermek zorunda kaldığım zamanda "formlar artı" için başka alternatifler de vardı, bunların çoğu şimdiye kadar ölü projelerdi ve muhtemelen yanlış olanı seçerek kazandım. bir.

Sonunda doğru araçları seçmek karmaşık bir karardır ve “tekerleğin yeniden icat edilmesi” çok yararlı bir perspektif değildir.

0
Ski