Hal 100:Kucağına düşen 3ncü parti ürün üzerinde bug/fix yapıp sevinir ve ardından yeni taleplerle karşılaşır.

Özellikle sahada kullanılan ürünleri olan firmaların olmassa olmaz ihtiyaçlarından birisi teknik destektir. Var olan ürünlere yapılacak yeni eklemeler veya güncellemeler haricinde, müşterilerden gelen geri bildirimler doğrultusunda acil olarak halledilmesi gereken vakalar da vardır. Bunlar her ne kadar bazı profesyonel firmalar tarafından seviyelendirilip uygun birimlere yönlendiriliyor olsa da hayat bu kadar toz pembe değildir. Doğruyu söylemek gerekirse olası pek çok vaka vardır. Bu vakalardan belki de en kötüsü bir servis sağlayıcıdan alınmış olan ürünler ile ilgilidir. 

  • Ürüne olan teknik destek, sahibi olan firma tarafından kesilmiş olabilir,
  • Ürünün sahibi teknik destek için yüksek miktarda fatura kesiyor olabilir(Vendor Lock-In anti pattern’ inin oluşma nedenidir),
  • Ürün sahibi firma kapanmış olabilir,
  • Ürün eskidir ve aslında üzerinde çalışmış geliştiriciler sahibi olan firmada artık yoktur
  • Ürünün teknik dokümantasyonu olmayabilir vb

Eğer söz konusu ürün, onu kullanan firma tarafından kolay kolay terk edilemiyorsa durum vahimdir. Ürün yeteri kadar ayrık yapıda tutulmamışsa sistemden kopartmak ve yerine başka bir alternatifi koymak her zaman güçtür. Durum böyle olunca birisinin o ürün üzerinde değişiklik yapması şarttır.

Üçüncü parti bir ürünün üzerinden değişiklik yapmak risklidir. Ancak bazı sebeplerden ötürü servis sağlayıcından habersiz olarak değişiklik yapılması çok daha risklidir.

Çünkü servis sağlayıcının yeni bir sürüm çıkartması halinde, yapılmış olan güncellemelerin bu versiyona da aktarılması gerekir. Bu, Dead End adı verilen anti-pattern’ in yolunu açar.

Eğer yukarıda sayılan sebeplerden ötürü 3ncü parti ürün üzerinde değişiklik yapılması kaçınılmazsa elden bir şey gelmez ve bir geliştiricinin bu konuya eğilmesi gerekir. Ürünün çeşidine, isteğin aciliyetine göre başına verilecek adamın kaliteli bir kumaşa sahip olması gerekebilir. Çünkü 3ncü parti ürün tam bir kod çöplüğüne benzeyebilir.

Ürünün hızla analiz edilmesi, çabucak keşfedilmesi, büyük resmin hemen fark edilmesi, içeride kullanılmış mimari kalıp veya prensiplerin anlaşılması, müdahale edilmesi gereken en uygun yerin bulunması gerekir. Bir anlamda geliştiricinin tersine mühendisliğin farkında olması ve kullanması icap edebilir.

SOA gibi üst düzey mimariler içeren, farklı platformlarda koşan ürünlerin bir arada konuştuğu sistemlerde, çıktıları kiritik olan 3ncü parti ürünler kullanılmakta olabilir.

Bu ürünlerin sistemden kolayca kopartılamadığı, üstüne bir de teknik destek alınamadığı ve bazı kanuni kurallar yüzünde acil değişikliklerin yapılması gerektiği durumlar karşısında yetkin geliştiricilerin bir mucize yapması beklenir.

Bu mucizeleri yapan geliştiriciler gerçekten de vardır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Dead End Anti Pattern
  • Lavaflow Anti Pattern
  • Vendor Lock-In Anti Pattern
  • Tersine Mühendislik (Reverse Engineering)

Hal 98:Mimari tanımlanmadan önce, teknoloji seçimi yapılması gerektiğine inanır.

Bir yazılım projesi geliştirilmeye karar verildiğinde ekibin sahip olduğu yetenek ve kabiliyetler önem arz eden konuların başında gelir. Ekibin daha önceki başarıları, hataları ve ürettikleri bir sonrakisi için katma değer niteliği taşıyan unsurlardır.

Ne varki pek çok ekip sahip olunan bilgi ve deneyimi o kadar çok benimser ki diğer bütün problemleri de aynı yollarla çözümlemeye çalışır. Bir nevi Golden Hammer ve biraz da Cargo Cult Programming Anti-Pattern’ lerinin sıklıkla yaşandığı haldir.

Oysaki bir ürünün çözüm gerektiren mimarisi tasarlanmaya başlanmadan önce sorgusuz kabul gören teknikler, pratikler, disiplinler ve teknolojik araçlar ürünün gelişimine olmusuz etkide bulunabilir. Süreler uzayabilir, ortaya OverEngineering anti-pattern’ i çıkabilir ve aslında aile için tasarlanmış sedan otomobilin içine 340 km hızla gidebilmesini sağlayacak motor konulmuş olabilir.

Birden fazla ekibe sahip olan firmalarda ekipler arası teknoloji transferi ve bilgi aktarımı yeni nesil ürünlerin geliştirilmesinde seçilecek enstrümanları belirleme açısından önemli bir konudur.

Dolayısıyla mimari tasarımların oluşturulmasında şekillenmeye başlayan teknolojileri göz önüne almak çok daha doğru bir yaklaşımdır. Pek tabi seçim yaparken sıkıntıya düşülebilecek bir husus vardır ki o da bu teknolojik bilgiyi kimin bu kadar iyi bileceğidir. Ekip içi görevlendirmeler ile gelişmelerden haberdar olunması, uygun görev ve sorumluluk atamaları ile sürekli güncel kalınması sağlanabilir.

Teknoloji, pratik, prensip gibi enstrümanların seçiminde çözüm/yazılım mimarlarına büyük sorumluluk düşer.

Mimari tasarımdan önce kullanılacak teknolojinin seçilmesi ürün gelişimi açısından sorun teşkil edebilirken bazı hallerde de kullanılabilecek teknoloji sadece bir tanedir. Böyle haller istisnai olarak kabul edilebilir tabi.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Golden Hammer,
  • Cargo Cult Programming,
  • OverEngineering

Hal 97:Arada bir de olsa masasındaki klavyeyi temizlemeye üşenir.

Junior developer olarak işe başladığım da IBM marka bir Laptop sahibi olmuştum. Evdeki antika bilgisayar göz önüne alındığında bu benim için harika bir şeydi. Her gün eve getirip götürüyordum. Tatile bile birlikte giderdik. Lakin bilgisayar benden önce bir kaç geliştiricinin elinden geçmişti. Hatta ilk sahibi şirketin ortaklarından birisiydi. Yeni bilgisayarlar geldikçe eskiyenler daha alt kademelere veya işe yeni başlayanlara veriliyordu.

Geliştiriciler bir süre sonra kullandıkları donanım üzerinde biriken toz parçaların fark etmezler. Özellikle klavye ve monitörlerin arada bir temizlenmesi gerekirken kullanıcıları için onlar hiç tozlanmaz parçalar gibidir.

Laptop’ un herşeyi iyiydi. Hızlı, dayanıklı, yüksek çözünürlüklü. Tek sıkıntı klavyesi içerisine birikmiş olan susam, saç ve tırnak parçalarıydı. E haliyle kimse temizlemediğinden klavye içi oldukça kirlenmişti. Aralara bir şekilde pek çok parça girmiş son bir senedir orada konaklamaktaydılar. Bir gün klavyenin her bir tuşunu tek tek çıkartıp bir diş fırçası yardımıyla her bir parçasını temizledim. Pırıl pırıl olmuştu. Tek sorun Space tuşunu istediğim gibi oturtamamış olmamdı.

Bu hikayeden çıkaralacak hisse şudur aslında: Pek çok yazılım geliştirici (özellikle erkek olanları) pasaklıdır. Masada bir şeyler içerken sakarlıkları ile onu klavye üstüne dökmek bir yazılımcı geleneği olmuştur. Göbek üstünde biriken poaça veya susam parçaları ise olmassa olmazlardandır. Hele ki evinde bilgisayarı başında sigara da içiyorsa o sinen nikotin kokusunu donanım üzerinden kazımak yıllar sonra epeyce zor olur. Masanın temizlenmesi her ne kadar kolay olsa da klavyelerde biriken partiküller yıllarca orada gizlenebilirler. Bu yüzden arada bir de olsa onları temizlemek de yarar vardır. Çevre ve bireysel sağlık açısından.

Anahtar Kelimeler (Bunlara Bir Bakalım)

Bakacak, öğrenecek bir şey yok! Temiz olun!

Hal 96:Bir suçlu aradığında bu genelde projede kendinden önce çalışmış olan geliştirici/geliştiriciler olur

Yazılımcının işi aslında hiç kolay değildir. Sayısız programlama dilinden birini veya bir kaçını kullanıp, karmaşık problemleri yine karmaşık sayılabilecek mimariler, disiplinler ile harmanlayarak, müşterinin yüzünde tebessüm bırakacak ürünlerin geliştirimesinde rol almaya çalışır. Hele ki bir ekip çalışmasının söz konusu olduğu geliştirmelerde koordinasyon, süreç ve yönetim güçlükleri de işin içerisine girince tebessüm bıraktırmak epeyce zorlaşır.

Projenin veya iterasyonun sonlanmasına yakın artan baskı, sıkışık teslimat süreleri, yönetici tavırları, müşterinin olur olmaz isteklerinin kabülü, beklenenden az elde edilen gelir, kız/erkek arkadaşla yapılan kavga ve daha bir çok şey geliştiricinin zaten çorba olan kafasına tuz biber eker.

Yoğun olarak yazılım geliştirme işinde yer alan kişilerin zaman içerisinde psikolojik yıpranmaya uğramaları çok da şaşılacak bir durum değildir.

Peki işler kötüye gitmeye başladığında? Pproje geciktiğinde, istenen görevlerde sarkmalar olduğunda? Geliştiricilerin hepsi insandır ve çok doğal olarak psikolojisi vardır. Günlük rutin içerisinde değişken durumlarda değişkenlik gösterebilen bu psikolojinin içinde savunma ve yaptığını korumu dürtüleri de vardır.

Eğer süreç içinde işler bir geliştirici için ters gidiyorsa mutlaka “ürünün önceki zaman diliminde meydana gelen bir hat”a sonucu bu noktaya gelinmiştir düşüncesi hakimdir. Bu düşünce esasında önceki geliştiriciyi veya geliştiricileri suçlama noktasına kadar gider.

Bir ürüne geliştirme yaparken var olan koşullar çerçevesindeki standartlara uymak ve bunun dışına çıkmadan kodlama yapmak, sonradan gelen geliştiricilerin hakkımızda iyi şeyler düşünmesine neden olur.

En azından şirketin var olan kod-kalite standartlarına uyulmaya çalışılmasında yarar vardır.

Ne yazık ki bu tip savunma mekanizmalarının yöneticiler için bir kıymeti yoktur. Her ne kadar geçerli bir sebep olsa da yönetim kademesi veya işin sahibi, ürünün istenen nitelikleri ile istenen zamanda veya olabilecek en kısa sürede çıkmasını bekler.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Hatasız Kodlama
  • Okunabilir Kod
  • Kodlama Standartları
  • Kod-Kalite Standartları

Hal 95:O anda geçici çözüm olarak kullandığı try…catch bloğunu kodun orasında ebediyen unutabilir.

Yazılım geliştiriciler de aslında birer insandır. Bu yüzden çok doğal olarak gün içerisinde sıkıldıkları, bunaldıkları anlar olur. Bu tip anlarda iş verimliliği düşer ve hatalı kodların oluşması söz konusu olur. Tedbir almak kolaydır.

  • Ekip olarak çalışılması halinde iç iletişimi ön plana çıkartarak ilerlemek,
  • Kodları çift kişi olarak geliştirmek(Biri bakar diğer yazar sonra roller değişir),
  • Kod gözden geçirmelerde bulunmak,
  • Test odaklı geliştirme gibi yaklaşımları kullanmak
  • Çeşitli kod kalite araçlarından faydalanmak

vb….

Ancak bazı hallerde geliştiriciler Lone Wolf Developer modunda takılırlar. Bu gibi bir halde kişinin kendi disiplinindeki kaçakların doğuracağı olumsuz sonuçlar vardır. İçi boş bir try…catch bloğu bunlardan birisidir. Bir anlık dikkatsizliğin veya o andaki vakadan bir an önce kurtulmanın ya da çabucak kodun kalan kısımlarını işletebilme isteğinin bir sonucu olabilir.

O anda yetiştirilmesi gereken iş için çalışma zamanı hatasının gerçektende bir önemi olmayabilir. Aslında oluşan istisnai durum daha sonradan değerlendirilecek ve gerekli tedbirler alınacak şekilde ilerlenebiliyorsa boş bir catch bloğu gerçekten işe yarar. Ne var ki çalışma zamanı hatalarının Exception mekanizması içerisinde yer almasının bazı dezavantajları da vardır. Herşeyden önce çalışma zamanına ek yük getirir. Belki de oluşan hatalar Exception Handling’ e başvurulmadan önlenebilir.

Bir dosyanın yerinde olup olmadığını kontrol ederken, “catch bloğuna düşüyor ve hatta FileNotFoundException alıyorsak dosyanın yerinde olmadığından emin olabiliriz” düşüncesiyle hareket etmek doğru bir yaklaşım değildir.

Aslında önlenebilecek bir takım hataların try…catch bloklarına başvurulmadan çözülmesi mümkün olabilir.  Kötü olansa geçici olarak uygulanan try…catch bloğunun kodun o kısmında ebediyen unutulabilmesidir. Bunun bilinen sonuçlarından birisi Boat Anchor isimli anti-pattern’ dir. Diğer yandan Error Hiding isimli anti-pattern için de bir gerekçe olarak düşünülebilir. Hatta AR-GE amaçlı başlayıp ürün haline gelmiş pek çok projede Lavaflow Anti-Pattern’ i oluşurken bu şekilde kullanılıp unutulan kod parçaları veya geçici çözümlere rastlamak son derece olasıdır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anti-Patterns
  • Boat Anchor
  • Error Hiding
  • Lavaflow
  • Exception Handling
  • Test Güdümlü Programlama (Test Driven Development)
  • Pair Programming
  • eXtreme Programming
  • Code Review

Hal 93:Ekranının görünür olmasından ve arkasından sürekli birilerinin geçmesinden rahatsız olur.

Yazılım sektöründe ürün geliştirme sıkışık süreler nedeniyle zaman içerisinde stres dozu yüksek bir hal alabilir. Her ne kadar modern dünyanın bilinen popüler süreçleri ve metodolojileri bu baskıları minimize etmekte olsa da, kod başında oturanların günün belirli saatlerinde yüksek konstantrasyon içerisinde bulunmaları şarttır.

Her ne kadar adam-gün hesabına göre yapılan planlamalarda 8 saat esas alınsa da, yazılımcının gün içerisindeki maksimum odaklanabilirliği bu kadar uzun değildir.

Yüksek konsantrasyon projeden projeye daha kritik seviyelerde gerekebilir. Söz gelimi askeri sanayide, finansal risk içeren ürünlerde, üretim bantlarına ait uygulamalarda, bilimsel unsurlar içeren arge  projelerinde çalışanların stresten uzak iş yapabilmeleri önemlidir. Bu nedenle yazılımcının konstantrasyonunu bozacak ortamlar içerisinde yer almaması tercih edilir. Konsantrasyonu arttırabilecek bir kaç unsur vardır. Söz gelimi,

  • Yeşillik veya mavi gökyüzü gören bir şirket katında çalışmak(adım atar atmaz yeşillik bir alan çıkabildiğinizi düşünün. Teknokent, Teknopark çalışanları kıymetini bilmeli)
  • Diğer geliştiriciler ile çok iç içe oturmayacak şekilde ferah bir masa da oturmak,
  • Çok fazla gürültü ihitva etmeyen ortamlara sahip olmak(iş birimleri ile bir arada olan ekipler, iş birimlerinin hararetli tartışma ve telefon konuşmalarına maruz kalabilirler)
  • Geceleri 00 ile 05 arasında mutlaka uyku halinde kalabilmek ve bu nedenle sabah yorgun uyanmamak,
  • Öğle araları, öğle sonrası çalışmalara olumsuz etkide bulunabilecek ağır gıdalardan kaçınmak vb

Bireysel konsantrasyon dışında ekip konsantrasyonu da önemli bir konudur. Bunu yüksek seviyede tutabilmek için gerekli aksiyonları üst kademe ve yöneticilerin sorumlulukları arasındadır.

Ortamsal veya bireysel anlamda bakılabilecek pek çok şey olmasına rağmen iş yerlerinde yazılımcı psikolojisini ve doğal olarak konsantrasyonunu bozacak etkenler de vardır.

  • Ortamın gürültülü olması,
  • Başka departmanların yazılım departmanı ile iç içe durması,
  • Havasız, gökyüzü görmeyen odalarda çalışılması(In-Box Developer written Code)
  • ve daha da önemlisi oturulan masanın arkasından sürekli birilerini geçmesi; sürekli olmasa da geçenlerin ekranda olup bitenleri merak etmesi,

Bu nedenle özellikle yönetimsel kadroda yer alanların, proje veya ürün yöneticilerinin sorumluluk alması, ekibin birey ve grup bazında konsantrasyonu azaltabilecek etkenleri minimuma indirgemesi önemlidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Yazılımcı ve Spor,
  • Yazılımcının uyku düzeni,
  • Gündelik yaşamda stresi azaltmanın yolları

Hal 91:Kimi geliştiricinin en kıymetli eşyası kulaklıklarıdır.Çünkü kod yazarken dünyadan soyutlanmak ister

Hal 93‘ de belirtildiği üzere geliştiricilerin konsantrasyonunu yüksek tutması için çeşitli yollar vardır. Bunlar arasında en bilinenlerinden birisi dünyadan soyutlanıp sadece ekran sınırları içerisinde kalarak bir süre kodlama yapmayı sağladığı düşünülen müzik dinleme eylemidir.

Bu eylemin sebebi genellikle müziği çok sevmek olabileceği gibi, “benimle konuşmayın yoğunum ayrıca size tepkiliyim” veya “şu adamın sakız çiğnerken çıkarttığı ses beni rahatsız ediyor” gibi psikolojiler de olabilir.

Gürültü kirliliği bulundurmayan çalışma alanları, geliştiricinin kulaklıkları ile kendisini dünyadan soyutlamaya gerek bırakmadan kod yazmasını olanaklı kılar.

Müzik dinlemek güzeldir hatta kimi zaman geliştiriciler kendi modlarına göre kaliteli ses veren kulaklarına bağlanıp Matrix’ in içine girer ve maksimum düzeyde efora ulaşarak kod yazar. Lakin bunun suyunu çıkartmamak önemlidir.

Bir geliştiricinin günlük çalışma kapasitesine göre çok yüksek oranlarda müzik dinleyerek iş yapmaya çalışması aslında çok da verimli değildir. Çevre ile olan iletişimi kesmek bir süre iyi kod yazılmasını sağlayabilir ama sonrasında farklı etkiler gösterir. Müziğe kapılıp sosyal ağlarda kaybolmaya başlanıldığı an atanmış görevler için gecikme anlamına gelir. Ayrıca bu kadar kulaklık bağımlısı olmak ilerleyen yaşlarda duymaya yarayan bazı hassas tellerin de çabuk eskimesine neden olabilir.

Bir zaman sonra geliştiricinin en kıymetli eşyası haline gelen kulaklıkları onu sahiplenir. İş yerinde, yolda, yatakta, oyun konsolu başında, mutfakta vs… Yine de iyi ses kalitesine sahip bir kulaklık her geliştiricinin vazgeçilmezidir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

Sennheiser

Hal 89:Bir fikir bulduğunda,Open Source dünyasında benzerleri var mıdır/yazılmış mıdır diye pek araştırmaz.

Bu aslında yazılım dünyasında ekip ve birey bazında Reinventing the Square Wheel isimli Anti-Pattern’e de yol açabilecek ihtimallerden birisidir. Bazen geliştirici çözüm arayışı içerisine girdiğinde, problemin daha önce karşılaşılmamış kadar özgün olduğunu düşünebilir. Bunun sonucu olarak tekerliği yeniden keşfetmeye çalışabilir. Ne var ki yazılım dünyasında var olan problemlerin çoğu bir şekilde çözülmüş olup asıl maharet içlerinden uygun olanını seçebilme becerisidir.

Bir AR-GE projesi olmadığı sürece tekerliği yeniden keşfetmeye çalışmanın çok fazla artısı olmayabilir elbette ama herşeyi körü körüne kabullenip nasıl çalıştığını bilmeden uyarlamak da doğru değildir ve Cargo Cult Programming adı verilen Anti-Pattern’ in oluşmasına sebebiyet verebilir.

Problemin büyüklüğüne göre uygulanması gereken çözüm farklılık gösterebilir ama mutlaka birilerinin denemiş olabileceğini düşünmek gerekir. Hatta problemin çözümü ile ilişkili vaka çalışmaları varsa okumak ve olasılıkları yakalamak mühimdir.

Günümüz yazılım dünyası pek çok ihtiyacın karşılanmasında kullanılabilecek sayısız açık kaynak çözüm içerir. Zor olan seçim yapabilmektir.

Açık kaynak çözümler sadece kullanılma aşamasında değil, geliştiricinin kendisini ileriye götürme noktasında da önem arz eder. Uygun olan çözümün tespit edilmesi ardından onu incelemek, hangi disiplinlerin uygulandığını anlamaya çalışmak hem öğretici hem de yaşanmış deneyimleri ileride kullanabilme anlamında faydalıdır. Tabi burada önem arz eden bir başka husus vardır. “Nasıl Karar Vereceğiz?”

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anti-Patterns
  • Cargo Cult Programming
  • Reinvent the Square Wheel
  • Codeplex
  • Sourceforge
  • GitHub
  • Case Studies

Hal 87:Uzun süre hatırlaması gereken devasa bir konunun özetini tek bir A4’e çıktı olarak almakta zorlanır.

Bazen öğrenilmesi gereken kavramlar bütünü veya bir projenin kritik çözüm mimarisi sayfalarca doküman yerine kağıt üzerine çıkartılmış akıl haritaları ile daha anlaşılır hale gelebilir.

Zor bir mimariyi öğrenmek zaman alan bir süreçtir ve hayatın geri kalan kısmında kullanılacaksa önemli kavramlarının zihne kazınması veya kolay ulaşılabilir bir yerlerde bulunması gerekir.

Bazı teknik kavramları kolayca hafızaya atmak mümkün değildir. Sürekli tekrar ve tecrübe edildiği takdirde beynin kabul edip saklamayı kabul edebileceği kavramlar vardır.

Her iki durumda da görünür ve anlaşılır not tutmak kıymetlidir.

Çoğu dedektiflik filminde koca bir pano ve üzerine suçla ilişkili detayların asıldığı pek çok materyal görülür. Fotoğraflar, oklar, post-it üzerine yazılmış kısa notlar vs…Bunlar vaka ile ilişkili büyük resmin daha kolay görülmesi ve gözden kaçabilecek detayların tekrar tekrar sorgulanması açısından önemlidir. Yazılımcılar için de bir şeyleri öğrenirken bu tip bir yaklaşım gütmek gerekir.

Öğrenme tekniklerinde bu amaçla pek çok araç kullanılabilir. Post-It tadında küçük not parçaları kullanılabileceği gibi A4 veya A3 üzerine çıkartılmış akıl haritası benzeri çizelgeler de işe yarar. Bazen bir iki cümle ile özetlenebilecek bir öneri veya vaka çerçeveletilerek bir yerlere asılabilir. Bu tip içerikleri sık sık görülebilecek yerlere asmak zihni çaktırmadan kandırmak olarak da düşünülebilir. Bir süre sonra beyin gördüklerini anlamlaştırarak hafızaya uzun sürece kalacak şekilde ekecektir.

Geliştiricinin kendi çalışma ortamında veya ekibin bir arada yer aldığı odalarda ilgili özetleri ve kısa mesajları içeren panolar bulundurmak gerekir. Hatta bir firmanın kendi ürettiği Framework’ ü şirketin bir duvarına boydan boya anlatacak şekilde resmetmesi çalışanlar için yararlı, müşteriler için de etkileyicidir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Mind Maps
  • Akıllı Panolar

Hal 86:Oyun oynamayı sever ama Game Credits kısmındaki isim listesini baştan sona okuyarak saygısını sunmaz

Oyun geliştiren firmalar yazılım sektörünün diğer kesimlerine göre çok daha kurnazdır. Öyleki “ben oyun oynamam” diyen yazılımcıları küçük cep telefonları başında dakikalarca vakit geçirmesine neden olacak psikolojileri tasarlamayı başarırlar.

Zamanında 64Kb bellek kapasitesi altında çalışan Commodore oyunlar ile günümüzün BlueRay disklerde gelen oyunları arasındaki en büyük benzerlik, kullanıcılarını ekran başına kitleyecek özellikleri sunmalarıdır.

Öyle ya da böyle her hangi bir platform üzerinde oyun oynayan yazılımcının çok doğal olarak en büyük arzusu, sıkılmadan oyunu bitirebilmektir. Bunun için epey çaba sarf etmesi gerekebilir. Bazen gece geç vakitlerden sabaha kadar makinesi başından kalkmaz ve ertesi günü oldukça yorgun geçirir!

Oyun firmaları sadece iyi oyunlar geliştirmek için uğraşmazlar. Kullanıcıyı ekrana bağlamak, bir sonraki sürümü sabırsızlıkla beklemesini sağlamak, ne kadar pahalı olursa olsun o parayı oyuncuya ödetmek ve en önemlisi kullanıcının tutkusunu daha da arttırmak için çabalarlar.

Eğer yazılımcı tutkulu bir oyun sevdalısı ise mutlaka bir konsola veya özellikleri ile sadece oyun oynamak için tasarlanmış bir bilgisayara da sahiptir. Ünlü oyun firmalarına üyedir. Oyun dergilerine abonedir. Çevresindeki arkadaşları ile online turnuva partileri düzenler.

Yeni nesil konsolların uzun süredir hareket algılama kabiliyetleri üzerine yaptıkları yatırımlar, yeni kuşakların bağımlılığını arttırma noktasındaki en büyük etkendir.

Ne var ki oyun endüstürisinin bu denli gelişmiş olması, yazılımcıları ekrana çivileyecek kadar akıllı tasarlanması, yazılımcının oyunu bitirdikten sonraki veya bitmeden önceki dönemlerinde Credit kısmını okumasına vesile olmaz. Bu biraz da işi yapanlara gösterilmesi gereken saygıdır.

Credit kısmında yer alan pek çok isim aslında kısa da olsa araştırılması gereken kişilere aittir. Kimisi oyunun motorunun geliştirilmesinde görev almış, kimisi ses efektlerini hazırlamış, kimisi 3 boyutlu giydirmeleri gerçekleştirmiş, kimisi de senaryosunu yazmıştır. Hatta bazı dev oyunlarda farklı firmaların bir arada yaşadığı da görülür.

