3 Tip Zehirli Yazılım Projesi

Yazılım evlerinde, genellikle hepsini gerçekleştirecek kaynaklardan daha fazla proje fırsatı vardır. En azından benim şirketimde, yazılımımızı geliştirmek için yapabileceğimiz pek çok şey var, ancak yatırım yapmak ve düzgün bir şekilde yapmak için zamanımız sadece çok fazla.

Bu, hangi proje üzerinde çalışılacağını ve hangi proje üzerinde çalışılmayacağını seçebilmenin çok önemli olduğu anlamına gelir. Bu, bir ekip veya bir şirket için üretkenlik için önemlidir, ancak aynı zamanda kodun kalitesi üzerinde de bir etkisi vardır. Gerçekten de, bazı projeler kodun kalitesi için zararlıdır. Bu anlamda zehirlidirler.

“Eğer bir proje zehirliyse, bunu yapmayacağım!” diye düşünebilirsiniz. Eminim. Ama bazen o kadar basit değil. Bazı projeler bizi içine çekmeye, zehirliliklerinden kör etmeye ve onları gerçekleştirmeye ikna etmeye çalışıyor. Sonunda kodu daha basit hale getirmek için bu projeleri belirlemek ve mümkün olan en kısa sürede kesintiye uğratmak için zaman içinde topladığım birkaç ipucu.

Zehirli proje #1: Ayy, ihtiyacımız olan şey bu değil projesi

Şunu hayal edin: Bir gereksinimi karşılamak için uygulamanızda yeni bir geliştirme projesi başlatmaya karar veriyorsunuz. Nasıl uygulanacağını görmek için teknik bir analiz yaparsınız, geliştirme planınızı yaparsınız, özellikleri hikayelere bölersiniz, tahmin eder, planlar ve kodlamaya geçersiniz.

Günler ve haftalar geçiyor, proje ilerliyor. Hikayeler birbiri ardına Agile dashboard panelinden geçerek “Backlog” sütunundan “Done” sütununa kadar ilerler.

Ekibiniz kod yazıyor, kodu gözden geçiriyor, birim testleri uyguluyor. PO veya özelliği talep eden kişi testler yapıyor ve geri bildirim veriyor. İlerleme kaydediyorsun.

Ama projenin sonundan çok uzak olmayan bir zamanda, omurganızdan aşağı doğru inen bir ürperti, projeye başlamamalıydınız.

Bunun olmasının çeşitli nedenleri vardır. Örneğin — benim başıma geldi — özelliğe artık ihtiyaç yok (bunun birkaç nedeni var: müşteri kabul edilebilir bir iş buldu veya iş ihtiyaçlarını karşılamak için daha basit bir yol buldu veya çalışmayı tercih etmeye karar verdi. rakibinizle veya her neyse).

Benim de başıma gelen diğer bir sebep ise, geliştirmenizin gerçek iş durumunu nasıl tatmin edeceğini yeterince anlamamış olmanızdır. Bu, örneğin, modülünüzü istenen özellikle uyumlu hale getireceğini düşündüğünüz için bir çerçeve uygulamaya karar verirseniz olabilir. Ve sonunda yanıldığınızı anlıyorsunuz, çerçeve bu özelliğe yardımcı olmayacak.

Çerçeveyi doğru bir şekilde uyguladığınıza dair artımlı testler yapabiliyorsanız ancak çerçeveyi tam olarak uygulayana kadar istenen ilk özelliği test edemiyorsanız bu zor bir testtir. Bütün bunlar başlangıçta yaklaşık bir anlayıştan çıktı. Bu yüzden anlamadığınız şeyi geliştirmeyi reddetmelisiniz.

Başta bir projeye başlamamanız gerektiğini fark etmenizi sağlayan birçok başka sebep varsa (eğer bu durumdaysanız, lütfen bir yorumda bana hikayenizi anlatın!).

Bu nedenler kontrolünüz dışında olabilir. Ama kontrolünüzde olan şey, şu anda projeyle ne yapmaya karar verdiğinizdir. Ve yanlış seçimi yapmanızı isteyen küçük bir şeytan var: batık maliyet yanılgısı.

Batık maliyet yanılgısı

Ekonomide batık maliyet, harcadığınız ve geri kazanamayacağınız bir maliyet anlamına gelir. Batık maliyet yanılgısı, zaten batık maliyetler yatırdığınız kötü bir projeye onu durdurmak yerine daha fazla kaynak yatırmanız için sizi dürtükleyen psikolojik bir önyargıdır, çünkü durmak hatayı kabul eder.

Yazılım projesinin yukarıdaki örneğinde, ilk etapta başlamamanız gerektiğini fark ettiğiniz için yapılacak en doğru şey, şimdiye kadar yaptığınız her şeyi çöpe atmak. Ancak batık maliyetler yanılgısı sizi buna iter. Gerçekten de, projeyi durdurmak hatayı somut hale getirecek ve boşuna çalıştınız. Bundan kim hoşlanır?

“Projenin çok uzağındayız, sona yaklaşıyoruz, bitirsek de iyi olur” diye düşünmek cezbedicidir. Ancak bunu yaparak, bir hata yapıp hiçbir şey için çalışmamış olmanın yanı sıra, özellik kod tabanınıza oturacak ve mevcut koda kendi karmaşıklığını ekleyecektir. Gelecekteki tüm gelişmelerinizi de daha karmaşık hale getirecek ve hiçbir şey için.

Projenize ihtiyaç olmadığını fark ettiğinizde ve üzerinde çalışmaya devam etmek istediğinizde, batık maliyetler yanılgısından etkilenebileceğinizi unutmayın. Projeyi çöpe atın. Yatırım yaptığınız her yeni dolar boşa gider ve kodunuzu daha karmaşık hale getirerek gelecekte daha da fazla israf etmenize neden olur.

