Öngör veya Uyum Sağla

İbrahim Kürce
Jan 31, 2019 · 8 min read

Değiştirilebilir kod oluşturmayı destekleyen doğru pratikler olmadan, kötü şeyler gerçekleştiğinde değişime ayak uyduramayız ve bunun sonucu stresli bir süreç olur.

Yazının yedinci bölümünü okumak için tıklayınız.

Büyük bir özelliğin gerçekleştirilmesi üzerinde çalışırken, yazılım takımları üzerinde çok stres olur. “Tamam her şey şimdi derlendi ama inşallah kod çalışır. Bunun sonucunda ne göreceğimi ben de merak ediyorum”

Stres daha iyi bir ürün elde edilmesine yardımcı olmaz. Geliştiricilerin veya temel olarak yazılım geliştirme endüstrisinin, ihtiyaç olduğunda değişime uyum sağlayan prensip ve pratikler yerine değişimin öngörülmesi etrafında inşa edildiğini fark ettiğinde, bu genç endüstrinin ilerlemesinin önünde hala uzun bir yolun olduğunu söyleyebiliriz.

Bu ikiliktir: öngörmek ya da uyum sağlamak (anticipate or accommodate). Çoğu geliştiriciler, yazılımda değişikliğe henüz nasıl uyum sağlayacaklarını bilmiyorlar. Her sinema oyuncusunun, ilk seferinde doğru çekimi yapmak zorunda olduğunu düşünün. Bir film yapmak çok stresli bir iş olurdu, herhalde. İlk seferde mükemmel olmak zorunda olmadığınızı bilmek, her şeyi çok daha kolay hale getirir ve performans endişesinin stresini ortadan kaldırır. Geliştiriciler, yeni bir fikir ya da bir şeyler yapmanın yolunu keşfederler ve daha fazla zorluk üstlenirler, artık bir kez başarısız olduklarında hâlâ iyileştirme yapabileceklerini bilmiş olurlar.

Birçoğumuz geleceği doğru bir şekilde tahmin edemeyiz. Takımdan istenilenleri kullanıcıya teslim ettikten sonra, kullanıcının isteyebileceği şeyleri kim tahmin edebilir? Gelecekteki ihtiyaçları önceden öngörmek yorucu olabilir ve muhtemelen yine de çoğu zaman yanlış tahmin edersiniz. Yine de pek çok geliştiricinin, bugün böyle bir ihtiyaç olmasa da, gelecekteki ihtiyaçlarını kodları içinde tahmin etmekle meşgul olduklarını görüyorum. Bu, şu anda ihtiyaç duyulmayan özellikler için geliştiricilerin zaman kaybetmelerine neden oluyor. Ayrıca, şu anda ihtiyaç duyulan şeylerle başa çıkmak için değerleri zamanları da boşa harcıyorlar.

Geliştiriciler, gelecekte kullanıcının ne isteyebileceğini tahmin etmeye çalışmak yerine, ya istendiğinde değişiklik yapmanın yollarını bulmuş olsaydı? Ya kod değişikliğini kolaylaştıran bazı prensipler ve pratikler olmuş olsaydı? Sonra kaçınılmaz olan gerçekleşip müşteri yeni bir özellik istediğinde, kod buna uyum sağlayabilirdi.

Bu sadece hüsnükuruntudan ibaret değil. Geliştiricilerin, değişimle başa çıkabilmek için paylaşabilecekleri bir dizi standart ve pratiklere sahip olmaları gerekiyor.

Yazılımda “İyi” Nedir?

Yazılımı “iyi” yapan şey nedir? Geliştiriciler bir kod parçasına baktıklarında, iyi yazılıp yazılmadığına nasıl karar verirler? Aradıkları şeyler nelerdir?

Geliştiricilere bu soruları sorduğum zaman, nadiren tutarlı cevaplar alıyorum. Bazıları için, iyi kod hızlı ve verimli olmalıdır. Diğerleri için okunması ve anlaşılması kolay olmalı. Ötekileri ise hatasız olması gerektiğini söylüyorlar.

