Bu yazıyı 08/04/2020 tarihinde yani bugün, Bilişim IO whatsapp grubundaki fikir alışverişimizin sonucunda yazmaya karar verdim. Bir de fırına özel tarifimle yaptığım cheesecake i verince beklerken bir yazı çıkar dedim.
Aslında çöp yazılımcı mı çöp yönetici mi konusunda yazacaktım ancak buna nasipmiş. Diğerini de yakında yazarım. Corona günlükleri gibi bir iki yazı yayınlarım belki. Yazıdan önce kısa bir noktaya değinmek isterim.
- Bu yazı argo içerir. Aslında mecaz ama argo diyelim tam olsun.
- Bazı durumları daha iyi açıklayan kelime bulamayışımı benim eksikliğime verin.
- Bu yazı da kervanın düzülmesinden yazılımcının walla benim makinamda çalışıyor sonucunu çıkar mı çıkmaz mı? Bilmem. Gelin biz yolculuğa çıkalım sonuca siz karar verin.
Herkesçe malum çok şık bir atasözümüz var.
Kervan yolda düzülür.
Kervanın düzülmesine geçmeden bir konuyu hemen cebimize koyalım. Sonunda lazım olacak. Saklarsak samanı gelir muhakkak zamanı…
- Ortada bir kervan var ise bir kervancı başı kesin vardır. Belki de kervanın gerisinde bir de sahibi olabilir.
Kervanda sıradan bir çalışana develerin sayısından, sağlığından sorumlu olan kişiye kervancı diyelim. Bu kervanın da çölleri aşarak Hicaz’a gideceğini düşünelim. Kervan doğrudan Hicaz’a gitmez. Yolda değişik şehirlere uğrar ve uğradığı yerlerde mal alır mal satar. Hatta yolda kendilerine katılan birçok ticaret adamı olur. Bu nedenle kervan yolda düzülür. Muhtemelen oldukça canlı, civcivli hatta yaşayan bir süreçtir. Ve her bir seferinde başlı başına iyi tasarlanması gereken bir süreçtir.
Kervancı başı, kervancıdan hayvanlar için aldığı bilgilerle bu planları yapar. Kimisi ince eler kimisi hiç elemez. Biz, elemez kısmından gideceğiz. Diğeri kolay.
Kervancı başı elinde 100 deve 40 katır 20 at olduğunu düşünerek bir plan yaptı. Alacaklarını, satacaklarını, yolda yiyeceklerini ve içeceklerini hesaplayıp kervancılara emir vererek bu develere yükletti. Ve yolculuk İstanbul’dan başladı, diyelim.
Sakarya, Konya, Hatay derken sıcak topraklara girdiler. Ben diyim 1 ay siz deyin 2 ay gittiler. Yolda aldıklarıyla – sattıklarıyla, yolda katılanlarla hem develerin hem kervancıların yükü artarsa ne olur?
Eğer kervancı başı en başta ince eleseydi aşağıdaki maddelere dikkat edecek ve herhangi bir sorun ortaya çıkmayacaktı.
- Kervandaki kervancı (çalışan) sayısı, hatırlarsanız yukarıda buna hiç dikkat etmedi.
- Develerin, katırların, atların sayısı kadar yaşları, sağlıkları, ağırlıkları. (Develerin ne kadar yükü ne kadar süreyle taşıyabileceği tamamen bununla ilgili.)
- Yiyeceklerin, içeceklerin ne kadar süre yeteceği.
Kervancı başı bu maddelere dikkat etmediyse kesinlikle en az bir, belki de birkaç kervancının başını yer. (Bu benim hatam ben yanlış yaptım diyen yönetici pek görmedim ben, ya siz?) Hatta kervan seferini tamamlayamadan dağılabilir de…
Peki kim bu kervancı başı,
- Gökten mi indi?
- Yoksa o da bir zamanlar diğerleri gibi kervancıydı. Bir şekilde yükselip kervancı başı mı oldu?
Bence ikincisi, o da bir zamanlar bir şekilde kervancıydı. Bu senaryodan gideceğim. Mavi kanlı olup mirasyedi olanlar ya da torpilliler konumuz dışında!!!
Kervancı başı, kervancıyken işini iyi yapsa develeri, katırları, yolları tanısa, önceden karşılaştığı sorunları bir kenara yazsaydı, emin olun kervancı başı olduğunda ince eleyip sık dokurdu. Böylece kendini, kervanını, kervancılarını ve/veya patronlarını zor duruma düşürmezdi.
Ok, şimdi elimizde bir kervan hikayesi var. Dönelim yazılıma.
Bugünkü whatsapptaki sohbetimizin ana konusu test driven development idi. Genelde yöneticilerin buna izin vermediğinden ya da nasıl yapılması gerektiğinden falan bahsedildi. Test piramidi falan paylaşıldı.
Test Driven Development, Acar pardon Agile Development gibi kavramları çok severim. Bana da bununla ilgili çok soru ya da şikayet gelir. İşte yeterince TDD yapmıyorlarmış, birim test yapmıyorlarmış, yeterince acar pardon agile değillermiş. vs vs…
Ben bu soru ya da muhabbetlere genelde tek bir soru ile eşlik ederim.
- Yazılım geliştirme planınızı, kodlama planınızı, karşılaşabileceğiniz teknik sorunları ve çözümlerini tanımlayan / tahminleyen gerçek anlamda teknik “mühendislik, yazılımsal” bir analiz / tasarım dökümanınız var mı? Hiç böyle bir döküman hazırladınız mı?
- Yani kabaca yazdığınız kodun nerede nasıl hangi şartlarda çalışacağını, kaç isteğe cevap vereceğini, ne kadar işlemci, memory, disk kullanacağını tahminlediniz mi? Hesaplamaya çalıştınız mı?
Nadiren aldığım cevap hayır oluyor. Genelde eveleme geveleme şeklinde devam eder bu konuşma. Yine aldığım cevaplardan biri de bugün olduğu gibi kelimesi kelimesine aynen şöyle oluyor.
tech designda bunun çıkartılmış olması gerekiyor zaten maliyetine kadar. tech designda yoksa ohoooo geçmiş olsun
Doğru diyor, çok doğru diyor da… Ben bu cevabı sevmiyorum. Bu cevap bana hep topun, suçun başkasına atıldığı hissini verir. Ben de bu hissi verene şunu sorarım. Peki sen bireysel olarak böyle bir döküman gelmeden en azından kendine düşen modülün, komponentin, birimin; işlemci, thread, ram, disk maliyetini hiç hesapladın mı? Junior, medior, senior farketmez sadece evet yaptım diyeni görmedim. Bunu hesaplamayı yapan sadece bir kişi ile tanışabilme şansına sahip oldum. Allah onun yolunu daima açık etsin.
Bu hesaplamaları her yazılımcı kendi modülünde, biriminde, komponentinde küçük küçük yaparak tekrar tekrar yaparak öğrenecek, alışkanlık edinecek ki bir gün kervancı başı olduğunda kervanı yanlış yola sürmesin. Benim takıldığım hatta sinirlendiğim nokta burası. Herkes her şeyi istiyor. Ama hazır istiyor. Emek yok, ter yok, uykusuz geceler yok. Ama her şeyin en idealini istemek var.
Sohbetlerimizin sonucunda, sohbeti ya da konuşmadaki kendi parçamı genelde şöyle bitiririm.
Kervan yolda düzülür. Kervan yolda düzülmezse üzülmeyin, kervancı o yolda düzülür.
Başta bir cebimize bir not almıştık. Bir kervan var ise bir kervancı başı ya da kervanın bir sahibi vardır. Bu da o kervan o yolda düzülmezse, kervancı o yolda kesin düzülecektir anlamına gelir.
Software Architect, System Architect adı her ne ise kervan yola çıkmadan yani yazılım geliştirme başlamadan hesaplamalarını tam yapmamış olabilir. Bu kesinlikle affedilemez. Ancak bir developer, bir yazılımcı, bir mühendis olarak o ekipteki herkes bu eksiği tamamlamaya çalışmaz ise hepsi birlikte toz duman olurlar.
Yazılım geliştirme süreci aynı bir kervan gibidir. Yola belirli planlarla çıkılır. Ancak yolda birçok değişken bir çok beklenmeyen durum ortaya çıkar.
Kervancı başı bindiği devenin, atın, katırın gücünü ve kapasitesini bilmeden yola çıkarsa o kervanın yolu karanlıktır.
Bir yazılım mimarı işlemci’nin, ram’in, disk’in, network’ün gücünü, kapasitesini hesaplamaz ise o projenin yolu karanlıktır. Eee ne olacak uygulama bir değil iki sunucuda çalışır olur biter diyenleriniz kesin olacaktır. Bizzat diyen tanıdıklarım var.
Geliştirdiği uygulamanın çalıştığı ortama ne kadar yük getireceği hesaplanmamış, anlık neye nasıl cevap verebileceği tahminlenlemiş yazılım projelerinde sorunlara getirilen her çözüm bir başka sorunu yaratır. Yani elinizde nur topu gibi bir sorun yumağı olur.
Bu yumaktan kaçınmanın tek yolu da yazılım metodolojilerinden önce bindiğiniz atın idrakine varmaktan geçer. TDD, Agile Development gibi metodolojilerden önce yazılım geliştirdiğimiz ve/veya yazılımları çalıştırdığımız ortamları çok iyi tanımalı, özümsemeliyiz.
Daha biz kullandığımız hatta yaşadığımız ortamların hangi koşulda nasıl tepki vereceğini bilmiyoruz. Neden TDD yapmıyoruz, neden acar değiliz diyoruz. Herkesi her şeyi acımasızca eleştiriyoruz. Ancak emin olun daha aynaya bakacak yüzümüz yok.
- TDD yapıyoruz abi, proda çıkmadan testte 2 + 2 = 4 sonucunu aldık.
- Scrum yapıyoruz abi, projeyi sprintlere böldük.
Peki 2 + 2 = 4 hesaplamasını yapıncaya kadar kaç thread açtın ne kadar ram yedin haberin var mı? Sprinte bölerken bir sonraki adımda seni neyin beklediğini hesapladın mı? Yoksa patron şunlar acil dedi diye onlara mı öncelik verdin.
Ben cevaplayayım. Hiç bir hesap yapmadın. Patron neye acil dediyse, onlar ilk sprinte alındı.
Peki nerede senin metodolojin, ideallerin. Onu da söyliyeyim. Onlar ecnebilerin Platon ‘u oryantalistelerin Eflatun ‘unun idea ‘lar dünyasında kaldı.
TDD ya da Agile Metodoloji, siz zemini doğru hazırlamış, süreci iyi planlamış iseniz size yardımcı olur. Diğer durumlarda ayağınıza taş bağlayıp denize atlayın daha iyi. Çünkü metodoloji iş yapmaz. O size bir projeksiyon sunar. İşi siz yaparsınız.
Hesaplamadığınız her sorun, ayağınıza bağladığınız bir taştır. Metodoloji o taşı sizin yerinize almaz, alamaz, taşımaz, taşıyamaz. O test yap, sprinte böl der. Doğru diyor da testi nasıl hangi şartlarda yapacaksın, sprinti neye göre böleceksin demez. Yaptığın işten haberin yok. Eline bir bayrak diline bir slogan dolamışsın Viyanayı 3 seferde kesin ben alacağımda ben alacağım diyorsun. Gazan mübarek olsun.
Ben şunu bilir şunu söylerim. Bindiği atın huyunu bilmeyen onu istediği kadar süslesin o at o biniciyi üzerinden muhakkak atar.
Günün sonuda döner dolaşır bu iş patronda biter. Patron ne zaman senin idea lar dünyana gelir, ne zaman senin ideallerini paylaşır biliyor musun? Ona neyi neden yapılması gerektiğini basma kalıp, slogan cümlelerle değil tek tek teknik nedenleriyle anlattığında hatta birkaç kez ispatladığında, patron senin ideallerini paylaşır. Hatta kervanı bile sana teslim eder. O zaman sen kervanı istediğin gibi yönetirsin.
O zaman dans…