Bir proje bittiğinde yazılımcının en çok şikayet ettiği şey yeterince takdir görmemesidir. Bunu göstermek çok da zor değildir. Hafifçe omuzu sıvazlamak, ekibi yemeğe çıkartmak, ilgi duyduğu alanı öğrenip ona göre hediye çeki ayarlamak, projenin zorluk derecesine göre bir kaç gün izin vermek vb pek çok aktivite ile ödüllendirilebilir. Yazılımcı bu tip ödülleri bekliyorken, kendisini saatlerce ekrana bağlayan oyunun Credit kısmını okumayı ihmat etmemelidir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Mevlüt Dinç (aka Mev Dinc)
  • Commodore 64
  • Kinect
  • XBox
  • Sony Playstation
  • Nintendo Wii

Hal 85:Kendinden yaşça daha küçük birisinin kendisine Rol Model olabileceğini düşünmez,düşünse de istemez.

Yazılımcılar yaşamları boyunca birilerini örnek alır ve onların yaptıklarını inceleyerek yürümeye çalışırlar. Bu örnek insanlar çoğunlukla rol modellerimiz olarak kabul edilirler. Ancak onların yaptıklarından fezy alıp bir şeyler başarmak ile onlar olmaya çalışmak arasındaki ince çizgi çoğunlukla gözden kaçırılır. Amaç özgün bir birey olarak başarılara imza atmak olmalıdır.

Rol modeller kimi zaman ulaşılmaları neredeyse imkansız insanlardır. Dünyayı peşinden sürükleyen bir firmanın CEO’su olmaları muhtemeldir.

Lakin rol modeller her zaman bu kadar ulaşılmaz noktalarda değildir. Kimi zaman yazılımcının yer aldığı ekibin takım lideri, birlikte çalışılan geliştirici de rol model olabilir. Hatta pozisyonu ne olursa olsun yaşça daha küçük birisi de rol model olur/olmalıdır.

Ne yazık ki pek çok yazılımcı kendinden daha iyi ama yaşça küçük olanları sevmez. Aslında yazılımcılar kendisinden daha iyi olanları genel olarak sevmezler. Bunun pek çok nedeni olabilir tabi ama temel sebep aslında bir yarış içerisinde olunduğunun düşünülmesidir.

Ufuk açacak nitelikte kaliteli olan fikir paylaşımları, hangi kuşaklar arasında olursa olsun yararlıdır ve kayıt altına alınması gereken çalışmalardır.

Pek çok rol model vardır. Bizden epeyce büyük olanların gerçek hayat tecrübeleri, aynı kuşaktan olanların farklı fikirleri ve  yaşça küçük olup sınırları zorlayanların hayal güçleri.

Hiç bir çocuğun hayal gücünü dinleyerek bir ürün geliştirmeye çalıştınız mı?

Anahtar Kelimeler (Bunlara Bir Bakalım)

Rol Model Nedir?

Hal 84:MIT 6.00 Introduction to Computer Science and Programming serisini bir kez bile baştan sona izlemez.

Yazılım geliştirmenin tarihçesine bakıldığında aslında Bilgisayar Bilminin ve Programlamanın ne kadar önemli bir yere sahip olduğunu fark ederiz. Çoğu yazılımcı bilgisayarlar üzerinde koşan uygulamaları geliştirmenin sanıldığı kadar zor olmadığını düşünür. Aslında çoğu yazılımcı bu düşüncesinde haklıdır. Eldeki araçlar bu işi mümkün olduğunca  basitleştirmektedir.

Bir devlet başkanının savunduğu üzere gelecek yıllarda sıradan bir insan olarak bilgisayarı kullanmak yeterli gelmeyecektir. Ona hükmetmek adına herkesin bir parça programlamadan anlaması, en azından onun dilini tanıması gerekecektir.

Yazılımcının düştüğü yanılgılardan birisi de işleri kolaylaştıran söz konusu araçların olması ve yaygınlaşmasıdır. Bu sebepten program yazmak eskisi kadar zor değildir. Ancak işin bir de kamera arkası vardır. Bu araçlar acaba nasıl geliştirilmektedir? İşi bu kadar kolaylaştırma noktasında ne çeşit prensipler uygulanmaktadır? Bu prensipler bir bilmin parçası mıdır? Bu bilim nedir? Ne kadar sonsuzdur? Ne kadar derine inmektedir? İnsanlığa hizmet edecek uygulama çeşidinin tanımı nasıl yapılabilir? Gündelik hayatta iş yerlerinde geliştirdiğimiz uygulamalar “insanlığa hizmet edenler” olarak düşünülebilir mi?

Çocuklar, gençler veya programlamadan anlamak isteyenler için yazılmış olan Scratch acaba nasıl geliştirilmiştir?

Kutucukları bu işi hiç bilmeyenlere sürüklettirmek yazılımcı için basit bir kod parçası ile mümkün olabilir ama asıl mevzu bu aracın eğitici olarak nasıl tasarlandığı ve gerçekten hiç bilmeyenlere programlayı nasıl olup da başarılı bir şekilde öğretebildiğidir. 

Bu ürünü geliştiren düşünce şekli bir bankacılık uygulamasınınkinden çok daha farklı ve ötedir.

Proje geliştirdikçe, ürün yazdıkça, bir ekibin parçası olarak hareket ettikçe yazılımcılar kendisini geliştirir ve tecrübesini arttırır. Ancak bu, zamanla egonun yükselmesine neden olur. Esasında bu işin bilimsel tarafı ile ilgilenen bir kesim de vardır ve onlar bilgisayar programlamaya, bilgisayarı anlamaya ya da ona hakim olmaya çok farklı bir boyuttan bakmaktadır. O bakış açısını yakalamak için giriş noktalarından birisi MIT’ nin 6.00 kodlu dersidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • MIT Video Lectures
  • Scratch

Hal 83:Guru’ larca hoş görülmeyen buton arkası çözümlerin bazen milyarlar kurtarabileceğini hiç düşünmez.

  • En iyi yazılımı geliştirmek? Nasıl olmalı?
  • Mimari ne kadar önemli?
  • Çözüm için en uygun teknolojiler hangisi?
  • Tasarım kalıplarından hangileri tercih edilmeli?
  • SOA olmassa olmaz mı?
  • En iyisi her zaman en pahalı olanı mı?
  • RDBMS’si yürüyemez miyiz?
  • Fark yaratması nasıl sağlanabilir ki?

Bu gibi sorular hemen her ekibin başına gelen veya yazılım işine yeni yeni girenlerin karşılaştıkları arasında yer alır. Hep en iyisini en güzelini yapmak ister yazılımcı.

Adamın biri zamanında Sedan tipinden bir aile arabasına onun saatte 340 km ile gidebilmesini sağlayacak bir motor yerleştirmiş.

İşin kötü tarafı aracı kullanacak ailelerin saatte 90 km’yi geçmeleri pek de olsaı değilmiş. Gereksiz yere üstün teknoloji ürünleri kullanılmış, üretim maliyetleri ve süreleri artmış. Sonunda bu maliyetleri düşürecek yollar aranmaya başlanmış ve yeni mühendislik çözümleri getirilmiş.

Sonuçta iş OverEngineering isimli bir Anti-Pattern olmuş.

Bazı hallerde, özellikle acil durumlarda ileriyi düşünmeden hareket edip şirketin önemli bir sorununu ortadan kaldırmak adına bodoslama çözümler uygulamak gerekebilir. Bu her ne kadar buton arkası bir durum olarak yorumlansa ve hatta bazen ürünü Magic PushButton’a(arayüz tabanlı iş mantıkları söz konusu olduğunda) götürse de zaman zaman hayat kurtarabilir.

Buton arkası tabir edilecek ve şık sayılmayacak bir kaç hareketle bir bankanın yıl sonunda hayatını kurtardığınızı ve kredi kartı satabilir hale getirdiğinizi düşünün. Bu anda uygulanan çözümün hiç bir pratikle bağdaşmadığını savunabilir misiniz? Gerçek hayat vakaları bazen çok şaşırtıcı olabilir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anti-Patterns
  • OverEngineering
  • Magic PushButton

Hal 82:Mesleki hayatı boyunca ne kadar kaçmak istese de doküman yazmaktan asla kurtulamaz.

Teknik dokümantasyon yazmak keyifli bir iş değildir. Günlük tutmaya pek de benzemez. Bir gazete köşesi yazmak gibi insanlara anlamlı gelmez. Bu ve benzeri sebeplerden yazılımcılar teknik dokümantasyon çıkartmaktan genellikle kaçma yolunu seçer. Oysa ki teknik dokümantasyonların bazen hayati derecede önemi vardır. Bu önem dokümanın çeşidine göre farklılık gösterir.

Bir ürünün Production ortamına kurulumu esnasında yaşanan sıkıntılar ve bulunan çözüm yolları mutlak suretle dokümante edilmesi gereken vaka çalışmalarının en güzel örneğidir.

Teknik dokümantasyon çoğunlukla XML Comment gibi işi kolaylaştırıcı unsurların bir araya getirilmesinden daha öte bir şeydir. Söz gelimi bir fonksiyonelliğin parametrik yapısı çoğu zaman usta geliştiriciler için dahi bir anlam ifade etmez. Oysa ki, bu fonksiyonelliğin kullanım biçimi, ne işe yaradığı, hangi hallerde değer kazandığı, iş değeri gibi pek çok detay onun kolayca anlaşılmasına olanak tanır.

Dünya üzerindeki yazılım şirketlerinin pek çoğu online olarak teknik dokümantasyon desteği verir. Ama en başarılısı MSDN’ dir. Güncelliği, teknik içeriklerin kolay anlaşılabilir olması, konuya göre seviyelendirilmesi, dokümanlar arası ilşkilerin kişiyi gerekli ve doğru noktalara götürecek biçimde oluşturulması, gerçek hayat vaka çalışmalarına yer verilmesi ve benzeri pek çok kriter bu başarının sebepleri arasında yer alır.

Teknik dokümantasyonların en büyük sıkıntısı güncel tutulmalarının zor olmasıdır. Pek çok geliştirici angarya olarak gördüğü bu işten bir an önce sıyrılmak maksadıyla gelişi güzel içerik üretme yoluna gider. Eğer denetleme mekanizması yoksa, bu doküman uzun süre raflarda(veya ortak bir klasörde) öylece kalır. Bir süre sonra unutulan doküman güncellenmediği takdirde gelecek için de pek bir anlam ifade etmeyecektir.

Teknik dokümantasyonlar açık kaynaklı ürünlerin başarısına doğrudan etki eden unsurların başında gelmektedir.

Bazı yazılım firmaları teknik dokümantasyon noktasında ayrıca görevlendirilmiş kişileri barındırlar. Özellikle ürün geliştirmekte olan firmaların bu konuda çok hassas davranıp gereken önemi vermesi beklenmektedir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Release Management – Sürüm Yönetimi
  • Teknik Dokümantasyon Çıkarmanın İp uçları
  • Teknik Dokümantasyon Türleri
  • MSDN
  • Örnek Açık Kaynak Ürünlere Ait Teknik Dokümantasyonların

Hal 81:Katıldığı projelerde elbette başarısızlıkla sonuçlananlar olabileceği ihtimalini kabullenmek istemez

Yazılım geliştiriciler bazen kendi aralarında toplanır ve birbirlerine başarıyla tamamladıkları projeleri anlatır. Hata onlara göre sadece ve sadece başarı ile tamamlanmış projeler konuşulmalıdır. Bu son derece doğal bir psikolojidir. Nitekim başarısızlıkla sonuçlanan projelerin maliyetleri herkes için fazladır.  Bu yüzden başarısızlık hem korkulan hem de gizlenmesi gereken bir olgu gibi görünür. Bir projeyi başarısız olarak saymanın pek çok kriteri vardır,

  • Zamanında bitmemiş olması,
  • Zamanında bitmesi için bir noktadan sonra ek kaynak kullanılmış olması,
  • Zamanında bitmiş olsa da ilk başta planlanandan çok daha farklı bir ürünün ortaya çıkmış olması,
  • Bir takım anti-pattern’ leri içermesi nedeniyle ürünleşme sonrasındaki zaman diliminde başkalarının başına dert açacak olması,

vb

Elbette bir projede başarısız olunmasını kimse istemez. Ürün sahibi başta olmak üzere herkes iş bitiminde bir parti ile kutlama yapmak ister.

Tecrübe arttıkça hata yapma olasılığı azalır. Aslında az hata yapmaya başlamak tecrübenin arttığının bir göstergesidir.

Yazılımcıların hata yapmaktan korkmaması ancak bunu alışkanlık haline de getirmemesi gerekir. Hata yapmayı azaltmak için bir kaç konuya dikkat edilmesi yeterlidir.

  • Sürekli pratik yapmak,
  • Öğrenilenleri unutmamak adına tekrarlarda bulunmak,
  • Anlık olarak ihtiyaç duyulan bilgilere doğru yollardan ve en hızlı şekilde ulaşabilmeyi sağlayacak yolları keşfetmek,
  • Bol bol farklı çözümleri okumak ve bunları irdelemek,
  • Sık sık daha tecrübeli insanlarla bir araya gelip onları sadece dinlemek,
  • Sorgulayıcı yaklaşmak ama bunu fazla abartmamak,
  • Öğrenilenleri tartışabileceği kişilere anlatmak ve onlardan fikir almak

vb

Elbette hata yapmanın da sınırları olmalıdır. Öğrencilik yıllarında yapılan yazılımsal hatalar, fark edildiği sürece kıymetlidir. Hatta öğrencilik yıllarında mümkün olduğunca fazla hata yapılması bir yazılımın olası hatalarını öngörme ve baştan tedbir alma yeteneklerini de arttırıcı bir etkendir.

Bazen büyük başarısızlıkların başka fırsatların kapısını açabileceği gerçeği de unutulmamalıdır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Başarılı Proje Kriterleri
  • Anti-Patterns,
  • Best Practices,
  • Case Studies,
  • Whitepapters

Hal 80:Boş zamanlarını,Stack Overflow da gezinip çözümleri okuyarak/problemleri çözmeye çalışarak geçirmez.

Bir yazılımcının tecrübesi gelecek zamanlarda karışalacağı problemlerin çözümü veya kariyer basamaklarını tırmanışı açısından önemlidir. Hatta bu tecrübe onu izleyen ve geriden gelen bireyler için de böyledir. Bir yazılımcının kendi tecrübesini arttırmasının pek çok yol vardır.

  • Yıllarca farklı projelerde bulunmak,
  • Müşterilerin akıl almaz sorunlarını çözmeye uğraşmak,
  • Epik görülen senaryolara çözüm üretmeye çalışmak,
  • Epik senaryoları çözüme kavuşturan adamları can kulağı ile dinlemek,
  • Bol bol kod yazmak,
  • Kod pratikler yapmak,
  • Sık sık bilinen önemli prensipleri(son zamanlarda kullanmıyorsa bile) şöyle bir gözden geçirip hatırlamak,
  • Kod gözden geçirme toplantılarında bulunmak,
  • Çeşitli firmaların sorun çözümü için kullandığı pratikleri ve vaka çalışmalarını okumak,
  • Daha önceden yazılmış eski proje kodlarının üzerinden geçmek ve daha iyisi nasıl olurduyu sorgulamak,

vb

Yazılımcılar her ne kadar yıllar geçtikçe tecrübe kazansa da, gelişen çevre koşulları, farklılaşan müşteri ihtiyaçları ve benzeri kriterler, onların birer tıp uzmanı gibi kendilerini sürekli diri tutmalarını gerektirir.

Bunlara ek olarak aslında boş vakitlerde değerlendirilebilecek ve özellikle sektöre yeni başlamış veya uzmanlaşmak isteyenlerin yapabileceği iki önemli davranış vardır. Stackoverflow sitesindeki soruları ve bunlara getirilen çözümleri okumak ve yeni sorulara çözüm bulmaya çalışmak.

Bu tip sitelere gelen dünya çapındaki ciddi sorular, uygun çözüm yolları ve yapılan yorumlar, kişisel gelişim açısından son derece önemlidir. Hatta genellikle çözülmüş problemlerin çözümüne bakmadan çözmeye çalışmak gerekir.

Problemlere getirilen farklı görüşleri bilmek ileri de karşılaşılacak sorunlarda hareketsiz kalmanın önüne geçecektir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

Hal 79:İş bitimleri ile ilgili süre tahminleri konusunda en azından ilk bir kaç yıl tutarsızlık gösterir.

Müşteri veya ürün sahibi dışında kalan yazılım unsurlarının en çok zorlandığı konu bir işin ne kadar sürede bitebileceğinin tahmin edilmesidir. Her ne kadar bu alanda bilimsel yaklaşımlar olsa da sonuçlar tecrübenin ilk yıllarında pek de tutarlı değildir. Dolayısıyla bilimsel süre tahminlemelerini ve tecrübeyi harmanlayan bazı bilir kişilerin buradaki mentorluğu çok önemlidir.

Yine de bir birimlik işin yapılma süresi genellikle işi üstlenecek olan geliştiriciye de sorulur. En azından geliştiricinin görüşü alınır. İşte bu soruya cevap verebilmek her zaman kolay değildir. Bir birim işin sadece ne kadar sürede bitirilebileceği yeterli bir ölçüm kriteri de değildir. Bu işi zaman bağımsız bir nicelikle ilişkilendirebilmek ve iş birimi açısından değerini tespit edebilmek de önemlidir.

Yapılması gereken bir birimlik iş, zaman bağımsız olacak şekilde değer ve büyüklük odaklı düşünülebilmeli, önceliklendirilebilmelidir.

Ürün geliştirmeyi etkileyen ve özellikle tahmin edilemeyen faktörlerin teslimatları geciktirebileceği gerçeği unutulmamalıdır. Her ne kadar başlangıçta tutarlı süreler verilmiş gibi görünse de evdeki hesap çarşıya uymayabilir. Riskleri de önceden hesaba katabilmek gerekir. Kapasitenin planlaması, kimin ne zaman tatile çıkacağının belirlenmesi, sağlık sorunları olması halinde felaket senaryolarının tasarlanması vb tedbilerin düşünülmesi önemlidir.

İşte bu gibi temel problemler, ekiplerin çevik metodolojilere yönelmesine neden olmuştur. Nitekim çevik süreçlerde iterasyon bazlı çalışılması ve ekibin genel iş yapma hızı ve süresinin ilk bir kaç iterasyondan sonra olgunlaşıp hep aynı seviyede devam ediyor olması gibi bir durum söz konusudur. İşte buna göre ekip ve üyeleri, zamanla daha isabetli paket teslimatları yapabilmektedir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Scrum Poker Oyunu
  • Scrum’ da Süre Tahminleme Teknikleri
  • Kapasite Planlama
  • Kanban

Hal 78:Yazdığı kodlar günlük psikolojisine göre değişiklik gösterebilir.

Başarılı projelerin yetenekli ve kumaşları kaliteli ekiplerin elinden çıktığı söylenir. Ancak en profesyonel ekiplerin dahi etkilenebileceği çevresel faktörler vardır. Bu faktörler bireyleri, ekibin tamamını ve ona bağlı olan diğer unsurları etkileyebilir. Başarı, söz konusu etkenlerin bireysel veya ekip seviyesinde nasıl aşılabildiğine göre değişiklik gösterir.

Özellikle ekibi zorlayan faktörleri aşma noktasında, pek çok yazılım geliştirme süreci farklı disiplinleri ele almaya çalışır. Çevik süreçlerde ekip içi iletişimin ön plana çıkmasının en büyük nedeni de karşılaşılabilecek zorlukları kolayca aşabilmek veya önceden görerek tedbir alabilmektir. Nitekim ürünün bireysel olarak değil ekipçe geliştirilme olgusunun ön planda olduğu bir yaklaşımı benimsemektedir.

Yazılımın kalitesini arttırmak ve başarılı projeler çıkartabilmek, bazı zorlu disiplinlerin uygulanmasını gerektirir.

Yine de disiplinlerin uygulanması noktasında bireylerin zamanla robotlaşan ve standartlaşan bir düzen içerisine girmelerinden kaçılamaz. Hemen her sektörde olduğu gibi yazılım sektöründe de insan psikolojisi genellikle göz ardı edilen bir unsurdur. Oysaki ekip üyelerinin psikolojisi, dertleri ve çözümsül kalan sorunları gün içerisinde yazdıkları kodları olumsuz yönde etkileyebilir. Her ne kadar kod gözden geçirmeler, stand-up meeting toplantıları, pair programming pratikleri vb çözümler uygulansa da psikoloji problemleri farklı bir yaklaşımı gerektirebilir.

Yazılımcıların duygusu olmayan makinelere söz geçirmeye çalıştığı ve hatta duygusuz makinelere duygu katmaya çalışacak karmaşık teknolojilerle uğraştığı unutulmamalıdır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Yazılım Geliştirme Disiplinleri
  • Code Review Toplantıları
  • Çevik(Agile) Metodolojiler
  • Stand-Up Meeting içerisinde Konuşulması Gerekenler
  • Pair Programming’ in Anlamı ve Önemi

Hal 77:Üniversitede ona göre en gereksiz dersin,günün birinde bir yazılımda işe yarayacağına ihtimal vermez

Yazılımcıların çoğu okul yıllarındaki dersleri ihmal eder.  Bunun bir kaç sebebi vardır. Kimi zaman dersin ne işe yaradığı veya hangi amaçlarla kullanılabileceği anlaşılmaz. Bu, yazılımcı adayının konuyu yeteri kadar sorgulamamasına ve sadece geçilmesi gereken bir ders olarak görmesine neden olur. Diğer bir sebep, dersi anlatanın konuyu yeteri kadar çekici ve eğlenceli hale getirememesi hatta işe yarar olduğunu ispat edememesidir. Ne varki bu sebeplerin hiç biri, yazılımcı adayının konuyu araştırmasına engel değildir.

Araştırmacı olmak, yazılımcıların sahip olması gereken önemli karakteristiklerden sadece birisidir.

Derste işlenen bazı konulara ilerleyen zamanlarda ihtiyaç duyulma ihtimali her zaman için vardır.  Bu konu, o an için gerekli önemli bir algoritmayı işaret edebileceği gibi uygun çözüm yaklaşımını da(modeli de) barındırabilir.  Bu yüzden yazılımcı adaylarının müfredatta yer alan derslerden sıkılmadan önce, gerçek hayatta hangi alanlarda ele alındığını öğrenmelerinde(gerekiyorsa öğretenlerden istemelerinde) yarar vardır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Araştırmacı Olmak

Hal 76:1den 100e kadar olan sayıların toplamını for döngüsü ile bulur ve Gauss’ un kemiklerini sızlatır.

Bilgisayarların hayata girmesinin yarattığı en büyük heyecan işleri kolaylaştırması ve hızlandırmasıdır. Her ne kadar istihdam noktasında n sayıda insanın işini üstlenecek bir misyona sahip olsalarda, zaman içerisinde herkesin bilgisayar kullanabilir olması dengesel dağılımı biraz olsun düzeltmiştir. Lakin bilgisayarlar sadece kullanıcıların hayatını kolaylaştırmamaktadır. Yazılım dünyasının inanılmaz hızla gelişen teknolojileri, yazılımcıların hayatını kolaylaştıracak yenilikleri de beraberinde getirmişir.

Bir zamanlar sadece tek bir programlama dilini kullananlar zamanla yerlerini, Framework’ ler ile uygulama geliştirenlere bırakmıştır.

Günümüzün Framework’ leri, başka Framework’ ler den türeyen ve belirli domain problemlerini çözmeye odaklanan niteliktedir.

Yazılım sektörü gelişirken eski problemler problem olmaktan çıkmakta ve değişime uğrayarak yeni nesil sorunlar haline dönüşmektedir. Hal böyle olunca eskiden çözmek için zaman harcanan veya kafa patlatılması gereken konular kolayca unutulmaktadır. Hatta yeni nesil geliştiricilerin hiç fark etmeyeceği ve çözmek için uğraşmayacağı problemler Framework’ lerin içerisinde erimektedir.

Geliştiriciler çoğu zaman aynen Gauss problemlerinde olduğu gibi kafa yormadan çözüme ulaşabilir. Sonuç, geliştiricinin matematik gibi konulardan uzaklaşması ve beynin tembelleşmesidir.

Günümüz geliştiricileri karşılaştıkları problemlerin çözümünde mutlaka alternatif yol arayışına girmektedir. Bu arayış içerisinde açık kaynak kütüphaneler mutlak uğrak noktaları arasında yer alır. Amerika’ yı yeniden keşfetmenin gerekmediği çoğu zaman ortadadır. Hatta zaman zaman ekipler bunu göz ardı edip yeni maceralara girer ve işin içinden çıkılmaz durumlara düşer.

Ne varki bazı hallerde çok daha iyi şekilde keşifler yapılmalıdır. Bazı problemler için tamamen In-House geliştirme yoluna gidilmesi noktasında bu şarttır. İşte böyle bir durumda matematiği Gauss’ dan çok bilmek gerekebilir. Dolayısıyla geliştiricin dimasını zinde tutmasında, arada sırada bulmaca çözer gibi vaka çalışması yapmasında ve problem çözme yeteneklerini geliştirmesinde yarar vardır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Carl Friedrich Gauss
  • Framework Nedir?
  • Framework İlkeleri Nelerdir?
  • Domain Odaklı Framework’ ler

Hal 75:Dennis M. Ritchie’nin The C Programming Language kitabını okur ve “I know kung fu” diyerek gezinir.

C yazılım ve sistem dünyasının efsaneleşmiş programalama dillerinden birisidir. Alt seviyeye yakın kodlama yapılmasına olanak tanıyan dili öğrenmek sanıldığı kadar kolay değildir. Daha çok akademik çevrede öğretilmeye/öğrenilmeye çalışılan ama dünyadaki pek çok sistemde uzun zamandır var olan dilin yetenekleri oldukça geniştir.

Günümüz yazılım ürünlerinin çoğu yüksek seviyeli diller ve hazır Framework’ ler ile geliştirilmektedir ancak bu C dilinin modasının geçtiği anlamına gelmemelidir. Bkz: TIOBE Programlama Dilleri Kullanım İstatistikleri

Dilin neredeyse her türlü makine de kullanımı mümkündür. Otomasyon sistemleri, endüstüriyel çözümler, robotlar, havacılık ve uzay teknolojileri, işletim sistemleri, oyun motorları, yapay zeka algoritmaları, NoSQL yapıları, eski nesil bankacılık uygulamaları ve daha pek çoğu örnek olarak verilebilir.

Ppek çok geliştirici C dilini öğrenmeyi düşünür/düşünebilir. Lakin bir dili öğrenmek her zaman için yeterli değildir. Saha tecrübesi, karşılaşılan vakalarda çözüme ulaşmak için uygulanan teknikler, analitik düşünce yetenekleri ve benzeri kriterler de önemlidir. Bu yüzden pek çok yazılımcı C dilini öğrendikten sonra herşeyi başarabileceğini sanabilir. Hatta onun babası Dennis MacAlistair Ritchie tarafından kaleme alınmış bir kitabın bu anlamda yeterli geleceğini sanabilir. Oysa ki C dilinin yakın durduğu sistemleri anlamak ve nasıl çalıştıklarını iyi bilmek çok önemlidir.

C dili üzerinde kariyer yapmayı düşünen bir geliştiricinin, programlama dilinin etkin kullanımı dışında, sistemleri en alt seviyede tanıması gerekir.

 

Bellek yönetiminden, soketlerin davranış biçimlerine, TCP/IP gibi protokollerin çalışma mantığından, broadcast mesajlarının biçimine, bilgisayar donanım sürücülerinin port haberleşmelerinden, resimlerin sıkıştırma formatlarına kadar geniş bir bilgi havuzu söz konusudur.

