Yaygın bir Hata Acemi Yazılım Geliştiricileri yapar ve Nasıl Önlenir?

Unsplash üzerinde Fancycrave tarafından fotoğraf

Üniversiteden yeni çıkmış bir yazılım geliştiricisi olarak işime sadece bir ay kaldım. Ekibime katkıda bulunmak için ısınıyordum. Her nasılsa, mevcut kod tabanından geçerken kendimi çok ilginç düşüncelere sahipken yakaladım. Ekibim bu kod tabanını aylarca ve yıllar süren çabalar üzerine kurmuştu.

İlk görevim olarak, hizmetin gelecekteki sürümlerini dengelemeye yardımcı olacak küçük bir hata düzeltmem vardı. Ekibim bana hizmetin mimarisini ve daha büyük projenin büyük planında nereye sığdığımızı açıkladı. Hata düzeltme yapmak için kodun nereye eklenmesi / silinmesi veya değiştirilmesi gerektiğini bulmak üzereydim.

Son iki yılda yaratılan kod tabanını kazmaya başladım. Standart olarak, eski koddu. Derinleştikçe ve derinleştikçe kendimi oldukça saygısız düşüncelerle buldum. Bu kodun estetik açıdan hoş olmadığını söylemek, koymak için hafif bir yol olurdu. Takımımın kod tabanına bu şekilde tepki gösterdim:

Bu berbat !!!

Yuck, burada iki yüz çizgi işlevi var.

Bu saçmalığı kim yazdı!

Tanrım, bir if-else bloğunun içinde bir if-else bloğu var.

Bu kod kıllı bir karmaşa! Eff.

Bu sıfırdan yeniden yazılmalıdır.

Ben öfkeliydim. Bu düşüncelere sahipken, bir parçam merak ediyordu, tüm bunları anlamanın bir yolu olabilir mi? Bazı kodlar vardı, bu kıdemli ekibin ekibimde bu kodun çoğunu yazan kim olduğunu bilmiyordum. Bulmaya başladım.

Hızlı bir sohbet için ekibimdeki kıdemli adamı yakaladım ve sorularımı ona atmaya başladım.

Tartışmadan sonra öğrendiklerim benim için çok aydınlatıcıydı. Ekip, kodun bazı bakım problemleri olduğunu biliyordu. Ancak, mevcut kod tabanı birkaç nedenden dolayı olduğu biçimindeydi. Bana bu nedenleri açıklamaya devam ederken, bu gönderinin neden anlamlı olduğunu görebiliyorum.

Neden herhangi bir yazılım geliştiricisine üzerinde çalıştıkları kodun kalitesini sorduğunuzu sormak için okumaya devam edin, varsayılan yanıt: “Bu bir karmaşa”. Ve ayrıca, neden bir şeyleri yerden inşa etmek çoğu durumda bir çözüm değildir.

Kod farklı bir nedenden dolayı yazılmıştır

Ben dahil yazılım geliştirmede yeni olan çoğu kişi, bu kodun makineler için yazıldığını düşünüyor. Yanlış. Nada. İnsanlar için yazılmış. Makine yazdığınız JavaScript kodunu bile görmüyor, tek gördükleri 0 ve 1'lerin bir sırası. Ve ekibimin hizmeti inşa edilirken, teslim edilmesi gereken teslimatlarla ilgili gerçek tarihler vardı. Yazılım geliştiriciler zaten zihinsel olarak vergilendirilmektedir. Sağlama baskısı altında bir yerde, kodun çalışmasını sağlamak, süper estetik açıdan hoş bir kod yazmaktan daha önceliklidir.

Bir dosyadan diğerine atlamak yerine, bir şeyleri geliştirmek için büyük bir kod yığınını şahsen geliştiriciye yazmak ve açıklamak kolaydır. Bu kararlar daha sonra uzun süre kalabilir.

Üretim kodu savaşta test edilmiştir

Ekibim kodda kritik hata düzeltmelerine neden olan birçok olay raporu alıyor. Başka bir cümlecik burada işlenirken bir hata işleme, orada bir deneme yakalama ve aniden, tüm kod tabanı kıllanmaya başladı. Bu, kod tabanının en iyi niyetlere rağmen nasıl daha karmaşık hale gelmeye başladığını göstermektedir.

İşte bu yüzden kodun sıfırdan yeniden yazılması çok naif bir fikir. Bu, yapılan tüm hata düzeltmelerini ve iyileştirmeleri atmaya neden olur. Bunlar, muhtemelen bazı gerçek sorunları olan bir kullanıcı tarafından aylar ve yıllar boyunca toplandı. Bir geliştirici bildirildikten sonra bu hataları düzeltmek için birkaç saat harcayabilir.

İşe yarayan yol budur

Ürün veya hizmetinize bağlı olarak müşterilerin olabileceği iş dünyasında. Hiç kimse kodunuzun mümkün olan en iyi şekilde yeniden imha edilmesini önemsemez. Her kod satırı bir iş problemini çözmek için yazılmıştır. Kendinize sorun, yeniden düzenleme çabalarınız hangi değeri yaratacak? Muhtemelen hiçbiri ve daha fazla hataya neden olabilirler. Ayrıca, zamanınızın en iyi kullanımı bu mu?

Panzehir

İlk adım, sorunu tanımaktır. Sorun benim egomun, üretim seviyesi kodunu nasıl yazacağını açıkça bilemeyen üst düzey geliştiricilere göre daha iyi bir iş yapabileceğini düşünmesiydi. Bu çok saf bir düşünce tarzı ve şimdiden kaçınmak için geçmişte yeterince zaman yaktım.

Sadece egonuzun varlığını kabul ederek, bunun üzerinde büyük bir avantaj elde edersiniz. Birdenbire saklanacak yeri yok. Sorunu kabul etmek bir şeydir, ve çözmek başka bir şeydir. Aşağıda bu dizlik tepkisi reaksiyonu aşmanın yolu. Farklı bir yönteminiz varsa, yorumlar bölümüne yazın.

Meraklı Olun

Nedenini sormaya başla!

Bu kod neden bu şekilde yazıldı? Kim yazdı? Bu kişi hala buralarda mı ve bunu ona sorabilir miyim? Bu adamlar benim bilmediğim ne biliyor? Bu özelliğin çözdüğü problem nedir?

Çoğu zaman, cevap sizi şaşırtacak.

Alçakgönüllülük geliştirin

Bu zor bir iş değil. Her ihtimalde, kendinizi merdivenin neresine koyacağınız önemli değil, öğrenmek için hala çok miktarda var.

Büyüme zihniyetini benimsemek, kendimi doğru zihin durumuna sokmamı sağlayan şeydi. Aptal görünme korkusu olmadan soru sormamı sağladı. Tüm cevapları bilmemeniz gerektiğini bildiğiniz halde tüm cevapları öğrenmeniz gerektiğini bildiğiniz zaman, soru sormak önemsiz bir hale gelir.

Sonuç

Kod yazma şeklinizin en iyisi olduğunu düşünmek çok kolaydır ve diğer herkesin emmesi. Üç kişiden bir dizgiyi bir karakter dizisine nasıl ayırdıklarını sorun ve hepsinin bunu yapmanın üç farklı yolunu vereceğini sorun. Muhtemelen, hepsi eşit derecede iyidir ve hepsinden bir şey öğrenilebilir.

Kötü kalite kodu ile ilgili olarak, onu atmak kesinlikle çözüm değildir. İş dünyası için daha kolay olan yol, filleri birer birer birer birer ısırmaya başlamak ve kodunuzu doldurmak için kullanmak olacaktır.