Bunların hepsi iyi şeyler ama bunları nasıl başarabiliriz? Ve bir şeyi diğeriyle takas etmemiz gerektiğinde, ayrımı nereden yapmak zorunda kalırız? Bunlar, yöneticilerin ve yazılım geliştiricilerin günlük olarak nasıl çalıştıklarını etkileyebilecek sorulardır.

Müşterinin yaşadığı dış nitelikler (kullanılabilirlik, hatasızlık, zaman bazlı güncellemeler vb.) yazılımın iç niteliklerinin belirtileridir. Kullanıcılar bu iç nitelikleri doğrudan deneyimlemeseler bile, onlardan etkilenirler. İç kalitesi düşük yazılımlar ile geliştiricilerin de çalışması zor olur.

Çok uzun bir süredir, yazılımın değiştirilmesinin gerekmediği varsayımına dayanarak, yazılım geliştirmenin bir kerelik bir etkinlik olduğu düşünüldü. Ancak gerçek şu ki, kullanılan yazılım değişiklik ister ve bu iyi bir şeydir. Kullanıcıların yazılımdan değer üretmek için farklı yollar bulması demektir. Geliştiriciler, yazılımlarını değiştirilebilir hale getirerek, kullanıcılarla uyum sağlamak isterler.

İnsanların değerli bulduğu ve kullandığı yazılımın gelecekte değişmesi kaçınılmazdır. Bu nedenle geliştiricilerin, yazılımla çalışmayı kolaylaştıran, iç kod kalitesini artıran standart ve pratiklere odaklanması gerekir. Geliştiricilere iç kod kalitesini artıran şeylerin neler olduklarını sorduğumda, tutarlı bir cevap alamıyorum. Henüz bu yönde bir evrensel uzlaşmaya varamadık.

Sadece bir kişiye değil genel olarak sanayimize yönelik, iyinin ne olduğu konusunda ortak bir anlayış geliştirmeliyiz. Bunu yaptığımızda, profesyonel yazılım geliştirmenin temel hedefleri hakkında fikir birliği sağlayabileceğiz. Genel olarak, iyi yazılımın yapması gerekeni yaptığını ve gelecekteki ihtiyaçlara göre değiştirebilir olduğunu söyleyebiliriz.

Yazılım, sadece bugün için değil, gelecekte de ondan değer elde edebileceğimiz bir varlıktır. Yazılım yaşam döngüsünün yönetimi, ürün mimarisini inşa etmenin ve ürün tasarımın önemli bir parçası haline gelmiştir. Bu nedenle yazılım geliştirmenin ayrılmaz bir parçası haline gelmiştir.

Elbette, geliştiriciler çoğunlukla kodlarının hangi bölümünün değişmesini gerektiğini önceden kestiremezler. Bu nedenle, tüm kodlarını değiştirebilir şekilde yazmaları gerekir. Geliştiriciler, kaliteli yazılımın ne olduğunu ve zaman içinde nasıl değiştirilmesi gerektiğini anlayarak, değişilebilirliği yönetebilirler.

Pek çok kişi, yazılımdaki kaliteyi, doğru olanı yapan, hatasız olan, hızlı çalışan gibi ölçütlerle dış kalite olarak görebilir. Ancak bu kitapta tartışacağımız, yazılımın iç kalitesi olacaktır.

Neden Dokuz Pratik?

Scrum, Çevik geliştirmeyi ve Extreme Programlamayı desteklemek için az sayıda bir çerçeve sağladı ve başlangıçta on iki temel pratiği önerdi.

Bunu dokuz temel pratik olarak sadeleştirdim. İlk ikisi, Scrum hakkında çoğu insanın ne düşündüğü hakkında, son yedisi ise özel teknik pratiklerdir.