C dilini öğrenmeyi GO oyununu öğrenmeye benzetebiliriz. Ne kadar çok oynarsanız oynayın ancak onlarca müsabaka sonrasında onu kavrayabilir ve çok basit görünen temel kurallarını anlamaya başlayabilirsiniz. Ustalaşmak ise neredeyse bir ömür sürebilir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Dennis MacAlistair Ritchie
  • TIOBE
  • C Dilinin Kullanım Alanları
  • GO Oyunu

Hal 74:Aklına gelen fikirleri Johnny Menomic gibi tutacağını sanıp hiçbir yere not etmez ve unutur gider.

Bir yazılımcının gün içerisinde ilgilendiği ve çözmeye çalıştığı pek çok problem vardır. Bu problemler arasında gidip gelen akıl zaman zaman kayıt altına alması gereken bilgileri kaçırır. Diğer yandan aklın, anlama yeteneklerinin ve hafızanın yaş ilerledikçe yorulması da biyolojik bir gerçektir. Bu gerçek ileri yaşlarda hafızanın sürekli olarak out of memory exception vermesine neden olur. Dolayısıyla dimamız her tür bilgiyi tutamaz.

Yazılımcının gün içerisinde “sonradan çözerim” dediği bir problem bile kayıt altına atılmadığında kolayca unutulabilir.

Bu yüzden ürün geliştirme süreçlerinde User Story’ ler, Task’ lar ve benzeri kavramlar söz konusudur. Bu yüzden Scrum gibi metodolojiler de üzerlerinde post-it’ ler bulunan panolar vardır. Bu yüzden müşterinin bir ürün backlog’ u ve önceliklendirmeleri vardır. Bu yüzden neredeyse 50 yıldır var olan Kanban gibi sistemler vardır.

Günlük bilginin hafızada tutulmasının zorluğu hayatın tamamında da görülür. Yaş ilerledikçe beyne iletilen bilgilerin sayısı matematiğin sınırlarını zorlayacak derece de artış gösterir. Bu kadar çok iletiyi işleme hızı giderek düşer. Yapılması gereken bilgiyi bir şekilde filtrelemektir. Aslında sadece işe yarar olanların tespiti bile başlı başına bir iştir. Filtreleme sonrası sadece önemli olan bilgilerin hafızada tutulmaya çalışılması önemlidir. Yine de bir yazılımcı tedbiri elden bırakmamalı ve kolayca unutulabilecek bazı bilgileri kayıt altına almalıdır.

Beynin, karşısına çıkan her tür bilgi ile uğraşması yerine kişisel filtreden geçirilmiş bilgiyle mücadele etmesi daha kolaydır.

Johnny Menomic, filmde beynine sabitlenmiş hard disk içerisinde yüksek kapasitede bilgi taşıyan birisidir. Ne var ki hiç birimizin beyninde kolayca formatlayabileceği, istediği bilgiyi atacağı istediği zaman sileceği veya üzerine yazacağı bir disk yoktur(Şimdilik) Bu nedenle elde edilen bilgiler sonradan kolayca unutulabilirler. Onları kayıt altına almak, ulaşılabilir bir yerde tutmak, doğru bir şekilde kategorize etmek önemlidir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Bilgi nasıl işe yarar hale getirilir.
  • Bilgi beyin dışında nasıl kalıcı halde saklanabilir.
  • Bilgi nasıl doğru bir şekilde kategorize edilebilir.
  • Doğru bilgiye nasıl ulaşılabilir.
  • Scrum
  • Kanban
  • Product Backlog
  • User Story
  • Task

Hal 73:Bazı uygulamaların bilhassa komut satırından kullanılmak üzere geliştirildiklerine inanmak istemez.

Komut satırı pek çok sistemcinin hatta geliştiricinin sıklıkla başvurduğu/kullandığı ortamlar arasında yer alır. Basitliği, hızlı çözüm üretmesi gibi üstünlükleri vardır ancak yazılım işinin ilk yıllarında olanlar için genellikle sevimsizdir.

Meseleğe yeni yeni adım atan veya bir uygulama geliştirme platformunu tanımaya çalışan herkes görsel etkileyiciliği olan ekranlar ile uğraşmak ister. Masaüstü uygulamalar, web siteleri, mobil platformda koşan programlar vb…Hatta bir programlama dilini öğrenmeye, Windows Forms üzerine sürüklenip bırakılan Button kontrolünün Click olay metodunda başlanıldığına sıklıkla rastlanır. Ne yazık ki!

Oysa ki bir dilin temel yeteneklerinin en iyi öğrenildiği ortam komut satırıdır. Dilin temellerinin öğrenilmesi bir yana doğrudan sonuca götüren pek çok program aslında görsel arayüz detayları ile geliştirilmez. İstenirse sonradan bu programları kullanan görsel arayüzler ve yönetici panelleri sunulabilir.

Visual Studio gibi gelişmiş IDE’ lerin bir program kodunu derlerken ya da bir Web Servisini referans olarak eklerken komut satırından da çağırılabilen programları kullanığını biliyor muydunuz?

