En büyük güç zihinsel esnekliktir. Zihinsel esneklik perspektif değiştirebilmeyi sağlar. Perspektif her seydir. İnsan onunla yaşar, algılar, mutlu ve mutsuz olur, görür ve karar verir.
Hayata hep aynı pencereden bakılmaz. Gerektiğinde perspektif değiştirmek zaruridir. Yeni bir perspektif bir anda her şeyi başka türlü görmeyi kolaylaştırır. İnsan çoğu zaman olayların değil, kendi perspektifinin mahkûmudur.
Zihnin esnek kalabilmesi için sürekli olanlarla değil, kendisiyle meşgul olması gerekir. Dış etkenler zihni şekillendirir ve her şeye onların dayattığı perspektiften bakmayı öğretir.
Zihinsel esnekliği kazanmanın en etkili yolu olanları olduğu gibi kabullenmek ve teslimiyettir, cünkü direnç, zihni tek bir gerçekliğe hapseder. Kabulleniş ise zihni yeniden hareket ettirir. Bu kabulleniş zihnin zaman içinde solmasını engeller. Solmayan bir zihin ise aynı olaya her seferinde başka bir pencereden bakabilecek kadar canlı kalır.
Zihninizi bir gül gibi düşünün. Onu solduran fırtınalar değildir; her fırtınaya direnmeye çalışmasıdır. Kabulleniş rüzgâri durdurmaz, ama kökleri güçlendirir. Güçlü kökleri olan bir gül nasıl kolay kolay solmazsa, kabullenmeyi öğrenmiş bir zihin de perspektifini kaybetmez.
Belki de en büyük güç, fırtınaları durdurmak değildir. Onlara rağmen solmayan bir gül olabilmektir.
Dünyada varligini artirmaya calisanlar degil de hep hiclige ulasmaya calisanlar var olmuslardir.
Ahlak insanin en somut tarafi ile en soyut tarafinin iliskili hale gelmesidir. Insanim özü ile sözü arasindaki bosluk bir ahlak boslugudur. Ya kapatilir ya da ucurum acilir.
Yaratan nezdinde hersey yasandi ve bitti. Rahat olun.
Kimseye planlarinizi anlatmayin. Sessizce calisin, basariyi da sessizce yasayin.
Sadece özgüven yoksunu insanlar ilgi ve övgü beklerler. Genel olarak kimsenin sizi övmesine izin vermeyin. Bildigiiniz seylerin size anlatilmasinin bir anlami yoktur. Insanlari sizin eksiklerinizi dillendirmeye tesvik edin.
Kendinizi anlatmayin. Birakin baskalari konussun. Herkes kendisini anlatmaya meraklidir. Dinleyin ve ögrenin. Masadan kaltiginizda siz karsi tarafin herseyini bilirken, karsi taraf sizin hakkinizda hicbir fikir sahibi olamayacaktir.
Hergün kisisel gelisiminize yatirim yapin.
Bosa vakit harcamayin. Ölünce dinlenmek icin yeterince vaktiniz olacak.
Hayati bir bilgisayar oyunu gibi görün. Tek bir sansiniz var ve gelebileceginiz en iyi levele gelmeye calisin. Kaybedecek hicbir seyiniz yok.
Hayatta anlam aramayin. Kendinize bir hedef secin ve onu gerceklestirmek icin en üstün gayreti gösterin.
Para, mal, mülk anlamsiz degerlerdir. En kiymetli degerleriniz size en yakin olan insanlardir. Onlar ile mümkün olan en yüksek seviyede kaliteli vakit gecirin.
Kendinizden vazgecmeyin. Hayatinizin basrolü hep siz kalin. Figüranlar hayatiniza cokca dahil olup, ayrilacaklar. Siz kendi filmizi cekmeye devam edin, kimseye hayatinizda basrolü vermeyin, özellikle karsi cinse.
Bir gün öleceginizi hatirlayin. Mezarliklara ugramayi aliskanlik haline getirin. Ölümü yeni bir baslangic olarak adledin ve merakla bekleyin, ama bu hayatinizdaki potansiyelinizi en son raddesine kadar kullanin ve icinden gecin.
Spor yapin, yürüyün, kas kütlenizi artirin. Protein ve takviye alin.
Iyilik yapin, iyilik iyidir.
Yaptiginiz her isi severek yapin. Ayni isi o hali ile bir daha yapmayacaksiniz.
Hep sükredin.
Kontrolünüzde olmayan hicbir seye kafa yormayin. Sadece düsünceleriniz kontrolünüzdedir. Bunun haricinde bu dünyevi yasamda hicbir sey kontrolünüz altinda degildir. Kontrol etmeye calismak beyhude bir cabadir. Kendinize ve düsüncelerinize odaklanin.
Her olani oldugu gibi kabul edin. Olmasi gereken olur, olmasi gereken olacak.
Kitap okuyun.
Hayati dengeli yasayin. Fazla vermeyin, cok almayin.
Hayatinizin ilk yarisindan almaniz gerekenleri alin, diger yarisinda verin.
Olumlu düsünün.
Sevin, yarin yokmus gibi sevin.
Huzur arayin, huzur verin.
Sizden daha bilgili, cesur, zengin, akilli insanlarla biraraya gelin, düsük seviye insanlarla zaman kaybetmeyin. Birlikte oldugunuz insanlarin ortalamasi haline geleceksiniz.
Bir gün bu dünyadan ayrildiginizda, arkada biraktiginiz sevdiklerinizin sizin hakkiniizda ilk akillarina gelen hos bir sada birakmis olmaniz olsun.
Amaciniz hayatta kalmak degil, insan kalmak olsun.
Gidenin arkasindan üzülmeyin. Ders cikarin ve eksiklerinizi tamamlayin.
Mutlulugu aramayin. Mutluluk dengeli bir hayatin yan ürünüdür.
Kendiniz icin, zevk aldiginiz birseyler yapmiyorsaniz, bütün emekleriniz var olmayan bir dünyanin boslugunu doldurma cabasindan ileriye gitmez.
Aslinda hic kimsenin umrunda degilsiniz. Buna en sevdikleriniz bile dahil. Esegin calistigi atadir misali baskalari icin ömrünüzü tüketiyorsunuz. Hicbir seye sahip degilsiniz, ölünce yaninizda birsey götüremiyorsunuz, sahip oldugunuz herseyi siz öldükten sonra baskalari sahipleniyor ve döngü kendisini tekrar ediyor.
Insanlar yok olma korkusunun yanina var olma cabasini koyup, hayatlarini dis etkenlere bagimli sekilde sürdürme egilimi gösterirler. Evrensel ölceklerde cok kisa bir yasam süresine sahip insan, kendisini bulamadan bütün korku ve cabalari ile hakikat idraki yoksunu olarak ömrünü tamamlar. Var m isin ki yok olmaktan korkuyorsun diyen Farabi cok yillar önce bu konuya isaret etmistir.
Nedir o halde o hakikat? Hakikat sizsiniz. O sizin gercekleri kavrayabilmesi icin gerekli ortam ona hazir olarak sunulmus. Her sabah dogan günese bakmaniz yeterli olacaktir. Onu orada asili tutan ve parlatan seyin fizik kurallari oldugunu mu düsünüyorsunuz? Eger öyle ise, varliginizi da ispatlayabilirsiniz o halde? Birseylere dokundugunuzu, birseyleri gördügünüzü, birseyleri isittiginizi mi düsünüyorsunuz? Bunu neye dayanarak savunuyorsunuz? Hayati boyunca gün isigi bile görmemis birkac yüz gramdan olusan bir et parcasinin etrafta olup, bitenleri kavramak icin sizinle sürekli konusuyor olmasina mi?
Hazineler her daim derinlerde gizlidir, denizin derinliklerinde, topragin altinda, demirden kasalarin icinde oldugu gibi. Bu yüzden erisilmeleri güctür. Gercekler de bir hazine gibi insanin kendi icinde gizlidir. Denizin yüzeyinde hazine aramakla insanin kendi disinda o hazineyi aramak ayni türde bir beyhudeliktir.
Bu hayatta kendinize öncelik verirseniz ve gerceklere odaklanirsaniz, her yolun Roma’ya cikisi gibi sizde kendi icinizdeki o hazineye dogru yol almaya baslarsiniz. Bir bilgisayar oyununda oldugu gibi tüm düzen sizi bunu yapmaktan alikoymak üzerine kurgulanmis. Hazineler o iclerinde tasidiklari deger olmasaydi bir anlam ifade etmezlerdi. Ayni sekilde erisilir olmalari da kolay olsaydi ayni sey gecerli olurdu. Bu iki sebepten ötürü her hazine kendisine erisilmesini zor kilmak ister ki degeri bilinebilsin ve ugrunda fedakarlik yapmak anlamli olsun. Ice yolculuk da böyle birseydir. O hazinenin pesine düsenler, onu bulduklarinda, asil pesine düstükleri seyin kendileri oldugunu görürler.
Insan olaganüstü iyi tasarlanmis bir organizma. Disardan bakinca bunu görmek zor degil. Disi bu kadar güzel tasarlanmis bir varligin, ic dünyasinin nasil mucizevi bir yapida olabilecegini düsünmekten kendisini alamiyor insan!
Tapduk Emre’nin dedigi gibi: Benim inanip, kabullendiklerimin cok az bir kismi gözümle gördüklerimdendir.
Tapduk Emre baska birsey daha söylemis: Az cogun ispatidir. Hakikatler az da olsa kendilerini gösterirler. Bu fiziksel mevcudiyetin ötesinde cok büyük anlamlarin gizli ve var olduklarina isaret eder.
Yazılımcı olarak bazı gerçeklerle yüzleşmemiz gerekiyor.
Copilotu sadece bir sefer Claude Sonet 4.5 ya da türevleri ile deneyimleyen bir yazılımcı, anti yapay zeka savlarının birçoğunun gerçek dışı olduğunu görecektir. Nedir bu anti yapay zeka savları?
Vibecoding iyi netice vermez,
Senior programcı vazgeçilmezdir,
Yapay zeka yazılımcı mesleğini ortadan kaldıramaz,
ve türevleri…
Yapay zekanın tecrübeli bir yazılımcıyı ortadan kaldırma ihtimalinin olmadığını düşünenlerdenim. Aynı şekilde vibecoding hızlı MVP tarzı prototipleme için kullanılabilecek bir yöntemdir. Ancak yazılıma yeni başlayanlar için vibecoding bir zehirdir. Adapte olabilen senior vazgeçilmez olacaktır.
Bunlara değindikten sonra, asıl anlatmak istediğim mevcuza gelmek istiyorum.
Statükocu zihniyet…
Bence çok hızlı bir şekilde bu statükoyu korumacı zihniyetten vazgeçmek gerekiyor. Kendimize asıl sormamız gereken soru şu:
Biz yazılımcılar için çalışma tarzı nasıl değişecek ve biz buna nasıl adapte olabiliriz?
Bugün modern bir araba fabrikasında insanlar sadece gözlemci durumda. Tamamen karanlıkta faaliyet gösteren fabrikalar var. Bir senior seviyesinde gelmiş programcının teknik olarak yapay zeka ile rekabet etmesi imkansız. Senior pogramcılar ilerde yapay zeka işini yaparken gözlemci ve kontrolcü konumunda kalabilir.
Benim yanımda örneğin benim kadar, belki de daha yetkin birisi oturuyor artık: LLM. Ben ona hergün iş yaptırıyorum ve zamandan tasarruf ediyorum. İşi bilen birisinin ona ne yapması gerektiğini anlatması işin küçük bir bölümü artık. Kısa bir zaman sonra yazılımcılar olarak çok farklı bir ortamda çalışıyor olacağız. Buna ne kadar hazırız?
Kod yazmak işin çok küçük bir kısmı. Biz yazılımcılar bu dar alanda yapay zeka ile rekabet etmek zorunda değiliz. Bırakalım angaryayı onlar yapsın. Bizi ayrıcalıklı kılacak olan hardskilller değil, softskillerdir. Onlara odaklanarak her an artan yazılım talebini rahatlıkla karşılayabiliriz.
Yapmamız gereken tek şey değişimi kabul edip, onunla yaşama yetisi geliştirmektir.
Yeni bir programlama dilini öğrenmek için çok değişik yöntemler olabilir. Burada ben size en kestirme olanından bahsetmek istiyorum. Bu yöntemi kullanarak son bir kaç ay içinde dart, swift ve typescript dillerinde ve android, ios ve flutter ile çok rahat kod yazar hale geldim.
Yeni bir programlama dili öğrenmenin yolu bir yöntemden değil, bir araçtan geçiyor. Bu aracın ismi Github Copilot. Daha önce denemediyseniz, mutlaka bir göz atın, ne demek istediğimi anlayacaksınız.
Burada geniş çaplı bir Github Copilot tanıtımı yapmayacağım. Kullanmaya başladığınız andan itibaren ne kadar güçlü bir araç olduğunu göreceksiniz. Sizi sadece uyarmak istediğim bir konu var! Eğer herhangi bir programlama diline ve genel programlama konseptlerine hakim değilseniz, Github Copilotın sundukları sizin için Stackoverflow dan copy/paste edilen kod parçalarından farksız olacaktır. Buradaki önemli nokta yepyeni bir programlama dilini öğreniyor olsanız bile, Copilot tarafından sunulan çözümün ne anlama geldiğini kavrayabilmektir. Eğer bu varsa, yeni dili öğrenmeye başlıyorsunuz. Copilot tarafından sunulan kod parçasının teknik olarak ne anlama geldiğini göremiyorsanız, bu copy/paste den öteye gidemeyen bir çabaya dönüşecektir.
Şimdi gelelim esas mevzuya. Yeni bir programlama dilini nasıl öğrenebilirim? İlk etapta Hello World denemelerini terk etmek gerekiyor. Bir dili semantik yapısını oluşturan öğelerin nasıl çalıştığını anlayarak öğrenmeniz çok zor. Bu insanların kullandığı gerçek diller için de geçerli bir durum. İstediğiniz kadar kelimi hazineniz geniş olsun ve tüm gramere hakim olun, konuşma pratiğiniz yoksa, o dili konuşamazsınız. Pratik dediğiniz şey derdinizi bir başkasına başka bir dilde anlatma çabasına girdiğinizde gerçek anlamda vücut bulan birşeydir. Bunu şimdi programcılığa aktaralım.
Ortada çözmek istediğiniz bir problem varsa, kullanacağınız programlama dili bir araç haline gelir. Burada amaç dili öğrenmek değil, problemi çözmektir. Bunu aksine Hello World ile dili öğrenmeye çalıştığınızda dil araç değil, amaç haline gelmektedir. Amaç olan bir dili derinlemesine öğrenmeniz imkansızdır, çünkü onun gerçek yüzünü görecek derinliğe inemezsiniz. Bu sadece bir problem çözerken gerçekleşebilecek birşeydir. Bu yüzden bir programlama dili öğrenmek için kullanmanız gereken iki şey vardır: 1. Github Copilot, 2. Yeni bir proje.
Son zamanlarda bir startup projesi üzerinde çalışıyorum. Bu proje bünyesinde bir mobil uygulama mevcut. Bu mobil uygulamayı önce Android/Java ile yıllardır mobil uygulama geliştirici edasıyla kısa bir zamanda tamamladım. Akabinde aynı uygulamayı İOS/Swift ile geliştirdim. Bu noktada aynı uygulamanın iki değişik platform için iki değişik teknoloji ile yazılmasının çok anlamsız olduğunu anladım. Şimdilerde aynı projeyi flutter ile geliştiriyorum. Hadi Android/Java çok zor değildi diyelim, çünkü yıllarca Java dilinde kod yazdım. Ama İOS/Swift benim için tamamen yeni bir dünyaydı. Ama Copilot ile Swift dilini öğrenmek çok kolay oldu. Aslında ben Swift dilini öğrenmedim, sadece mobil projeyi geliştirmek zorunda olduğum için problem çözerek ilerledim ve bu sayede Swift dilini yakından tanıma ve kullanma fırsatı buldum. Amacım Swift öğrenmek değildi. Amacım Swift ile bir mobil uygulama geliştirmekti. Problemleri çözerken Swift dilini bilmediğim için hiç zorlanmadım, çünkü Github Copilot çözüm için gerekli kod parçalarını bana sundu. Ben sadece bana sunulan bu kod parçalarının ne anlama geldiğini anlamaya çalıştım ve bu esnada aslında Swift dilini öğrendim. Burada Copilot tarafından sunulan kod parçalarını anlamamdaki en önemli etken Java diline ve programlama konseptlerine olan hakimiyetimdi. Eğer bu olmasaydı derinlemesine Swift dilini öğremem mümkün olmayacaktı.
Şimdilerde Flutter/Dart ile tekrar aynı uygulamayı geliştiriyorum ve Github Copilotın ne kadar güçlü bir araç olduğuna tekrar şahit oluyorum.
Bana istediğiniz bir dili öğrenmem için tavsiye edebilirsiniz. Benim aklıma gelen ilk soru bu dili nasıl öğrenirim olmayacaktır. Aklıma gelecek ilk soru hangi projeyi yaparak, bu dil ile bir problem çözerim olacaktır.
Bir yazılım ürününün kontrollü ve istenilen nitelikte ortaya çıkabilmesi için gereksinim analizi yapılması gerekmektedir. Gereksinim analizi kısaca müşterinin piyasa koşullarından doğan gereksinimlerinin tespit edilmesidir. Bu analiz müşteri ne ister sorusunun cevabını vermelidir. Aksi taktirde müşterinin ihtiyacı olmayan bir ürün ortaya çıkma riski oluşabilir. Bu yazımda bu tür gereksinim analizlerinin doğru yapılmadığı durumlarda doğabilecek sıkıntılardan bahsetmek istiyorum.
Günümüz projelerinde Jira vari sistemler kullanılarak müşteri gereksinimleri kullanıcı hikayeleri (user story) olarak kanban board üzerinde sprint backlog ya da genel backlog içinde yer alırlar. Bu kullanıcı hikayeleri müşteri ile yapılan görüşmeler sonunda tespit edilen gereksinimlerin kağıda dökülmüş halleridir. Bir kullanıcı hikayesi sonuç itibarı ile uygulama bünyesinde oluşturulması istenen bir özelliğin kısa bir özetidir. Örneğin “kullanıcı isim ve şifresini kullanarak, sisteme giriş yapar” bir kullanıcı hikayesidir. Yazılımcılar plannıng poker oturumlarında bu tür kullanıcı hikayelerinin hangi zaman diliminde implemente edilebileceklerini tahmin etmeye çalışırlar. Genelde story point olarak tabir edilen bir derecelendirme yöntemi ile tahminler yapılır. Herkesin bildiği gibi bu tahminler aslında gerçekleri yansıtmaz, lakin proje yönetimi nedendir bilinmez bu tahminlerin yapılmasında ısrar eder.
Bir kullanıcı hikayesinin içeriği yanı sıra onay/kabul kriterlerinin de (acceptance criteria) tanımlanmış olması önem taşımaktadır. Şahsen onay/kabul kriteri tanımlanmamış bir kullanıcı hikayesine elimi bile sürmezdim, çünkü hangi kriterlere göre daha sonra bu kullanıcı hikayesinin çalışır halde olduğunu ispatlayabilirdim! Bu mümkün değil. Bu sebepten dolayı kullanıcı hikayesini oluşturan kişinin, bu genelde gereksnim analizi yapan ürün sahibi (product owner) olabilir onay/kabul kriterlerini de eklemesi gerekmektedir. Yukarıdaki örnek kullanıcı hikayesinin onay/kabul kriterleri şu şekilde olabilir:
Kullanıcı ismi ya da sifresi yanlış ise, kullanıcıya “Lütfen doğru bilgiler ile giriş yapınız” hatası gösterilir.
Kullanıcı ismi alanı boş bırakılarak, login butonuna tıklandı ise, kullanıcıya “Lütfen kullanıcı ismini giriniz” hatası gösterilir.
Şifre alanı boş bırakılarak, login butonuna tıklandı ise, kullanıcıya “Lütfen şifrenizi giriniz” hatası gösterilir.
Kullanıcı ismi ve şifre doğru ise, login işlemi gerçekleştirilir ve kullanıcı ana sayfaya yönlendirilir.
Yazılımcı oluşturacağı implementasyonu bu onay/kabul kriterleri doğrultusunda şekillendirir. Burada ATDD (acceptance test driven development) tam da onay/kabul kriterlerine karşılık gelen bir implementasyonun oluşmasını sağlayacaktır. Bu implementasyon ne bir eksiklik ne de bir fazlalık ihtiva edecektir. Genellikle yazılımcı test güdümlü çalışmadığında “belki kullanılır, su metot da olsun” eğilimi ile fazladan kod yazabilir. Test güdümlü yazılımda oluşturulan kullanıcı ve program arayüzünin (APİ – application programming ınterface) ilk kullanıcısı testler olduğu için, yazılımcı bu api arkasında sadece gerekli ve yeterli olan implementasyonu oluşturarak, ilerleyecektir.
Buraya kadar kabaca gereksinim analizinin nasıl bir kullanıcı hikayesine, oradan da koda dönüşebileceğine değindik. Sonuç itibarı ile gereksinim analizinden doğan kullanıcı hikayeleri ürün sahibi (product owner) ile yazılımcı ekibi arasındaki kontratı temsil etmektedirler. Ürün sahibi ne istediğini (bunlar müşterinin istekleri ve gereksinimleridir) kullanıcı hikayeleri olarak formalleştirir ve yazılım ekibine implemente edilmek üzere devreder. Yukarda bahsettiğim kullanıcı hikayesi çok basit bir örnek, bu yüzden büyük çapta arzu edilmeyen bir şeylerin implemente edilme olasılığı çok düşük. Ayrıca onay/kabul kriterleri de tanımlı olduğundan, yazılımcı bu kriterler doğrultusunda çok hızlı bir şekilde gerekli implementasyonu oluşturabilir. Şimdi daha büyük çaplı ve karmaşık kullanıcı hikayelerinin oluşturulmasında bir takım hatalar yapılması durumunda, oluşabilecek problemlere değinmek istiyorum.
Bizden gerekli verilerin yüzlerce kolonu olan bir excel dosyası olarak export edilmesinin istendiğini düşünelim. Böyle bir kullanıcı hikayesinde yazılımcının görmek istediği ilk şey hangi verinin hangi kolondo yer alacak oluşudur. Bu amaçla ürün sahibinin böyle bir mapping oluşturarak, kullanıcı hikayesine eklediğini varsayalım. Onay/kabul kriteri olarak da “kullanıcı export butonuna tıklayınca, veriler excel dosyası olarak indirilir” tanımlı olsun. Şimdi bu örnek üzerinden nelerin yanlış gidebileceğine yakından göz atalım.
Daha önce 200+ kolonu olan bir excel dosyası oluşturdunuz mu bilmiyorum, lakin çok eğlenceli bir uğraş değil. Ana problemlerden birisi verilerin nereden geleceğini tespit etmektedir. Bu ürün sahibinin görevidir ve hangi verilerin nereden alınacağını oluşturacağı mapping bünyesinde tanımlar. Bunun yanı sıra bu verilerin hangi kolona yerleştirileceği bilgisi de bu mapping bünyesinde yer almak zorundadır. Şimdi biz haftalar süren çalışmalar sonunda export özelliğini çalışır hale getirmiş olalım ve uygulama bu yeni özelliği ile müşteriye/kullanıcılara yeni bir sürüm bünyesinde sunulmuş olsun. Kullanıcılar doğal olarak bu özelliği kullanarak, ilk excel dosyalarını oluşturacaklar ve bize ulaşan bilgilere göre export özelliği istedikleri verileri ihtiva etmeyecek. Durum bir bug olarak tekrar bize iletiliyor ve hatayı girememiz talep ediliyor.
Ortada gerçekten bir hata var mı? Ben böyle bir durumu daha önce yaptığım bir projede yaşadım ve bundan sonra olanları aktararak, nelerin yanlış yapıldığına değinmek istiyorum, çünkü yazılımcı ekibi gereksinimi doğru implemente etmemekle suçlandı. Bakalım suçlu kim!
Öncelikle amaç hiçbir zaman suçlu aramak olmamalıdır. Bu zayıf insanların işidir ve kesinlikle böyle süreçlere dahil olmamak gerekir. Bunun yerine sürecin neresinde hata yapıldı ve bu hatanın bedeli ne oldu sorusuna cevap aranması gerekmektedir. Sonucu biliyoruz, ama buraya nasıl gelindi?
Tekrar kullanıcı hikayesine bir göz atalım. Bu kullanıcı hikayesi bünyesinde 200+ kolon ihtiva eden bir mapping tablosu mevcut. Bize iletilen bugda belli kolonlarda verilerin eksik olduğu bilgisi mevcut. Tekrar kullanıcı hikayesindeki mapping tablosuna baktığımızda boş kalan kolonların nedenini görebiliyoruz: bu kolonlar için sadece belli tipte bir veri tanımlanmış (Drugtype.MIXTIRE ) ve yapılan export işlemi diğer tiplerdeki verileri (örneğin DIVISION) ihtiva etmiyor ve göz ardı ediyor. Aşağıda bu mapping tablosunda yer alan 44. ve 45. satırları görmekteyiz. 44 ve akabinde bu gruba dahil kolonlarda MIXTIRE türünde verilerin kullanılması gerektiğinden bahsediliyor. Gelen bug raporunda ise MIXTIRE harici diğer verilerin excel dosyasında yer almadığından bahsediliyor.
Verilerin hangi yapıda olduklarını anlamak için aşağıdaki enum sınıfına bir göz atalım:
public enüm DrugType{
MIXTIRE,
DIVISION,
COMPLETED_PRODUCTS,
DIVIDED_PRODUCTS
}
Kullanıcı hikayesinde sadece MIXTIRE tipinde olan verilerin export edileceğinden bahsediliyor. Bu durumda yazılımcı kullanıcı hikayesinde yer alan veriler doğrultusunda gerekli implementasyonu gerçekleştirmiştir. Ama kullanıcılar DIVISION ya da başka tipte olan verileri de export etmeye çalıştıklarında, gerekli kolonlar boş kalmaktadır.
Ürün sahibi ile yaptığımız bir kriz toplantısında bize bunun bir bug olduğunu ve diğer tipteki verilerin de export edilmesi gerektiğini söyledi. Hemen şunu belirteyim: ortada bir bug yok! Bu bir change request, çünkü kullanıcı hikayesinde ne yer alıyorsa, yazılımcı ekibi onu implemente etmiştir. Bunu bu şekilde ürün sahibine aktardığımızda, “ben refinement toplantılarında bunu sözlü olarak söylemiştim” cevabını aldık. Ürün sahibi ne yazık ki kusura bakmasın! Kullanıcı hikayesinde ne yazıyorsa, gerçek o dur ve yazılımcı ona göre hareket eder. Bir takım toplantılar esnasında konuşulanlar eğer kullanıcı hikayelerine not düşülmesse, geçerlilikleri yoktur. Bu yüzden ürün sahibinin böyle bir argüman ile gelmesi kabul edilemez. Eğer bir kullanıcı hikayesi ürün sahibi ile yazılım ekibi arasında bir kontrat vazifesi rolünü üstlenerekse, bu durumda gerekli bütün bilgilerin kullanıcı hikayesi bünyesinde yazılı olarak yer alması gerekmektedir.
Ben çoğu zaman bir kullanıcı hikayesini implemente eden bir yazılımcının gördüğü eksikleri kullanıcı hikayesine not düşmeden ürün sahibi ya da diğer yazılımcılar ile bilateral çözmeye çalıştığına şahit oluyorum. Bu çok tehlikeli bir durum arz etmektedir. Eğer bir eksik varsa ve bunun ne olduğu tespit edilmişse, hiç zaman kaybetmeden kullanıcı hikayesine gerekli not düşülmeli ve kontrat yenilenerek, yapılması gerekenler somutlaştırılmalıdır. Oluşturulan implementasyonun garantisi her zaman bu kontrattır.
Bahsetmiş olduğum export konusundaki ana problem analizi yapan şahsın ya da ürün sahibinin export için gerekli olan analizi geniş kapsamlı yapmamış olmasıdır. Oluşturması gereken mapping tablosunun daha kapsamlı olması gerekiyordu. Bunun yanı sıra ürün sahibi oluşturulan bu yeni özelliği test ederek, kabul etmiştir. Yani en geç test esnasında bu hatanın göze batması gerekirdi, lakin böyle bir şey olmadı.
Yazılımcı olarak kendimizi sadece onay/kabul kriterlerini baz alarak gerekli implementasyonu yaptığımızda garantiye alabiliriz. Bu yüzden mutlaka ve mutlaka onay/kabul kriterlerinin kullanılması gerekliliği DOR (definition of ready) bünyesinde tanımlı olmalıdır.
Kısaca özetleyecek olursak:
Her bug olarak gelen repor bir bug olmayabilir. Çoğu zaman bu bir change requestdir ve gereksinim analizi yapan ekip işini doğru yapmadığı için bu eksikliği etrafına bug olarak lanse edebilir.
Yazılımcılar önlerine gelen her kullanıcı hikayesini içerik olarak doğru olup, olmadığını sorgulamalıdırlar. Eğer eksik olduğunu düşündükleri noktalar varsa, kullanıcı hikayesini reddetme hakkına sahiptirler. Ürün sahibi tespit edilen eksiklikleri tamamlamakla yükümlüdür.
Toplantılarda sözlü olarak yapılan tespitler mutlaka kullanıcı hikayelerine not düşülmelidirler. Bu şekilde kontrat yenilenir ve bu bilgiler göz ardı edilmez.
Yazılımcılar onay/kabul kriteri olmayan kullanıcı hikayelerini reddetme hakkına sahiptirler. Onay/kabul kriteri olmayan kullanıcı hikayeleri saatli bomba gibidirler. İmplementasyonun kullanıcının elinde patlama ihtimalleri çok yüksektir.
Ürün sahibi tanımladığı onay/kabul kriterlerini elden yaptığı testler aracılığı ile kontrol eder. Yazılımcı her onay/kabul kriteri için bir onay/kabul testi yazar. Bu testleri otomatik olarak çalışır ve kullanıcı hikayesinde yer alan uygulama özelliğinin çalışır durumda olduğunun kanıtıdırlar.
DOR bünyesinde yer alan kriterlere uymayan kullanıcı hikayeleri yazılım ekibi tarafından sahibine geri gönderilir.
DOD (definition of done) bünyesinde yer alan kriterlere uygmayan kullanıcı hikayesi implementasyonları ürün sahibi tarafından yazılım ekibine geri gönderilir.
Bu sene sonunda San Francisco şehrinde yapılacak yirminci JavaOne konferansına konuşmacı olarak aşağıda yer alan sunum önerisini gönderdim. Sunum önerilerini 29 nisana kadar bu link üzerinden göndermek mümkün.
Bugün Amazon.com’dan sipariş ettiğim Kindle DX geldi. Tek klime ile harika. Daha önce uzunca bir zaman Irex Iliad kullandım. Ama Kindle DX onu arattırmayacak sanırım :)
Teknik Özellikleri
Boyutları
264 x 180 mm x 9,7 mm
Ekran
9,7 Inch (24,6 cm)
824 x 1200 Pixel
150 ppi
Hafıza
4GB
CPU
ARM 11
532 MHz
Bateri
3,7 V
1530 mAh
Desteklediği Formatlar
Kindle (.azw)
Text (.txt)
HTML (.html)
Mobipocket (.mobi, .prc)
Adobe PDF (.pdf)
Kindle DX’in en ilginç özelliklerinden birisi, bünyesinde bir EDGE/UMTS modem barındırması. Amazon’dan alınan kitaplar anında mobile network üzerinden Kindle DX’in hafızasına ışınlanıyor.
Benim asıl ilgimi çeken, kullanılan E-Ink teknolojisi ve Kindle DX’in PDF formatındaki dosyaları okuyabiliyor olması. Doğal olarak ilk aldığım tepki neden IPad almadığım oldu. IPad bir LCD ekranına sahip ve baterisi 10 saat kadar dayanabiliyor. LCD ekranda PDF dosyaları okumanın gözler için ne kadar yorucu olduğunu düşünebilirsiniz. Buna karşın Kindle DX E-Ink teknolojisiyle çalışan bir ekrana sahip. Böyle bir ekranda bir PDF dosyasını okumak, bir kitabı okumaktan farksız ve bir o kadar da zevkli.
Bug ingilizce dilinde böcek, bilgisayar dillerinde bir program hatası anlamına geliyor. İlk program bug’ı 1947 yılında Grace Murray Hopper’in Harvard Üniversitesi’nde kullandığı Mark II Aiken isimli röle (relay) (resim 1) bazlı hesaplayıcıda (primitif bir bilgisayar) bulundu.
Resim 1
9 eylül 1947 tarihinde hesaplayıcının programlandığı şekilde çalışmadığı, sorun çıkardığı görüldü Yapılan araştırma üzerine F panelindeki 70 numaralı rölenin bacakları arasında bir güvenin (moth) sıkışıp kaldığı görüldü. Program hatasının sebebi bulunmustu; bir güve yani bir böcek (ingl. bug).
Bilgisayar programlama tarihine ilk program hatası olarak geçen bu böcek operatör tarafından log defterine resim 2’deki şekilde eklendi.
Resim 2
Bu işlemin ardından operatörler hata giderildi anlamına gelen debugged (böcek temizlendi) kelimesini kullanmaya başladılar. Bizim bugünlerde sıkça kullandığımız debug kelimesinin kökeni bu güveden geliyor :)
Bug kelimesi 1947’den öncede sistem hataları için kullanılan bir terimdi. Örneğin Amerika’daki ilk telefon şebekelerinde sesin karıncalı gelmesi durumunda hatta hata var anlamına gelen „bugs in a telephone cable“ ifadesi kullanılırmış.
JUG (Java User Group) e-posta listesinde olduğum için bana ulaşan bir e-postayı sizlerle paylaşmak istedim. E-posta Oracle’ın Sun ve Java için stratejik planları hakkında ip uçları verebilir…
———————————–
This is the only statement that I am aware of thus far:
“Oracle plans to increase investment in Java, Sparc, Solaris, and
MySQL technologies which is expected to increase the demand for
professionals with proven expertise in these areas. Oracle remains
fully committed to developing and promoting the expertise of these
sought-after specialists. Oracle University will continue to provide
comprehensive training and certification programs for these areas, and
will honor all unexpired certification exam vouchers purchased through
Sun. ”
I will provide more info if I can get my hands on it.
Justin Kestelyn
On Feb 1, 2010, at 4:02 PM, Joshua Partogi wrote:
> Hi all,
>
> Does anybody know about the status on Sun Certifications? Will the
> title changed to Oracle Certification in the future? I looked at the
> certification page is still at Sun’s Certification website, but if
> someone is for example taking the Certified Java Programmer, will he/
> she be called SCJP or OCJP? Calling him/her as an SCJP can be
> misleading since Sun as a company has been acquired by Oracle. Does
> anybody know Oracle’s plan on this? Shall I just wait until Oracle
> has made an official announcement before taking any Java
> certification? Also, will our previous Java certification still valid?
>
> Kind regards,
>
> —
> http://twitter.com/scrum8