Bunlar;

  1. Nasıldan Önce Ne, Niçin ve Kimin İçin Olduğunu Söyle
  2. Küçük Gruplar Halinde İnşa Et
  3. Sürekli Bütünleştir
  4. İşbirliği Yap
  5. Temiz Kod Yaz
  6. Önce Testi Yaz
  7. Testlerle Beraber Davranışları Belirle
  8. Tasarımı En Son Gerçekle
  9. Miras Kodu Yeniden Düzenle

İnsanların kafasında, ortalama 7 şeyi tutabildiği ve en fazla hatırlayabileceği ise 9 şey olduğu söylenir. Bu dokuz pratik en yüksek değere sahip olarak gördüğüm, bununla birlikte en kötü veya yanlış anlaşılan pratiklerdir.

Dokuz pratiğin hepsini uygulamak zorunda değilsiniz, ancak amaçlarını anlamak zorundasınız. Bu pratiklerden birinin ele aldığı sorunları hafifletmek için başka yollarınız varsa, o zaman güvenli bir şekilde yenisiyle değiştirebilirsiniz. Fakat aynı Picasso’nun yaptığı gibi, onları güvenli bir şekilde aşabilmeniz için önce kuralları iyi anlamanız gerekir.

Bu dokuz pratik, değişebilir kodların oluşturulmasını desteklerken, yazılım geliştirme sürecini kolaylaştırmaya yardımcı olur.

Bölüm 5: Nasıldan Önce Ne, Niçin ve Kimin İçin Olduğunu Söyle

Geleneksel bir yazılım projesinde, geliştirme süresinin yaklaşık %50'si gereksinimlerin toplanmasına gitmektedir. Takımlar gereksinimleri toplamaya odaklandıklarında, kodlama konusunda teknik bir yönelimi olmayan (iş analistleri gibi) en az deneyimli olan insanları işe alırlar. Ve bu insanları, müşteriler ile konuşmaları için gönderirler.

Hepimiz, insanlara duymak istediklerini söyleme eğilimindeyiz ve müşterilerle yüz yüze gelen profesyoneller hâlâ bu tuzağa düşerler. Müşteriye şunları demek pek hoş karşılanmaz; “Hayır, siz bunu istemezsiniz, şunu istersiniz” veya “Nasıl çalışacağı hakkında endişelenmeyin ve bunu yapmak için geliştiricilerimize güvenin.

Müşterinin isteklerini listelemek kolaydır ve onlara duymak isteyecekleri şeyleri söyleriz: “Anladık, bunu yapabiliriz.” Ama gerçekten yapabilir miyiz? Daha da önemlisi, yapmalı mıyız?

Konuşulan dilde, uygulama üzerine konuşmak kolaydır. Gerçekten uygulamayı yapmaya kalktığımızda ise bu iş zor olur. Özel olarak anladığımdan bir genelleme yaparım. Bu genelleştirmeyi duyup ve kendi anlayışınıza göre, tekrar yorumlarsınız. Sonunda, ortak zemin olduğunu düşündüğümüz 2 farklı deneyimsel anlayışa sahip oluyoruz.

Müşteri gereksinimleri analiste söyler, analist bunları yazıya döker. Geliştirici bunları okur ve koda döker. Bu işin en sonunda ise müşteri şunu der, “Benim dediğim bu değildi. İstediğim de bu değildi.”

Nasıl Olacağını Söyleme

Müşteriler ve müşteri hizmetleri yöneticileri, geliştiricilere bir şeyi nasıl yapacaklarını söyleme fikrinden uzak durmalıdır. Bunun birkaç sebebi bulunur.

Yazılımın ortaya çıkış şekli, nasıl yapılacağını bilmeyen insanlar için çok sezgisel değildir. Yazılım, sanki bir anda bilgisayara oturup, her şeyi çözebilir bir hale gelecek gibi bir iş değildir. Bu nedenle, meslekten olmayan insanlara karşı yazılım geliştirme süreçlerini daha anlaşılır bir hale dönüştürmek için, büyük çaba harcanmaktadır. Bu makul bir istektir ama sıkı bir gereksinim kümesi ortaya çıkarmaktadır.

