Kendi çerçevenizi oluşturmak, var olanı kullanmaktan daha verimli ne zaman? [kapalı]


22

Şirketinizde neden kendi çerçevenizi oluşturmaya karar verdiğinizi bilmek istiyorum .

Çerçeve olarak, sık kullandığınız birkaç kütüphaneyi kastetmiyorum. Bunun üzerine, temel sınıflar, kongre vb. İle belirli bir uygulama oluşturma yöntemi demek istiyorum.

Peki neden kendi çerçeveni kurdun? Bunu sizi istihdam eden kişiye nasıl haklı gösterebilirsiniz. Olumlu ve olumsuz etkisini ölçtünüz mü?

Tecrübelerinizle ilgili olarak, bazı durumlarda bir şirket çerçevesinin gerçek faydalar sağladığını ya da diğer yandan, geliştirme maliyetlerinin arttığını fark ettiniz mi (öğrenme eğrisi, hata ayıklama, bakım, ...)?


6
Karar vermedim. Kendini yarattı ...
Mchl

Yanıtlar:


16

Sebebinin cevabı:

  • Lisans sorunları
  • Mevcut çerçevelerde bulunmayan şirkete özgü gereksinimler
  • Şirket, çerçevenin desteği ve bakımı üzerinde kontrol sahibi olmak istiyor
  • Mimar daha iyisini bilmiyordu! Bu özel çerçevenin var olduğunu bilmiyordu, bu yüzden tekerleği yeniden icat etmeye karar verdiler.

Güncelleştirme:

İşletmeler "küçük" çerçeveler kullanmak yerine tekerleği yeniden icat etmeyi tercih ediyorlar. Küçükken, belirsiz geleceği olan çerçevelere atıfta bulunuyorum. Örneğin .NET çerçevesi, işletmeler için küçük bir topluluk tarafından oluşturulan bir çerçeveden daha güvenli bir seçimdir. İşletmeler güvenliğe ihtiyaç duyuyor, çünkü uygulamalarının çoğu iş açısından kritik öneme sahip ve ayrıca uzun ömürlü. Tekerleği yeniden icat etmenin maliyeti kısa vadede daha fazla olabilir. Ancak, şirket başvurusunda kullanılan çerçeve kullanımdan kaldırılmış ve artık desteklenmiyorsa veya lisanslar değiştirilirse maliyet daha yüksek olabilir. Burada şirketin mevcut çerçeveyi atması ve bir tane daha koyması gerekebilir. Visual Basic, artık Microsoft tarafından desteklenmeyen bir dilin güzel bir örneğidir. Ve bu maliyet, milyarlarca firmaya yeni bir gelişme ile başlaması gerektiğinden milyarlarca dolar.


8

Neden kendininkini kurdun?

  1. çünkü daha önce hiç yapılmamıştı (nadir, fakat yine de bir olasılık)
  2. çünkü tam kontrol istiyorsun.
  3. çünkü sadece biraz daha fazla işlevselliğe ihtiyacınız var, böylece onu kendiniz kurmanız daha ucuz olur.

Neden kendikini yapmıyorsun?

  1. Bunu yapacak vaktin yok
  2. Mevcut bir çerçeveyi satın alırsanız muhtemelen çok daha ucuz
  3. çok zaman kazandırır ve daha hızlı üretken olabilirsiniz

7

Gelen tekerleği yeniden icat için uygun zaman benim yazı bir yeniden gerçekleştirmenizin bir çok avantaj sıralar. Bu avantajların özellikle çerçeve kütüphaneler için geçerli olduğunu düşünüyorum. Örneğin, uygulamanızın küçük bir bölümünde bir çerçeve kütüphanesinin kullanımını yalıtmak genellikle imkansızdır. Bunun yerine, müşteri kaynak kodunun yapısını dikte etme eğilimindedirler ve bu nedenle kütüphane üzerinde tam kontrol sahibi olmaları istenir .


3

