Başka bir hizmet sağlayıcının yarım bıraktığı eklentiyi devralmak
Yarım kalmış bir eklenti, artık yanıt vermeyen bir geliştirici, bekleyen bir mağaza: soru «bitirebilir misiniz» değil, «bu kodun içinde gerçekte ne var» sorusudur ve buna kimse okumadan cevap veremez.
Bir şey söylemeden önce topladıklarım
Üç şey isterim: eklentinin sunucuya kurulu hâliyle tam kodu, çalıştığı mağazaya okuma erişimi ve ne yapması gerektiğinin anlatımı. Üçüncüsü neredeyse her zaman eksiktir ve en yararlısı odur: onsuz, bilinçli bir davranışla bir hatayı ayırt edemezsiniz. Yarım bırakılmış bir işlev, bozuk bir işleve çok benzer.
Ardından eklenti klasörünün dışında nelerin teslim edildiğini denetlerim: başka yere bırakılmış sınıf geçersiz kılmaları, veritabanına eklenmiş tablolar, sunucudaki zamanlanmış görevler, bir yerde saklanan API anahtarları. Yarım kalmış bir eklenti çoğu zaman kendi klasörünün dışına parçalar bırakmıştır ve sonradan sorun çıkaran da bunlardır.
Bitirmekle yeniden yazmak arasında karar veren dört nokta
-
Mimari platformun mimarisi mi
Kurulum döngüsüne, bağlantı noktalarına ve platform geleneklerine uyan bir eklenti tamamlanır. Öngörülen nesneleri atlayıp doğrudan çekirdek tablolara yazan bir eklenti yeniden yazılır, çünkü her güncelleme onu yeniden tartışmaya açar.
-
Kod okunabilir mi
Tutarlı adlandırma, görüntüleme ile işlemin ayrılmış olması, on kez kopyalanmış bloklar bulunmaması. Bu bir zarafet meselesi değildir: bir düzeltmenin bir saat mi bir gün mü süreceğini bu belirler.
-
Veriyle ne yapıyor
Kaçışsız sorgular, kısıtsız saklanan veriler, hiç hata yönetimi olmaması: yalnızca bu üç işaret, görünürdeki ilerleme ne olursa olsun çoğu zaman yeniden yazmayı haklı çıkarır.
-
Gerçekte ne kadarı bitmiş
Bir ekran gösteren eklenti, çalışan eklenti demek değildir. Bildirilen ilerlemeye inanmadan önce gerçek durumları denerim.
Bitirmek bazen yeniden yapmaktan pahalıya gelir
Sezgiye aykırıdır ve yine de düzenli olarak söylerim: yazmadığınız bir kodu devralmak, hiç dokunmayacağınız bölümleri de dâhil olmak üzere onu bütünüyle anlamayı gerektirir. Küçük bir eklentide bu okuma süresi, temiz bir sürümü yazma süresini aşabilir. Böyle olduğunda gerekçeleriyle söylerim ve kararı siz verirsiniz.
Tersine, temel sağlamsa devralmak yeniden başlamaktan belirgin biçimde hızlıdır: işlevsel seçimler yapılmıştır, işinizin özel durumları kodda zaten yakalanmıştır ve geriye bitirmek ile sağlamlaştırmak kalır. Her iki durumla da aşağı yukarı aynı sıklıkta karşılaşıyorum.
Her hâlükârda devralma aynı şeyle biter: başkasına devredebileceğiniz bir eklentiyle. Eksiksiz kaynak kod, belirlenmiş bağımlılıklar, yazılı bir kurulum yordamı. Başlangıçta eksik olan tam olarak buydu.
İlgili sayfalar
-
Bakım ve yönetilen destek
Bir eklentinin yeniden sahipsiz kalmaması için sonrasında yerinde olması gerekenler.
-
Mağazanın eklenti envanterinin incelenmesi
Birbirini sürekliliksiz izleyen birden çok geliştirme olduğunda eksiksiz envanter.
-
Özel bir eklentinin fiyatını ne belirler
Bir devralmanın neden sıfırdan geliştirme gibi fiyatlandırılmadığı.
-
Acil e-ticaret arıza giderme
Devralma düzenlenirken mağaza üretimde bloke durumdaysa.
- 2019 e-ticaret geliştiricisi, başlangıç
- 3 platform: PrestaShop, WooCommerce, Shopify
- 3 çalışma dilleri: FR, EN, TR
- 100 % doğrudan geliştiriciyle iletişim
Aracı yok: yanıt veren kişi, kodun üzerinde çalışan kişidir.
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.