Gereksinimler iyi bir fikir gibi gözüküyor ama insanlar “nasıl” üzerinden iletişim kurmaya alışkın oldukları için, bunun sonucunda çözdüklerinden daha fazla soruna neden olurlar. Bu arada, bu konuşma dilinden kaynaklı bir sorundur. Öz-bilincin çalışma şeklinin sistematiğidir ve yazılım gereksinimlerine mahsus değildir.

Nasıl yapılacağını söyleyen gereksinimleri görür görmez, geliştirici takımları sanki elleri arkalarından bağlanmış gibi hissederler.

Yazılım geliştirme artık bilgisayara bunu yapma, şunu yap gibi emirler vermek gibi değildir. Artık, bilgisayarın sahip olduğu nesnelerin etkileşimine dayanarak bu işleri yapmaya zorlandığı, bir dünya yaratmakla ilgilidir.

Ve iş kurallarımızla beraber bir şeyler yapmakla ilgilidir.

İş kuralları sistemin kurallarıdır, if ifadeleri içindeki kod parçalarıdır. İş kuralları sisteme, ne zaman harekete geçmesi gerektiğini söyler.

Yazılım geliştiricileri, bu kuralları, modellediğimiz domain(etki alanı) olarak ifade etmek ister. Yazılımımız, domain veya işletme için neyi modelliyorsa, kendi terminolojisini kullanmak ve bu domain bilgisi üzerine işlem yapmak isteriz. İş kurallarımızın, yazılım modellerimizdeki (ya da kendi isimlendirme ile problem domaini) nesneleri takip etmesini isteriz.

Yazılım geliştiricileri de aynı şeyi yazılım nesneleriyle yapmak isterler. Bir programın sanal dünyasındaki nesneleri, gerçek dünyadaki nesnelerin ilgili yönlerini temsil etmektedir.

“Nasılı”, “Neye” Dönüştürmek

Müşteri ile işbirliğine dayalı bir ilişkiye hepimiz sahip olmalıyız. Ancak konuşulan dil, sorun olmaya devam eder. Bir şeyi nasıl yapılacağını söyleme modelinin başarısız olması çok kolaydır. Nasıl yapılacağının domaini, aslında yazılım geliştiricinin domainidir.

Yazılım geliştiricileri olarak, Ürün Sahipleri’nden (Product Owners) ve müşterilerden ne istediklerini ve neden istediklerini bilmek isteriz. Aynı zamanda, kimin için olduğunu da. Ancak, bize nasıl yapılacağını söylemelerini istemeyiz, çünkü orası bizim işimizdir. Nasıl olduğunu bilen de tek kişi biziz, yani yazılımcılar.

Kendim için bir ev yaptırmak isteseydim, bir mimar, müteahhit, bir tesisatçı vb. kiralardım. Mimar bana çatının açısını kaç derece olmasını, müteahhit ise hangi çivileri kullanayım gibisinden sorular sorsaydı, onlara “işin kodu neyse ona göre yap, ayrıca iyi olsun” derdim. Mimar bana kodun ne olduğunu sorsaydı, onu bırakıp başka bir mimar ile anlaşırdım. İnşa kodunun ne dediğini bilmiyorum ama profesyoneller ile çalışmak bizi her zaman mutlu eder. Ayrıca, profesyonellere işlerini doğru yapacakları için güven duyarız.

Yazılım için “inşa edici kodlar” olmasa bile, “nasıl” ile başa çıkabilecek ve aynı zamanda yeni fikirler ve yeni yaklaşımlar sunabilecek eğitimli ve deneyimli profesyoneller vardır.

Yazılım geliştiricileri, soyutlamayı iyi yapmanın yanında somutlaştırmada da uzmandırlar. Geliştirme sürecinde, geliştiriciler, geliştirici olmayanlara bir anlam ifade etmeyebilecek her türlü alternatif çözümü bulabilirler, çünkü iyi bir geliştiricinin temel kaygısı sürdürülebilirliktir.