Tekerleği yeniden icat etmenin tek gerçek nedeni, iş için kritik bir uygulama olması. Şirketiniz gelecek bir süre kullanacaksa. Bu uygulamalar ise / framework / etc. Muhtemelen mevcut ticari çerçevenin sunması gerekenin ötesine geçecek, daha sonra şirket kodlayıcılarının uygulanmasını kesinlikle kabul edilebilir kılması.

Buna karşı tek gerçek neden ise:

  1. Mevcut çerçeve iyi korunur, görevinize tam olarak uyar ve geleceğe iyi gelir.

  2. Bu sadece ' Burada İcat Edilmedi ' sendromu vakası

  3. Mevcut kurulumunuz, bu çerçeveyi makul bir maliyet karşılığında makul bir sürede başarıyla oluşturamayacak.

Joel Spolsky konuyla ilgili çok güzel bir makale yazdı: İcatsız Burada Sendromu Savunmasında


2

Temel olarak, başkalarının çalışmalarını kullandığınızda, onları görünmez işveren veya "fazladan el" olarak eklersiniz.

Eğer iyilerse size yardımcı olacaklar. Değilse, kendi işinize ek olarak işlerini yapmak zorundasınız - başka bir deyişle kodlarını koruyabilirsiniz. Bu kabul edilemez bir risk olabilir, ancak çok nadir olduğunu düşünüyorum.

Anahtar kelime, bir arayüze kodlayarak çerçeveyi değiştirilebilmektir. Java dünyasındaki en katı arayüzler, sunucu uygulaması API'sı tarafından kanıtlanan Sun özellikleridir.

O zaman çerçeve kullanmamak için herhangi bir sebep olduğunu düşünmezdim.


1
Hangi çerçeveye uyarladığınızı geliştirme sürecine bakmak yararlı olacaktır. Bir kullanıcı olarak devam eden her şeyi görebileceğiniz ve etkilemek için oy verebileceğiniz güçlü bir topluluğa ve açık bir sürece sahip çerçeveler düşük risklidir, özellikle kaynak kodla gelirlerse (koddan kaçınmaya çalışıyorum) ). Bu durumda, çerçevenin etrafında ilave bir sarmalayıcı geliştirmek gerekli değildir.
Joeri Sebrechts

2

Çalıştığım yerde oldukça olgun bir çerçevemiz var. İşte Vakıflar Çerçevesinin bir özeti

Kullanmanın en önemli nedenlerinden biri kararlılık. Yıllar geçtikçe Microsoft'a veya yeni özellikler ve karmaşıklık eklemek isteyen herhangi bir tedarikçiye bakmadık.

(Kendi görüşüme göre, işverenime vb.)


2

Bunu birkaç kez yaptım, mevcut çerçeveler tarafından kapsanmayan gereksinimleri karşılamak için (o zamanlar).

Çoğu durumda, bu ev yapımı çerçeveler daha sonra tamamen yeni geliştirilmiş çerçeveler tarafından kaldırılmıştır. Mesela 2000 yılında, Rails ile kıyaslanabilecek bazı yönlerden, birkaç sıralanmış formdan oluşan karmaşık bir sipariş giriş sistemi oluşturmak için kullanılan bir Java web çerçevesi oluşturdum. İyi çalıştı, ama elbette, birkaç yıl sonra Struts ve JSF gibi daha olgun çerçeveler modası geçmiş hale getirdi. Ancak o zaman yapılacak doğru şeydi, iyi çalıştı ve geliştirme hızı etkileyiciydi.

Geliştirdiğim bir başka çerçeve hala kullanımda (ve ayrıca aktif gelişimde); ilk versiyon 2004'te yazıldı. Bu, temel olarak intralojistik uygulamalar için kullanılıyor; Onu kullanan şirket hala onu ayırt edici bir özellik olarak görüyor. Bunu yaratmanın temel nedeni, mobil barkod tarayıcıları için veritabanına bağlı uygulamalar oluşturmayı kolaylaştırmaktı (Windows CE'nin bazı lezzetlerini çalıştıran); o kadar iyi çalıştı ki patronlar PC yazılımı için de aynı konsepti kullanmaya karar verdiler ve ondan hala memnunlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.