Zehirli proje #2: Ayy, düşündüğümüzden daha zor bir proje

Yukarıdakiyle aynı hikayeyi ele alalım: gereksinim, geliştirme planı, hikayeler, tahminler ve uygulamaya geçiyoruz. Ancak bu sefer proje o kadar sorunsuz ilerlemiyor. Geliştirme aşamasında, beklemediğiniz zorluklarla karşılaşıyorsunuz.

Bunun olmasının çeşitli nedenleri vardır (yine, hepsi benim başıma geldi): kodun o bölümünde şüphelenmediğiniz bağımlılıkları keşfedersiniz veya profil oluşturma, uygulama performansını tolere edilebilecekten daha fazla etkilendiğinizi söyler veya gereksinimi o kadar iyi anlamamışsınızdır ve düşündüğünüzden çok daha karmaşık ya da birçok test eklediniz ve hepsini kontrol etmeniz gerekiyor ya da başka bir sebep.

Bir geliştirme projesinde ortaya çıkabilecek pek çok beklenmeyen başka zorluk vardır. Bazılarıyla karşılaştıysanız, lütfen bir yorum bırakın ve bize hikayeyi anlatın.

Değer/Maliyet Oranı

Herhangi bir zamanda, getirdiği değer (kısa veya uzun vadeli) maliyetinden daha yüksekse, bir proje üzerinde çalışmalısınız. Ve birden fazla proje arasından seçim yapmak zorunda kalırsanız, değer/maliyet oranı en yüksek olanı seçmelisiniz. Bu sağduyudur.

Değer ve maliyet oranının tahmini olduğunu anlamak önemlidir. Bir projenin ne kadara mal olacağını veya sonunda ne getireceğini kesin olarak bilemeyiz. Tahminler yaparız ve bu tahminler yeni bilgiler mevcut olduğunda değişir.

Beklenmedik bir zorluğun farkına vardığımızda, bu, maliyet tahminimizi ve sonuç olarak bir geliştirmenin değer/maliyet oranını değiştirir. Yeni koşullar altında, kalan kısmın maliyetlerinin projenin getireceği değerden daha ağır bastığını tahmin edersek, proje artık buna değmeyebilir.

Batık maliyet yanılgısı yeniden devreye girerek sizi devam etmenin bir yolunu bulmaya çağırıyor. Bunun bir yolu, özelliği olduğu gibi göndermek olabilir. Özellik gerçekten tutarlı bir durumda değilse bu, kod için zararlı olabilir, çünkü bu tutarsızlığı kod tabanına ekleyecektir. Başka bir yol, projeyi hızlı ve kirli bir şekilde bitirmek için birkaç hile bulmak olabilir. Bu da kodun kalitesi, ifadesi ve gelecekte onunla çalışma yeteneğiniz için zararlıdır.

Tüm bunlar maliyetleri artırır ve şimdiye kadar yaptığınız işi çöpe atmak için en iyi kararı verebilir. Durum bu, merhamet etmeyin ve diğer geliştiricilerin yanı sıra gelecekteki kendiniz için hayatı kolaylaştırdığınızı düşünün.

Zehirli proje #3: Belki-sonra-ihtiyacımız olacak proje

Yazılımdaki en iyi uygulamayı tanımlayan popüler bir kısaltma YAGNI’dir. You Ain’t Gonna Need It (Buna İhtiyacın Olmayacak) anlamına geliyor. Bu, gelecekte ihtiyaç duymamız durumunda özellikler geliştirmememiz veya bir noktada birinin buna ihtiyacı olabileceği için bir API’ye gereksiz kapasiteler eklemememiz gerektiği anlamına gelir.

Bu kılavuzun arkasındaki mantık, gelecekte neyin faydalı olacağını tahmin etmenin zor olması ve şimdi bir şey eklemenin karmaşıklık yaratarak kesin bir maliyeti olması. Bu nedenle, şu anda gerekli olmayan özellikleri eklemekten kaçınıyoruz.

Ancak bazı projeler teslim edilir, kod tabanına oturur ve çok sonra onların hiç kimse tarafından kullanılmadığını fark ederiz.

Düşünmenin bir cazibesi var: Onları burada bırakabiliriz, bir gün faydalı olabilirler.

YAGNI’nin geleneksel uygulaması geliştirme aşamasındadır. Ancak, hakkında daha az şey duyduğumuz bir YAGNI biçimi var: zaten kod tabanında bulunan projelerin YAGNI’si.

Mevcut bir kod parçası kullanılmıyorsa, onu kaldırmanız yeterlidir. Gelecekte faydalı olabileceği gerçeğine güvenmeyin. Şu an için kesinlikle zararlı: Çevresindeki yeni gelişmelerin bunu hesaba katması gerekiyor, bu yüzden bunların uygulanmasını zorlaştırıyor. Üstelik yeni gelişmeler, kullanılmayan özelliği kapsayan testleri de kırabilir. Ancak kullanılmayan bir özelliği kapsayan testler, analiz etmek için zaman kaybıdır.

Bu projeler yukarıdakiler kadar zehirlidir ve onları pişmanlık duymadan koddan çıkarmalısınız. Anlaşılması daha az zaman alan kod, var olmayan koddur. Bu nedenle, bir proje yeterli değere sahip değilse, onun kod tabanınıza girmesini veya burada kalmasını engellemelisiniz.

Başka toksik proje örnekleriniz var mı? Onları nasıl hallettin?

Kaynak :

https://www.fluentcpp.com/2020/03/10/3-types-of-toxic-software-projects/