Ve bir şey yapmanın her zaman birden fazla yolu vardır.

Farklı ekiplerin tamamen aynı yazılımları oluşturmaları neredeyse imkansızdır. Bin tane geliştiriciye aynı gereksinimleri versem, bin tane farklı yaklaşım görürüm, ki yaşayarak bunu gördüm. Son görünüş belki aynı olur ama uygulamanın gerçekleştirilme detayları çok farklı olur. Bu iyi bir şeydir, yeni ve daha iyi fikirler buradan gelir ama bağlamın ilk olarak belirlendiği bazı ortak zemine, standartlara ve pratiklere ihtiyaç duyarız. Böylece, gerçekleme üzerinde çok fazla bağımlılık olmadan, yazılımı düzgünce oluşturabiliriz.

Farklı geliştiriciler, işleri farklı şekilde yaparlar. Bu işleri yapmanın tek bir doğru cevabı yoktur. Bir geliştiricinin bir özelliği nasıl gerçekleştireceği beni çok ilgilendirmez. Beni ilgilendiren şey ise geliştiricilerin seçtikleri yol ile seçmedikleri arasındaki farkı bilmesi gerekliliğidir.

Yazılım geliştiricilerin, bazı temel prensipler, şablonlar ve pratiklerin haricinde, gerçekleme detaylarını standart haline getirmesi gerekmez. Ancak, davranışları nasıl tanımladıklarını ve hangi testleri yazacaklarını standart haline getirmeyi kesinlikle isterler. Davranışları belirtmek için hangi testlerin yazılacağı konusunda, geliştiriciler hemfikir olabilirlerse, o zaman büyük ortak noktalara ulaşabilirler.

Projede Ürün Sahibi Olsun

Üzerinde çalıştığım her harika yazılım geliştirme projesinde, muhakkak bir Ürün Sahibi(Product Owner) olmuştur. Bu kişi, üründen sorumlu olan kişi, müşteriyle en çok temasa geçen kişi ve ürünün gerçekte ne yaptığını en iyi anlayan kişi olur. Ürün Sahibi yetkili bir kaynak olur ve bu rolün varlığı hayatidir.

Ürün Sahibi, sadece teknik bir rol olmasa da, geliştirme sürecini yönlendirmekle kalmaz, aynı zamanda onu domine eder. Aslında, ürünün ne olduğu hakkında kesin bir bilgiye sahipse, Ürün Sahibi’nin teknik olmaması daha iyi sonuç doğurur.

Ürün Sahibi nihai otorite olmalıdır. Ürün Sahibi bazen yanlış olsa bile, yazılım geliştiricilerin sorulara açık ve doğrudan cevap vermeleri gerekir. Geliştiriciler, çoğu insanın hiç düşünmediği ayrıntılara vâkıftırlar.

Ürün Sahibi, “sonraki yapılacak en önemli özellik budur” diyen kişidir.

Ürün Sahibi, birikmiş işlerin(backlog) sırasını belirler. En önemsizleri en sona bırakır.

Geliştiricilerin kimsenin düşünmediği soruları sormakta üzerlerine yoktur. Bu soruları yapmak zorunda oldukları şeyi yapmak için, çok detaylıca sormak zorundadırlar. Eğer bunu yapmazlarsa, bilgisayarın ne yapacağı konusunda emin olamayız ve sonuç olarak program çöker. Ürün Sahibi, gereken bu doğru cevapları vermesi için vardır.

Spesifikasyonlar olmadan çalışma düşüncesi, geliştiricileri korkutur. Geliştiricilerden bunu istemek de etkili olmaz ama geliştiriciler tüm gereksinimler olmadan bir şeylere oluşturmaya başlayabilirler. Bu da bizi, “Nasılı” değil “Neyi” sormamız gerektiği düşüncesine götürür.

Öyleyse, gereksinimlerin alternatifi nedir?

Hikayeler Neyi, Niçini ve Kimin İçini Söyler

Yazının devamını okumak için.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade