Clean Code’dan Notlar: Bölüm 2 — Anlamlı İsimlendirmelerle Takım Arkadaşlarınıza Küçük Sürprizler Yapın

İyi isim seçmek zaman alır, ancak uzun vadede daha çok zaman kazandırır.


Her şeye bir isim veririz; değişkenlerimize, fonksiyonlarımıza, argümanlarımıza, sınıflarımıza ve paketlerimize. O kadar çok isimlendirme yaparız ki, bunu iyi yapsak iyi olur aslında. 🙂

İlk örneğimizle başlayalım:

int d; //elapsed time in days (gün cinsinden geçen süre)

d burada hiçbir şeyi açıklamıyor, günlerle ya da zaman ile alakalı hiçbir şey uyandırmıyor. Daha anlamlı isimler seçmeliyiz, şunlar gibi:

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

Peki aşağıdaki kodun amacı nedir? Ne yaptığını açıklamak neden bu kadar zor? Karışık işlemler yok, boşluklar ve girintiler (indentation) de mantıklı. Burada problem kodun basitliği değil, kapalı oluşu.

public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList)
        if (x[0] == 4)
            list1.add(x);
    return list1;
}
  1. theList ne içeriyor?
  2. theList’in ilk elemanın önemi nedir?
  3. 4 değerinin önemi nedir?
  4. Dönen list1 listesini nasıl kullanmalıyım?

Bu soruların cevapları kodda değil, yazan programcının zihninde. Ancak şöyle olsa:

public List<int[]> getFlaggedCells() {
    List<int[]> flaggedCells = new ArrayList<int[]>();
    for (int[] cell : gameBoard)
        if (cell[STATUS_VALUE] == FLAGGED)
            flaggedCells.add(cell);
    return flaggedCells;
}

Kodun basitliğinin değişmediğini farkedin. Hala aynı sayıda işlemci ve sabit var. Ama kod daha açık hale geldi. Daha da ileri giderek, int[] dizisi kullanmak yerine, cell’leri içeren bir Cell sınıfı yapabiliriz.
Yaptığımız bu basit değişikliklerle kodda neler olduğunu anlamak hiç de zor değil.


Kötü isim örneklerinden biri de küçük l (Lüleburgaz’ın L’si) ya da büyük O kullanmaktır. Çünkü görünüşte bir ve sıfıra benzerler.

int a = l;
if (O == l)
    a = O1;
else
    l = 01;

Yazılımcılar kod yazarken problemleri kendileri yaratırlar. Örneğin aynı ismi aynı kapsamdaki (scope) 2 farklı objeye veremediğimizden, birini değiştirme yoluna gideriz. Sayı eklemek yeterli olmadığında, bunu birinin bir harfini eksilterek yaparız. Ancak, isimlerin farklı olması gerekiyorsa anlamları da farklı olmalıdır.

a1, a2, a3, … gibi isimlendirmeler kesinlikle anlamlı değildir. Bu tür isimler yazarın amacı hakkında en ufak bir ipucu bile vermezler. Burada a1 ve a2 yerine source (kaynak) ve destination (hedef) kullanılması çok daha anlamlıdır:

public static void copyChars(char a1[], char a2[]) {
    for (int i = 0; i < a1.length; i++) {
        a2[i] = a1[i];
    }
}

Product isimli bir sınıfınız olduğunu hayal edin. Bir de ProductInfo ve ProductData sınıflarımız olsun. “Info” ve “Data” birbirine yakın çağrışımlı, dolayısıyla etkisiz kelimelerdir ve aynı kapsamda kullanılmaları belirsizlik yaratır. Örneğin yeni eklenecek bir alanın (field) hangisine ekleneceği tamamen belirsizdir.


Şu şekilde metotlarımız olsun:

getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();

Geliştiriciler bu metotlardan hangisini çağıracağını nasıl bilebilir?

Benzer durum değişkenlerde de karşımıza çıkabilir. Örneğin moneyAmount değişkeni money değişkeninden, customerInfo customer’dan ya da accountData account’tan ayırt edilemez.

Telaffuz Edilebilir İsimler Kullanın

Eğer bir değişkenin adını telafuz edemiyorsanız onu kullanmayın. Yakın zamanda karşılaştığım bir örnek: “yeterli” anlamında, adequate kelimesinin yerine, daha yaygın kullanılan ve dolayısıyla telaffuzu daha iyi bilinen enough kelimesi tercih edilmelidir.

Aranabilir İsimler Kullanın

Tek harfli isimler ya da sayı sabitleri arama dostu değildir.
Örneğin MAX_CLASSES_PER_STUDENT sabitini çok rahatça bulabiliriz. Ancak 7‘yi bulmak oldukça zahmetlidir. Aynı şekilde e de çok kötü bir seçimdir. İngilizce’deki en yaygın harftir ve neredeyse her yerde karşımıza çıkacaktır.

Kişisel tercihim, tek harfli isimleri yalnızca kısa metotlarda lokal değişken olarak kullanmaktır. Bir ismin uzunluğu, o değişkenin kapsamının genişliği ile eşdeğer olmalıdır. Eğer bir değişken ya da sabit bir kod bloğunda birden fazla kullanılacaksa, arama dostu bir isim vermek en iyisidir.

Şu iki kodu karşılaştıralım:

for (int j = 0; j < 34; j++) {
    s += (t[j] * 4) / 5;
}
int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j = 0; j < NUMBER_OF_TASKS; j++) {
    int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
    int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK);
    sum += realTaskWeeks;
}

sum çok kullanışlı bir isim değil ancak en azından aranabilir. Benzer şekilde
WORK_DAYS_PER_WEEK sabitinin kullanımlarını bulmak, 5 sayısını bulmaktan kat be kat daha kolaydır.

Arayüzler ve Gerçekleştirimler (Interfaces — Implementations)

Bir arayüz ve onu gerçekleştirecek somut (concrete) bir sınıf yazacağınızı düşünün. Bu iki sınıfa ne isim verirdiniz? IShapeFactory ve ShapeFactory mi? Ben arayüz sınıflarını sade bırakmayı tercih ediyorum. Başa I harfi eklemek yaygın bir pratik, ancak dikkat dağıtmakta bir numara ve bilgi vermek konusunda da sonuncu. Eğer arayüz ya da gerçekleştirim sınıflarından birini belirtmem gerekiyorsa, gerçekleştirim sınıfını seçiyorum; ShapeFactoryImpl şeklinde. Arayüz sınıfını belirtmekten çok daha iyi.


Sınıf isimleri Customer, WikiPage, Account ya da AddressParser gibi isimlerden/isim tamlamalarından oluşmalıdır. Sınıf isimleri asla bir fiil olmamalıdır.


Metot isimleri postPayment(), deletePage() ya da save() gibi fiillerden/fiil tamlamalarından oluşmalıdır. Erişimci (getters), mutatör (setters) ya da doğrulayıcı (predicate) (true/false dönen; isEmpty() gibi) metotların başlarına, Java standartlarına göre get, set, is eklenmelidir.

String name = employee.getName();
customer.setName("Mike");
if (paycheck.isPosted())
...

Farklı parametrelere sahip kurucular (constructors) oluşturmak yerine, “static” yapıcı (builder) metotlar kullanılmalıdır.

İlk satırdaki kod örneği, ikincisinden çok daha iyidir:

Complex fulcrumPoint = Complex.FromRealNumber(23.0);
Complex fulcrumPoint = new Complex(23.0);

Kelime Oyunu Yapmaktan Kaçının

İki farklı amaç için aynı kelimeyi kullanmaktan ya da aynı amaçlar için farklı kelimeleri kullanmaktan kaçının. Örneğin Controller, Manager ya da Driver kelimelerini aynı kapsamda farklı sınıflar için kullanmak iyi bir kullanım örneği değildir. Birini seçin ve onunla devam edin.

Örneğin birileri sizden önce add metodu yazmış olsun ve bu metot da iki değeri birbirine birleştiriyor (concat) olsun. Bizim de bir listeye değer ekleyen bir metota ihtiyacımız olsun. Bu metoda add mi demeliyiz? Hayır. Bu durumda yeni metodumuza insert ya da append demeliyiz. Yeni bir add metodu yazmak, kelime oyunu yapmaktır.

Gereksiz Bağlamlardan Kaçının

firstName, lastName, street, houseNumber, city, state ve zipcode isimli değişkenlerimiz olduğunu düşünelim. Birlikte alınca bir adresin detayları olduğunu çok çabuk anlayabiliyoruz. Ancak sadece state değişkenini görürsek, gene de adrese ait olduğunu düşünebilir miyiz?

Önekler (prefix) kullanarak bağlam (context) sağlayabilirsiniz; addrsFirstName, addrLastName, addrState vb. En azından okuyucular bu değişkenlerin daha büyük bir yapının parçası olduğunu anlayabileceklerdir. Elbette daha iyi bir çözüm Address isimli bir sınıf yaratmaktır.

Aşağıdaki örnekte ise metot oldukça uzun ve bir sürü değişkene sahiptir:

private void printGuessStatistics(char candidate, int count) {
    String number;
    String verb;
    String pluralModifier;
    if (count == 0) {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    } else if (count == 1) {
        number = "1";
        verb = "is";
        pluralModifier = "";
    } else {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
    String guessMessage = String.format(
        "There %s %s %s%s", verb, number, candidate, pluralModifier);
    print(guessMessage);
}

Bu metodu daha küçük parçalara bölebilmek için GuessStatisticsMessage isimli bir sınıf oluşturmalı ve içine üç adet değişken koymalıyız:

public class GuessStatisticsMessage {
    private String number;
    private String verb;
    private String pluralModifier;
    
    public String make(char candidate, int count) {
        createPluralDependentMessageParts(count);
        return String.format(
            "There %s %s %s%s",
            verb, number, candidate, pluralModifier);
    }
    private void createPluralDependentMessageParts(int count) {
        if (count == 0) {
            thereAreNoLetters();
        } else if (count == 1) {
            thereIsOneLetter();
        } else {
            thereAreManyLetters(count);
        }
    }
    private void thereAreManyLetters(int count) {
       number = Integer.toString(count);
       verb = "are";
       pluralModifier = "s";
    }
    private void thereIsOneLetter() {
       number = "1";
       verb = "is";
       pluralModifier = "";
    }
    private void thereAreNoLetters() {
       number = "no";
       verb = "are";
       pluralModifier = "s";
    }
}

Son örneğimize geçelim: Gas Station Deluxe isimli bir uygulamamız olsun. Bu uygulamada her sınıfın başına GSD öneki koymak kötü bir fikir. Örneğin GSD’nin hesap modülüne bir MailingAddres sınıfı eklediğinizi ve ismine GSDAccountAddres dediğinizi düşünelim. Daha sonra müşteri modülü için de bir MailingAddres sınıfına ihtiyaç duyduğunuzda GSDAccountAddres sınıfını kullanır mısınız? Doğru isim mi sizce?

Burada 10 karakter (GSDAccount) tamamen gereksizdir. Bu nedenle kısa isimler, açık ve net oldukları müddetçe uzun isimlerden her zaman daha iyidir.


İsimlendirme demişken…

https://medium.com/t%C3%BCrkiye/https-medium-com-busrauzun-clean-code-kitabindan-notlar-2-anlamli-isimlendirmeler-de309168e13e


Reklamlar

Clean Code’dan Notlar: Bölüm 1 — Temiz Kod Derken?

“Bu kitabı iki sebepten ötürü okuyorsunuz: ilki yazılımcısınız, ikincisi daha iyi bir yazılımcı olmak istiyorsunuz. Güzel, çünkü daha iyi yazılımcılara ihtiyacımız var.” diye başlıyor Clean Code’a, usta yazılımcı Robert C. Martin, ve devam ediyor:

Bu kitap iyi programlamayı anlatıyor. Bir sürü kodlama örneği olacak. Bitirdiğimiz zaman ise iyi kod ve kötü kod arasındaki farkı anlayabileceğiz. Nasıl iyi kod yazabileceğimizi ve kötü yazılmış bir kodu iyi bir koda nasıl dönüştürebileceğimizi öğreneceğiz.


80’lerde bir şirket müthiş ve çok popüler bir uygulama yazdı. Ancak bir zaman sonra yeni sürüm çıkma (release) dönemleri uzamaya başladı. Bir sonraki sürümde hatalar çözülmemiş oluyordu. Yüklenme süresi uzuyor ve çökmeler artıyordu. Büyük bir hüsran ile uygulamayı kaldırdığım günü hatırlıyorum. Zaten bir zaman sonra da şirket tamamen piyasadan çekildi.

20 yıl sonra şirketin ilk çalışanlarından biri ile karşılaştım ve ona ne olduğunu sordum. Cevabı korkularımı doğruladı. Ürünü markete erkenden sürebilmek için çok acele etmiş ve kodda çok büyük bir kargaşaya sebep olmuşlardı. Daha fazla özellik ekledikçe, kod daha da kötü bir hal almış ve o kadar kötü hale gelmişti ki, artık kodu yönetemiyorlardı. Böylece kötü kod şirketin kapanmasına sebep olmuştu.

Hepimiz zaman zaman geri dönüp kodumuzu temize çekeceğimizi söylemişizdir. Ancak o zamanlar LeBlanc’ın şu kuralını bilmiyorduk: “Sonra asla demektir (Later equals never).”


Kod karmaşıklığı arttıkça takımların verimliliği düşer ve sıfıra yaklaşır. Verimlilik düştükçe de yöneticiler yapabildikleri tek şeyi yaparlar; verimliliği artırması umudu ile projeye daha çok insan kaynağı eklerler. (İnsan kaynak mıdır yoksa değer mi?) Takımdaki herkes verimliliği artırmak için büyük baskı altındadır. Öyle ki verimliliği sıfıra daha da yaklaştıracak şekilde kod karmaşası yaratmaya devam ederler.


Peki Koda Ne Oldu?

Ne oldu da iyi kod bu denli bir hızla kötü koda dönüştü? Bunun için bir çok sebep sıralayabiliriz. Gereksinimlerin (requirements) çok fazla değiştiğinden şikayet edebiliriz. Teslim tarihlerinin (deadline) çok sıkı olduğundan da yakınabiliriz. Beceriksiz yöneticilere ya da hoşgörüsüz müşterilere de püskürebiliriz. Ancak hata tamamen bizde. Bizler profesyonel değiliz!

Kabul etmesi zor, hata nasıl bizde olabilir? Diğerleri, onların hiç suçu yok mu? Hayır. Yöneticiler taahhüt vermek için bizden birşeyler duymayı beklerler. Beklemedikleri zaman bile onlara ne düşündüğümüzü söylemekten kaçınmamalıyız. Proje yöneticileri de zamanlama için bizden birşeyler duymayı beklerler. Bu yüzden, proje planlaması ve başarısızlıklar konusunda epey suçluyuz!

“Eğer yapamazsam kovulurum!” diyorsun fakat büyük ihtimalle kovulmayacaksın. Çoğu yönetici istiyormuş gibi yapmasa bile gerçeği ister. Çoğu yönetici iyi kod ister, zamanlama konusunda takıntılı olduklarında bile. Zamanı ve gereksinimleri tutkuyla savunabilirler, ancak bu onların işidir. Senin işin ise aynı tutku ile kodunu savunmaktır.

Temiz kod yazabilmek, temizlik (cleanliness) duygusuyla uygulanmış sayısız küçük teknik yöntemlerin disiplinli bir şekilde kullanımını gerektirir. Bazılarımız bu duyguya doğuştan sahiptirler. Bazılarımız ise elde edebilmek için savaşmak zorundadırlar. Bu duygu sadece iyi ya da kötü kodu ayırt etmemizi sağlamaz, aynı zamanda kötü kodu temiz koda (clean code) dönüştürebileceğimiz stratejiyi de bize gösterir. Bu duygudan yoksun bir yazılımcı karmaşık bir modüle baktığında karmaşıklığı tanır ancak onunla ne yapacağı hakkında en ufak bir fikri yoktur. Bu duyguya sahip bir yazılımcı ise bu karmaşık koda bakar ve seçenekleri görür.


Temiz Kod Nedir?

Yapılmış birçok tanımı var. Ben de çok iyi bilinen bazı yazılımcılara ne düşündüklerini sordum:

Bjarne Stroustrup (C++’ın mucidi): Kodumun şık ve temiz olmasını seviyorum. Kodda mantık, hataların saklanmasını zorlayacak kadar düz; bağımlılıklar (dependency) bakımı kolaylaştıracak kadar minimal olmalı. Tüm istisnai durumlar (exceptions) ele alınmalı, performans optimale yakın olmalı.

Grady Booch (Object Oriented Analysis and Design with Applications kitabının yazarı): Temiz kod basit ve açıktır. Temiz kod, iyi yazılmış bir düzyazı gibidir. Temiz kod, asla tasarımcının niyetini gizlemez, daha çok berrak soyutlamalarla ve düz kontrol satırlarıyla doludur.

Dave Thomas (OTI Labs’ın kurucusu): Temiz kod, onu geliştiren yazılımcı dışında başka geliştiriciler tarafından da okunabilir ve iyileştirilebilir. Birim ve kabul testleri vardır. Anlamlı isimlendirmeleri vardır. Bir şeyin yapılması için tek bir yol vardır. Çok az bağlılığı vardır ve temiz bir API sağlar.

Michael Feathers (Working Effectively with Legacy Code kitabının yazarı): Temiz kod için bildiğim birçok özelliği sıralayabilirim; ancak bir tanesi diğer tüm özellikleri kapsıyor. Temiz kod her zaman ona değer veren biri tarafından yazılmış gibi görünür.

Peki Robert C. Martin olarak ben ne düşünüyorum? Bu kitap size tam da bunu anlatacak; bir değişken, sınıf ya da metod adının temiz olabilmesi için ne düşündüğümü yazacağım. Elbette bu kitaptaki önermelerin çoğu tartışmaya açık. Büyük ihtimalle bazılarına katılmayacaksınız, bazılarına şiddetle karşı çıkacaksınız. Sorun değil. Sadece şunu bilmelisiniz ki, bu yöntemleri onlarca yıllık tecrübeler sonucunda, birçok deneme ve yanılmamalarla öğrendim.


İlk cümlesinden itibaren yeni bakış açıları edinmemi sağlayan bu kitabı okurken aldığım notları sizlerle paylaşmasam edemezdim:

“Bu kitabı iki sebepten ötürü okuyorum: ilki yazılımcıyım, ikincisi daha iyi bir yazılımcı olmak istiyorum. Siz de buraya kadar okuduğunuza göre benimle aynı saftasınız. Güzel, çünkü hepimizin daha iyi takım arkadaşlarına ihtiyacı var.”

https://medium.com/t%C3%BCrkiye/clean-code-kitabindan-notlar-1-temiz-kod-derken-44e6f7a27eb0

Yazılımcı Olmak İsteyenlere!

  • Yazılımcı olmak istiyorum. Ne yapmalıyım?
  • Bazı internet projelerim var, onları hayata geçirmek istiyorum. Nereden başlamalıyım?
  • Programlama öğrenmeyi çok istiyorum. Hangi dille programlamalıyım?
  • Yazılım mühendisi olmak istiyorum. Henüz lisedeyim, şimdiden nasıl hazırlanabilirim?
  • Başka bir sektörde çalışıyorum. Yazılımcı olmak istiyorum. Nasıl bir yol izlemeliyim?

Açıkçası son dönemde daha sıkça karşılaştığım bu tür sorulara yanıt olarak net bir yazı yayınlamamış olduğumu fark ettim ve o yüzden bu yazıyı yazmaya koyuldum.
İlk olarak belirli terimleri oturtmaya çalışalım istiyorum. Nedir bunlar?

– Web programcısı
– Yazılımcı
– Programcı
– Veritabanı yöneticisi
– Veritabanı programcısı
– Analist
– Yazılım mimarı
– Proje yöneticisi
– …

Bence başlamadan önce ilk olarak bunları kafamızda oturtmalıyız. Çok bilinen bir mühendislik alanından örnekleyerek anlatacağım, bire bir örtüşmeler olmayacak ama yine de sektörün dışındakiler için daha aydınlatıcı olur diye düşünüyorum.

Yazılımı bir mühendislik olarak düşündüğünüzde, bu inşaat mühendisliği gibidir. Bina, köprü, tesis birçok farklı şey inşa edebilirler. Ama bu işi tek başına inşaat mühendisi yapmaz. Bir alışveriş merkezi yapılacağını düşünün. Projenin çizimi, çalışanların yemek ve yatacak yerlerinin sağlanması, temel atma, sıva, tuğla örme, boya/badana, su tesisatı, vb. Ne kadar farklı ustalık/uzmanlık alanları var değil mi?

İşte yazılım mühendisliği de böyle bir alan. Henüz inşaat mühendisliği kadar taşlar yerine oturmuş değil. Ama yazılım dendiğinde ya da yazılımcı dendiğinde asıl büyük resim yukarıda anlattığım çaptadır. Siz olaya sadece kod yazan yazılımcı açısından bakarsanız, bu inşaattaki sıva ustası, ya da katları atan ustayla eşleşebilir belki…

Bu durumdan varacağımız sonuç; yazılım mühendisliği programlamadan çok çok daha büyük bir şeydir. Bununla ilgili https://www.chip.com.tr/blog/kadi … rme-Sureci_524.html bağlantısındaki “Yazılım Geliştirme Süreci” isimli yazımdan biraz daha ayrıntı öğrenebilirsiniz. Yazılım mühendisliğine daha tanımsal bir bakış içinse “Yazılım Mühendisliği Nedir?” başlıklı yazımda, https://www.chip.com.tr/blog/kadi … igi-Nedir_1488.html bağlantısına bir göz atın.

Şimdi gelelim asıl konuya: Nereden başlamalısınız?

Nereden ve nasıl başlayacağınızı, neyi hedeflediğiniz belirleyecektir. Siz eğer bir kariyer meslek olarak, “birinci ligde” bir yazılım mühendisi olmak istiyorsanız yolunuz farklı; hobi olarak programlama yapmak istiyorsanız yolunuz farklı olacaktır.
Öncelikle hedefinizi; ne olmak, ne yapmak istediğinizi belirleyin.
Diyelim ki ne olmak, ne yapmak istediğinizi belirlediniz. Şimdi aşağıdaki reçetelerden size uygun olanını seçin. Unutmayın, bunlar başlangıç reçeteleridir.

***

A – Bazı projelerim var, bunları hayata geçirmek istiyorum:
Eğer bir internet projeniz ya da sektörel çözüm fikriniz varsa bunu hayata geçirmek için yazılım öğrenmek, kafanızdaki evi hayata geçirmek için inşaatçılığı öğrenmekten farklı olmaz. Hem sıvacı hem boyacı, hem su hem elektrik tesisatçısı, hem iç mimar hem mimar hem çeşitli hesaplamalar için mühendis, hem marangoz ve hem vb. olmanız gerekecektir.

İlk bakışta sadece bir programlama dili öğrenmek gibi duran yapılacak işler listenize, hemen aklıma gelen birkaç başlıkla yardımcı olayım.

–        Herhangi bir programlama dilinde uzmanlık
–        Veri tabanı tasarımı ve programlama
–        Veri tabanı yönetimi
–        Kullanıcı arayüzü (web grafik arayüzü) tasarımı
–        Web programlama (bu herhangi bir dilde programlamayı bilmekten farklıdır)
–        Web sunucu yönetimi
–        Yazılım mimarlığı
–        Sistem/yazılım analistliği
–        Test uzmanlığı
–        Teknik doküman yazarlığı
–        …

Açıkçası bu liste uzar gider.

Benim bu şıktakiler için önerim, siz nasıl bir proje olması gerektiğine odaklanın. Yazılım mühendisliğiyle ilgili temel kavramları öğrenin. Özellikle yazılım isterleri alanında kendinizi geliştirin ve bırakın gerisini sizin için uzmanlar yapsın. İnanın böylesi daha ucuza mal olur ve daha kısa sürede biter.

Sizin için önerim yazılım mühendisliği kitaplarını okumanız. Burada yazılımın gerçekte ne olduğu hakkında genel bir kavrayış edinirsiniz. Daha sonra yazılım kalitesi ve yazılım isterleri üzerine biraz daha vakit harcayın. Sonra asıl zaman ve enerjinizi projenizi gerçekleştirecek iyi bir yazılım ekibi bulmaya ve onlarla çalışmaya ayırın.

“Arada hasta olduğunuzda kendi reçetenizi kendiniz yazasınız diye gidip de tıp okumayın!”

B – Başka bir alanda eğitim aldım ve şu an yazılım dışında bir sektördeyim. Ancak yazılımcı olmak istiyorum.
Özel sektörde bilişim akademilerindeki on yıllık tecrübem esnasında çok net olarak gözlemlediğim bir durumdur bu. Birçok arkadaşın başarıyla yazılımcı olduğuna şahit oldum. Hatta bazıları ortalama bir yazılımcının ötesine geçip, yazılım alanında danışmanlık ve eğitmenlik yapmaya kadar ilerlediler. Sektörde işverenler tabii ki eğitiminize ve diplomanıza bakıyorlar. Ancak kendinizi gerçekten yeterince iyi yetiştirirseniz, gerekli sertifikasyonla da bilginizi belgelerseniz diploma pek de sorun olmuyor. En azından sektörde kendinize yer bulabiliyorsunuz. Bu konuda sektörde isim yapmış birçok insan tanıyorum.

Yani isterseniz, yaparsınız!

Eğer böyle bir düşünceniz var ve yolun çok çok başındaysanız, henüz hiçbir şey yapmadıysanız size önerim şudur: Kendinizi test edin.

Başlangıç seviyesindekiler için yazılmış programlama kitaplarından birini alın ya da internetten adım adım anlatılmış örnek program makaleleri bulun. En kolay öğrenilebilecek programlama dillerinden olduğu için Visual Basic iyi bir tercih olabilir. Sonra bunu uygulamaya çalışın. Zor bir başlangıçtır, ama eğer yılmaz ve ilerleme gösterirseniz bu bir işarettir. Yazılımcılık eğer hasbelkader bu konuda lise, meslek yüksekokulu ya da üniversite okumadıysanız (tesadüfen kazanılmış ya da başlanmış olmasını kastediyorum) sevmeden yapılacak bir iş değildir.

Bu dediğimi test etmenin daha kolay bir yolu, eğer yaşadığınız yerde bilişim akademileri varsa bunların tanıtım eğitimlerine katılmaktır.

Eğer yapabileceğinizi düşünüyorsanız bundan sonrası ne kadar zaman ve para ayırabildiğinizle ilgilidir. Ne hızlı ve kesin çözüm sertifikalı bir eğitim merkezinde bu işin ustalarından eğitim almaktır. Eğer böyle bir imkanınız varsa çevrenizdeki yetkili eğitim merkezlerine gidin, programlarını inceleyin, hocalarıyla tanışın. Derslerine misafir olarak katılın. Ödeme şartlarına bakın. Sizin için uygun olanını seçin.

Tabii bu aşamada aynı zamanda sizin hangi dilde ya da teknolojide uzmanlaşacağınız hakkında da karar vermeniz gerekecektir. Yazılımcı olmak istemenizin nedeni bu işten para kazanmak olduğu için, hangi dili seçeceğinizi de sektör belirleyecektir.  Şu an piyasaya bakarsanız en çok aranan yazılımcılar Java ya da C Sharp bilenler. Yani karşınızda iki temel alternatif var: Microsoft teknolojileri ve açları ya da Sun teknolojileri ve araçları. İkisinin de sektörde farklı yerleri var. Seçim sizin.

Bir kere tarafınızı seçtikten sonra bu hep orada kalmanız gerekecek anlamına gelmiyor. Ama mümkün olduğu kadar bir tarafta kalmak uzmanlığınızı daha kısa sürede belirli bir seviyeye taşıyacaktır.

Eğer kursa gidemiyorsanız iş size kaldı demektir. Kitaplar ve internet kaynaklarıyla kendinizi geliştirmelisiniz. Bir kitapçıya gidin ve size okunması ve anlaşılması en kolay gelen kitaptan başlayın. Bitirdiğinizde her şeyi anlamış olmanız gerekmez. Ama bir şeyler yapıyor olmalısınız.

Yazılımla ilgili mümkün olduğunca yazıları ve blogları takip edin. Bu sizin yazılım alanındaki görüşünüzü zenginleştirecektir. Vaktiniz oldukça hem programlama hem de genel olarak yazılım mühendisliği konularında kendinizi geliştirin.
Başlangıç için bu blogdaki “Kaynak Kitaplar” https://www.chip.com.tr/blog/kadi … -Kitaplar_1480.html  ve “Çevrimiçi Kaynaklar” https://www.chip.com.tr/blog/kadi … Kaynaklar_1368.html bağlantılarına bakabilirsiniz.

Bu gruptakiler için en önemli konu: mutlaka ama mutlaka sürekli olarak uygulama geliştirin!
“Merhaba Dünya “ ile başlayın ve her seferinde yeni öğrendiğiniz bir şeyleri uygulayarak yeni uygulamalar geliştirin. Programlamayı öğrenmenin en iyi yolu programlama yapmaktır.
Ödülü bir yazılımcıdan (ki şimdilerde aynı zamanda bir yazılımevi sahibi) “İyi Bir Yazılımcı Olmanın Reçetesi” için https://www.chip.com.tr/blog/kadi … -Recetesi_1322.html bağlantısına bakabilirsiniz.

C – Hobi olarak programlama yapmak istiyorum.
Size de önerim öncelikle kendinizi test etmeniz yönündedir. B grubundakiler için yazdığım ilgili paragrafa bir göz atın. Eğer testte başarılı olursanız yolunuz açık demektir.

Siz bu işi zevk olarak yapacağınız için, sizin şartlarınız B grubundakilerden farklıdır. Zevk için herhangi bir programlama dili seçebilirsiniz. İstediğiniz zaman çalışır istediğiniz zaman bırakırsınız. Ama bilin ki yabancı diller gibi programlama dilleri de nankördür. Eğer sürekli kodlamazsınız, çok çabuk unutursunuz.
Sizler için önerim kolay dillerle ilerlemeniz yönünde olacaktır. Visual Basic bu konudaki en iyi seçimlerden biridir.  Belki çok yoğun olmayan bir yazılım kursu ya da kitaplar ve internet kedinizi geliştirmeniz için kullanabileceğiniz araçlar olarak düşünülebilir.

Ne yapmak istediğiniz tam olarak netleştirmek için bir eğitim merkezine gidin ya da yazılım alanından biriyle konuyu tartışın. Belki de yapmak istediğiniz şey yazılım geliştirmek değil de web tasarımcılığıdır. Aralarındaki ince çizgiler, kendinizi geliştirme sürecinde size gereksiz para ve zamana mal olabilir. Buna mutlaka dikkat edin.

D – Yazılım Okuyorum/Okuyacağım, mezun olup sektöre çıkana kadar bir şeyler yapmak istiyorum.
Meslek liseleri, yüksek okul ve üniversitelerde yazılım alanıyla ilgili eğitim alanlar doğal olarak yukarıdaki şıklardan daha şanslılar. Ama şunu bilin ki diploma tek başına hiçbir işe yaramayacaktır. En az B grubu kadar çaba göstermelisiniz.
Okul size teorik olarak birçok şey verir. Ama uygulama kısmında sizin ayrıca zaman harcamanız gerekecektir. Bol bol uygulama yapın. Öğrendiğiniz programlama dillerinde uygulamalar geliştirin, mühendislik konularını anlamaya çalışın ve patrik olarak nasıl kullanabileceğiniz üzerine çalışmalar yapın.

Siz de kendinize bir alan seçin (Örneğin: web programlama, Microsoft teknolojileri). Okul bunun dışında bir şeyler gösterse bile siz bu seçtiğiniz konuda kendinizi geliştirin. Böylece sektöre çıktığınızda hem güncel ve sektörde kolaylıkla iş bulabileceğiniz bir birikimle hem de okulda öğrendiklerinizin kattığı zenginlikle daha çok tercih edilir bir eleman olursunuz.

Size de “İyi Bir Yazılımcı Olmanın Reçetesi” başlıklı yazıyı okumanızı tavsiye ediyorum. Bunun dışında madem bu işin okullususunuz, mühendislik konusuna özellikle eğilin.
Siz de yolun daha çok başında olduğunuz için kendinize fazla yüklenmeyin. En basitinden başlayın. Ama mutlaka kodlayın. İş yapın.

***

Sonuç olarak yaptığınız ya da yapacağınız şeyin ne olduğunu anlamanız önemli. Yazılım Mühendisliği başlıklı yazıda kuş bakışı bir fotoğraf çekmeye çalıştım. Bunu okuduktan sonra işin programlamayla ilgili genel bakışı için de https://www.chip.com.tr/blog/kadi … sel-Bakis_1006.html bağlantısındaki “Programlamaya Bütünsel Bakış” yazısını okuyun. Bunlar size seçimlerinizi yapabilmeniz için gerekli olan bilgiyi sağlayacaktır.

Tabii ki yazılımcı olmak isteyen herkes için hedefi, birikimleri, arka planı farklı farklıdır ve bu kadar genellemeyle herkes için çözüm üretmek mümkün değildir. Ama en azından bir fikir oluşturabildiğimi düşünüyorum.

Yazılımcı olmak istiyorsanız ve aklınıza takılan sorularınız varsa bunları bu yazıya yorum olarak gönderin. Hepsine teker teker cevap vereceğimden emin olabilirsiniz.

Gerçekten istediğiniz bir hedefiniz olursa, başaramayacağınız hiçbir şey yoktur!

Hoşça kalın.
Kadir Çamoğlu
kadir.camoglu@hotmail. com

https://www.chip.com.tr/blog/kadircamoglu/Yazilimci-Olmak-isteyenlere_1754.html

Kim Senior Programcıdır?

İlk bakışta bir programcıyı senior yapan teknik bilgisidir. Yüksek seviyede teknik bilgiye sahip olmak için çok tecrübe sahibi olmak gerekir. Yüksek seviyede teknik bilgiye sahip bir şahsın senior olarak algılandığını düşünebiliriz. Lakin teknik bilgi senior olmanın sadece bir boyutudur. Senior mozaiğinin tamamlanması için birçok parçanın bir araya gelmesi gerekir.

Kendisini senior olarak tanımlayan birçok programcı gördüm. Benim açımdan bu programcıların çok büyük bir kısmı senior değil. Şu sebeplerden dolayı:

  • Üç ya da beş sene programcı olarak çalıştıktan sonra kıdem alma zorunluluğu varmış gibi kendine durup, dururken senior ünvanını uygun görürler. Böyle programcılar senior ünvanından en uzak olan programcı adaylarıdır.
  • Bir ya da birden fazla çatıyı (framework) iyi kullanabildiklerinden dolayı senior olduklarını düşünürler. Bu tip programcılar senior olma yolunda değil, daha ziyada uzman olma yolunda ilerlemektedirler.
  • Yıllarca programcı olarak çalışmış olmalarına rağmen ekibin parçası olmaktan acizdirler. Kendi dünyalarında yaşayıp, ekipten kopuk olarak çalışmaya devam ederler. İletişim kurmakta zorluk çekerler.
  • Çoğunun müşteriyle iletişimi yoktur ya da çok azdır. Müşterinin tam olarak ne istediğini bilmeden kod yazarlar. Müşterinin ne istediğini bilmediklerinden dolayı nerede durmaları gerektigini bilmezler. Onu da ekleyelim, bu da olsun derken gereksiz zaman ve para kaybına neden olan kod yazarlar.
  • Kitap okuyup, kendilerini devamlı geliştirmezler. Geçen yılların onları otomatik olarak senior yaptığını düşünürler. İlk sene bir şeyler öğrentikten sonra dokuz sene aynı şeyleri tekrar etmeyi on senelik tecrübe sahibi olmak olarak algılarlar. Bu onların açısından senior olmak için yeterlidir.
  • Test yazmayı zaman kaybı olarak görürler. Başlarını en çok ağrıtan durumun bu olduğunu anlamakta zorlanırlar.
  • Teknik olarak belki çok iyidirler ama detaylarda kaybolduklarından veya lüzumsuz şeylerle uğraşmayı sevdiklerinden gereğinden fazla kod yazarlar. Bu hem işverene zarar verir hem de müşteriyi daha çok memnun edecek bir netice ortaya koymaz.

Bu listeyi sayfalar dolduracak sekilde genişletmek zor değil. Benim senior olabilmek için iki kriterim var. Yukarıda saydığım durumları zaman içinde aşıp, senior olmak zor değil. Lakin aşağıda sıraladığım iki kriter olmadan senior olmak hemen hemen imkansız. Bu kriterler:

  • Programcının müşteri ile olan iletişimde ne kadar başarılı olduğu.
  • Programcının başarıyla kaç proje tamamladığı.

Program yazmak çok maliyetli bir iş. Yazılan her satır kod para demek. Eğer bu satır gereksiz bir satır ise, o zaman bu para pencereden dışarıya atılmış para demektir. Programcı yazdığı her satırın gerekli olup, olmadığını nasıl anlayabilir? Müşteriye ne istediğini sorarak. Müşterinin ne istediğini anlamadan yazdığı kodun gerekliliğini bilemez. Müşteri ne istediğini tam olarak ifade eder ya da etmek zorundadır. Ben şunu istiyorum dediği zaman, programcının müşterinin şu olarak ifade ettiği şeyi koda dökmesi gerekir. Bundan fazlası zarardır, maddi kayıptır. Ne yazık ki kendisini senior olarak gören birçok programcı müşterinin ne istediğini anlamadan oturup, günlerce, haftalarca ya da aylarca program yazabiliyor. Müşterinin ne istediğini tam olarak anlamadan kod yazan, senior programcı olamaz, çünkü kendisini işverenine karşı sorumlu olarak gören bir programcının gönlü kendi yaptığı hatanın ya da keyfi çalışmalarının parasal zarar olarak işverenine yansımasına razı gelmez. Senior programcı bu dengeleri hep kafasında kendisiyle birlikte taşıyan programcıdır.

Başarıyla birçok projeyi tamamlayarak sınır koymanın, sadece gerekeni yapmanın, müşteriyi memnun etmenin, işvereni mutlu etmenin ne demek olduğunu bilmeyen programcı senior ünvanını hak etmez. Başarıyla tamamlanan her proje programcıyı senior olma yolunda ilerlerken pekiştirir, tecrübelendirir. Başarıyla bir proje tamamlamak demek, müşterinin isteklerini tatmin eden bir ürün ortaya koymak demektir. Bu başarıyı birkaç kere tatmadan gerçek anlamda senior olmak çok güçtür ya da imkansızdır.

Senior olmayı bazıları sadece bilgi küpü olmak ve daha fazla maaş almak olarak tanımlıyor demiştim geçenlerde attığım bir tweetde. Senior olmayı sadece bilgili olmak ve fazla maaş almak gibi iki zayıf sıfat ile tanımlamaya kalkmak gerçek senior programcılarin hakkını yemek olur. Bu iki şey gerçek senior programcılar için çok öncelikli olmayan şeylerdir. Onlar müşteriyi dinlemeyi, onun isteklerini tatmin etmeyi yeğlerler.


EOF (End Of Fun)
Özcan Acar

 

http://www.kurumsaljava.com/2013/06/21/kim-senior-programcidir/