Bknz: csc.exe(C# Compiler), wsdl.exe, svcutil.exe, vbc.exe(Visual Basic Compiler)

Sistemcilerin çoğu hızlı aksiyonlar almak için komut satırı araçlarından sıklıkla faydalanır. Hatta bazı sunucu ailelerinde öyle şatafatlı görsel arabirimlere rastlanmaz. Çünkü son kullanıcı ile doğrudan iletişim kurmak gibi bir ihtiyaç yoktur. Bunu yerine asıl üstlendikleri işi yapmak için tasarlanmışlardır. Mutlak suretle komut satırına inmeniz ve bazı araçları parametreleri ile kullanarak çağırmanız gerekir. Kısacası komut satırı diyip geçmemek en doğrusudur.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Windows Komut Satırı Araçları
  • Komut Satırı Oyunları

Hal 72:Yazılan bir oyunu alt üst edecek testleri, uygun yaş aralığındaki çocukların yapacağını kestiremez.

Acımıdır bilinmez ama 4 yaşındaki bir çocuğun düşünce gücü ve bunu eyleme geçirme şekli genellikle bir yazılımcının öngördüğünden çok daha karmaşıktır. Hatta çoğu zaman tahmin edilemezdir.

Yazılımcılar uygulamalarını geliştirirken zaman zaman ipin ucunu kaçırıp mühendislik ötesi düşünce yapısında hareket ederler. Bu yaklaşım sonuncu ise pek çok basit noktayı kolayca atlayabilmeleri olur. Bunun pek çok nedeni vardır. Aşırı güven ve karmaşık düşünmeye eğitilmiş beyin yapısı kök sebeplerdir.

Oysa ki basit düşünce tarzında hareket eden ve çoğunlukla aptal kullanıcı olarak adlandırdığımız testçiler, çoğu zaman geliştiricinin fark etmediği veya yukarıdaki sebeplerden dolayı göz ardı ettiği durumların oluşmasına sebebiyet verirler.

Bazen, aptal kullanıcılara göre tasarlamaya çalıştığımız uygulamaların ne kadar karmaşık hale geldiklerini fark edemeyecek kadar aptalca geliştirme yaparız.

Oyun programlama alanında ise bu durum çok daha belirgindir. Genellikle oyunun kullanılabilirliğini test edenler aklı başında insanlar olurlar. Oysa ki onları minik ellerin test etmesi kadar zorlu bir test süreci daha yoktur. Nitekim bu tip testler bir oyunun kolay oynanabilirliği veya kullanıcı deneyimini arttırma noktasında çok önemli ip uçları barındırırlar.

Bir oyunun nasıl oynanacağını yetişkin birisinin gözetimi altında pek fazla zorlanmadan keşfedebilen bir çocuk, oyun geliştiricisi için altın değerinde tecrübeler üretir.

Çocuklar geliştiricinin onu izlerken “yok artık oraya o anda o koşullar oluştuğunda basmayı nasıl akıl etti” dedirtecek hareketler de bulunurlar. Bu zorlu mücadeleler geliştirici açısından kıymetli kazanımların ve tecrübelerin elde edilmesine de olanak sunar.

  • Daha dikkatli kodlama yapmak,
  • Kullanıcı bakış açsını yakalayabilmek,
  • Kullanıcı hareketlerini daha geliştirme aşamasında tahmin edebilmek ve tedbirler baştan almak,
  • Daha yalın bir düşünce tarzında hareket edebilmek vb

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • User Experience – Kullanıcı Deneyimi
  • Overengineering
  • Dummy User
  • Yalın Geliştirme – Lean Development

Hal 71:Öğrencilikte en iyi antrenmanın, var olan ürünleri sıfırdan geliştirmeye çalışmak olduğunu bilmez.

Öğrencilik yıllarında kafasına yazılımcı olmayı koymuş insanların aklındaki en büyük sorulardan birisi de bir kaç yıl tecrübeli eleman arayan iş yerlerine nasıl girebilecekleridir. Pek çok iş yeri ilanlarında “en az 2 yıl deneyimli” gibi klişe cümleleri kullanmaktadır. Peki yeni mezun olmuş bir öğrencinin ne kadar tecrübesi olabilir. Sene bazında olmasa da bu açığı geliştirdiği projeler ile kapatmış olabilir mi? En azından kendi bilgi seviyesini iş verene rahatlıkla gösterebilir mi?

İşte bu nokta da öğrencilik yıllarında yapılan staj çalışmalarının çok önemli bir yere sahip olduğu düşünülebilir. Gerçekten de öyledir. Hatta mümkünse standart 1 aylık stajlar yerine olabildiğince uzun staj dönemleri geçirmek gerekir. Yine de yeterli değildir. Pratik yapılmalıdır…Çok daha fazla kod yazılmalıdır…Daha fazla ürün incelenmelidir…Daha fazla kaynak okunmalıdır…Daha fazla çözüm incelenmelidir.

Bu sebeplerden dolayı öğrencilerin bol bol proje geliştirmeye çalışmasında yarar vardır. Lakin ne geliştirilebilir? Aceleci olanlarımız genellikle boşa vakit kaybetmek istemez ve kısa sürede paraya dönüşebilecek fikirlerinden peşinden gitmek ister. Hatta bir gelir modeline dayanan çözümler üretilmesi harikadır. Fakat pratik yapmak bilindiği üzere insanı mükemmelleştirir.

Öğrencilik yıllarında, var olan ürünleri tek başına(veya amatör ruhla bir  araya gelen ekipler olarak) geliştirmeye çalışmak, yolda karşılaşılacak problemler ve çıkmazlar göz önüne alındığında çok değerlidir.

Çözülmeye çalışılan her problem farklı bir deneyim kazandırır. Gerçekleştirilmiş olan bir fikrin sıfırdan değerlendirilmesi kafalar da “acaba nasıl bir çözüm tercih edilmiştir, hangi teknolojilere yer verilmiştir, bu sorun nasıl aşılmıştı ve neden?” gibi ki kıymetli soruların kapısını açar.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Business Model Canvas
  • Gelir Modeli
  • Ürün Yönetimi
  • Best Practices
  • Whitepapers

Hal 70:Kendi kendini eğitmek için nasıl bir yol izlemesi gerektiğini 20li yaşlarda keşfetmeye çalışmaz.

“Bir insan 7sinde neyse 70inde de O’dur” felsefesi çoğu zaman geçerlidir. Kişinin tüm karakteristik özellikleri için olmasa bile pek çok yoğurt yiğiş  yaşamı boyunca hep aynıdır. Yazılımcılar için de benzer bir durum söz konusudur. Yazılımcıların en büyük sıkıntısı, sektörü yönlendiren daha zeki yazılımcıların, mühendislerin ve bilim insanlarının olmasıdır. Bu yüzden yazılımcı sürekli olarak bir şeyler öğrenmek zorunda kalır. Çünkü sektör baş döndürücü bir hızla ilerlerken gerisinden gelen yeni nesil meslektaşları teknolojik araç ve donanım bakımından çok daha farklı bir dünyada yürümektedir.

30 sene öncesin çocukları çatapat patlatmak ile eğlenirken, günümüzün pek çok ilk öğretim talebesi dokunmatik ekranlı cihazlar kullanmakta ve hatta bazı gelişmiş ülkelerde Scratch gibi ortamlarda bilgisayar programlamayı öğrenmektedir.

Ancak yaş ilerledikçe ve zihin gençlik günlerindeki enerjisini kaybettikçe, yeni bir şeyleri öğrenmek de giderek zorlaşır. Dolayısıyla yazılımcının erken yaşlarda kendi kendisini keşfetmesi, zayıf taraflarını öğrenmesi ve daha da önemlisi kendisini yeni konularda nasıl yetiştirebileceğini bilmesi gerekir.

Kişinin erken yaşlarda kendisini en verimli şekilde nasıl eğitebileceğinin yolunu bulması önemlidir.

Bir deneme, iki deneme, üç deneme derken er ya da geç kişi kendisinin en iyi öğrenebileceği yolu keşfedecektir. Yeter ki bu yolu bir şekilde bulmaya çalışsın. Ancak unutulmaması gereken nokta şudur; zaman ilerledikçe kişinin kendisini yetiştirme teknikleri de değişime ayak uydurabilmelidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Öğrenme Teknikleri
  • Araştırma Teknikleri
  • MIT Scratch

Hal 69:’Yazılımda herşeyi yazmak mümkün, ama bu herşeye yazarız denilmesini gerektirmez’ sözünü benimsemez.

Yazılımılar karakteristik olarak ellerindeki araçlar ile pek çok işin üstesinden gelebileceğini düşünürler. Bu son derece doğaldır. Sektörel çevremizi şöyle bir gözlemlediğimizde bir kaç sene önce hayal bile edemediğimiz ürünlerin geliştirildiğini ve müşteri deneyimlerinin sürekli yükselen bir çizgide olduğunu görebiliriz.

Ürün sahipleri kendi hayal güçlerini çevrede gördükleri benzer ürün fonksiyonellikleri nedeni ile zorlamayı severler.

Bunun sonucu olarak yazılım ekiplerini zorlayabilecek ve genellikle daha küçük parçalara bölünmesi şart olan epik senaryoların altına imzalarını atarlar. Yazılım ekipleri sonuç itibariyle istenen ürünleri beklenen sürelerde teslim etmekle yükümlüdür. Bu işten para kazanmaktadır. Ancak yeri geldiğinde müşterinin uygun bir şekilde uyarılması, söz konusu isteğin her ne kadar yazılabilir olsa da risklerinin ortaya konulması, en azından gecikmeler yaşanabileceği konusunda bilgilendirilmede bulunulması önemlidir.

Scrum gibi pek çok modern ürün geliştirme metodolojisinde, Backlog Item’ lar oluşturulmasının, Business Value’ lar belirlenmesinin, kapasite planları yapılmasını, Item’ lara  önceliklendirmeler verilmesinin ve bu gibi aksiyonlar gerçekleştirilirken ekipçe karar verilmesinin en büyük sebebi; “olur olur yaparız” diyip sonrasında yapılamayan, bitirilemeyen isteklerin oluşmasının önüne geçilmek istenmesidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Scrum
  • Product Backlog Item
  • Business Value
  • Capacity Plan
  • Item Priority
  • Agile

Hal 66:Sosyal hayatı dijital dünyada arar.

Çevreye baktığımızda özellikle yeni nesillerin, ellerinden düşürmedikleri akıllı telefonları ile dünya üzerindeki bir noktadan diğerine hareket ettiklerini görürüz. Bu koordinatlar çeşitlilik gösterse de, aralarında değişmeyenler de vardır. WC, Yemek Masası, Çalışma Masası vb…Hatta, otobüste ayakta giderken, yolda yürürken, gün batımının karşısında otururken…

Peki bu insanlar bu mobilite içerisinde neye bakmaktadır. Onları ekranları başına bu denli fazla kitleyen şeyler nelerdir? Çok doğal olarak sosyal medyadır. Facebook’ un dan tutunda Twitter’ ına, Pinterest’ inden, Instagram’ ına kadar bir çok alan…

Oysa ki unutulan önemli bir kaç husus vardır…

  • Güzelim gün batımını izleyip o anın tadını çıkartmak varken, mobil cihaza gömülüp kaybolmak…
  • Bir çocuğun en mutlu gülümsemesini hissetmek yerine onu fotoğraflayıp Facebook’ a yüklemeye çalışıp Like’ ları saymak…
  • Pek çok kişinin gidemediği ülkelere gidip Instagram’ a koyacağı fotoğraflar ile övünüp, gittiği yerler için kağıda not çıkarmamak…
  • Arkadaşlar ile karşılıklı oturup sabahlamak varken, bunu bilgisayar başından kalkmadan yapmak…

vb…

Sosyal medya olmazsa olmazlardandır ama tüm hayatı onun üzerine kurup kişisel düzeni bu şekilde yürütmek olmaması gerekenlerdendir.

Hal böyle olunca da yazılımcının sosyal dengeyi aradığı en önemli yer olur dijital dünya. Zaman ilerledikçe yazılımcı, kendisini gerçek dünyada daha da yalnız hisseder. İnsanlarla iletişime geçmek için konuşmak yerine email yazmayı tercih eder. Yoğun iş temposu ve sıkıntılar da işin içerisine girince, dertlerini yakın arkadaşları ile paylaşmak yerine, Tweet mesajları atarak anlatmaya çalışır cümle aleme. Olan psikolojiye olur.

Anahtar Kelimeler (Bunlara Bir Bakalım)

Arda Çetinkaya

Hal 65:ThoughtWorks vb firmaların yayınladığı Technology Radar gibi bültenleri dikkate almaz.

Günümüzde yazılım sektörüne yön veren, endüstürileri doğrudan etkileyen, ürettikleri fikirler ile hepimize farklı vizyonlar ve bakış açıları sunan bazı kişiler ve hatta firmalar vardır. Bu kurum ve kuruluşların ortaya koyduğu fikirler dikkatlice takip edilmelidir.

Özellikle sektöre yeni yeni girmeye çalışan, bir süredir var olan ya da olgunlaşmış birer geliştirici olarak yer alanların aklında, kişisel gelişimleri açısından her zaman için bir takım sorular vardır.

  • Hangi teknolojiye/teknolojilere odaklanılmalı?
  • Teknoloji seçerken nasıl karar vermeli?
  • Şu anda yükselen trendler acaba hangileri?
  • Bu X teknolojisi gerçekten söylendiği kadar iyi mi?
  • Peki ya bu Y teknolojisinin endüstüriyel konumlandırması nasıl?
  • Kimler kendisini endüstüriyel anlamda ispat etmiş durumda?
  • Öğrenilebilecek yenilik olarak neler var?

vb

Bu gibi soruların cevaplarını yakın çevremizdeki tecrübeli arkadaşlarda da arayabiliriz. Ancak doğru cevaplar için sürekli hareket halinde olan, sektörün nabzını yakınen takip edebilen ve ona yön verenleri göz önüne almalıyız.  ThoughtWorks firmasının bu anlamda yayınladığı teknoloji radarı ilk bakılması gereken yerlerden birisidir. Bu radar sayesinde hangi trendlerin endüstüride nasıl konumlandığını keşfedebilir ve “işte bunları takip etmekte yarar var” diyebiliriz.

ThoughtWorks’ den Martin Fowler,  bloğunda yeni bir trend’ den bahsediyorsa(Örneğin Microservice Mimarisi gibi) bu mutlak suretle takibe alınması gereken bir konudur.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • ThoughtWorks
  • Technology Radar
  • TIOBE Programming Community
  • Martin Fowler

Hal 62:Mesleğin ilk yıllarında iddialı bir oyun motoru geliştirme hayali kurar.

Çoğu yazılım geliştiricinin rüyasıdır belki de akıllı motorlar yazmak veya yazan takımlarda yer alıyor olmak. Ne varki bu sanılanın aksine oldukça zordur. Özellikle de söz konusu motor oyun sektörüne yönelikse.

Bir konuyu iyi şekilde öğrenmenin en iyi yollarından birisi var olan örneklerini sıfırdan yazmaya çalışmaktır. Tekerleği yeniden keşfetmek bazen bireysel gelişim açısından oldukça yararlıdır.

Söz gelimi oyun motoru yazma hayali kuran bir geliştiricinin Packman, gibi insanları yıllarca peşinden koşturan ürünleri düşünerek geliştirmeye çalışması ilk adımlardandır. Tabi oyun dünyasın muazzam derecede geniştir. Oyun türleri fazladır. Platformlar değişkendir. Bir motorun hem mobil tarafa hem XBox gibi oyun konsoluna uygun versiyonlarını geliştirmek oldukça karmaşıktır.

Bir oyun motoru pek çok yazılım mimarisinden karmaşık ve anlaşılması daha zor parçalara sahiptir.

Bazen oyun motoru geliştirmek tek kişinin başarabileceği bir iş gibi görünebilir. Fakat pek çok oyun motoru cüssesine göre profesyonel ekipler tarafından oluşturulur. Firmanın sonraki oyunlarında ilgili motoru çekirdek olarak kullanmak istemesi halinde zorluk derecesi fazlasıyla artar.

Doğruyu söylemek gerekirse bu tip esnek bir oyun motorunu geliştirmek pek de kolay değildir.

  • İyi algoritma bilgisi,
  • Donanımları teknik mimari seviyesinde tanımak,
  • C,C++ gibi dillere çok iyi düzeyde hakimiyet,
  • Oyun motoru mimarilerini tanımak yeri geldiğinde yenisini tasarlayabilmek,
  • Oyun oynanabilecek farklı platformların teknik kabiliyetlerini tanımak,
  • Yapay zeka gibi konularda akademik düzeyde yetkinliğe sahip olmak vb

önemlidir.

Diğer yandan açık kaynak olarak paylaşılan ve sadece üzerine oturtulacak oyun sahasını geliştirmenin yeterli olduğu pek çok ücretsiz oyun motoru da bulunmaktadır. Hatta bazı başarılı Framework’ ler mevcuttur. Var olan bu oyun motorlarına bakılarak hareket edilmesi ve neyin nasıl yapıldığının anlaşılmaya çalışılması bu hayali kuran geliştiricilerin genellikle göz ardı ettikleri işlerdir.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Oyun Motoru Mimarisi – Game Engine Architecture
  • Ücretsiz Oyun Motorları
  • Unity Framework

Hal 60:İyi yazılmış kodların,kendini anlatmak için yorum satırlarına ihtiyaç duymayacağını bilmeyebilir.

Yazılım geliştirmek, onun için gerekli araçları öğrenip projeden projeye koşmaktan ibaret değildir. Önemli olan ve dikkat edilmesi gereken daha pek çok unsur vardır. Bunlardan birisi de geliştirilen ürünü kullanacak olanların ihtiyaçlarına göre, kodun okunabilir olmasını sağlamaktır.

Üretilen bir yazılım sadece dummy user olarak nitelendirilen kesime hitap etmez. Yarın bir gün onu genişletmek veya kendi ürünlerinde kullanmak için açıp kurcalayacak geliştiriciler olabileceği unutulmamalıdır.

Kodun okunabilir olması çok geniş bir yelpazeyi işaret etmektedir. İsimlendirme standartlarından Domain odaklı olmaya, gereksiz kod tekrarlarını engellemekten düzgün ve doğru parçalanmaya kadar pek çok kriter vardır. Bu sebepten kodun okunurluğunu arttırmak adına ortaya konmuş pek çok standart, metrik ve ölçümleme aracı bulunur.

İyi yazılmış ve tasarlanmış uygulama kodları çoğunlukla yorum satırlarına ihtiyaç duyulmaksızın kendisini ifade edebilir. Aslında pek çok yazılım takımı yorum satırı kullanılmasına karşıdır. Yorum satırları kodun okunurluğunu azaltan, kafa karıştıran ve oralarda bir şeylerin işaret edilerek kolayca unutulabileceği yerlerdir.

Hangimiz “bu kısımda metod parametrelerinin null olup olmadığını kontrol edelim” şeklinde bir yorum satırı açıp bunu ebediyen oracıkta unutmak ister.

Yorum satırına ihtiyaç duyulmadan kendisini kullananlarına gayet güzel bir şekilde izah eden kod parçalarını geliştirmek bazen ileri seviye teknikleri kullanmayı gerektirebilir. Örneğin Domain odaklı bir dil geliştirilirken, iş biriminden elemanların ilgili söz dizimlerini kolayca anlayabilmesi ve keşfedebilmesi önemlidir.

İşte bu noktada daha akıllı arayüzlerin sunulması gerekir. Fluent Interface gibi prensipler kodun okunabilirliğini arttırma noktasında önemli kabiliyetler sunar. Pek çok fonksiyonel dil bu tip özellikleri bünyesinde hazır olarak barındırır. Yine de kullanan yazılımcı, ürettiğini kullananlar için onu mümkün mertebe kolay okunabilir ve kullanılabilir olarak tasarlamalıdır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Domain Specific Languages
  • Flunet Interface
  • Martin Fowler
  • Okunabilir Kod
  • Kodlama Standartları
  • Kod Kalite Değerleri – Code Quality Metrics

Hal 59: Hayatı boyunca neredeyse hiç kağıt üstünde kod yazıp zihinde debug etmeye çalışmaz.

Bir programlama dilini öğrenmenin etkili bir kaç yolu vardır. Var olan ürünlerin benzerlerini yazmaya çalışmak, çeşitli kod pratiklerini tekrar edip uygulamak popüler olanlarındandır. Ancak olay sadece nihai sonuca ulaşmak olmamalıdır. Kodun kaliteli yazılması, içerdiği disiplinler varsa bunları harfiyen uygulaması, okunur ve daha da önemlisi hatasız yazılması da önem arz eden mevzulardır.

Bir programlama dili/ortamı sadece anahtar kelimelerden ibaret değildir.

Ancak geliştiricilerin sıklıkla düştüğü bazı öğrenme hataları vardır. Bunlardan birisi de en son sürüm IDE’ye sahip olmak ve onun üstünde görsel bir uygulama geliştirmeye çalışmaktır(Çoğunlukla bir Web veya Windows uygulaması)

Oysa dilin temel özelliklerini ve yeteneklerini öğrenmenin en iyi yolu çoğu zaman siyah Console ekranı üzerinden geçer. Hatta geliştirici ara sırada da olsa kağıt üzerinde çalışarak ilerlemelidir.

Kağıt üzerinde kod yazmak, onu kafada derlemeye çalışmak, olası hatalarını tahmin edebilmek, geliştiricinin içgüdüsel bazı kabiliyetlerini arttırıcı pratiklerdendir. Bu her ne kadar taş devrine dönmek gibi görünse de bir süre yapıldıktan sonra yazılan kodların derlenmesi sonucu oluşan hata ve uyarı mesajlarının giderek azalmasına yol açacaktır.

Bir kodu kağıt üzerinde yazmak şart değildir. Yazılmış kod parçalarını Notepad gibi bir arabirime alıp çalışma zamanı sonuçlarını tahmin etmek de önemli bir pratik olarak düşünülebilir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Kod Kalitesi
  • Özcan Acar – Kod Kata
  • Notepad2

Hal 58: Code Review gibi çalışmalarda sebepsiz yere sıkılır,bunalır ve faydasını görmek istemez.

İster küçük ister büyük ölçekli olsun, yazılım geliştiren firmaların önemli sorunlarından birisi de eleman sirkülasyonu sıklığıdır. Bu hazırlıksız olunduğunda ekibin gidişatını olumsuz etkileyen, verimli iş geliştirmenin önüne geçen bir durumdur.Her gidenin kontrolsüz şekilde bıraktığı kod parçaları, yapılmayanlar ile unutulanlar, yeni gelenlerin adaptasyon süreçleri vb kötü senaryoların oluşmasına gebedir.

Bu yüzden pek çok yazılım firması içeride uygulanan kod standartlarına dikkat eder ve kaliteyi arttırmak amacıyla çeşitli yöntemlere başvurur. Bu yöntemlerden en bilineni aslında Code Review adı verilen ekip içi kod gözden geçirme toplantılarıdır.

Code Review faydalı bir çalışma olmasına karşın kodun kalitesinin arttırılması ve verimliliğin yükseltilmesi açısından tek başına yeterli değildir.

Denetmenlerin profesyonel olması, doğru tecrübelerin aktarılması, eXtreme Programming gibi bazı pratiklere ait tekniklerin adapte edilmesi de gerekir.

Toplantıların amacı bellidir. İlk seanslarda etki etmese de ilereleyen zamanlarda ekibin aynı standartlar üzerinde kod yazmasına olanak sağlar. Faydalı sonuçları vardır.

  • Kodun okunurluğunun artması,
  • Bilinen kod standartlarının hatasız uygulanması,
  • Ekip içindeki bireylerin bir birlerinin kod parçalarını daha kolayca anlaması,
  • Bug ayıklama kabiliyetlerinin gelişmesi,
  • Daha kaliteli bir kodun ortaya çıkması,
  • Ekibin kendi içinde deneyimini arttırması ve kafalar arasında teknoloji transferi yapılması,
  • Hata oranlarının azalması
  • Daha isabetli test sonuçlarına ulaşılması

vb.

Ne yazık ki pek çok geliştirici bu etkinliklerin yazdıkları kodları aşağlayıcı bir amaç güttüğünü düşünür. Oysa ki yazılan koda veya uygulanan disipline karşı sorulan sorular, geliştiriciyi geriye değil ileriye doğru yönlendirecek niteliktedir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • eXtreme Programming
  • Code Review

Hal 56:Yazılım firmalarının Case Study olmuş çalışmalarını ara sıra da olsa okumaz.

Yazılım dünyasına henüz adım atmış veya atmak isteyen geliştirici adaylarının bazı temel problemleri olduğu kesindir. Örneğin öğrenilen dillere/ürünlere aşırı bağımlı olmak veya öğrenilenlerin nerelerde kullanılabileceğini tam olarak bilememek gibi. Birinci problem belki tolere edilebilir ancak ikincisi özellikle kazanılmak istenen vizyonerlik açısından bir engeldir.

Farklı ürünlerin Case Study çalışmaları, yazılım dünyasında yaşayan her pozisyon için vizyon arttırıcı fikirler barındırır.

Dünya çapında yazılım geliştiren, açık kaynak kod dünyasında yaşayan/yaşamayan ne kadar firma varsa zaman zaman ürünlerine ait Case Study çalışmalarına yer vererek başarılarını paylaşırlar. Bu paylaşımları takip etmek önemlidir. Çünkü ortada var olan bir müşteri ihtiyacı, karşılaşılan sorunlar, çözüm için ele alınan teknolojiler ve kısa bir başarı öyküsü içerirler.

Özellikle teknoloji seçimi ve bunun niye yapıldığı konusu geliştiriciler için keşfedilmesi gereken mevzulardan en önemlisidir. Bu sayede yazılımcı kafasındaki pek çok soruya cevap bulabilir.

  • Neden SQL ve Oracle yerine NoSQL kullandıklarını(ya da tam tersi),
  • SOA mimarisini hangi sebepten tercih ettiklerini,
  • Müşterinin firmadan tam olarak ne istediğini,
  • Birden fazla teknolojiyi tek bir çatı altında nasıl birleştirdiklerini,
  • Yolda karşılaştıkları sıkıntıları ve bunları aşmak için tercih ettikleri yolları,
  • Nasıl bir insan gücü kullandıklarını

vb

Bu tip kaynakları arada sırada olsa okumak, yazılım ekiplerinin daha sonradan karşılaşacakları sorunların çözümü ve teknoloji seçimi noktasında yararlıdır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Microsoft Case Studies
  • Oracle Case Studies
  • Amazon Web Services Case Studies
  • vb

Hal 55: Bir sınıfı isimlendirirken roman yazarından daha çok zorlanır.

Geliştiriciler her ne kadar kodlama standartlarına tam hakim olsalar da, iş fonksiyonelliklerini isimlendirmek her zaman kolay değildir. Özellikle nesne yönelimli dünya üzerinde yazılım geliştirirken bu sıkıntı kendisini iyiden iyiye hissettirir. Mimarinin atlına açılan çözüme ait proje isimlerinden, en küçük seviyede tasarlanan birim metodun adına kadar bir karmaşa söz konusu olabilir. Sıkıntı biraz da ürün sahibinin jargonu ile yazılım dünyasını eşleştirme güçlüğünden kaynaklanır.

Sektörel her yazılım ürünü küresel olarak kabul görmüş bir jargona sahiptir.

Ürünün özellikle belirli bir sektöre ait olması küresel seviyede kullanılan bazı isimlendirme standartlarını kullandırmayı gerektirebilir. Söz gelimi havacılık jargonunda yer alan terimler özellikle ürünün bileşen bazlı olup diğer ekiplerce kullanılacak olan kısımlarında pek değişikliğe uğratılmamalıdır.

Veriyi kaydetmek üzere kullanılacak bir fonksiyonelliğin Save kelimesini içeriyor olması önemlidir ama nesne kullanıcısının bunu SaveFlightPlan olarak ele alabilmesi anlamsal açıdan daha önemlidir.

Bir ürünün basit de olsa tüm çevresini ilgilendiren ortak bir jargonu vardır. Bu Domain bazında düşünülürse tasarım çok daha kolaylaşır.

Yazılımcının zorlandığı bu hali aşmasının kolay bir yolu vardır. Domain içerisinde kullanılan terimsel dili bilmek. Dilin iyi tanımlanmış olması ve kodlama standartlarına dikkat edilerek hareket edilmesi daha okunabilir bir çözüm oluşmasını sağlamakla kalmayacak, ürünle ilişkili bir dokümantasyon gerektiğinde bunun daha anlaşılır olmasına neden olacaktır. Örneğin bu felsefe ile Wiki sayfaları çok daha kolay hazırlanır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

Hal 54: Değil ara sıra, çoğu zaman W3C u ziyaret etmez ve standartlardaki gelişmeleri bilmez.

W3C(World Wide Web Consortium) dünyanın en önemli standartlarına hizmet veren bir kurumdur. XML teknolojilerinden HTML standartlarına, Web servisleri ile ilişkili mesajlaşma desenlerinden mimarilere, CSS’ den tarayıcı kriterlerine kadar pek çok konuda bilir kişi ve tanımlayıcı rolündedir. Ancak en önemli özelliklerinden birisi gelecek nesil standartlara, bunlarla ilişkili tartışmalar ve haberlere yer veriyor olmasıdır.

W3C çoğu zaman bir girişimciye yol gösterecek standartları ve Endüstriyel ilk el bilgilerini sunar. Semantic Web gibi.

  • Söz gelimi son yıllarda son derece popüler hale gelmiş olan Anlamsal Ağ ile ilişkili en güncel değişiklikleri buradan duyabilir ilgili bir geliştirici.
  • HTML’ i çok basit anlamda öğreticleri ile buradan öğrenebilir.
  • İlgili standartlar üzerinde çalışan grupları takip edebilir ve sadece tartışmaları okuyarak kişisel gelişimine katkıda bulunabilir.
  • Javascript WebAPI yi bile buradan hızlıca tanıyabilir.
  • Söz konusu standartlar ile ilişkili en güncel sektör haberlerini buradan okuyabilir.

Bu nedenle arada sırada da olsa geliştiricilerin düzenli olarak takip etmesi gereken önemli bir adrestir. Özellikle yazılım dünyasına yeni yeni adım atmaya başlayanlar için HTML’in, CSS’in, XML’in, Semantic Web’in, Javascript’in kolayca öğrenilebileceği bir dünyadır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Anlamsal Ağ – Semantic Web
  • W3C

Hal 53:Parametrik olarak dışarı alınan hassas bilgileri encrypt ederek tutmayı genellikle ihmal eder.

Yazılımcılar da unutkanlık sık rastlanan bir hastalıktır. Bazen bu kod tekrarı yapmalarına neden olur. Bu yüzden Don’t Repeat Yourself diyoruz.

MessageBox.Show(“Kullanıcı Mesajı”,”Madde 52yi oku yeter”);

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • DRY – Don’t Repeat Yourself
  • Encryption/Decryption

 

Hal 52: User/Pwd gibi hassas bilgileri ‘sonradan dışarı alıp parametrik yaparız’ der ama kod içinde unutur

Yazılım dünyasının değişmez kurallarından birisi “bu günün işini yarına bırakma” felsefesidir. Örneğin kod içerisinde o anda kullanılan bir veri tabanı bağlantı bilgisinin dışarıya alınmasında uygulanması gereken bir felsefedir.  Hatta bu dışarıya alınma işleminin yetersiz olduğu ortadadır. Biraz paranoyak olmalı ve ilgili bilgilerin yanlış ellere geçmesini ya da istenmeyen kişiler tarafından ellenmesini engellemek gerekir. Şifreleme, yetkilendirme ve doğrulama bu noktada değer kazanan konulardır.

Acemi geliştiriciler yazılım güvenliği konusunda yeterince paranoyak düşünmezler.

Paranoyaklık pek çok meslek dalında olduğu gibi yazılım için de iyi bir karakteristiktir.

  • Ya kod başkalarının eline geçer ve veri tabanı bağlantı bilgileri ele geçerse?
  • Ya kodun 38 yerine yapıştırdığım veri tabanı bağlantı bilgisi değişikliğe uğrarsa?
  • Ya Login işleminde geçici olarak kullandığım kullanıcı adı ve şifre bilgisini o metod içerisinde hard-coding olarak unutursam? (Hard Coding Anti Pattern)
  • Ya dışarıya alıp konfigurasyon dosyasında tutulan hassas içerikli bilgilerin olduğu sunucuya yetkisi olmayan birisi erişirse?
  • Ya parametrik hale getirilen içerikleri yöneten panele yetkisi olmayan herkes bağlanabiliyorsa?

vb

Oysa ki hassas içerikli ve uygulama geneline ait bilgiler pekala konfigurasyon dosyalarında veya çeşitli veri kaynaklarında(veri tabanı gibi) hatta cihaz üzerinde özel bölgelerde tutularak tek merkezden koordine edilebilirler. Üstelik bunların üstüne yazılacak çeşitli admin arayüzleri ile kolayca yönetilebilirler. Hatta ilgili arayüzlerin yetkilendirilmesi ile sadece izin verilen rollerdeki kişilerin bu işleri icra etmesi de sağlanabilir. Ancak yeterli değildir. Bilgiler hassas içerikli iseler şifrelenmelidir.

Pek çok Framework, Encryption/Decryption işleri için gerekli tüm fonksiyonellikleri içerir.

Kullanımları kolay olan bu işlevsellikleri ciddi anlamda düşünmek hatta konu ile ilişkili örnek pratikleri öğrenmek gerekir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Encryption / Decryption
  • Yazılımda Bilgi Güvenliği
  • Kod Erişim Güvenliği – Code Access Security
  • Doğrulama – Authentication
  • Yetkilendirme – Authorization
  • Rol Bazlı Yetkilendirme

Hal 51:Koca Solution da önemli bir değişiklik yapmadan önce, nerelere etki edeceğinin analizini yapmaz.

Bazen öyle Solution’ lar üzerinde çalışırız ki içerisinde onlarca proje yer alır. İşin kötü tarafı Solution’ ın tamamına hakim olamayacağımız durumlar söz konusudur. Pek çok takım projesinde geliştiriciler genellikle birbirlerinin alanlarına pek fazla müdahale etmeden kod üretebilirler. Söz konusu kod parçaları 3ncü parti kütüphaneleri/servisleri referans da edebilir. Bu yüzden her pozisyonun çözüme olan bakış açısı gereği görünümü farklılık arz eder.

Bir çözüm üzerinde çalışan her pozisyon için farklı bakış açıları söz konusudur.

Geliştiriciler her ne kadar birbilerinin alanlarına müdahale etmeden kod geliştirebiliyor olsalar da bazen yaptıkları değişikliklerin nereleri etkileyeceğini düşünmeden hareket ederler. Yapıyı minor olandan major olana kadar bozabilecek etkiler oluşabilir. Hatta bazı etkiler zincirleme reaksiyon başlatarak süreçleri olumsuz etkileyebilir.

Uygun metodolojilerin, TFS gibi yardımcı araçların kullanılması takım içindeki geliştiricilerin bulunduğu proje veya diğer projeleri olumsuz etkileyebilecek bir değişiklik yapmalarına engel değildir. Her ne kadar koordinasyonu ve ekip içi iletişimi üst seviye de tutsalar da bu böyledir.

Kritik kod müdahalelerinde uygulamanın etki analizlerine göre düşünerek hareket etmek çok önemlidir. Tehlike kodsal bir hataya mahal vermeyen ama iş sürecinin aksamasına veya yanlış çalışmasına neden olan küçük veya büyük kod değişiklileridir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Etki Analizi
  • TFS – Team Foundation Server
  • TFS Neleri Çözümler?

Hal 50:Koca Solution da önemli bir değişiklik yaptığında bunu dokümante etmez.

Dokümantasyon çıkartmayı seven kaç yazılım geliştirici vardır!? Bu zahmetli görülen iş mesleki olarak roman yazmayı tercih etmemiş geliştiriciler için elbette külfettir. Ancak bir yazılım ürününün dokümantasyonu gelecek nesil ekip arkadaşları için de önemlidir. Her ne kadar bazı ürünlerin kitap haline gelebilecek dokümantasyon içeriği söz konusu olsa da büyük çaplı projelerde birilerinin bu işle ciddi anlamda ilgilenmesi gerekir.

Dokümantasyonda işi zorlaştıran faktörler üç aşağı beş yukarı bellidir. Ürüne ait her hangibir noktada gelecek major veya minor değişiklilerin takip edilerek dokümantasyona yazılması önemli bir takip ve koordinasyonu gerektirir.

Pek çok yazılım geliştirme metodolojisi dokümantasyona karşıdır. Özellikle çevik süreçlerde odak noktası, Product Backlog’ dan itibaren müşterinin arzu ettiği isteklerin iterasyon sonlarında teslim edilebilmesidir. Ürünün istekleri müşteri gözünde net ve açık olduğundan dokümantasyona ihtiyaç duyulmaz.

Ürünün mimarisini, nasıl kullanıldığını, içeride yer alan iş fonksiyonelliklerinin ne işe yaradığını, sıkça sorulan soruları, best practices senaryolarını dokümante etmek gerekebilir. Bu tip bir yola girildiğinde ise değişikliklerin veya güncellemelerin dokümanlar üzerinde de yapılması şarttır. Oysaki pek çok geliştirici kritik sayılabilecek bir güncellemeyi dokümante etmeyi çoğunlukla unutur nitekim bunu yapmaya pek vakti yoktur ya da angarya olarak gördüğü bir iştir.

Ancak açık kaynak pek çok projeye veya büyük yazılım firmalarının sundukların ürünleri geliştiren takımlara bakıldığında, dokümantasyon konusunda da oldukça önemli eforlar sarf ettiklerini ve profesyonelce ilerlediklerini görebiliriz. Söz gelimi pek çok açık kaynak ürün mutlaka bir Hello World veya How To dokümanı içerir. Hatta pek çok ürünün takım blogları ve Wiki sayfaları bulunmaktadır. Hatta Product Manager, Architect ve Team Leader gibi pek çok pozisyonun buralarda düzenli olarak blog tuttukları görülebilir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Open Source projelerin dokümantasyonlar (Codeplex)
  • Microsoft Team Blog’ ları
  • MSDN
  • Best Practices
  • Product Backlog

Hal 49:Bir problemi duyar duymaz kodlayarak çözmek ister ve “Bi dur, düşün,optimize et,çöz,yaz” demez.

İlk okul sıralarından bu yana problem çözen bir milletiz. Ancak çocuk yaşlarda öğrenmemiz gereken, bir problemi algılama yeteneğinin kazanılması ve eğer karmaşık bir problemse daha küçük parçalara ayrılması gibi önemli kısımları kaçırmış durumdayız. En azından bunu kaçırmış koca bir nesil olduğunu söyleyebiliriz. Bunun doğal bir sonucu olarak söz konusu önemli yaklaşımları üniversite sıralarında kafa bir dünya sorunla doluyken anlamaya çalışıyoruz.

İşte belki de bu eksiklik nedeniyle pek çok geliştirici, bir problemi duyar duymaz kağıt kaleme sarılmak yerine doğrudan kodlamaya başlıyor. Ve ne yazık ki kodlama sonucunda tekrardan düzenlenmesi gereken çözümler ortaya çıkıyor.

Kaybedilen zaman, harcanan efor ve ortaya çıkan maliyet…Bu etkiler ve daha fazlasının seviyesi problemin büyüklüğüne göre de değişiyor. Büyük problem, acele çözüm ve sonuç büyük maliyetli kayıp anlamına geliyor.

Büyük Problem+Acele Çözüm=Büyük Zarar

Pek çok meslek dalında olduğu gibi yazılım dünyasında da problemi mümkün olduğunca basit şekilde düşünebilmek, yeteri kadar küçük ve yine anlaşılabilir parçalara ayırabilmek gerçekten önemlidir.

Çoğu geliştiricinin içinde yaşadığı Scrum gibi çevik süreçlerde Epic sayılabilen bir senaryo, daha anlaşılır parçalar haline getirilmeden çözümlenmeye çalışılmaz.

Hatta mümkünse geliştiricinin problem ile ilişkili çözüm yolunu ilk önce kendisine basit bir şekilde anlatabilmesi gerekir. Eğer bunu yapabiliyorsa belki en yakınındaki geliştiriciye bunu aktarması ve tepkilerini alması gerekir. Sonrasında problemin sahibine veya ekibe ilgili çözüm yolu anlatılabilir. Önemli noktalardan birisi de çözümün anlaşılabilir bir dille ifade edilebilmesidir.

Vaktiyle zamanında çalıştığım bir firmada müşterinin istediği ürünlere ait mimari yaklaşımları çıkartırken ekipçe tahta başına geçer, mimarın önerdiği modele sorular sorarak bozmaya çalışırdık. Model bozulmadığı yerde kabul gören çözüm haline gelirdi.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Yazılımda Problem Çözme Stratejileri
  • Scrum’ da Epic Senaryo Yaklaşımları

Hal 48:Kişisel gelişimi açısından kısa,orta ve uzun vadeli planlar yapmaz, paso kod yazar.

Geliştiricilerin belki de en büyük sıkıntısı sıkışık iş süreleri nedeniyle kafayı monitörden kaldıramayışlarıdır. Aslında bir geliştirici gün içerisinde kendisini rahatlatabilecek pek çok kaçış anı bulur. Ne varki bu anları değerlendirmek için genellikle sosyal ağlarda gezinmeyi tercih eder. Bu gereklidir tabi ama süreklilik arz etmemelidir.

Geliştiricinin gün içerisinde ara sırada olsa kendi alanı ile ilişkili güncel içerikleri okuması, ürün güncellemelerini takip etmesi gerekir ve bu gelişim açısından önemlidir.  Fakat ortada bir sıkıntı vardır ki o da çevresel bilginin korkutucu ve ölçümlenmesi zor olan hacmidir. Bu hacimsellik cevaplanması zor soruları beraberinde getirir;

  • Acaba ne okunmalıdır?
  • Yoksa okumamak mı gerekir?
  • Ya yanlış bir şeyler okunuyorsa?
  • Okunanlar gelecek için gereksiz olabilir mi?
  • Bu kadar bilgiden hangileri akılda tutulmalıdır?
  • Peki gelecek n yıl için neler mutlaka öğrenilmelidir?

 

Bu sorulara cevap verebilmek zor olsa da iyi planlama ve neyi istediğini biliyor olmak çözüme ulaşmak için yeterlidir.

Hey sen geliştirici; gün içinde veya geçtiğimiz ay boyunca ne kadar karmaşık kod blokları yazdığının veya hangi tasarım kalıpları ile uğraştığının farkında mısın? Onları başarabiliyorken, kendi gelişimini planlamayı mı beceremeyeceksin?

 

O yüzden geliştiricinin paso kod yazmaması bunun yerine sık sık kafayı kaldırıp monitöründen dış dünyaya bakması gerekir. Geliştiricilerin iki monitör ile çalışması bu anlamda önemlidir. Birisi kodlama alanını içeren ekranlar için diğeri de okunması gereken teknik yazılar için.

Geliştiricinin yerinde durması ileride Lone Wolf haline gelmesine sebebiyet verebilir. Her geliştirici istenen mertebeye gelemese de en azından hedeflediği bir konumda olabilmelidir. Bu konumlar yıldan yıla değişiklik gösterir. Bu hedeflere ulaşmak ise akıllı planlamayı gerektirir. Günü, haftayı, ayı ve hatta bir kaç sene sonrasını planlamak ve buna ulaşmak için gerekli adımları atmak önemlidir.

Anahtar Kelimeler(Bunlara bir bakalım)

  • Planlama
  • Kişisel planlama teknikleri
  • Zaman yönetimi
  • Lone Wolf/Single-Developer written code

Hal 47:İmkan olsa da, bir sürü niteliği olan bir varlığı, tip-nesne ilişkisi çerçevesinde düşünmez.

Eğer bundan 10larca yıl öncesinde olsaydık sürekli prosedürel formasyonda yazılım geliştirmek zorunda kalabilir ve nesne yönelimli dillerin nimetlerinden yararlanamayabilirdik. Ne var ki bu korkutucu sayılabilecek senaryo kendisini günümüzde de gösterebilmektedir.

Kimi yazılımcı nesne yönelimli bir dil ile geliştirme yaptığı halde bunun neleri çözdüğünü tam olarak anlamadan yürür.

Nesne yönelimli dil temellerinin yeterince kavranamayışı yüzünden zaman içerisinde yazılan kodlar metod içerisindeki satır sayılarının artmasına, birbirleriyle tanımlanabilir ilişkisi olmayan sınıfların oluşmasına neden olur. Hatta durum bir süre sonra o kadar vahimleşir ki ortaya Spaghetti Code, Lava Flow, Boat Anchor gibi Anti-Pattern’ ler çıkar.

Aslında nesne yönelimli düşünebilmek sanıldığı kadar da kolay değildir.

  • Sorumlulukları doğru şekilde dağıtabilmek,
  • varlıkların sadece veri taışıyıp taşımayacağına karar verebilmek,
  • varlıklar arası ilişkileri doğru biçimde kurabilmek,
  • çok biçimliliği etkin kullanabilmek,
  • kalıtımın hangi koşullarda fayda sağlayabileceğini karar verebilmek
  • Süreç odaklı sınıf yazmaktan uzak durabilmek,

ve daha pek çok konuyu iyi bilmeyi gerekirir.

Bazen elimizin altında ayrıştırılması son derece zor bir Text dokümanı olur. Bunu sadece satırlardan ve karakterlerden ibaret bir kaynak olarak düşünmek her ne kadar “basit düşünüyorum” mentalitesin uygun olsa da yeterli değildir.

Dokümanın değerlendirilebilir olması onun uygulama ortamına anlayacağı şekilde aktarılmasını gerektirir. Bu ise satırların kod tarafında doğru yorumlanmasını ve aslında parçaların aralarında doğru ilişkiler bulunan bir nesne bütünü şeklinde ele alınabilmesi demektir.

Yani doküman içeriğindeki parçalar uygulama için yaşayan nesnelerdir.

Ve ne yazık ki bu düşünceler de yeterli değildir. Dokümanın haritasının değişmesi, yeni parçaların eklenmesi/çıkartılması, yarın öbür gün Text yerine XML tabanlı bir içeriğin konumlandırılması söz konusu olabilir. Olay böyle bir noktada pek tabi bir takım yazılım prensiplerini de OOP çerçevesinde kullanabilmeyi gerektirir.

100Kb’yi geçmeyen bir Text içeriği kimi zaman sadece Text kimi zaman ise ilişkili nesneler topluluğu olarak görülebilmelidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Spaghetti Code,
  • Lava Flow,
  • Boat Anchor,
  • Anti-Patterns,
  • OOP Temelleri,
  • Polymorphism,
  • Inheritance,
  • Encapsulation,
  • SOLID Prensipleri,

Hal 46:Bilgisayara akla gelen ne varsa kurulur sonra “çok yavaşladı” denir.

Genç bir yazılımcı veya yazılımcı adayı son derece meraklıdır. Ama bu merak çoğunlukla yeni bir mimariyi/prensibi/algoritmayı öğrenmeye çalışma noktasında kendisini göstermez. Onun yerine son güncel ürünü kullanma merakı daha da kuvvetlidir. Örneğin geliştirme yapıtğı ortamın IDEsinin son sürümü mutlaka bilgisayar üzerinde yüklü olur.

Tabi istisnai durumlar vardır. Örneğin yazılımcı zaten araştırma amaçlı olarak son ürünleri kullanmak denemek zorunda olduğu bir pozisyonda çalışıyor olabilir.

Bu kadar çok ürün yüklenmesi sebebiyle yazılımcı, kişisel bilgisayarını belirli periyotlarda formatlama yoluna gitmek zorunda kalabilir. Çünkü sistem son derece yavaşlamıştır. Bunun pek çok sebebi vardır;

  • En son IDE’ ler mutlak suretle tedarik edilir ve bilgisayarda hepsinin olmasına izin verilir(Oysa ki çoğunlukla yeni IDE’ ler eskileri ile geliştirilen projeleri açabilme kabiliyetine de sahiptir)
  • Arada sırada dahi olsa çalışmakta olan servislere bakılmaz ve gereksiz olanlarının kapatılması yolu tercih edilmez.
  • Sağdan soldan duyulan ne kadar açık kaynaklı proje varsa kurulur.
  • Kişisel bilgisayar bir sunucu zannedilir ve üzerine kaç tane servis yüklediğine bakılmaksızın hantal uygulamalar atılır(Team Foundation Server, SQL Server gibi)

Hatta çoğu zaman makine de SQL Server yüklü olmassa geliştirme yapılamayacağı sanılır. Oysaki SQL Server yüklü olmayan bir makine de veri odaklı uygulama geliştirmeye çalışırken Dependency Injection gibi kavramların daha iyi öğrenilebileceği unutulmamalıdır. En nihayetinde SQL Server veriyi saklamak için bir Repository’ dir. (Veriyi artık Cloud üzerinde tutabildiğimiz düşünülürse bir veritabanı sunucusuna yerel bilgisayarda ihtiyaç dahi yoktur)

Ne yazık ki pek çok yazılımcı kişisel bilgisayarında SQL Server benzeri bir veri tabanı motoru olmadan Data-Centric uygulama yazamayacağına inanır.

Dolayısıyla bu hatalar peşi sıra devam eder ve bir süre sonra işletim sistemi üzerinde koşan servislerin haddi hesabı olmaz. Bellek kullanımı artar, işlemci o anda geliştiricinin hiç ihtiyacı olmayan hizmetleri ele almak zorunda kalır. Dolayısıyla yazılımcı kaotik bir ortama kavuşmuş olur. Çare bellidir…Format atmak.

Kurumsal kabul edilen pek çok ürün son sürüm IDE’ler ile geliştirilmez . Buna karşın başarılı bir şekilde yaşar ve genişler.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Veri kaynağı bağımsız uygulama nasıl geliştirilebilir?
  • Dependency Injection
  • Inversion of Control

Hal 45: Bir dilin veya ürünün fanatiği olunur ve diğerlerine ömür boyu tu kaka denilir.

Fanatiklik her zaman için olumsuz etkilere neden olabilecek bir davranış biçimidir. Pek çok insan gibi yazılımcıların da sorgulamadan savundukları konular vardır. Ancak bir yazılımcının ürün odaklı fanatikliği diğer fanatikliklere pek benzemez. Çünkü bir programlama diline veya yazılım ürününe aşırı derecede bağlanmak, onu her platformada savunmaya çalışmak getiriden çok götürüye sebebiyet verebilir.

Ürün fanatizmi yazılımcıları Anti-Pattern oluşumuna götüren sebeplerin en önemlisidir.

Aslında bir ürüne bu kadar çok bağlı olmak bir takım Anti-Pattern’ lerin de oluşmasına neden olur. Cargo Cult Programming, Vendor Lock-In, Golder Hammer, Over Engineering, Design by Commitment gibi karşıt desenlerin oluşmasında önemli bir faktör olarak düşünülebilir. Bu da aslında kritik bir kaç sonucun doğmasına neden olur.

  • Ürünün zamanında yetişmemesi,
  • İstenen ürünün ortaya çıkmaması,
  • Beklenenden fazla zaman harcanması,
  • Proje maliyetinin artması,
  • Kişisel güvenin kaybolması vb

Zaten yazılımsal bir ürünün geliştirilmesi noktasında sahip olunan bilgiler ile harekete geçmek çoğu zaman yeterli olmaz. Geliştirilmesi istenen/düşünülen ürünün hangi teknolojiler ile ele alınması gerektiğine karar vermek yolun başında yapılması gerekenler arasında yer almaktadır.

Kimi programlama dili çok az kullanılsa da o ürün veya ihtiyaç için biçilmiş kaftan olabilir. Kimi platform her yerde kullanılıyor olsa da istenen ihtiyaç için fazla gelebilir. Bu nedenle fanatik olmak yerine farklı ürünleri de göz önüne almak, özellikle bir ürünün hangi pratiklerde uygun olabileceğinin farkında olmak önemlidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Anti-Patterns
  • Cargo-Cult Programming
  • Golden Hammer
  • Vendor Lock-In
  • Design by Commitment
  • OverEngineering

Hal 44:Bir problemin çözümünde bazen Pseudocode dan yararlanabilmenin çok kıymetli olduğunu fark etmemek.

Yazılımcının dünyası sürekli çözüm bekleyen problemlerle doludur. Kimi problemin çözümü bellidir, başkaları tarafından uygulanmış ve yazılımcı tarafından fark edilmesi ilerlemek için yeterlidir. Çözümü bulmak her ne kadar önemli olsa da, onu uygulayacak bir tarafın varlığı çok daha önemli olabilir. Sorun, problemin çözümünün nasıl uygulanması gerektiğini anlaşılabilir bir şekilde aktarıp aktaramamaktır.

Problemi daha küçük parçalara ayırma felsefesi kendisini Scrum gibi çevik süreçlerde de gösterir. Epic bir kullanıcı hikayesi, ele alınabilir parçalara bölünerek anlaşılmaya çalışılır.

Çözümün anlatılacağı taraf değişkenlik gösterir. Bu bazen aynadaki siz bazen takım içindeki ekip üyeleriniz ve bazen de yazdığınız matematik algoritmasına ait tezin okuru olabilir. Eğer herkes aynı dili konuşuyorsa çözümünün anlatımı kolaydır. Ama fazla detay, sorunun daha karmaşık olarak algılanmasına da neden olabilir.

Pseudocode kimi zaman ekip liderinin ekibine armağan ettiği bir şiirdir.

İşte bu gibi hallerde Pseudocode kullanmak son derece yararlıdır. Nitekim temel programlama mantığı olan herkesin anlayabileceği bir söz dizimi sunar. Bu sayede bir matematik profesörü, okuru olan programcılara nasıl yazmaları gerektiğini kolayca aktarabilir.

Pek çok matematik modelin, yazılım tarafında her hangi bir dil ile ele alınabilmesi için Pseudocode’ lar dan yararlanılır.

Pseudocode dilini bilmek iş birimi gibi çok fazla teknik detaya girmeyenler için de paha biçilmez bir nimet olabilir(Hatta bir proje yöneticis için) Bu kimi zaman teknik detay düşkünü elemanlar ile iş mantığını konuşanlar arasında bir köprü vazifesi görür.

Anahtar Kelimeler(Bunlara bir bakalım)

  • Pseudocode Örnekleri
  • Pseudocode Standartları
  • Numerik Analiz ve Pseudocode

Hal 43:Algoritmaların sadece sıralama işlemlerinde kullanıldığını düşünmek.

Pek çok yazılım geliştirici eğitim dönemlerinde yoğun şekilde algoritmalar ile ilgilenir. Ne varki söz konusu algoritmalar çoğu zaman sıralama için kullanılanların ötesine pek geçmez/geçemez. Çünkü algoritma okumak, öğrenmek, uygulamak hep sıkıcı olmuştur.

İşin aslı gerçek dünya da geliştirilen uygulamalar da ileri seviye veya adı pek de duyulmamış algoritmalara pek de ihtiyaç duyulmaz. Çünkü dünyanın ağırlıklı olarak veri odaklı uygulama geliştirme üzerine kurulduğu düşünülür.

Gerçek şu ki, yazılım dünyasında kullanılan algoritmaların sadece sıralama işlemleri için var olduğunu düşünmek hatadır.

Ancak pek çok endüstriyel çözüm de tabiri yerinde ise zihni-sinir fikirlere ihtiyaç vardır ve bu fikirleri ortaya koymak için iyi algoritma bilgisine sahip olmak gerekir. Hatta bu da yeterli değildir. Var olan algoritmaları tanımak, hangi amaçlarla kullanıldığını sezmek ve çözüm de rol alıp alamayacaklarını bilmek de önemlidir.

  • Çünkü bir alış veriş sisteminin müşterilerine karakteristik özelliklerine göre en uygun önerilerde bulunması ve bunu kargo sisteminin verimliliğini arttıracak bir model ile birleştirmesi için iyi bir algoritmaya ihtiyaç vardır.
  • Çünkü çok büyük boyutlu dosyaların içerisinde aranan parçaları çekip çıklartma noktasında uygulamayı hızlandıracak algoritma çözümleri gerekir.
  • Çünkü ileri düzey grafik işlemlere izin veren bir programın algoritmalara ihtiyacı vardır.
  • Çünkü bir oyun motorunun çoğu noktada oyun sahasının ektin yönetimi için algoritmalara ihtiyacı vardır.
  • Çünkü firmanın üretim hattının optmizasyonu için gerçeğe en yakın sonuçların tespiti noktasında etkili bir algoritmanın seçimine ihtiyaç vardır.
  • Bir arama motorunun diğerlerinden öne çıktığı noktada mutlaka iyi bir algoritma vardır.
  • Finansal hareketlerin olduğu ekonomik göstergelerin anlamlaştırılması noktasında çeşitli algoritmalara ihtiyaç vardır.
  • vb…

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • List of Algorithms (Gerçek burada)
  • Amazon’ da Algoritmalar ile ilişkili kitaplar
  • Vasif Vagifoğlu Nabiyev

Hal 42:Kullanılan Framework kod içeriklerine bakıp ne kadar çok şey öğrenebileceğini düşünmemesi.

Nesne yönelimli dünyadaki Framework’ ler, uygulama geliştirmeyi hızlandıran, çözümün daha derli ve toplu halde vücud bulmasını sağlayan bir alt yapı topluluğu olarak düşünülebilir. Önemli olan özelliklerinden birisi ise hangi ekipten çıktığına bağlı olarak sunduğu  deneyim izleridir.

Pek çok büyük yazılım firmasının geliştirme ortamına ait Framework’ ler olduğu bilinmektedir. Bu framework’ lerin bir kısmı kapalı kodlardan oluşsa da zaman içerisinde içerikleri açılanlar olduğu da unutulmamalıdır. Hele ki Open Source dünyasında yer alan bazı Framework’ ler tamam geliştirilmeye açıktır.

Yazılım disiplinlerinin örnek pratiklerini içeren Framework’ ler, derinlemesine incelenmesi gereken enstrümanlardır.

Dünya üzerinde yetenekli ve çok yönlü Framework’ ler yer almaktadır.  Aslında yazılım dünyasında Framework denildiğinde akla ilk gelen noktalardan birisi Microsoft .Net Framework’ tür.

Ne var ki yazılımsal Framework denildiğinde konu daha farklı biçimde ele alınır ve sadece nesne yönelimli dünya söz konusu olmaz. Bknz: Software Framework.

Bir programlama dilini ve özellikle ortamını öğrenirken, konuları kavrama noktasındaki en büyük destekçi şüphesiz bunu uygulamış olan alt yapılardır. Bir başka deyişle Framework’ ler. Özellikle kendi dilinde yazılmış olan Framework’ ler dilin kabiliyetleri hakkında epeyce bilgi sunar ve önemli pratikleri bünyesinde barındırır. Dolayısıyla geliştiricilerin göz atması gereken enstrümanlar arasında önemli bir yere sahiptir.

Yazılımcılar çoğunlukla bir desenin uygulanması noktasında kafa karışıklığı yaşar. Ancak Framework’ ler içerisinde bu disiplinlerin örnek pratikleri de yer alır. Yazılımcının bunlara bakması önemlidir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Açık Kaynak Framework’ ler
  • Framework Design Guidelines

Hal 41:Juval Lowy’nin C# Kodlama Standartları dokümanını okumamasıdır.

Yazılımcılar çoğunlukla sıkılgan yapıdadırlar. Bu yüzden sık sık iş değiştirmek durumunda kalabilirler. Buna bir de Y kuşağı bilmecesi eklendiğinde ve uzun soluklu projeler katıldığında, bir ekibin başındaki üyeler ile sonundakiler aynı insanlar olmayabilir.

Böyle bir vakanın yaratacağı en büyük sorun ise ürünün geliştirilmesindeki yazılımın kalitesinin korunmasının güçleçmesidir. Çünkü eleman sirkülasyonunun oluşturacağı pek çok sorun yanında ürün kod standartlarının, çarklar arasına yeni katılanlar tarafından da korunuyor olması gerekmektedir.

Kod standartlarının kaçırılmaya başladığı ve yazılımcının kendi dünyasındaki kuralları koymaya başladığı nokta, ürün kod kalitesinin bozulmaya başladığı noktadır.

Kodun kalitesinin arttırılmasının ve bunun devamlılığının sağlanmasının pek çok yolu vardır. Örneğin düzenli olarak yapılan Code Review toplantıları veya IDE ortamlarında kullanılan kod kalite ölçüm araçları bunlardan sadece bir kaçıdır. Yine de yeterli değildir. Ekibin üyelerinin de belli kalitenin üzerinde geliştiricilerden oluşması önemlidir. Pek tabi yeni katılacakların da en az bu kalitede olması gerekir.

Yazılımcının kalitesini arttıran önemli unsuırlardan birisidir kod standartlarını biliyor ve uyguluyor olması.

Kod standartlarının harfiyen uygulandığı bir ürün kendisini hemen belli eder. Standartları bilen her geliştiricinin okuyabileceği, kolayca anlayabileceği bir söz dizimi ve alt yapı bütünü söz konusu olur.

Dünya üzerinde bilinen bir kaç önemli kod standartı vardır. Bu standartların önemli özelliği kendilerini endüstüriyel alanda kanıtlamış olmalarıdır. Standartlar bir fonksiyonun nasıl isimlendirilmesi gerektiğinden, etkin bir metodun satır sayısının ne olması gerektiğine kadar pek çok konuda önerilerde bulunur.

Yazılımcıların kaliteli kod üretmesi için Juval Löwy gibi ustaların endüstüriye kazandırdığı kodlama standartlarını en azından okuması gerekir.

Ne var ki kod standartlarını iyi uygulamak büyük çaplı bir proje de küçük bir detay olarak kalabilir. Çünkü büyük çaplı projelerde uygulanan mimari çözümler, kullanılan desenler ve daha iler seviye tekniklerin standartlarının sağlanması ve korunması da oldukça önemlidir.

Anahtar Kelimeler(Buınlara Bir Bakalım)

  • Kod Standartları (Code Standards)
  • Kod Kalite Ölçüm Araçları (Code Metrics)
  • NDepend
  • C# Kod Standartları
  • WCF Kod Standartları

Hal 40: Unit Test leri çoğunlukla angarya iş olarak görüp ihmal etmesi.

Geliştirilen ürünlerin büyüklüğü ne olursa olsun ihmal edilen veya tam olarak yerine getirilemeyen işlerden birisi de test süreçleridir. Test ile ilgili işler genellikle son kullanıcının, bir başka deyişle ürün tüketicisinin yapması gereken işler olarak düşünülür. Ancak Test denilen olgu, günümüz modern uygulama yaşam döngüsü yönetimi ve geliştirme süreçleri göz önüne alındığında, birim iş fonksiyonelliklerinden başlar.

Yazılımcılar zaten kısa olan proje sürelerinde, fazla sayıda olan görevle uğraşmak zorunda kaldıklarından, artan fonksiyonellikler nedeniyle Unit Test işlemlerinden sürekli kaçma eğiliminde olurlar. Eğer ki ekip içinde Code Review tarzı toplantılar yapılmıyor ve hatta birim testler görevler(Task diyelim) ile ilişkilendirilmiyorlarsa kaçış kolaylaşır. Oysa ki pek çok yazılım yönetim süreci, görev olarak adlandırılan senaryolarının başarılı olmasını test sonuçlarına bağlar.

Aslında alıştıktan sonra bir geliştiricinin Unit Test olmadan ilerlemesi pek de mümkün değildir. Yine de alışılmayı zorlaştıran bir kaç unsur vardır. Test senaryosuna karar vermek, test metodunun adının ne olacağını belirlemek, test metodlarının içeriklerini yazmak, TDD ile gidiliyorsa Red Green Blue olarak ilerlemeye çalışmak bunların başında gelir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Tabi ki Unit Test nedir?
  • Uygulama Yaşam Döngüsü Yönetimi(Application LifeCycle Management)
  • Test Güdümlü Geliştirme (Test Driven Development)

Hal 39:Bazı ürünlerin geliştirildiği ortam/çevre nedeniyle Agile yürütülemeyeceğini kabul etmemesi.

Yazılım sektörü yaşadıkça çeşitli geliştirme süreçleri popüler olacak, bazıları kötülenecek, bazıları gelişimlerine devam edip daha çok kitleye ulaşacak, bazıları tamamen terk edilmek istenecektir.

Bir problemin çözümünde uygun metodoloji seçimini yaparken “şu an en popüleri bu, o yüzden bunu tercih ettik” dememek gerekir.

Bir ürünün geliştirilmesine etki eden pek çok faktör olduğu unutulmamalıdır. Ekip, teknolojildeki yenilikler, müşterinin uçuk kaçık istekleri, asıl önemli olan gereksinimler, sahip olunan donanımlar, lisanslamalar vb. Tüm bunlar aslında birbirleriyle ilişkili olan bir domain yapısı gibi düşünülebilir.

Bir ekibin hazır olmadığı veya uygulamakta güçlük çekeceği aşikar olan bir sistem de ısrarcı olmak ekibin geliştireceği ürün için hatalı hedeflere ulaşılmasına sebep olabilir. Hatta daha kötüsü hiç bir hedefe ulaşılamamasıdır.

Bu yüzden ekibin öncesinde iyice eğitilmesi ve hatta bir test projesi ile konuya hakimliğinin arttırılması gerekir. Hatta en iyi pratiklerin anlatılması ile ekibin çeşitli istisnai vakalara hazırlıklı olması da sağlanmalıdır. (Eğer gerçekten Scrum uygulanmak isteniyorsa)

Günümüzün en popüler yazılım geliştirme metodolojilerinden birisi gerçekten de Scrum’ dır. Ancak bir ürünün geliştirmenin en iyi yolu olduğunu söylemek doğru değildir. Bazen Scrum tek başına yeterli olmayacaktır da. Çevik olmak ille de Scrum anlamına gelmez.

Bu hal çoğunlukla ürün veya proje yöneticilerinin bildikleri bir metodolojiyi fazlasıyla sahiplenmelerinin bir sonucudur. Sonuçlar bazen düşündürücü olur. Scrum gibi metodolojilerin standart yaşam biçimlerinin değiştirilmesi veya tam olarak uygulanmaması bile söz konusu olabilir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Yazılım Geliştirme Metdolojileri
  • Çevik (Agile) Metodolojiler
  • Scrum’ ın Avantajları
  • Waterfall Nedir?
  • Extreme Programming

Hal 38: Loglama denilince bunu her hareketi bir yerlere yazmak olarak düşünüp, anlamlaştırmayı unutmaktır.

Yazılım dünyasındaki en tehlikeli sorunlardan birisi de miktar olarak hızla artan verinin ta kendisidir. Bazen bir uygulama kapsamı içerisine dahil olan her tür bilginin çeşitli ortamlara yazıldığı görülür. Ağırlıklı olarak veritabanları kullanılır. Haliyle veri zaman içerisinde şişerek genişlemeye devam eder. Sonuçta performans kayıpları olur, sistem yavaşlar, aranan asıl veriler bulunamaz.

Her tür bilgi veri olarak düşünülüp saklanabilir. Ancak bu, işe yarayacak verileri bulmayı zorlaştırmamalıdır.

Loglama denilen olay bilindiği üzere uygulama içerisindeki hareketleri çeşitli seviyelerde kayıt altına alma noktasında etkin olarak kullanılır. Aslında bir Cross-Cutting olarak düşünüldüğünde AOP tarafında da değerlendirilen önemli bir olgudur.

Loglama çeşitli amaçlarla yapılır. Bazen uygulamadaki olası hataların kayıt altına alınmasında, bazen bir sürece ait müşteri hareketlerinin çeşitli kurumlar için kayıt edilmesinde vb.

Fakat bazen Loglama öylesine abartılır ki, log kayıtlarına dönüp bir şeyleri aramak gerçekten zaman kaybına neden olan bir iş haline gelir. Hatta bazen gereksiz veri içerikleri log kayıtlarını fazlasıyla şişirir. Sorun aslında işe yarar verinin ne olması gerektiğinin ilk baştan tespit edilemeyişi ile ilgilidir. Bu yüzden loglama stratejisi belirlenirken aslında işe yarar veri desenlerinin de tespit edilmesi önemlidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • AOP-Aspect Oriented Programming
  • Cross-Cuttings
  • Logging
  • Büyük Verilerde Performans

Hal 37:Dev bir Solution’ın neresinden Debug etmeye başlanması gerektiğinde ki kararsızlık durumudur.

Malesef işler her zaman geliştiricinin istediği şekilde gitmez. Bazılarımız hayatının çok az bir döneminde sıfırdan bir projeye başlama şansı yakalar. Özellikle çok uzun soluklu projelerde ve yıllara varan geliştirme süreçlerinde ise projenin sonunu göremeyen çok olur.

Dolayısıyla geliştiricinin sıklıkla karşılaşacağı durumlardan birisi zaten geliştirilmiş olan bir ürün üzerinden gelen yeni isteklerin karşılanmasıdır. Bu bazen can sıkıcı hata yakalama ve düzeltme işlerini de beraberinde getirir. Söz konusu ürün oldukça eski olabilir ve tek bir geliştiricinin üstüne yapışabilir. Artık geliştiricinin yatıp kalkıp uğraştığı sadece bu sıkıcı iştir.

37

@coderizbiz

Bu tip ürünlerde asıl sorun bazen de kalabalık ve karmaşık proje topluluklarıdır. .Net’çe düşünürsek Solution içerisinde n sayıda proje olabilir(30un üstünde proje içeren Solution’ ları görmüş birisi olarak söylüyorum) Eğer doküman da eksikse “vay halime” diyebilirsiniz ama demeyin. Doküman olabilir ancak var olan doküman güncel olmayabilir. İşte bu hale düşen geliştirici çoğunlukla Solution’ un neresinden, hangi projesinden başlayacağını ilk etapta kestiremez.

Yapılması gereken basittir; Solution’ u Collapse All ile ufaltmak ve büyük resme daha geniş bir açıdan bakıp parçalar arasındaki ilişkiyi kavramaya çalışmak.

Bir nevi tersine mühendislik gibi görünen bu işler arttıkça geliştiricinin tecrübesel yetkinliği artsa da yıpranma olasılığı yükselecektir.

Anahtar Konular(Bunlara Bir Bakalım)

  • Tersine Mühendislik(Reverse Engineering)
  • Visual Studio Solutions Collapse All
  • Bug-Fix
  • Debugging

Hal 36:Evrende veri depolamak,sunmak için sadece MS SQL ve Oracle olduğunu zannedip NOSQLi hiç araştırmamak

Yazılım sektöründe veriyi bir yerlere depolamak istediğimiz de genellikle aklımıza gelen iki ürün vardır. Microsoft SQL Server ve Oracle. İkisi arasında karar vermek zordur. Oysa ki ille de bunlardan birisi seçilmek zorunda değildir. Dahası hangi veritabanı sistemi ile çalışılacağına karara varmak için bakılması gereken kriterler çoğunlukla göz ardı edilir.

36

@coderizbiz

  • Ne çeşit bir veriden bahsediyoruz?
  • Veri hacminde nasıl bir büyüme trendi bekliyoruz?
  • Saklayacağımız yer neresi? Cihazın direk kendisi mi ya da bulut üzerinde bir yerler mi?
  • İlişkisel bir veri modeli mi söz konusu?
  • Hız ne kadar önemli?
  • Veriye olabilecek en iyi hızda erişebilmemiz gerekiyor mu?
  • Veri tümüyle bellekte saklanabilir mi?
  • Veri üzerinde anlık bir işlem sayısından bahsedilebilir mi? Ne kadar bir sayı söz konusu olabilir?
  • Her hangi bir ünlü algoritmaya hizmet edecek bir veri içeri söz konusu mudur?(Graph gibi)
  • Belki de saklanacak veri kocaman PDF dokümanlarından ve sahiplerinden ibarettir.
  • Verinin gizliliği söz konusu mudur? Söz konusu ise ne kadar önemlidir?
  • Verinin ölçeklenebilirliği hakkında elimizde ne gibi bilgiler bulunmaktadır?
  • Veri için o kadar lisans ücreti ödemeye değer mi?
  • İlişkisel Veri Tabanı Sistemlerinden birisini seçtikten sonra ilerleyen yıllarda performans ve iyileştirme için bir şeyler yapılması gerekir mi? Bunun için danışman tutmamız gerekecek mi?(Oracle’ dan bir danışman getirtin bakalım nasıl meblağlar telafuz edecekler)

 

Soruların sayısı elbette arttırılabilir. Ama önemli olan verinin tutulma şekline karar vermeden önce iyice düşünülmesi gerektiğidir. Çoğumuzun düştüğü hata, bir ürünü geliştirmeye başladığımızda veri modelini anında düşünüp, SQL Server veya Oracle üzerinde hızlıca tabloları inşa etmeye başlamaktır. Oysaki modelden önce belki de arayüzden geriye doğru gitmek daha doğru olacaktır.

Zaten veri saklamak için ille de ilişkisel sistemlerin göz önüne alınması şart değildir. Bu yüzden NoSQL sistemlerinden haberdar olmak önemlidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • İlişkisel veritabanı yönetim sistemleri – Relational Database Management Systems
  • NoSQL
  • Graph Model Veritabanları
  • Bellek üzerinde çalışan veritabanları
  • Graph Algoritması
  • Oracle Performance/Tunning Danışmanlık Ücretleri
  • Oracle , Microsoft SQL Lisansları

Hal 35:Bazen bulunan çözümlerin zamanla Anti Pattern haline geleceğini düşünmeden hareket etmesi.

Özellikle nesne yönelimli dünya da gezinen pek çok yazılımcı, tasarım kalıpları konusuna oldukça titiz yaklaşır.  Tasarım kalıpları standartlaşmış problemlerin standartlaşmış çözümlerinde oldukça etkilidir. Her ne kadar öğrenilmeleri ve hangi senaryoda kullanılmaları gerektiğine karar verilmeleri zor olsa da , geliştiricilerin baş tacıdır.

Acil giderilmesi gereken bug-fix’ ler ve kısa verilen proje süreleri geliştiriciyi Anti-Patterns noktasına iten önemli etkenlerdir.

Ne var ki gerçek hayat senaryolarında çoğu zaman ihmal edilebilirler. Bunun bir çok sebebi vardır. Kısa proje süreleri, bir anda kendimizi içinde bulduğumuz geçmişi olan ürünlerdeki bug-fix işleri vb… Bu gibi hallerde geliştiricilerin çoğu en kısa yoldan sorunu çözmeye çalışmak zorunda kalır ve bu durum haliyle bir süre sonra çeşitli sancılara yol açar.

  • Geliştirici spagetti kod üretiminde ustalaşır. (Spaghetti Code)
  • copy-paste programcılığı alanında ihtisas sahibi olur. (Cut and Paste Programming)
  • Yeri gelir tekerleği yeniden keşfeder. (Reinvent the Wheel)
  • Kocaman bir sınıf ile bütün sorunların üstesinde gelmeye başlar. (God Class)
  • Teknik desteği bir anda kesilen veya çok eskilerde kalan açık kaynak ürünlere bağımlı hale gelir. (Dead End)
  • İlle de bu mimari olacak bundan başkası olmaz diye diretir (Golden Hammer)
  • vb

Bu sebepten her yazılımcının aslında Anti-Patterns konusuna bakması, en azından belli başlı maddelerini incelemesi ve özümsemeye çalışması şarttır.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Anti Patterns
  • Design Patterns
  • Nesne Yönelimli Programlama (Object Oriented Programming)

Hal 34:Bir servisin başka platformlarca kullanılabileceğini düşünmeden platform bağımlı yazılması.

Servis odaklı yaklaşımların gözden kaçan unsurlarından birisi de, geliştiricinin bulunduğu platforma sıkı sıkıya bağımlı olmasıdır. Oysaki kurumsal çözümler, küresel çerçevede çalışan ürünler sıklıkla diğer platformlardaki uygulamalar ile anlaşma ihtiyacı hissetmektedir.

34

@coderizbiz

Bir yazılım ürününü geliştirmek için kullanılabilecek sayısız platform olduğu bir gerçektir. Bu farklı platformlar sadece müşterinin direk ihtiyaçlarını karşılayacakmış gibi görünse de zaman zaman müşteriler farklı platformlardaki uygulamalar da olurlar.

Bir iş fonksiyonelliği bütününü servis olarak tasarlamaya başlamadan önce sorulması gereken ilk soru “kimin/kimlerin tüketeceği” olmalıdır.

Bu felsefeden yoksun bir geliştirici kuvvetle muhtemel bir kaç hello world uygulamasında gördüğü adımları takip ederek hareket edecek ve servisi yayına aldıktan sonra dünyanın çok daha güzel bir yer olduğuna emin olacaktır. Bu yaklaşım yazılımcıya göre farklı bir evrenden gelen bir hayat formunun ilgili servisten yararlanamaması noktasında ise son bulacaktır.

Yazılımı bazen bir satranç oyunu gibi düşünmeye çalışmak gerekir. Bir kaç hamle ötesini görebilmek, tahmin etmek ve buna göre tedbirler alıp hareket edebilmek önemlidir.

Anahtar Kelimeler (Bunları Bir Araşatıralım)

  • Web servis standartları
  • WS-I Profilleri
  • Açık protokoller (OData, OAuth vb)

Hal 33 : Semantic Web gibi bir gerçeğin farkındalığına hala varmamış, önemini kavrayamamış olması.

Şüphesiz ki hemen her yazılımcı gününün büyük çoğunluğunu internet üzerinde geçirmekte. Bir şeyler okunmakta, paylaşılmakta veya üretilmekte. Ortada dolaşan veri transferi yoğunluğu veya genişleyen veri hacmi ise neredeyse uçsuz bucaksız ve sürekli olarak artmakta.

33

@coderizbiz

Makinelerin yapay zekalar ile daha fazla bütünleştiği bir evrende, ortada dolaşan verinin anlamlı hale getirilebilmesi her şeyden önce yazılımların en önemli sorumluluğu. Semantic Web bu çerçeve de tanımlanırken biz yazılımcılara da önemli bir amaç sunuyor!

Veriyi, onu anlamlaştırabilecek makinelerin anlayacağı biçimde sunmak ve bunun için gerekli hazırlıkları yapmak.

Anlamsağ ağ, WWW ile ilişkili yeni girişimlerin/yeni oluşumların mutlaka ele alması ve yatırım yapması gereken bir konudur.

Bu bir arama motoruna bulunduğumuz yerden “şu an tokyo borsasındaki prinç endeksinin kur değeri nedir?” sorusunu sorabilmekten çok daha öte bir şey. Araştırılması gereken bir konu olmaktan çıkmış olan Anlamsal Ağ kavranılması gereken bir mevzu. En azından Web 3.0′ ın yaşam hayatı boyunca.

Yaptığımız işler ne kadar sıkıcı olursa olsun bazı sektörel konulara en azından hobi olarak da eğilmeliyiz.

Anahtar Kelimeler(Buınlara Bir Bakalım)

  • Semantic Web – Anlamsal Ağ
  • Resource Description Framework (RDF)
  • Web Ontology Language (OWL)
  • Extensible Markup Language (XML)

Hal 32: Dünyada bir tane Facebook, bir tane Twitter vs teorisine karşı çıkıp sıfırdan yazmaya kalkması.

Çok doğal olarak güncel trendlerde hangi ürün ön plandaysa yazılımcının ona karşı bir hayranlığı vardır. Bu hayranlıkla “nasıl ve ne şekilde yapmışlar, kazanmayı nasıl başarmışlar?” sorularını sormak yerine “iyi de şu da olsa iyi olurmuş” veya “abi bu fikir benim aklıma gelmişti aha burada yazıyor” gibi cümlelerin görüldüğü çok olur.

32

@coderizbiz

Hiç isim yapmış bir ürünün nasıl doğduğu ile ilişkili kaynakları okudunuz mu? Örneğin Amazon’ un, Dell’ in veya Google’ ın. Hatta basit bir ürünün gerçekleştirilme hikayesini. Hatta TED konferanslarında yapılan konuşmaları izlediniz mi?

Fikirleri ortaya sunmak her zaman en kolayı olmuştur. Bu, kahve içerken arkadaş ortamında bile yapılabilir. Ama gerçekleştirebilmek zor olan, bir gelir modeline oturtup kazanbilmek çok daha zor olanıdır. Bu yüzden atıp tutarken bunu destekli yapmakta fayda vardır. Bir ürünün sadece yazılımdan ibaret olmadığını iyi düşünmek gerekir.

Zaten dünyayı kasıp kavuran bir ürünün daha iyisini yapmaya kalkışmak, çoğu zaman kötü bir taklidini ortaya koymaktan öteye geçmeyecektir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Case Studies (Her hangibir ürün veya firmanın ki olur)
  • Dell Tarzı : Direk Satış Direk Başarı
  • One Click: Jeff Bezos and the Rise of Amazon.com
  • Google Hikayesi
  • Microsoft Case Study Home
  • TED

Hal 31:Sürekli fikir üretir ama Business Model Canvas gibi olgulardan bi haber inovasyon yapacağını sanar.

Düşünmek güzeldir. Düşünülenleri not etmek, üzerinde çalışmak daha güzeldir. Ama her düşünülen kaleme alınan fikrin facebook, twitter olmasını beklemek daha çok hayalciliktir. Fikirler gerçeğe dönüştürülebildiklerinde değil çoğunlukla bir gelir modeli ile şekillendirilebildiklerinde dikkat çekmeye başlarlar. Gelir modeli olan bir fikrin ilk dakikadan itibaren para kazanıyor olması gerekmese de, modelin iddiası ilerleyen zamanlarda artan ivme de dönüşlere neden olabilir.

Gelir modeli tasarlamak işin sadece küçük bir parçasıdır. Girişime dönüşebilecek ve hatta kazanması beklenen bir fikrin oluşturulmasında bilimsel bazı enstrumanlar ile ilerlemek çok daha akılcı olacaktır.

Bazı fikirler ne kadar basit olurlarsa olsunlar hiç beklenmedik etki gösterip yüksek gelirlerin elde edilmesini ve büyümeyi olanaklı kılabilirler. Ama bu basit fikirler bile Business Model Canvas ve benzeri enstrümanlarda hayat bulurlar.

Günümüzün pek çok teknoloji şirketi özellikle Ar-Ge departmanlarından çıkartılacak yeni fikirlerde bu tip ve benzer modelleri kullanmaktadır. Modeller gelişmekte ve değişmektedir. Dolayısıyla bunların farkında olmak fikirlerin olgunlaştırılması açısından önemlidir. Hatta karar vermek için sayısız teknik yöntemin olduğu da bilinmelidir.

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • Business Model Canvas
  • Gelir Modeli
  • Innovasyon
  • Girişimcilerin Best Practices’ ları

Hal 30 : ALM gibi bazı terimlerin koca bir okyanusu işaret edebileceğini gözden kaçırmak.

Kısaltmalar ile konuşmak veya yazışmak günümüzün moda iletişim parametrelerinden birisidir. Kimi zaman bir toplantının sonuna gelindiğinde içeriğinde bahsedilen bir çok kısaltma olduğu ancak fark edilir. Edilir de bilmeyen bilmediğini göstermemek için sormaz, bilen de etkinliğini arttırmak için kısaltmayı açmaz, bir güzel havasını atar.

30

@coderizbiz

Nitekim söz konusu kısaltmalar genelde açıldıklarında ortaya kallavi bir ifade çıkartır. Bu kısaltmalar arkalarında devasa açılımlar ile gelebilir. Bunun için bir kaç 3 harfliyi Google’lamak yeterlidir. İşte bir kaç örnek;

  • SOA – Service Oriented Architecture
  • EDA – Event Driven Architecture
  • OOP – Object Oriented Programming
  • AOP – Aspect Oriented Programming
  • TDD – Test Driven Development
  • SLA – Service Level Aggrement
  • ALM – Application LifeCycle Management

ALM içerisine girildiğinde araştıran kişinin karşısına pek çok kavram çıkar. Bunları sürüyle araç izler. Sürecin ele aldığı çözüm metdolojilerinden Toyota kökenli Kanban’ a, TFS’ den Jira’ dan test sonuçlarının ele alındığı araçlara bir sürü parametre vardır. Bireysellik yoktur yerine takım kavramı vardır. Takım demek yine bir sürü pozisyon anlamına gelmektedir. Bir sürü pozisyon demek yönetim zorluklarını aşmak demektir. Hepsinden önemlisi ise bu terimi kullanan kişinin bunlar hakkında az çok fikir sahibi olması demektir.

Ortaya bir fikir atmadan önce fikrin temelini oluşturan üç harfli kelime hakkında ne kadar bilgili olduğumuzu şöyle güzelce bir tartmamız yerinde olacaktır.

Devir değişti. Özellikle kurumsal çaptaki ürünleri tek bir deha adam ile geliştirmek artık popüler değil ve hatta imkansız. Bunun yerini etkin ve verimli takım çalışmaları aldı.

SAFe’ nin meşhur giriş sayfası fotoğrafını görüp, bundan etkilenip bir kaç maddesini okuduktan sonra firmaya kalkıpta size SAFe’ yi öneriyorum demeden önce, iyice düşünmek gerekir!

Anahtar Kelimeler(Bunlara Bir Bakalım)

  • ALM – Application LifeCycle Management
  • TFS – Team Foundation Server
  • Jira
  • SAFe – Scaled Agile Framework
  • Agile Metodologies

Hal 29: İçini henüz yazmayacağı metoddan, NotImplementedException tadında bir şey fırlatmaya üşenmesi.

Bu hal daha çok yazılımcının fazla sayıda görevden oluşan stresli bir projede çalışmasından ve genellikle de unutkanlığından kaynaklanır.

Vaktiyle bug-fix geçmek zorunda kaldığım bir projede void tipinden dönüş yapan ama hiç bir kod bloğuna sahip olmayan metodu keşfettiğimde, yazılışının üzerinden epey zaman geçtiğini fark etmiştim.

29

@coderizbiz

Metod kritik bir veri dönüştürme işleminde çağırılmayaydı iyiydi ama çağırılıyordu. Henüz canlı ortamda kullanılmadığından o kadar yıl dönüşümler hatalı olmuş ama kimse önemsememişti. Hatta pek fark edilmemişti. Çünkü doğru bir test süreci söz konusu değildi.

Aslında bir ürünün içerisindeki parçaların kurgusal bütünlüğünü sağlamak için, sık sık tiplerin sadece metod/fonksiyon imzaları ile oluşturulduğuna şahit oluruz.

En üst seviyeden tasarlanmaya başlanan yazılım mimarisinin ön gördüğü parçaları birer birer konuşlandırdıktan sonra içlerinin doldurulması son derece doğaldır.

Bu metodların içleri çoğunlukla ilerleyen zamanlarda farklı geliştiriciler tarafından ve aynı zaman dilimleri içerisinde paralel olarak da doldurulabilir. Ancak içeriği yazılmamış bir metod, onun kullanıcısı tarafından fark edilmeyedebilir. Sürekli 0 döndüren bir metod için bir terslik olup olmadığı çok zor fark edilir. Ki söz konusu metodlar kaynak kodu dışarıya açık olmayan kütüphanelerde olduğunda durum daha da vahimleşecektir.

Doğru testler ve özellikle de birim testler çok önemlidir. Bu nedenle test güdümlü geliştirme söz konusu halin oluşmasına müsade etmez.

Visual Studio gibi ortamlar böyle hallerde fonksiyon içlerine otomatik olarak istisna nesneleri yerleştirmektedir. Ancak bu işin araçtan bağımsız olarak benimsenmesi geliştirici açısından daha önemlidir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • NotImplementedException nedir? Niçin vardır?
  • Bug-Fix
  • Birim Test – Unit Test
  • Test Güdümlü Geliştirme – Test Driven Development

Hal 28: Bir teknik dokümantasyonun edebi eser olacağını sanıp, sürekli güncellemesi gerektiğini unutması.

Yazılımcılar teknik kökenli olan veya olmayı seven ruh halindedir. Edebiyatı sevenleri olsa da her ay kalın bir kitabı bitirseler de konu, teknik dokümantasyonlara gelince şöyle bir ilkilirler. Yazılımın en zor taraflarından birisi, sürekli güncellenebilen ürünlerin değişen dinamiklerinin dokümante edilmesidir. Daha zoru ise bu dokümantasyonun güncel tutulmasıdır.

28

@coderizbiz

Pek çok ürünün ya yazan ekibi ya da kullananları tarafından basılan kitapları vardır. Teknik dokümantasyonun daha ötesine geçildiği eserlerdir. Hatta bazı açık kaynak kodlu projelerde öne çıkan kitaplar söz konusudur. bknz:DotNetNuke Tabi güncel tutmak her zaman ki gibi zordur.

Bu hale düşen geliştiriciler çoğunlukla üstlerine görev olarak verilen teknik dokümantasyonu hazırlama işini bir an önce icra etme çabası içerisine girerler. Görevin atanmasıyla geliştiricinin tek ve yegane amacı dokümantasyonu olabildiğince kısa sürede bitirmektedir.

Bazı yazılım geliştirme süreçleri/metodolojileri dokümantasyon işini pek sevmez. Bu süreci yavaşlatan bir unsur olarak görülür. Bunun yerine müşteri ihtiyaçlarının anlaşılır, kısa ve yeterli sayıda olması daha önemlidir.

Sonrasında ise bu doküman üstlere gösterilir, belki bir kaç düzenleme yapılır ve derken raflara(veya portal üzerinde bir adrese) kaldırılıp orada unutulur. Raflarda tozlanırken de William Shakespeare’in ünlü bir eseri gibi ebedi olacağı sanılır.

Yeni bir ürün öğrenmek veya kullanılmak istendiğinde yapılan hareketlerden birisi, sitede basit bir Tutorial’ ın olup olmadığına bakılmasıdır.

Bazı firmaların sırf ürün dokümantasyonu ile ilgilenen ekipleri vardır. Onlar için bile zaman zaman sıkıcı olan bir iştir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Teknik Dokümantasyon Türleri
  • Açık Kaynak Ürünler – Open Source
  • DotNetNuke

Hal 27:Kodlarını, yıllar sonra başka bir geliştiricinin yeniden kurcalayabileceğini düşünmeyerek yazması.

Yazılımcı ne kadar çok sıkışırsa, işin yetiştirilmesi için üzerinde kurulan baskı ne kadar artarsa, ortaya çıkacak işin kalitesinin azalması her zaman için bir ihtimaldir. Bu tip bir durumda yazılımcının panik olmadan, baskıyı kaldırarak, emin adımlar ile ilerleyememesi halinde uygulama kodlarının enkaz haline dönmesi de kaçınılmazdır.

27

@coderizbiz

Bir yazılım ürününün kod anlamında enkaz haline gelmesi epeyce çaba isteyen bir iştir. Ancak şartlar bunun oluşması için bazen çok uygundur!

Acele acele yazılan kodlar, ilerisi düşünülmeden entegre edilen geçici çözümler(bilhassa yıllar içinde teknik desteği azalan veya kaybolan açık kaynak kütüphaneler), var olan ürünler üzerindeki pansumlanlarda çalışan deneyimsiz yazılımcılar gibi nedenler, zamanla kodun kirlenmesine ve enkazın devleşmesine sebebiyet verecektir.

Enkaz ürünler özellikle kod ve kalite standartlarını denetleyen araçların hışmından kurtulamaz.

Unutulan bir şey varsa o da bu hale gelmiş ürün kodlarına yarın öbür gün başka bir geliştiricinin bakacak olmasıdır. Öyle ürünler vardır ki onlarca yıl belirli sektörlerce kullanılır, sürekli eklemeler ile genişler, genişler, genişler… Hatta şirketin farklı iş ihtiyaçlarını yürüten kanallara ve buradaki uygulamalara kadar etki eder. Genişleyen bu tip ürünlerin yıllara varan oluşumu sırasında kullanılan teknoloji eskiyebileceği gibi, o teknolojiyi bilen ve pansuman yapabilen yazılımcı sayısı da azalır. Bu nedenle yazılımcının daha az “Ah!” alması ileriyi düşünerek yapacağı hamlelere de bağlıdır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Hatasız Kodlama
  • Okunabilir Kod
  • Kod Kalite Standardları
  • Anti-Patterns
  • Desteği Bitmiş/Azalan Açık Kaynak Ürünler

Hal 26:KISS in ne anlamına geldiğini iyi bilmesi ama önemli bir prensibi ifade ettiğini de hep unutmasıdır.

Bu madde her ne kadar muzur görünse de gerçekçi bir tarafı da vardır. O da K.I.S.S. in aslında öpücük olmadığıdır. KISS’ in yazılımcı için anlamı “Keep It Simple, Stupid” prensibi olarak algılanmalıdır.

Teori o kadar iddialıdır ki animasyon sektöründeki 80e 20 kuralından tutun, DRY(Don’t Repeat Yourself) veya YAGNI(You aren’t gonna need it) gibi yazılım presiniplerine kadar pek çok konuya ilham kaynağı olmuştur. İşin ilginç yanı, bir sistemin karmaşık tasarlanmasının yerine oldukça basit olmasına odaklanan prensibin askeri bir platformda doğmuş olmasıdır(US. Navy 1960) Gerçi askerlik hizmetini yerine getirenler dışarıdan mantıksız görünen bazı kural veya yordamların aslında bu tip sadelik ve basitlik temelli esaslarla geliştirildiklerini bilirler.

26

@coderizbiz

Kelimeler basit gibi görünse de prensibin ortaya koyduğu iddiayı gerçekleştirebilmek sanıldığı kadar kolay değildir. Geliştirici zihni çoğunlukla karmaşık ve kompleks düşünmeye odaklanır.

İyi bir fotoğrafta konunun dışında kalan detayların mümkün mertebe çıkartılması ve konunun olabildiğince sadeleştirilmesi istenir.

Fotoğraf çeken pek çok insan olmasına rağmen bu prensib çoğunlukla ezilir ve o istenen fotoğraf bir türlü ortaya çıkmaz.

Anahtar Kelimeler(Bunlara Bir Bakalaım)

  • KISS – Keep it simple,stupid
  • DRY – Don’t Repeat Yourself
  • Yazılım Geliştirme Felsefeleri – Software Development Principles

Hal 25:Bazen bir ürünün kullanıcılarının doktoralı mühendisler olduğunu sanıp basitlikten uzaklaşmasıdır.

Google ilk çıktığında sadece bir TextBox ile kullanıcılarına her türlü basitliği sunacağını vaat etmiş görünüyordu(ki öyle de oldu). Arka plandaki dahiyane mühendislik ve kullanılan arama algoritmaları ise son derece zor olmakla birlikte pek çok yazılımcının da mutlaka öğrenmek istediği sistemlerdi. Ama felsefe son kullanıcı için basit olması şartıydı. O devrin diğer arama motorlarının web sayfalarında genellikle kaybolurduk.

25

@coderizbiz

Google bu felsefesinden hiç bir zaman vaz geçmedi. Arama motoru devinin son kullanıcıya mümkün olduğunca kullanışlı ve basit bir kutucuk sunması aslında pek çok geliştiricinin pek de fark edemediği en önemli yeteneğiydi.

Google’ ın arama motorunun basit arayüz tasarımına sahip olması, arka planda dahiyane mühendisliklerin uygulanmadığı anlamına gelmemelidir.

Söz gelimi harf hatası yaptığınız veya aklınıza tam olarak gelmeyen kelimeleri yüksek yüzde ile tahmin edip size önermesi o metin kutusunda çok basit görünen bir iş iken, arka planda kullanılan önemli bir algoritmanın eseridir.

Ne yazık ki sektörde pek çok ürün de bu tip basitlikler bulunmaz. Bunun en büyük nedenlerinden birisi de geliştiricinin karşısında hep kendisi gibi bireylerin bulunduğunu düşünmesi olabilir. Aslında son kullanıcıyı hep aptal birisiymiş gibi düşünmek gerekir.

  • Bir profesörün kullanacağı ve karmaşık matematik algoritmalarını deneyeceği arabirimler mümkün olduğunca basit tasarlanabilmelidir.
  • Kalabalık ve yoğun iş süreçleri olan bir sistemin ekranları onlarca pencereden, yüzlerce kontrol ve menü öğesinden uzak sunulabilmelidir.
  • Genel kullanıma açık bir kütüphanenin fonksiyonellikleri çeşitli prensip ve kalıplar ile desteklenip diğer geliştiriciler için kullanımı kolay hale getirilebilmelidir.
  • vb

Basit tasarım aslında bir düşünce yapısı olarak geliştirme ekibinin uçtan uca her elemanında var olması gereken bir kabiliyettir. Doğuştan olmasa bile bu düşünce yapısı sonradan öğrenilebilir veya varsa da iyileştirilebilir. Sadece ön yüz için değil kodun kendisi içinde basitlik/sadelik önemlidir.

Sanılanın aksine kurumsal bir çözüm içerisindeki kodları yalınlaştırıp basitleştirmek ama bilinen prensipler ve kalıpların dışına çıkmadan bunu gerçekleştirebilmek çoğu yazılımcı için neredeyse imkansızdır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • K.I.S.S. İlkesi
  • Arama Algoritmaları
  • Tahmin etme
  • Google arama algoritmaları
  • Bir zamanlar arama motorları

Hal 24: Her sabah, gazetelerden önce takip edilmesi gereken feed içeriklerine göz gezdirmeyişi.

İş hayatı güne erken başlar. Hatta bazen sabah kadar süren mesaileri nedeniyle hiç bitmez. Ancak sabah erken saatlerde masasının başına geçen bir yazılımcının her gün veya düzenli olarak arada sırada da olsa yapması gereken rutin sayılabilecek işler vardır.

24

@coderizbiz

  • Dün akşam oynanan maçın özetini seyretmek,
  • Gündem haberlerine bakmak,
  • Bir kaç tweet atıp facebook üzerinden bir kaç yorum yazmak, bir şeyleri Like etmek veya etmemek,
  • Güncel fırsat sitelerinden elbise seçmek veya elektronik mağzaları dolaşmak,
  • Kişisel epostaları okumak /cevaplamak vb

Tabiki bunları yapıyorsanız önemli bir kaybınız vardır. O gün için olmasa bile gelecek adına. Yapılması gereken ilk iş takip edilmesi gereken blog’ lara düşmüş olan son içerikleri hızla taramaktır. Yani Feed okumak. Bu işe her sabah en az 15 dakikanızı ayırmalısınız. Sadece başlıkları göz gezdirseniz ve sonradan (örneğin yemekten döndükten sonraki ilk dakikalarda) okumak için işaretleseniz yeterli olacaktır. Feed okumak için pek çok araç kullanabilirsiniz. FeedReader ve Microsoft Outlook sadece bunlardan ikisidir.

Çalışılan sektörün tek düze ve standard işler yapıyor olması, yıllar öncesinden kalma diller kullanması veya sıkıcı bug-fix ve support işleriyle uğraşılması, kendi kişisel gelişiminiz için ayırmanız gereken zamanı tahsis etmeye engel olmamalıdır.

Yazılım sektörü baş döndürücü bir hızla gelişen ve genişleyen bir sektördür. Kısa süreli bir takipsizlik geliştiriciyi bilgi seviyesi ve donanım açısından bulunduğu konumdan daha geriye atmaya yeterlidir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • FeedReader
  • OPML
  • Takip Edilmesi Gereken Kişileri Bulun

Hal 23: Bir toplantıya not defteri ile gitmenin demode olmuş eski bir gelenek olduğunu düşünmesidir

İş dünyasının vazgeçilmez iletişim yöntemlerinden birisi de toplantıdır. Ekip toplantıları seçilen metodolojiye göre belirli kurallara uygun olacak şekilde yapılır. Toplantılara katılırken yanımızda olsa iyi olur diyebileceğimiz materyaller vardır. Cep telefonu, ses kayıt cihazı, kamera ve benzeri bir cihaz olması şart değildir. Sadece bir ajanda ve yazan bir kalem yeterlidir.

23

@coderizbiz

Aslında el yazısını tanıyıp soft ortama aktarabilen cihazlar da söz konusu olabilir. Yine de kağıt üzerindeki el serbestliği ve rahatlığını birebir sunmayacaklardır.

Bu hale düşen pek çok geliştirici  çoğunlukla hafızasına ve zekasına güvenerek toplantılara katılır. Yanlarında not alabilecekleri en ufak bir malzeme dahi olmaz. Oysaki, toplantının uzaması, verimli zaman dilimleri dışına taşması, anlatılanların karmaşıklığı, sorulan soruların sıklığı, hararetli tartışmaların yaşanması,  toplantıya geç kalınması, toplantının sık sık dış aramalar yüzünden bölünmesi gibi pek çok nedenden ötürü asıl noktalar rahatlıkla hafızayı teğet geçip odanın duvarlarına çarparak absorbe olabilir.

Tabi Microsoft OneNote gibi şirket içinde paylaşıma açabileceğiniz araçlar kullanıyorsanız not tutmamayı düşünebilirsiniz ama bu sizin kendinize özgü notlar almanızın önüne geçebilir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Verimli Toplantı Teknikleri
  • Toplantı Doğasını Bozan Haller
  • Microsoft OneNote

Hal 22: Aslında bazı problemlerim çözümünde kağıt kalem kullanmanın ne kadar önemli olduğunu fark etmeyişidir.

Bazen bir probleme bütünüyle baktığımızda meseleyi tam olarak algılayamayabiliriz. Problemi mümkün mertebe daha anlaşılabilir parçalara bölmek, çözüme ulaşmak açısından önemlidir ancak tek başına yeterli değildir. Bazen bir kağıt parçası ve bir kurşun kalem sorunun çözümlesindeki en güçlü araçlar olurlar.

22

@coderizbiz

Boş bir kağıt ve siyah bir kurşun kalem, sahibine oldukça yalın bir ortam sunar. İşleri kolaylaştıran bir bilgisayar veya program yoktur. İşte bu yalınlık ortadaki problemi çözme noktasında yazılımcıyı daha sade düşünmeye zorlar. Sade düşünebilmek, gereksiz detayları dışarıda tutup odak noktalarını keşfedebilmek, problemin epiklikten uzaklaştırılmasında oldukça mühimdir.

Bazen karmaşık ve can sıkıcı görünen bir problem, çöp adamların eğlenceli hale getirildiği bir sayfa üzerinde daha neşeli çözümlenir.

Bu kağıt ve kalem çoğu zaman daha tecrübeli bir yazılımcının, az tecrübeli birisine sorunu anlatma noktasında da işe yarar. Sözlerle ifade edilmeye çalışılan kavramlar, kağıt üzerinde geometrik şekiller ve benzeri çizgiler ile daha anlaşılır biçimde aktarılır.

Tabi bu teknik bir ekip için beyaz tahta ve keçeli kalem anlamına da gelir. Ekibin etrafında toplandığı tahta, deneyimli ekip lideri için problemi anlatabileceği, çözümü ifade edebileceği ilk ve en önemli yerdir. Bazı yazılım ekiplerinin halen daha bu tip tahtalara sahip olmamaları bir kayıptır. Tabi ille de tahta ve keçeli kalem olması şart değil. Hatta dokunmatik bir tahta varsa daha mükemmel olur. Önemli olan tahtanın ve kalemin bir arada etkili kullanılarak problemlerin sadeleştirilebilmesidir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Problem Çözme Teknikleri
  • Yazılımda Epik Senaryolar
  • Dokunmatik Tahta – Touch Board, Touchable Board

Hal 21: Sosyalleşmek için evin duvarları dışına bedenen çıkması gerektiğini inkar etmeye çalışmasıdır.

Her halde programcılığın ilk yıllarındaki o kasvetli monitorler üzerinde çalışmaya devam ediyor olsaydık, belki de dışarı da daha çok vakit geçirebilir, başka uğraşlara daha fazla zaman ayırabilirdik. Ne varki ilerleyen teknoloji beraberinde sadece kolaylıklar değil yan etkiler de getirdi.

Bir insanın en büyük felaketi, var olan akıl sağlığını yitirmesidir.

Artık daha renkli, daha ince ekranlar üzerinde çalışma fırsatı bulan yazılımcılar sadece donanımsal anlamda değil, ilgilendikleri ürünler açısından da bilgisayarlara daha bağımlı hale gelmiş durumdalar. Günün sekiz saatten fazla bir zamanını bilgisayar başında geçiren, zihni oldukça yoran problemlerle veya rutinleşmiş sıkıcı kod parçaları ile uğraşan yazılımcının en büyük yanılgısı da sosyal hayat ihtiyaçlarını internet üzerinden gidermeye çalışmasıdır.

21

@coderizbiz

Aslında sosyal hayat yazılımcı için çoğunlukla anlamını yitirmiş ve kalıp değiştirmiş bir kavram olarak düşünülebilir. Şu soruları kendinize bir sorun:

  • En son ne zaman aynı sektörden olmayan bir arkadaşınızla buluşup normal de internetten sipariş verip eve getirttiğiniz o leziz yemeğin sahibi olan restorana gittiniz?
  • En son ne zaman aynı sektörden olmayan bir arkadaşınızla kahve içip iş dışında bir şeylerden bahsettiniz?
  • En son ne zaman aile fertlerinizle pikniğe gittiniz?
  • En son ne zaman lisede birlikte basketbol/futbol oynadığınız arkadaşlarınızla bir müsabakayı izlemeye gittiniz?
  • En son ne zaman bir konuyu araştırmak için bir üniversitenin kütüphanesine girip tüm gününüzü araştırarak geçirdiniz?
  • En son ne zaman cep telefonunuzun şarjı bitmiş halde saatlerce şehrin sokaklarında gezdiniz?
  • En son ne zaman mezun olduğunuz ilk okul arkadaşlarınızla buluşup ilk okulunuzu ve öğretmenlerinizi ziyaret ettiniz?

Maddeler daha da çoğaltılabilir. Hatta kültürel aktivitelerde bulunmak, müzik ve dansla uğraşmak, doğa yürüyüşlerine katılmak gibi insan iletişiminin yüksek olduğu etkinlikleri hiç saymadık bile. Şu unutulmamalıdır ki, yetkişkin bir insanın sosyal çevresinde aile fertleri, iş arkadaşları ve bunların dışında kalan arkadaş çevresi önemli bir rol oynamaktadır. Bu çevreler google+ da geçen Circle’ lar değildir. Hangilerine sahip olduğumuzun veya sahip olup da kaybetmek üzere olduklarımızın farkında olmalıyız.

Ünlü CEO’ lardan Bryan Dyson ın kısa konuşması.

Hayatı 5 adet topu havada çevirdiğiniz bir jonglörlük olarak düşünün. Bunlar “İş, Aile, Sağlık, Arkadaşlar ve Ruhunuz” ve hepsini havada tutmaya çalışıyorsunuz.
Yakın bir zamanda anlayacaksınız ki iş bir lastik toptur. Eğer düşürürseniz yine size zıplayacaktır. Ama diğer dördü – Aile, Sağlık, Arkadaşlar ve Ruhunuz- camdan yapılmıştır. Eğer bunlardan birini düşürürseniz geri dönüşü olmayacak bir şekilde aşınacak, üzerinde iz oluşacak, hasar görecek ve belki de tuzbuz olacak. Hiçbir zaman eskisi gibi olmayacaklar. Bunu anlamalı ve bunun olmaması için çaba göstermelisiniz.
İş zamanınızda iyi çalışın ve zamanında çıkın. Ailenize, arkadaşlarınıza ve düzenli dinlenmenize gereken zamanı ayırın. Değerler sadece değerlerine değer verdiğiniz sürece değerdir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Sosyal Hayat
  • İnsanın Sosyal Çevresi
  • Sektörel Hastalıklar
  • Sektör Bazlı Psikolojik Sorunlar
  • Bryan Dyson

Hal 20: Kod yazan kodları geliştirmeye çalışmak gibi öğrencilik hobilerinin yararını fark etmeyişidir.

Ürünlerin planlanan sürelerde yetiştirilemeyişinin pek çok nedeni vardır.

  • Takım içi uyum sorunu,
  • Ekibin ilgili alandaki deneyimsizliği,
  • Proje planının makul ve mantıklı sürelerde yapılmayışı,
  • Görev dağılımının hatalı olması,
  • Düzgün bir metodolojinin izlenmeyişi veya izlenenin yanlış yürütülmesi,
  • Hatalı teknoloji seçimi,
  • Müşteri isteklerinin yanlış anlaşılması,
  • Kod ve ürün kalite kontrollerinin önemsenmemesi,

20

@coderizbiz

ve benzerleri bu başarısızlığa etken maddeler olarak sayılabilir. Hal böyle olunca pek çok ürünün geliştirilmesi noktasında yazılımcının uzun ve fazla mesai yapması kaçınılmaz olmaktadır.

Hatta fazla mesailer ile ürün zamanında yetiştiğinde(bazı kesimlerce) bu başarı olarak sayılmakta, proje planı yapılırken bir adamın günde sekiz saat iş yapacağı hesabına göre sonuçlara bakıldığında ise zarar edildiği gözden kaçırılmaktadır.

Böyle sıkışık zamanlarda geliştiricinin kişisel becerileri de ön plana çıkar. Hızlı klavye kullanmasından ziyade akıllı kodlar geliştirmesi de hayat kurtarabilir. Böyle bir süreçte ürün için gerekli kodları üreten veya bir kaç günlük hammallığı bir kaç saate indirgeyen yapılar büyük önem kazanır.

Pek çok yazılım sevdalısı belki okulda belki de başka bir zaman diliminde hobi olarak da olsa kod üreten kodlar yazmaya çalışmıştır. Çalışmamışsa güçlü bir silahı kaybetmiş olarak düşünmelidir(Hele ki o yapay zeka algoritmaları üzerine kurulu dersler görmezden gelinmişse…)

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Projelerin Başarısız Olma Nedenleri
  • Kod Üreten Kod Parçaları
  • T4 Templates
  • Yapay Zeka Algoritmaları

Hal 19: Bazı projelerin ekip çalışması olmadan da bitebileceğini zannetmesidir.

Yazılımcıların yaptığı en büyük hatalardan birisi de bazen sadece koda bakıyor olmaktır. Hatta çoğunlukla bir ürünü sadece koddan ibaret bir vücud şeklinde değerlendirmektir. Kodun dışında kalan dünya göz ardı edilebilir. Aslında bir ürünün yaşadığı uzay sadece mimariler, kalıplar, prensipler veya metodolojilerden ibaret bir ortam olarak düşünülmemelidir.

19

@coderizbiz

Yazılım odaklı ürün uzayını eksik görmek ne yazık ki pek çok geliştiricinin, çevreden gördüğü hemen her ürünü tek başına üretebileceği fikrinin doğmasına neden olmaktadır.

Aslında bir ürünü iyi bir yazılımcı baştan sona tek başına geliştiremez diye bir kural yoktur. Ancak zaman, maliyet gibi unsurlar göz önüne alındığında en azından buna değip değmeyeceğinin baştan tespit edilebiliyor olması önemlidir.

Tahmin edileceği üzere zeki, çok yönlü ve tek başına Rambo gibi ortalarda dolaşıp bir helikopter’ den diğerine atlarken arada asenkron kod geliştiren insan sayısı epeyce azdır. Bu duruma düşülmesinin nedenlerinin başında büyük resmi görememek gelmektedir. Bu biraz da yazılımcının ürün kavramı hakkındaki bilgisi ve bakış açısı ile alakalıdır.

Bir ürünün takriben kaç kişilik bir ekip tarafından ne kadar sürede ve hangi teknolojiler ile geliştirilebileceğini ön göremiyorsak ileri de iyi bir proje/ürün yöneticisi adayı da olmayız.

Dolayısıyla bazı ürünlerin ve yeni keşiflerin geliştirilmesi düzenli ve sistematik ekip çalışmasına bağlıdır. Bu çalışma kalıbı sadece şelale modeli gibi bir süreç anlamına gelmemelidir.

Çevikliğin içerisinde de aslında basit ama kuralları kesin çizgilerle belirlenmiş bir yaşam döngüsü olduğu unutulmamalıdır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Proje Yönetimi
  • Ekip Çalışması
  • Takım Çalışması
  • Şelale Modeli – Waterfall
  • Çevik Süreç Yönetimi – Agile Process Management

Hal 18: MVC nin sadece Asp.Net  e özgü bişi olduğunu sanmasıdır.

Ne yazık ki bazı tasarımsal yaklaşımlar ve çözüm mimarileri kullanıldıkları ürünle birlikte anılır ve hatırlanırlar. MVC yani Model View Controller adı verilen mimari tasarım için de benzer bir durum söz konusudur. Çoğu geliştirici söz konusu yaklaşımın sadece Asp.Net’ e özgü olduğunu düşünür ve hatta farklı bir ortam da kullanılamayacağına inanır.

18

@coderizbiz

Biraz daha vizyoner olanlar bu desenin Web dışında kullanılamayacağına inanırlar ki bu da doğru değildir.

MVC, kullanıcı arayüzünün ve aslında onun kullandığı modelin birbirlerini etkilemeden düzenlenebilmelerine olanak sağlayan bir mimari tasarım olarak düşünülebilir.

İlginç olan, söz konusu kalıbın 1979 yılında ortaya konmuş olmasıdır. Hatta daha ilginci bu kalıbı farklı yazılım ortamlarında da kullanabiliyor olmamızdır. İlk yıllarında SmallTalk üzerinde uygulanan bu mimari çözümü, bir Windows Forms uygulamasında veya bir PHP çözümünde dahi kullanabiliriz.

Peki MVP olarak kısaltılan Model View Presenter mimarisin MVC’nin bir türevi olduğunu biliyor muydunuz?

Demek ki bazı üç harflileri değerlendirirken mümkün olduğunca geniş düşünmeli, farklı alanlardaki uygulamalarına bakmalı ve hatta biraz da tarihçelerini araştırmalıyız.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Model View Presenter
  • Model View View Model
  • Trygve Reenskaug
  • SmallTalk

Hal 17: Scrum ın sadece stand-up meeting lerden oluştuğunu sanmasıdır.

Scrum, çevik yazılım geliştirme metodolojilerinin günümüzde uygulanabilen ve popüler olanlarından birisi olarak düşünülebilir. Bu gözde metodolojide ekip içi etkin iletişim son derece önemlidir.

17

@coderizbiz

İster .Net platformunda ister Java platformunda olun, ister Objective-C ile mobil uygulama geliştiren ister yedek parça üretim hattının otomasyonunu C++ ile yenileyen bir ekipte olun Scrum, araçtan bağımsız şekilde bir metodoloji yürütebilmenizi ve periyodik olarak işe yarar bir ürünü veya ürünün parçalarını müşteriye sunabilmenizi sağlar.

Ekip içi iletişimin kuvvetli olması için Scrum’ ın sunduğu pek çok toplantı çeşidi vardır. Product Backlog’ u iyileştirme, Sprint planlama, günlük scrum, revizyon, Retrospektif ve hatta Scrum uygulayan ekiplerin bir arada olduğu sistemler için Scrum’ ların Scrum’ı toplantısı.

Tüm toplantıların basit anafikirler üzerine kurulmuş belli amaçları vardır. Harfiyen tatbik edildiklerinde Scrum’ ın başarılı bir şekilde uygulandığı ve en iyi sonuca daha çok yaklaşıldığı görülür. Bu yüzden Scrum’ ı sadece ayakta yapılan bir sohbet ile ekibin durumunun takip edilmesi olarak düşünmemek gerekir. Her toplantı, zincirin önemli bir parçasını oluşturur ve göz ardı edilemez. Ne yazık ki Scrum pratikleri uygulanmadığı veya yazılımcının konuyu öğrenmesine rağmen içerisinde yer almadığı durumda 17 numaralı hal oluşmaktadır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Daily Scrum,
  • Grooming,
  • Sprint Planing,
  • Sprint Review,
  • Sprint Retrospective,
  • Scrum of Scrums
  • Agile
  • Scaled Agile Framework

Hal 16: SOA’ nın sadece web servisi ve metotlardan oluştuğunun sanılmaslıdır.

Bir servisi nasıl tanımlarsınız? Bunu yaparken çok fazla tekniğe girmeden bir cümle kurabilir misiniz? Yazılım hayatının ilk yıllarındaki bir geliştirici için servis şimdilerde nasıl tanımlanır? Yoksa bu aslında bir XML Web Servis, WCF Service, Web API Servis ya da JAVA Web Servis tanımı mıdır? Servis denilen enstrüman çok daha geniş bir anlamda tanımlanamaz mı? Herşeyi bir servis haline getirmek mümkün müdür? Peki ya neler servis olarak düşünülmelidir?

Eğer bu sorulara doğru cevaplar veremiyorsak bu maddenin belirttiği hale düşmüşüz demektir.

16

@coderizbiz

Şimdi problemi biraz daha zorlaştıralım.

Bir servisi doğru biçimde tanımlayabildiniz veya tanımlamasını öğrendiniz. Peki ya Servis Odaklı Mimariyi nasıl tanımlarsınız? SOA’ nın n sayıda servise olan bakıç açısı sizce nedir?Sadece servisler arası ilişkileri tanımlayan bir kurallar dizisi midir? Yoksa yaşanan çeşitli problemlerden ortaya çıkartılmış derslerin ele alındığı kalıplar bütünü müdür? Çok daha ötesinde bir şey olabilir mi? Örneğin servislerden, bunların arasındaki mesaj trafiğinden, bağlantı noktalarından, adaptörlerden vb kavramlardan oluşan koca bir eko sistem olabilir mi? Neden bir sistem pek çok iş kuralını servis odaklı çalışacak şekilde ele almayı tercih eder, etmeli midir? Bu iş kurallarının doğru yürütülmesi nasıl sağlanabilir? Peki ya kontrol: Sistem bu kuralları dizisini nasıl doğrulayabilir daha doğrusu nasıl yönetebilir?

Bu sorular üzerinde yorum yapabildiğiniz az çok doğruya yakın cevaplar verebildiğiniz takdirde SOA’yı anlamaya başladığınızı ve ilk adımı attığınızı düşünebilirsiniz.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Servis Odaklı Yaklaşım – Service Oriented Architecture
  • Thomas Erl (Israrla ve yeniden)

Hal 15: SOA gibi mimari yaklaşımların gerçek saha da uygulanmasının ne kadar zor olduğunu anlamamasıdır.

Yazılımsal ürün çeşitliliği olan devasa bir sistem düşünün. Ortalık yazılım ürünlerinden geçilmiyor. Mainframe üzerinde koşan eskilerinden, kullanıcı deneyimi üst düzeyde olan mobil versiyonlarına kadar geniş bir yazılım ağı söz konusu. Aynı ekolojinin bir parçası olan bu minik sistemler çoğunlukla da aynı süreçlerde bir araya gelmekte.

Genellikle bu tipte ölçeği oldukça büyük sistemlerde, yönetilebilirlik, genişletilebilirlik, esneklik gibi kelimelerin anlamlandırılması her zaman zor olmaktadır. Bir de işin içerisine kalabalık ekipler ve insan faktörü eklenince bu iş bir anda çığrından çıkabilir ve en kötüsü de üretim bandının aksamasına neden olabilir.

15

@coderizbiz

Pek çok yazılımcı havalı bir mimariyi öğrenmeye çalışır ve bunun fanatiği olur. Örneğin Servis Odaklı Yaklaşım. Ancak bazılarımız da ne yazık ki sadece kulaktan dolma bilgiler ile bu tip bir mimariyi kolayca öğrenmiş olacağını zanneder.

İşin zor kısmı teoriyi bilmekten çok bunun ekolojik sistem içerisinde uygulanabilmesini sağlamak, uygulanıyorsa da gözden geçirip iyileştirebilecek veya düzenleyebilecek bilgiye sahip olmaktır.

Bir sonraki halde de bashedileceği üzere, SOA, bir servisin yazılması ve sunulmasından çok daha öte bir kavramdır. SOA’ nın anlaşılması epey zor prensipleri vardır. Bazen SOA’ nın bir şirkette uygulanması söz konusu olabilir ama bu hatalı prensipler üzerine inşa edilmeyeceği anlamına gelmez. Bazı büyük ölçekli firmalar sadece SOA ile ilgilenen departmanlara sahiptir ve işleri kod yazmaktan çok daha farklıdır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Servis Odaklı Yaklaşım – Service Oriented Architecture
  • Thomas Erl

Hal 14: Martin Fowler, Robert C. Martin gibi ustaların yayınlarını eski basım diye okumamalarıdır.

Ne yazık ki doktorları kıskandıracak hızda devam eden bir sektörün parçasıdır yazılımcılar. Hatta sektör o kadar hareketlidir ki geçen senin yeni basılan pek çok kitabı bir sonraki sene ve bazen de bir kaç ay içerisinde eskir.

Tüm bunlara karşın değişmeyen bazı kavramlar söz konusudur. Bir programlama diline veya bir araca sıkı sıkıya bağlı olmayan bu kavramlar kolay kolay eskimez. Örneğin yazılım prensipleri, tasarım kalıpları, belli başlı algoritmalar, yazılım geliştirme metodolojileri, mimari yaklaşımlar vb…

14

@coderizbiz

Pek tabi bu tip kavramlara öncülük etmiş ve hatta teorilerin altına imza atarak sektöre yön vermiş isimler vardır. Bu isimlerin yazdığı eserler eksi bile olsalar halen daha geçerliliğini korumaktadır. Hele ki yakın geçmişte yazılmış eserleri tam anlamıyla bu kuşak için bulunmaz nimettir.

Bir yaklaşımı pek çok uzmandan dinleyip öğrenebilirsiniz ama onun sahibi olanın bakış açısı ve düşünce yapısını okumak size bambaşka ufukların kapısını açacaktır.

Bu hale düşülmesinin en büyük nedeni aslına bakarsanız önemli bazı kitapların ilk basım tarihlerinin eski olmasıdır. Genellikle en yeninin peşinde olduğumuzdan bir sene öncesinin kitabına bile şüpheli yaklaşabilmekteyiz.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Martin Fowler – Patterns of Enterprise Application Architecture 2002, Refactoring: Improving the Design of Existing Code 1999,
  • Robert C. Martin – Agile Software Development: Principles, Patterns, and Practices 2002,
  • Thomas Erl – Service-Oriented Architecture: Concepts, Technology & Design 2005,
  • Kent Beck – Extreme Programming Explained 2005,
  • William J. Brown – AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis 1998,
  • Alan Key,
  • Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides – Design Patterns: Elements of Reusable Object-Oriented Software 1994

Hal 13: İlerde güneye yerleşip domates yetiştirebileceği hayaline cidden inanmasıdır.

Yazılım geliştirmek fiziki güce pek ihtiyaç duymasa da beyin için oldukça yorucu bir aktivitedir. Geliştirilmekte olan ürüne bağlı olarak kafa yorma oranı fark gösterebiliyor olsa da, sıkıntı daha çok yazılımcının pek yerinde duramaz bir adam olmasından da kaynaklanmaktadır.

Bunu anlayabilmek için çevrenizdeki yazılımcıları veya kendinizi kısa bir süre gözlemleyebilirsiniz. Tik haline gelmiş davranışlar söz konusudur. Kod yazmayı çok sevenlerin bile zaman zaman bunaldığı anlar olur. Karmaşık problemler, giderek yaklaşan teslim süreleri, analistler ile anlaşamamak, müşteriyi anlayamıyor olmak ve pek tabi maddi olarak hak edilenin alınmadığını düşünmek vb.

13

@coderizbiz

İşte bu gibi nedenlerden pek çok geliştiricinin zaman içerisinde şakayla karışık da olsa güneye inme(veya kuzeye çıkma) fikri hayat bulur. Bu aslında basit bir kaçış olarak düşünülmelidir. İşin gerçeği bunu ciddi anlamda yapacak olanlar olsa da asıl sorunun kaçış anlarında nasıl davranılması gerektiği ile ilgilidir. Nitekim domates çiftliği fikri gerçekleşse bile o evde yüksek hızlı wireless internet bağlantısı olacağı aşikardır.

Yüksek Lisans’ da Araştırma Teknikleri konulu dersteki hocam bir keresinde şunu ifade etmişti:

Diyelim ki bir araştırmanın oldukça önemli ve can alıcı bir noktasında takıldınız. İlerleyemiyorsunuz. Fikir  dahi üretemiyorsunuz…Ne yaparsınız?

Tatile çıkarsınız (Sınıftaki sessizliği takiben)

Yazılımcılar için de kısa kaçışlar veya duruma bağlı olarak uzun kaçışlar söz konusu olabilir. Bu kaçışın ne olacağını bulmak önemlidir.

  • Adrenalini yüksek sportif bir aktitiveye katılmak,
  • Doğada tek başına yürüyüş yapmak,
  • Bir Marvel çizgi romanı koleksiyonu oluşturmaya çalışmak,
  • Deniz kenarına inip saatlerce ufka bakmak,
  • Yağmurlu havada deli gibi ıslanırcasına koşmak,
  • Uçak maketi yapmak veya modelcilikle uğraşmak,
  • Puzzle çözmek,
  • Varsa ailemizin veya bir komşumuzun bahçesinde gönüllü olarak bahçe işleri ile uğraşmak(Bakın bakalım domates yetiştirmek o kadar kolaymıy mış),
  • Fotoğrafçılık gibi bir hobi edinmek,
  • Kısa filmler çekmeyi denemek,
  • Belki de bir Tiyatro programına yazılmak,

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • DeadLine
  • Yazılımcı Psikolojisi
  • Yazılımcı Hobileri

Hal 12: Debugger ın verdiği Warning mesajlarını, Build’u kesmiyor diye kulak arkası etmektir.

Bu daha çok acele bir şekilde iş yetiştirmek, hep kısa olan Dead Line planına sadık kalmak ve aslında ürünün Build edilebilir olmasının yeterli olduğunu sanmak hali olarak da ifade edilebilir. Oysa ki geliştirilen bir ürünün başarılı kabul edilebilmesinin pek çok etkeni vardır.

12

@coderizbiz

Ürünün iş ihtiyaçlarına uygun olarak geliştiriyor olması, gerçek hayat testlerinden geçmiş olması, kullanıcı deneyiminin istenen şekilde vuku bulması, beklenen performans kriterlerini standartların üzerinde karşılaması, kolay genişletilebilir olması ve benzeri pek çok kriter bunlara örnek olarak verilebilir. Ancak işin bir boyutu da kamera arkası diyebileceğimiz yazılım ekibini ve onları gözlemliyenleri ilgilendirmektedir.

Yazılım ekipleri bazı acil durumlarda odadaki bütün çorap ve iç çamaşırları ilk gördükleri örtünün altına saklama eğilimi gösterirler.

Sıklıkla vurgulanan kod standartlarına uyulması bunlardan birisidir ve yazılım kalitesini doğrudan belirleyen faktörlerin başında gelir. Bu faktör .Net gibi bir platform düşünüldüğünde, derleme zamanındaki uyarı mesajlarının da ele alınmasını gerektirir. Bazı yazrdımcı uygulamalar ile bu mesajların oluşma hali sonrası Build işlemlerinin de Fail etmesi sağlanabilir ama bu çoğu zaman düşünülmez ve göz ardı edilir.

Geliştirilen ürünlerin yarın öbür gün başka meslektaşların elinden geçeceği bilinci ile yazılımcılık yapmak önemlidir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Kod Standartları,
  • Kaliteli Kod Ölçüm Kriterleri – Code Metrics
  • Dead Line

Hal 11:Bazen bir dilin temellerinin öğrenilebileceği en iyi yerin komut satırı(Console) olduğunu unutmaktır.

Elbette bir müşteri sizin komut satırından yaptığınız ürüne pek rağbet etmez. Sizce bu cümle ne kadar doğrudur?

Müşteriniz pekala IT tarafında çalışan bir sistem yöneticisi olabilir ve aslına bakarsanız sistemciler işlerini genellikle komut satırı araçları ile halletmeyi ve hatta güçlü betik diller ile pekiştirmeyi tercih eder. (Hatta müşteriniz ürününüzü kullanan başka bir ürün bile olabilir) O halde müşterinin istekleri doğrultusunda yeri geldiğinde komut satırından çalışacak bir ürün yazmanız gerekebilir.

11

@coderizbiz

Tabi ülkemizi ve yazılım sektörünün genelini düşündüğümüzde, müşteri profilindekilerin görsel arayüze daha çok önem verdiklerini rahatlıkla hiç bir bilimsel dayanağa bakmadan ifade edebiliriz(İstisnalar mutlaka vardır) Her ne kadar yeni yazılımcılar ürün kavramı ve olgusu konusunda çok bilgili olmasalar da, gerek kullandıkları uygulamalar gerek çevreden aldıkları duyumlar düşünüldüğünde, bir dili öğrenmeye komut satırından pek başlamazlar.

C# öğrenmeye bir Windows Forms açıp Button’ u ekranın ortasına koyup üstüne basınca da mesaj kutusunda “Hello World” yazdırarak başlıyorsanız eğer, bir durun ve etraflıca düşünün!

Komut satırı programlarının en büyük özelliği yalın olamalarıdır. Son derece sade bir ortamları vardır. Detaylar arkada bırakılmıştır. Konsantre olabileceğiniz parçalar programlama dilinin temel öğeleri, karakteristikleri ve ifadeleridir. Bu yüzden dilin kabiliyetlerini öğrenmek açısından da idealdir.

Hatta bazı diller gösterişten uzak ve komut satırı diyebileceğimiz web arabirimlerindeki Tutorial’ lar ile kolayca kavranabilirler. Örneğin dinamik dillerden olan Ruby’ yi bu şekilde kolayca öğrenebilirsiniz. İddiaya göre bu sadece 15 dakikanızı alacaktır.

Aynı Hello World örneğindeki Form’ u Console uygulamasında yazmaya çalışın. Button dinamik olarak üretilsin. Üstüne basıldığında çalışmasını istediğiniz kod parçaları için gerekli olay metodunu siz yazın. İşte şimdi Windows Form’ un aslında bir tip olduğunu ve sınıf olarak inşa edildiğini kavramaya başladıınız.

Bu hale düşülmesinde profesyonel geliştirme ortamlarının da rolü büyüktür. Çoğumuz C# öğrenmeye başladığında bir şekilde Visual Studio’ yu edinmeye çalışır. IDE çok etkileyicidir. Pek çok işi kolaylaştırır.  Ancak Notepad 2 ile Console uygulamalarını yazıp dilin temel özelliklerini burada ele alıp irdelemek çok daha akılda kalıcı ve öğreticidir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

Ruby’ yi Online Öğrenmek

Hal 10: Matematiği önemsemiyor olmak gibi feci bir hataya düşmektir.

Yazılımcıların pek azı hayatları boyunca ağır matematik problemleri ile karşılaşır. Ne varki pek çok sistemin yenilikçi fikirlere dayanan geliştirmelerinde matematik modellerin kullanılması söz konusudur. Örneğin,

  • bir kargo firmasının çeşitli tipte optimizasyon ihtiyaçlarının karşılanmasında,
  • bir elektronik ticaret sitesinin müşteri bağlılığını arttırmak için en uygun yolları keşfesmesinde,
  • grafik tabanlı çizim yapan bir programda doğal ışığın etkilerinin yansıtılmasında,
  • çocukların okullarda kullandığı görsel eğitim programlarında fizik kurallarının öğretilmesinde,
  • bir arama motoru algoritmasının geliştirilmesinde,
  • uçak simülasyonun gerçek koşullar ile birebir uygulandığı bir oyunda,
  • çok büyük bir veri içeriğinin efektif bir şekilde anlamlı hale getirilmesinde,
  • anlamsal web’in genelinde,
  • bir fotoğraf işleme programında yüz hatlarının altın orana olan uygunluğunun tespitinde,
  • anlık veriyi etkili bir şekilde çok hızlı işlemesi gereken bir cihazın üzerindeki yazılımda,

vb

10

@coderizbiz

Matematik bilminin evrende olmadığı bir yer söyleyebilir misiniz?

Örnekler daha da çoğaltılabilir. Hatta pek çok değerli çalışma da matematik modellerin kurgulanması, uygulanması ve anlatılması aşamasında akademik kadrolardan destek alındığı da görülmektedir.

Kimi büyük dünya firması bazı işe alım süreçlerinde önemli bir formülü inşa edecek elemanı ararken, adayları ilk telefonda bir matematik sorusu ile elemeye çalışır. (Bu yakın bir arkadaşımın Amazon ile olan iş görüşmesinin ilk adımında başına gelmiştir)

Biz yazılımcılar çoğu zaman müşteri sepeti içerisinden bir sorgu yardımıyla promosyon uygulatabildiğimizde Matematik adına oldukça önemli bir iş yaptığımızı düşünürüz. Bu en büyük yanılgılardan birisidir. İster akademik ister alaylı olalım biz yazılım geliştiricilerin şu meşhur algoritma kitaplarına en azından bir göz atması şarttır. Hatta bir Numerik Analizi kitabına bakmakta yarar vardır. Eğer bunlar sıkıcı gelirse ünlü matematikçi Fermat’ ın Son Teoremi kitabı okunarak haz duyulmaya çalışılabilir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Arama Algoritmaları,
  • Numerik Analiz,
  • Anlamsal Web – Semantic Web
  • Altın Oran
  • Fermat

Hal 9: Tüm çalışma hayatı boyunca sadece bilgisayar kitabı okunmasının yeterli olacağını düşünmesidir.

Tabi ki mesleki kitaplardan özellikle baş yapıt niteliğinde olanları okumadan olmaz. Hatta bunları mümkünse yatağımızın yanı başındaki komidinin üstünde, çalışma odasındaki kütüphanede ve hatta iş yerinde görünüz bir yerlerde tutmalıyız. Ancak hem kişisel gelişim hem de kariyer başarısı açısından kitap okumak tek başına yeterli değildir!

9

@coderizbiz

Pek çoğumuz internet üzerinden indirdiği e-book’ ları bir yerlerde depolar. Hatta GB’ larca kitap arşivimiz olur.

Peki kaçını okuyoruz? Hatta okuduklarımızı uygulamalı olarak deniyor miyiz? Okuduklarımızı yakınımızdakiler ile tartşıyor muyuz? Tartışmalardan çıkarımlarda bulunuyor muyuz?

Bazı mesleki kitaplar bire bir tatbik edilseler de, öğrenilenler zamanla unutulabilir. Bazı iç güdüselleşen hareketler kalıcı olsa da(örneğin bir programlama dilinin syntax’ ı) bazıları kolayca unutulabilir(Örneğin Dependency Injection’ ın uygulanışı) Bu yüzden sık sık pratik yapmak ya da sık kullanılanları etkili ve kolayca ulaşılabilecek şekilde not etmek gerekir.

Kitap okumak dışında, örnekleri tatbik edebilmek ve pratikler yaparak düşünce yapısı ile problem çözme mantığını geliştirmeye çalışmak da önemlidir. Bunun için bilimsel yollar bulunabileceği gibi her geliştirici kendine en uygun yolu keşfetmeyi de tercih edebilir.

İşin gerçeği ise kitabın bir şeyleri öğrenmek için kullanılan materyaller arasında artık  bir demir baş olmadığıdır. Bunun en büyük sebebi tabiki yeni çevresel düzendir.

  • Okunması gereken bloglar ve tartışma forumları,
  • Katılmak gereken ekip toplantıları ve topluluk etkinlikleri,
  • İzlenilmesi gereken görsel eğitim setleri,
  • Stackoverflow gibi sitelerin çözülmeye çalışılması, takip edilmesi gereken problemleri,
  • İncelenmesi gereken açık kaynak kod uygulamaları/kütüphaneleri,
  • Dinlenilmesi gereken Podcast’ ler,
  • Takip edilmesi gereken mail listeleri/gruplar,

ve benzerleri vardır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Stackoverflow
  • Codeplex
  • GitHub
  • Hanselminutes
  • Channel 9
  • AltDotNet

Hal 8: Bir problem çözümünde akla gelen ilk çözümün en iyi çözüm olduğu yanılgısıdır.

Ne yazık ki ve malesef istek sahiplerinin vakti ilginç bir şekilde dardır. Mümkünse istekler veya sorunlar hemen halledilmelidir. Sonuçta parayı veren düdüğü çalar modeli daha geçerli olduğundan, geliştiricilerin genellikle en acilinden çözüm bulması gerekebilir. Bu, en düzgün proje yönetiminde bile söz konusudur. Geliştiriciden istenen tahmini süreler gerçekçi bile olsa, yönetim tarafından azaltılmaya çalışılabilir. Geliştiricinin Einstein gibi uzun süre düşünüp kısa bir süreyi çözüme ayırmak gibi lüksü yoktur.

Eğer dünyayı kurtarmak için bana 1 saat verilseydi, bunun 55 dakikasını problemi tanımlamak, 5 dakikasını da çözümü bulmak için kullanırdım.

Albert Einstein

Bu yaklaşım bir, iki, üç derken bir bakmışsınız ki yıllardır acele acele kod geliştiriyor, çözüm üretiyorsunuz. Herkes memnun belki. İstekler en hızlısından çabucak çözülüyor, yeni talepler en kısa sürede karşılanıyor vs…

8

@coderizbiz

Ama gözden kaçırılan bazı hususlar var. Bir bakmışsınız bulunan o ivedi çözümler birer anti-pattern haline gelmiş. Bir bakmışsınız ürün bir süre sonra müdahale edilemez veya edilmesi riskli kategoriye girmiş. Bir bakmışsınız 3 sene önce uygulanan çözüm zincirleme bir reaksiyon başlatmış ve artık bir bug-fix için harcanan süre ve uygulamada dokunulan yer çok daha fazla. En sonunda isyan eden yazılımcının kaçmasıyla süreç yaşam döngüsü de tamamlamış. Yeni gelenin vay haline!

Bu halin oluşmasını engellemek pek kolay değildir aslında. Hatanın belli bir kaç nedeni vardır;

  • Çözümler üzerinden yeterince düşünülmemesi,
  • Çevresel etkilerinin araştırılmaması,
  • Yöneticinin veya müşterinin geliştiriciyi dinlemeyişi, dinlese bile önemsemeyişi,
  • Ürünün geliştirilmesi sırasında elin adamının bin bir dert sonrasında edindiği tecrübelerden ortaya çıkarttığı metodolojilere hiç uyulmaması,

ve benzerleri. Dolayısıyla problem çözümüne daha metodolojik yaklaşılmasında yarar vardır. En azından problemi iyi tanımlayarak işe başlanabilir.

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Einstein bir problemi nasıl çözer?
  • Uygulama Geliştirme Yaşam Döngüsü – Application Life Cycle Management
  • Anti-Patterns
  • Yazılımsal problemleri çözme tenikleri

Hal 7: Yazılım dünyasının sadece Object Oriented olduğunu düşünmesidir.

Pek çok geliştirici, dünya en çok neyin peşinde koşuyorsa ona yönelme eğilimi gösterir. Bu çoğu zaman programlama dilleri için de geçerlidir. Genellikle Nesne Yönelimli Diller yazılım geliştiriciler arasında çok daha popülerdir. Her ne kadar ilk öğrenilen zamanlarda Kalıtım, Çok Biçimlilik, Sarmalama ve benzeri temelleri çok soyut kalıp kafa karıştırsa da, iyi seviyede öğrenildiğinde vazgeçilmez bir programlama yaklaşımıdır.

Programlama evreni sadece nesne yönelimli yaklaşımlar üzerine kurulmamıştır.

Şöyle bir düşünüldüğünde Yaptırımsal(Imperative), Yapısal(Structured), Yordamsal(Procedural), Bildirimsel(Declarative), Fonkisyonel(Functional), Olay Güdümlü(Event-Driven) vb yaklaşımlar da mevcuttur. Hatta bazı diller bu yaklaşımların bir kaçını bünyesinde barındırmaktadır. Dolayısıyla bir kaç yaklaşımdan haberdar olmak, genel karakteristikleri bilmek, yeni dilleri öğrenmeyi epeyce kolaylaştırır.

7

@coderizbiz

Farklı programlama dili yaklaşımlarının karakteristiklerini bilmek, bir çözüm için uygun teknolojilerin seçiminde önem arz eden konulardan birisidir.

Örneğin fonksiyonel dillerden olan Scala, nesne yönelimli yaklaşım kriterlerini de sağlamaktadır. Çoğu zaman Yordamsal olarak düşündüğümüz ve yazılım dünyasının vazgeçilmezlerinden olan C dili, Yaptırımsal ve Yapısal dil yaklaşımlarını da içerir. Hatta C++ tüm bunların yanında bir de Nesne Yönelimli karakteristik gösterir.

Günümüzün en çok tercih edilen programlama dillerini düşündüğümüzde, yaklaşım bilmenin öğrenimi kolaylaştırdığını düşünebiliriz. Ne varki C#, VB.Net, Java gibi popüler diller çoğunlukla bir Framework üzerine oturmaktadırlar. Dolayısıyla etkin ürün geliştirme noktasında Framework’ lere aşina olmak da önemlidir. Nesne yönelimli programlama veya farklı bir yaklaşımı bilmek, ürün geliştirilmesi açısından her zaman için yeterli olmayabilir. Ama en alt seviyede C ile yazıyorsanız durum tabi ki farklıdır :)

Anahtar Kelimeler(Bunları Bir Araştıralım)

  • Programlama Yaklaşımları – Programming Paradigms
  • Programlama Dili Yaklaşımlarının Karşılaştırılması – Comparison of programming paradigms
  • Yaptırımsal – Imperative,
  • Yapısal – Structured,
  • Yordamsal – Procedural,
  • Bildirimsel – Declarative,
  • Fonkisyonel – Functional,
  • Olay Güdümlü – Event-Driven
  • Kalıtım – Inheritance
  • Çok Biçimlilik – Polymorphism
  • Sarmalama – Encapsulation

Hal 6: Minicik bir metodun içine bin satır kod sığdırınca yazılımcı olduğunu düşünmesidir.

Çevik yazılım metodolojilerinin belki de en meşhuru olan Scrum’ da kullanıcı senaryolarının epikleştiği haller vardır. Böyle bir durumda senaryo daha küçük ve yönetilebilir parçalara bölünerek ilerlenir. Bu, işin kalitesini arttırmak, yönetilebilirliği küçük parçalar halinde ele almak, talepleri ve beklentileri iterasyonlara sığdırabilmek ve müşteriye çözüm verebilmek gibi nedenlerle önemlidir.

Ancak yazılımcıların bazıları ne yazık ki günlük olarak yazdığı kod satırı sayısının çokluğuna, kullanılan metodlar içerisindeki karmaşıklığa bakarak önemli işler yaptığını düşünür ve aslında metod içeriklerini epikleştirerek pek çok modern yaklaşımın kaçındığı durumlara düşmekten kurtulamaz. O gün için bir felaket olmasa da ilerleyen yıllarda kaos haline gelen projeler ortaya çıkacaktır.

6

@coderizbiz

Eğer bir projenin atmoik fonksiyonellikleri zaman içerisinde farklı geliştiricilerin elinden geçiyor, Code Review yapılmadan, standartları ölçen araçlara bakmadan ilerleniyorsa, bu modeldeki geliştiricilerin kod satır sayılarını binler seviyesine çıkartması kaçınılmazdır. Tecrübe ile sabittir, canlı olarak gözle görülmüştür.

Hal böyle olunca gittikçe büyüyen kalabalık kod parçalarından oluşan metodlar içerisinde Lord Of The Rings serisine benzer epik maceralar başlar. Bir de arka fona epik bir oyun müziği koydunuz mu tamamdır?

Kalabalık metod içerikleri (örneğin satır sayısı  20yi aşan bloklar)

  • okunurluğu zorlaştırır,
  • anlaşılmayı güçleştirir,
  • hata ayıklamayı işkence haline getirir,
  • sorumlulukların doğru bir şekilde dağıtılmasını önler,
  • scroll ile yukarıdan aşağıya doğru inildiğinde, ekrana bakan diğer geliştiricinin psikolojisinin anında bozulmasına neden olur,
  • müdahale edilmesini zorlaştırır,
  • dokunmak isteyen yazılımcı sayısını azaltır,
  • kodun kalitesinin bozulmasına neden olur,
  • ileride muhtemel bir anti-pattern oluşumuna zemin hazırlar,
  • ve bazı kod metriklerine uyulmaması nedeniyle programların derlenmemesine ve bazen uzun zaman alan Build işlemlerinin kesilmesine sebebiyet verirler.

Çözüm basittir. Problemi mümkün olduğunda küçük, kendini tekrar etmeyen, olabildiğince basit atomik parçalara ayırmaktır. Ama bu sadece işin küçük bir parçasıdır. Metodu iş yapan bir birim olarak düşündüğümüzde, bunun kullanıldığı çevrenin düzeni(kalıplar, prensipler vs) de önemlidir.

Anahtar Kelimeler(Bunarlı Bir Araştıralım)

  • Anti-Patterns
  • Kod Standartları – Code Standards
  • NDepend
  • Code Query Language
  • Code Metrics
  • Readable Code
  • DRY-Don’t Repeat Yourself
  • KISS İlkesi
  • Code Review

Hal 5: Özellikle fast food dan uzak durunca kilo verebileceğini zannetme vaziyetidir.

Yazılımcılar vakitlerinin büyük çoğunluğunu koşturmaca ile değil, bilgisayar başında saatlerce oturarak geçirir. Hal böyle olunca hareketsiz kalan vücudun yağ depolama ve muhafaza etme hevesi de artar. Sonuç genellikle göbek bölgesinde toplanır. Gıdı ön plana çıkar. Hele bir de şirketin sandalyeleri geliştiricilere özel ergonomik olanlardansa vay halinize. Oturduğunuz da kalkmak istemezsiniz çünkü.

5

@coderizbiz

Tabi bu durum her bünye için geçerli olmayabilir. Bazı bünyeler oturduğu yerde dahi kalori yakabilme yeteneğine sahiptir. Bazı geliştiriciler kodlara daha fazla kafa patlatarak daha çok içsel ısı üretmeyi ve bu sıcaklığı beyin bölgesinden yağlı kısımlara indirgeyerek daha çok kalori yakmayı umut eder. En büyük yanılgı ise fast food’ dan uzak durulduğunda epeyce kilo kaybedileceğinin sanılmasıdır. Aslında olay son derece basittir. Yaş ilerledikçe hareketsiz kalan vücud kalori yakmakta zorlanır.

Spor her yaştan insanın, yapabildiği ölçüde, mümkünatı var ise yapması gereken bedensel bir aktivite değil, ihtiyaçtır.

Günümüzün yeni nesil yazılımcıları bu konuda çok daha bilinçli hareket etmekte. 80lerin o göbekli, kalın çerçeve gözlüklü, dağınık saçlı, bol kot pantalonlu, karın bölgesini kapatamayan t-shirt’lü ve sürekli kutu kola ile gezen programcı modeli pek yok. Onun yerine IronMan gibi yarışmalarda boy gösteren, bisiklet ile şehir şehir gezen, tırmanan, deniz sporları ile uğraşan daha atlet geliştiriciler profilde.

Teknoloji de zaten tam da yazılımcıların istediği gibi spora hizmet eder olmuş durumda. Hangi aktivite ile tahmini olarak ne kadar kalori harcadığınızı, nereden nereye vardığınızı, ne kadar sürede tamamladığınızı ve benzeri pek çok bilgiyi detayları ile kolayca ölçümleyebiliyorsunuz.

Sonuç olarak geliştirici fast food’ dan uzak duramıyorsa bile bunu yakmasının bir yolunu mutlaka bulmalı. Asıl endişe verici olan, o kadar deli algoritma içinden kolayca sıyrılan bir adamın spor konusunda aciz kalmasıdır.

Anahtar Kelimeler(Bunları Bir Araştıralım)

Şimdi bilgisayar başında anahtar kelime araştırma değil, spor yapma zamanı. Kalk koltuğundan!

Hal 4: Ömür boyu sadece iyi kod yazmasının yeterli olacağını düşünmesidir.

İyi kodu nasıl tanımlarsınız!? Okunabilir olması mı? Bir kaç yazılım kalıbını başarılı bir şekilde uygulanabilmesi mi? Kodlama standartlarının bire bir entegre edilmesi mi? Yorum satırı olmadan da anlaşılabiliyor olması mı? Yoksa bunların hepsinin bir arada bulunması mı?

İyi kodlama için pek çok teknik, öğreti ve kitap vardır. Code Complete, The Art of Readable Code, Clean Code, Writing Solid Code(Bizdeki adıyla Hatasız Kodlama) sadece bu konuyu içeren kitaplardan bir kaçıdır.

4

@coderizbiz

Ama bu çoğu zaman bir geliştiricinin hayati hedefi haline gelir. Bu iyi bir şey gibi görünse de mükemmel kodu yakalamak her zaman için zordur. Dahası yakın geçmiş, günümüz ve gelecek nesil ürünlerin geliştirildikleri ortamlar göz önüne alındığında, iyi kodun sadece gerekli olan minik bir figuran olduğu kabul edilmelidir.

Sıklıkla vurgulandığı gibi iyi kodun etrafını saran pek çok kriter vardır. Doğru bir mimari ve uygun araçların seçimi, gerekliyse etkili bir dokümantasyon, süreç yönetimi, ekip çalışması, diğer bakış açılarının katkısı(örneğin finans departmanının ürüne bakış açısı, beklentileri nedir veya bir üniversite öğrencisinin bakış açısı nasıl olabilir vb), ürün olgusu, farklı ortamların bir arada sorunsuz konuşabilmesi vb…

Yani, kodlama artık 80li yıllardaki Commodore 64 ün 64Kb lık kısıtlı bellek kapasitesi altında yapılması gereken bir iş değildir.

Eğer hala öyle olsaydı sadece iyi kod yazmaya odaklanabilir bir hayatı hedefleyebilirdik. Dünyamız artık bir biri ile konuşabilen akıllı makinelerin olduğu bir gelecek vaat etmekte. Hatta o geleceği çoktandır yaşamakta. Şartlar çok ama çok değişti/değişiyor.

Çevresel kriterler ve kodu saran faktörler ortada. Dolayısıyla iyi kod yazmak gerekli olan ama tek bir hedef olarak düşünülmemesi gereken bir olgu olarak geliştiricinin karşısında durmakta.

Anahtar Terimler(Bunları Bir Araştıralım)

The Art of Readable Code
Clean Code
Kodlama Standartları – Coding Standards
Uygulama Geliştirme Yaşam Döngüsü – Application Lifecycle Management
Yazılım Mimarı mısın?

Hal 3: Unutkan olduğunu bilmesine rağmen, “Şu kod bloğunu bir comment’liyim sonra açarım” vaziyetidir.

Yazılım geliştirme satranç oyununu andırır. Geliştirici oyunun oldukça fazla olan kurallarını iyi bilirse sonuca ulaşma noktasında avantaj kazanır. Ancak bundan da önemlisi,

bir kaç hamle ötesini görebilmek ve buna göre hareket edebilmektir.

Kod yazan kod parçalarını, yapay zeka türevli akıllı sistemleri  bir kenara bıraktığımızda, biz insan oğlunun yazılım mesleğine kendisini adamış olanlarının yazdıklarını/yorumladıklarını/kaldırdıklarını kısacası eylemlerini bir süre sonra unutması ihtimaldir. Her şey olabilir. Yapılanları zaman unutturabileceği gibi aslına bakarsanız kafayı bir yere vurduktan sonra da bilgi kaybı meydana gelebilir.

3

@coderizbiz

Kod satır sayısı ve özellikle proje öğesi fazla olan sistemler göz önüne alındığında, bir yerlere bırakılan “sonradan yaparım, sonradan açarım, sonradan kaldırırım…” gibi felsefelere dayanan notlar çoğunlukla öylece kalırlar. Heleki bir uygulamanın hatalarını ve bir şeyleri düzeltmek istediğimiz hallerde kapattığımız kod parçaları, bir süre sonra unutulabilirler. Bu, yazılımın geleceği açısından risk yaratan bir durumdur.

Bu hal daha çok tamamlanmış ve bir yerleri düzeltilmesi gereken büyük çaplı ürünlerde debug işlemleri ile gezildiği durumlarda söz konusu olur. Üzerinden geçilen bir metod veya kod parçası o an gerekli olmayan bir dış sisteme bağımlı olduğundan ilerlemeyi engelleyebilir. O anki çare Drogba olmasa da ilgili kısımları yorum satırı haline getirmektir.

Böyle bir halde dikkat edilmeli, en azından yorumlanan kod satırının neden, ne zaman ve kim tarafından yorumlandığı ifade edilip TODO gibi IDE dostu yardımcı materyaller ile desteklenmelidir. Ya da basit bir post-it ile bir yerlere not düşülmelidir. Kısacası bir çözüm bulunmalı ve yorumlanmış kod satırları o şekilde unutulmamalıdır.

Anatar Terimler(Bunları bir araştırmak lazım)

  • Hata Ayıklama – Debug
  • Hata Düzeltme – Bug Fix
  • IDE – Integrated Development Environment
  • Visual Studio TODO
  • İleri seviye Debug işlemleri

Hal 2: “Ben Xciyim bu proje Y ile yazılmış, el sürmem hatta Yyi de yazmam, yazanı da sevmem” demesidir.

Bu Hali okurken X yerine büyük ihtimalle .Net, Y yerine de Java koyabilirsiniz. Bunun tam tersi de olabilir. Hatta X yerine VB, Y yerine C# bile gelebilir. Peki ya gerçek dünya bunları söyleyebilme lüksünü kaldırabilir mi?

2

 

@coderizbiz

Bir ürünün geliştirilmesi için bazen araçlardan, kullanılan programlama dilinden, dilin türevinden bağımsız düşünmek gerekir. Kimi zaman statik bir dil çözüm için biçilmiş kaftanken, bazı hallerde fonksiyonel bir dilin kullanılması icap edebilir. Bazı büyük çaplı çözümlerde birden fazla yazılım alt yapısını bir arada kullanmak da gerekebilir. Melez haldeki bu yapılarda her alan için o alanın uzmanı olan yazılımcıları tutmak çok maliyetli olabilir.

Esnek olabilmek daha önemlidir.

Yazılım prensiplerine, metodolojilerine ve ürün geliştirme süreçlerine hakim olmak, mimarileri tanımak ve uygulayabilmek, programlama dillerinin karakteristiklerinden ve hangi alanlarda etkili çözümler sunabildiklerinden haberdar olmak, müşteri gereksinimlerini doğru anlayıp analiz edebilmek vb gerekir.

Xciyim ve Yciyim demek aslına bakarsanız fanatiklikten farksızdır. Bunu pek çok grup toplantısında da görürüz. Xciler Ycileri suçlar, Yciler Xciler döver, yolda karşılaştıklarında birbirlerine rakip sokak dansçıları gibi caka satar ama sonuçta bir yere varılmaz/varılamaz. Nihai çözümlerde Xciler, Yciler ile bir noktada konuşmak durumunda, anlaşmak zorunda kalırlar.

Özellikle günümüz uygulama çözümlerinde, farklı platformların aralarında iletişim kurarak komple bir ürünü temsil ediyor oldukları düşünüldüğünde, Xcilik ve Ycilik den mümkün mertebe sakınmak en doğrusudur.

Anahtar Terimler(Bunları bir araştırmak lazım)

  • Yazılım Tasarım Prensipleri – Software Design Principles
  • Uygulama Geliştirme Yaşam Döngüsü – Application Lifecycle Management
  • Dinamik ve Statik Diller
  • Servis Yönelimli Yaklaşım – Service Oriented Architecture
  • Programlama dillerinin karakteristik özellikleri

Hal 1 : Bütün desenler ezberlenir sonra ilk projede hepsi birden kullanılmak istenir.

Nesne yönelimli programlama dünyasının tepe noktalarından birisidir tasarım kalıpları. Gang of Four’un pek çok standart yazılım sorununun çözümü için ortaya koyduğu ilkelerdir bunlar aslında. C# çı veya Java cı olunması fark etmez. Her nesne yönelimli dil için geçerli ilkelerdir.

1

 

@coderizbiz

 

İlk öğrenilenleri genelde Singleton ve Abstract Factory’ dir. Öğrenmeye devam ettikçe zorlaşan deseneler pek çok yazılımcının işi yarı yolda bırakmasına da neden olur. Tamamını öğrenenlerin ise unutmamak için çaba göstermeleri gerekir. Unutmamanın en iyi yolu bir yerlerde kullanmak veya bir yerlere yazarak sık sık tekrar etmektir.

Tasarım kalıplarını iyi bilenler genelde elit yazılımcılar olarak görülürler.

Henüz mesleğinin ilk yıllarında olan yazılımcıların düştüğü bir haldir bu maddede anlatılmak istenen aslında. Desenler bir çırpıda öğrenilmeye çalışılır, ezberlenir ve hatta ilk projede ne var ne yok mutlak kullanılmak istenir.

Oysa ki gözden kaçan önemli bir husus vardır. Bu, bir çözüm için gereken en doğru deseni/desenleri seçme noktasında nasıl karar verileceğidir?

Yani mesele sadece desenleri öğrenmek değildir! Mesele, bunların birbirlerine olan benzerliklerini, kimin kimin yerine geçebileceğini, hangisinin ne gibi avantajlar sunduğunu, bir arada kullanılıp kullanılamayacaklarını vb bilmektir.

Hatta n sayıda proje içeren dev bir çözüme bakıldığında, kullanılan desenlerin o binlerce satırlık kod kalabalığı içerisinde kolayca görülmesi, nereye müdahele edileceğinin tespit edilmesinin bilinmesidir. Bunlar, desenleri kategori bazlı olarak ayırt etmekten çok daha ötesidir.

Anahtar Terimler(Bunları bir araştırmak lazım)

  • Nesne Yönelimli Programlama – Object Oriented Programming
  • Tasarım Kalıpları – Design Patterns
  • Çözüm – Solution

Merhaba Yazılımcı!

Bir kaç madde ile Twitter üzerinde başlayan Yazılımcının Derman Bulunmaz Halleri serisinin Web Sitesidir. Eğer mümkün olursa karikatürler aracılığıyla ilgili maddeler güçlendirilip sizleri biraz neşelendirmek ama daha çok düşündürmek için yayın hayatına başlayacaktır.

Karikatürlerde gönüllü olarak yer almak isteyenler olursa benimle selim(at)buraksenyurt.com adresinden iletişime geçebilirler ;)