Asıl söyleyeceğimi başta söyleyeyim ki yanlış anlaşılma olmasın. Bu yazıdaki “bağımlılık” ifadesi İngilizce’deki “dependency” değil, “addiction” kavramının karşılığıdır.
Günümüzde yazılım dünyasında yer alıp da paket kullanmayan kimse var mı bilmiyorum. “NuGet” bugün ortadan kaybolsa, kaç projenin durmasına neden olur kimbilir.
Kimler Azer KOÇULU ismini hatırlıyor bilmiyorum ama kendisi bir günde Facebook dahil pek çok web uygulamasının bir anda çökmesinden sorumlu; hem de sadece 11 satırlık bir kodla! Üstelik de bu kodun hacking ile hiçbir alakası yok.
Kısace hatırlamak gerekirse Azer, NPM adındaki JavaScript paket yöneticisine hepi topu 11 satırdan ibaret olan, bir metni istenen uzunluğa kadar sola belirtilen karakteri ekleyerek uzatan bir paket yazmıştı.
Buraya kadar her şey çok güzeldi. Ta ki Azer, “kik” adındaki bir başka modülü NPM’ye yükleyene kadar. Bir sohbet uygulaması olan KİK bunu fark ettiğinde isim haklarının kendilerine ait olduğunu ve projesini başka bir isimle adlandırması için Azer’e bir e-posta atar ve olaylar hızla gelişir.
Dileyenin detaylarını burada okuyabileceği şekilde gelişen olaylar silsilesi, Azer’in NPM’nin de KİK’in tarafını tutması ile yazdığı tüm paketleri NPM’den kaldırması ile devam ediyor ve kendisine “İnterneti bozan adam” sıfatını kazandıran olaylar bundan sonra gelişiyor.
Günümüzün popüler JavaScript kütüphanelerinden React‘ın “leftpad“e bağlımlılığı (bu sefer “dependency“) olması sonucunda bu teknolojiyi kullanan pek çok proje 22 Mart 2016 tarihinde derlenemedi/çalışmadı. Bu konuda hızlı bir şekilde aksiyon alınıp sorun çözülse de yaşanan bu olay paket bağımlılığının ne kadar büyük bir risk teşkil edebileceği konusunda güzel bir örnek olarak tarihe geçti. (mi?)
Lev Troçki’nin de dediği gibi “İnsan, tembel bir hayvandır“. Suyun akarken en kolay yolu tercih etmesi gibi insan doğası da en kolayı tercih etmek üzere programlanmıştır ve bu yadsınamaz, yaşamsal bir niteliktir. Yazılım geliştirme süreçlerinin ve dillerinin gelişimini de inceledikçe görürüz ki diller gitgide makineden uzaklaşıp insan diline yaklaşmakta. Tabi ki bunun sonucunda da daha karmaşık yazılımları daha hızlı bir şekilde geliştirebiliyoruz. Günümüzde bu hız bile yetmiyor olacak ki artık pek çok işlevi daha hızlı kodlayıp sonuç elde edebilmek için, deyim yerindeyse “paketleri” kodluyoruz.
Buraya kadar olan kısımdan paket kullanımına karşı olduğumun düşünülmesini istemem, zira ben de projelerimde paketler kullanıyorum. Dikkati çekmek istediğim konu ise bilinçi paket kullanımı. Sorun şu ki paketler aslında bizim işimizi kolaylaştırmak için sunulmuş, içerisinde bir takım sihirli işler gerçekleşen kara kutular ve maalesef pek çok yazılımcı da paketler konusunda radyondan televiyona geçiş dönemindeki insanlar gibi bu sihirli kutuları büyük bir hayranlıkla izlemekteler.
“Ama paketlerden bazıları open source, bir sorun yaşarsak açar kodu bakarız” demeyin, o paketin o işi nasıl yaptığını anlasak zaten o paketi kullanmamıza gerek kalmaz. Evet, Amerika’yı yeniden keşfetmeye gerek yok ama Amerika kıtasının Hindistan’a daha kısa bir yol aranırken bulunduğunu unutmayın. Siz de Hindistan’ı ararken kendinizi istemediğiniz bambaşka bir kıtada bulabilirsiniz.
Dediğim gibi, asıl sorun paketleri doğru kullanmakta. Öncelikle “Gerçekten bu paketin sağladığı faydaya ihtiyacım var mı?” sorusunu kendimize sorup, dürüstçe bir cevap aramalıyız. Örnek olarak RESTful bir API çağrımı yapan projemiz olduğunu varsayalım. Hangi yolu tercih ederdiniz? .NET Framework içerisinde yer alan HttpClient sınıfını kullanmayı mı yoksa RestSharp ya da ServiceStack.Client gibi bir paketi kullanmayı mı? Her iki paketin de işimizi kolaylaştıran işlevler sunduğunun farkındayım ama bu işlevler çok da fazla zaman harcamadan, kod yazarak çözemeyeceğimiz şeyler mi? Asenkron çağrımlarla çalışan HttpClient ile kod yazamıyor musunuz? Ya da veriyi serialize/deserialize edemiyor musunuz? Bu paketleri kullanmak için zaten bilmeniz gereken temel bilgi eksiğinizin, aceleciliğinizin ya da tembelliğinizin dışına bir nedeniniz var mı? Eğer (dürüstçe yanıtladığınızda) varsa, birinci testimizi geçtiniz.
Birinci testi geçtikten sonra bu sefer ikinci test olarak sormamız gereken soru “Aynı işlevi sağlayan muadiller arasında hangisini seçmeliyim?” Subjektif olmakla birlikte bence cevabı en kolay olan bu. Hangisi çok tercih ediliyorsa. Buradaki bakış açısı birkaç kritere dayanmakta. Öncelikle, pek çok kişi tarafından tercih edilen bir ürünün, muadillerine karşı performans, kullanım, nitelikler ve sunduğu özellikler çerçevesinde daha iyi olduğu kabulünden yola çıkabiliriz. (Tabii ki burada daha az kişi tarafından kullanılan süper bir muadilin daha yeni hayata geçmiş olabileceğini unutmamalıyız.) Bunun yanında çok fazla kullanılan bir üründe sizin karşılaşacağınız bir sorunu daha önce daha çok kişinin yaşamış olabileceği ve bu sayede bir sorun yaşadığınızda ya da sorunuz olduğunda daha kolay yanıt alabileceğinizi varsayabilirsiniz. Aynı zamanda pek çok kişinin kullandığı, geçmişi olan bir paketin ilk çıkışından bu yana kat ettiği yolda olgunlaştığını da düşünebiliriz. Tabii ki tüm bunların yanında paketin güncellenme sıklığı, sorunların (issues) çözülüp çözülmediği, ne hızla çözüldüğü ve katkıda bulunan kişilerin (contributors) çokluğu da bakılması gereken diğer kriterlar arasında. Zira, sadece indirme sayısına bakarak artık devam etmeyen bir projeye bağımlı bir şekilde ortada kalma riskiniz yüksek. Tüm bunlar, bağımlılık ekleme sürecimizde ikinci testimizde yanıt aradığımız sorular olmalı.
Üçüncü testimizde ise bir adım ileri gidip kendimizi paketi geliştirenlerin yerine koymamız gerekiyor. Biz projemizi bu pakete bağımlı kılıyoruz, peki acaba kullanacağımız paket nelere bağımlı? Sizin bağımlı olarak taşıdığınız riskleri, kullanacağınız paketler de taşımakta. Hatta kullanmayı planladığınız paketin bağımlı olduğu paket(ler) hangi paket(ler)e bağımlı? Tüm bu soruların cevabı ne kadar kısa ve azsa o kadar iyi. Zira başka paket(ler)e bağımlı paket(ler) kullandığınızda hiyerarşik olarak tüm paketlerin riskini üstlenmiş oluyorsunuz.
Dördüncü testimiz, aslında önceki üç testten çıkan bir sonuç. Bu aşamada kendiniz sormanız gereken soru “paketin yayımcısına ne kadar güveniyorum?” Microsoft tarafından yayımlanan bir paket muhtemelen ilk üç kriterde çerçevesinde Ahmet KODYAZAR’ın yazdığı paketten daha çok güven verecektir. Burada elbette bir karşılık beklemeden yazılım geliştirme camiasına katkıda bulunan Ahmet kardeşimizi incitmek ya da cesaretini kırmak istemem, ancak Ahmet’in bu projeyi ne kadar daha sürdüreceği, ne hızla sorunlara çözüm getirebileceği ya da ne zaman pes edeceği benim için soru işareti iken projemi Ahmet’in koduna bağlamakta çok ciddi tereddüt yaşarım.
Tüm bu dört testten de geçen bir paketi güvenle fakat getirdiği risklerin de farkında olarak kullanabilirsiniz. Yazılım geliştirme süreçlerinde kendime vew birlikte çalıştığım kişilere en çok sorduğum soru “Neden?” dir. “Neden bu kodu yazdın?“, “Bu kodu neden böyle yazdın?“. Eğer bu sorulara cevap alabiliyorsam ne mutlu, ancak tatmin edici bir cevap yoksa o kodun işlevselliğine rağmen benim için pek bir değeri kalmıyor. Yapılan iş, arkası doldurulabildiği müddetçe değerli diye düşünüyorum. Yoksa günümüz dünyasında, yazılıma dair temel ilkelerden bihaber bir şekilde de pekala uygulama geliştirilebilir.
Aynı hassasiyeti paket kullanımı yönünden de bekliyorum. Paket kullanımı da para gibidir. “Siz ona sahip sahip olduğunuz sürece faydalıdır. Fakat o size sahip olmaya başladıysa başınız dertte demektir.“