Java Günlüğüm
Yazılım, Java, BT, azıcık felsefe, biraz mizah...
  • Udemy Eğitimleri
  • Temiz Kod
  • Tasarım Kalıpları
  • Hakkımda
  • Arşiv
RSS
25 Ocak 2015

Temiz Kod Nasıl Yazılır? – Basitlik İlkesi – III

Akin Java, Yazılım Mühendisliği anlaşılır kod, basit kod, odaklı kod

Daha önceki iki yazıda, burada ve burada, basit kodun iki farklı özelliğinden bahsetmiştik. Basit kod, hem standarttır hem de odaklıdır demiştik. Standart kod, rahat okunur, anlaşılırdır, odaklı kod ise hem anlaşılırdır hem de kısadır demiştik. Bu noktada, basit kodun, kendimiz ve başkaları tarafından, zorluk çekmeden, rahatlıkla anlaşılabilecek kod olduğunu vurguluyoruz. Zaten kodun standart yapıda olması ve anlaşılır isimler içermesi, daha önce de belirttiğimiz gibi, basit kodun şekil şartıdır. Ama kodu aslen basit yapan şey, şekilden ziyade içeriğidir. İçerik şartı da odaklı olmasıdır, odaklı kod belli bir soyutlama seviyesinde, sadece bir şeyle ilgilenir, bir şeyi halleder, bundan dolayı zihni dağıtmaz ve rahat kavranır.

Odaklı kod denince benim aklıma, “efradını cami, ağyarını mani” olarak ifade edilen nefis Osmanlıca tabir geliyor. Bu söz aslen “tanım”ın tanımıdır. Tanım denen şey, bir şeyle alakalı en temel bileşenleri içermeli ama alakasız olan her şeyi de dışlamalıdır. Yazılım yapılarımız da “efradını cami, ağyarını mani” olmalıdır. Dolayısıyla odaklı koda, ekleyerek değil, çıkararak ulaşılır. Yani bir kod parçasını en odaklı hale getirmek için, önümüze geleni ona eklemeyi değil, onunla ilgili olmayan kısımları çıkarıp, sadece ona has kısımları bırakmamız gerekir. Bu kod parçası bazen bir framework, bazen bir kaç paketten oluşan bir bileşen (component), bazen bir paket, bazen bir sınıf ya da arayüz, bazen bir metot, bazen bir metottaki bir blok, bazen de bir satırdır. Odaklı olmanın, bu sayılan soyutlama seviyeleri için farklı anlamları vardır.

Odaklanmak, işin aslını içermek, asıl olmayan kısımlarını, yani eski deyişle fürüatını atmak olduğundan, kısaltıcıdır. Ben bu şekilde kodu kısaltmaya, budamak diyorum. Budamak, asıl anlamı itibariyle, bitkilerin daha sağlıklı büyümelerini sağlamak için hastalıklı, zayıf, kurumuş dallarının kesilmesine verilen isimdir. Mühendislik açısından ise budamak, yapılacak şeyi sadece ve sadece gerekli parçalarıyla yapmak, gereksiz olanları ise çıkarmak demektir. Basitlik, yukarıda da belirtildiği gibi, gelişi güzel budamayla değil, asıl olanı teferruattan, gerekli olanı gereksiz ve süsten ayırt ederek elde edilir. Yani odaklı koda, bir seferde değil, ancak süreç içinde budayarak ulaşabiliriz ki bu da refactoring dediğimiz iyileştirici çalışmanın bir parçasıdır.

Fransız yazar Antoine de Saint-Exupery‘ın şu sözü mükemmel olmanın en temel özelliği olan minimalliği, fazlalıklardan arınmış olmayı yani budanmışlığı çok güzel bir şekilde ifade etmektedir: “Mükemmellik, eklenecek bir şey olmadığında değil, çıkarılacak bir şey olmadığında başarılır.” (Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.)

Basitlik için gerekli olduğunu ifade ettiğimiz odaklılık ve nihayetinde kodun kısa olması öyle kolayca elde edilecek bir şey değildir. Meşhurdur, Pascal, “The Provincial Letters” isimli eserinin 16. mektubunda şöyle der: “Bu mektubu böyle uzun yapabildim çünkü kısa tutmak için zamanım yoktu.”  (“I have only made this letter longer because I have not had the time to make it shorter.”).

Benzer şeyleri ben de hayatımda sıklıkla yaşıyorum. Örneğin zaman zaman danışmanlık verdiğim yerlerde benden, üst yönetime sunmak için rapor isteniyor. Ben, 2 ay çalıştığım bir yerde, gördüğüm sıkıntıları ve çözüm önerilerini, kendileriyle irtibatta olduğum çalışanlara 20-30 sayfa olarak, hatta istenen detay seviyesine bağlı olarak, daha geniş bir şekilde sunabilirim. Fakat bu kişiler benden, üst yönetimlerine sunmak üzere bir rapor istediklerinde, farklı bir anlayış ve yapıyla, çok daha odaklı ve kısa olan bir rapor yazmam gerektiğini düşünürüm. Bu şekilde bir raporu yazdığımda çoğu zaman ilk seferde üç sayfanın altına düşemem. Sonrasında, muhtemelen üzerinden iki defa daha geçerim ve her geçişte pek çok detayı atarım, cümlelerimi daha odaklı hale getiririm ve raporu gittikçe kısaltıp, 1 sayfa civarına indiririm. İşte bahsettiğim budamak budur.

Bu durumu kod açısından ifade etmek gerekirse, sadece kod yazmaya odaklandığımızda hiç bir zaman ilk ve bir seferde basit kod yazamayız. Basit kod yazmak için düşünmek gereklidir. Kod ancak, gereklilikleri çok iyi anlaşıldığında ve çözümü üzerine kafa patlatıldığında basit yazılabilir. Ne olması gerektiği iyi bir şekilde kavranmamışsa ne sağlıklı bir çözüm bulunabilir ve tasarım yapılabilir ne de odaklı olarak kodlanabilir.

Bir önceki yazıda verdiğim “login” metodu örneğine geri dönelim. Muhtemelen bu metodun en uzun hali, bir seferde yazılmamıştır. O metodun orijinal halinde muhtemelen sadece müşteriyi getirmek ve sonra da password kontrolü yapmak vardır. Yeni iş süreçleri ve kuralları keşfedildikçe, “login” süreci ve ilgili iş kuralları bu metoda eklenmeye başlamış ve bu yüzden metot 3-4 farklı işi yapar hale gelmiştir. Budamak ise, yeni iş kurallarını sisteme kazandırırken, metoda yeni bloklar ve if cümleleri eklemek yerine, metodun odağının kaybolması tehlikesinden dolayı, metodu bölmektir. Bu anlamda yazılımlar, satır sayısı olarak artar ve büyürken, metot, tip vs. soyutlamaları açısından da zenginleşmelidir ki soyutlamalar makul karmaşıklıkta kalsınlar. Burada konuda, “Yazılım Nasıl Geliştirilir? Ekleyerek mi Çıkararak mı?” başlıklı yazıya bakabilirsiniz.

Kodu kısa yazmak demek, şekil açısından kısaltmak demek değildir. Kodu kısa yazmak demek, yukarıda da anlatıldığı gibi odaklanmak demektir. Yoksa örneğin, bir sürü operatör kullanarak, anlaşılmayı zorlaştıracak şekilde karmaşık bir iş bir satırda yapılıyorsa, kısa kod yazmaktan kasıt yanlış anlaşılmış demektir. Bakın, aşağıdaki kod parçası kısadır ama anlaşılır değildir, çünkü odaklı değildir:

double rs = a + ++b * c/a * b;

Bu kod kısadır ama odaklı olduğundan kısaltılmış bir kod değil, işgüzarlıktan kısaltılmış bir koddur. Bu koddaki problem, sonucun ancak operatör önceliğiyle belirlenecek olması ve dahası “++” operatörünün en öncelikli olmasından dolayı “b”nin bir artması ve nihayetinde ifadenin en sağındaki “b”nin de yeni değeriyle işleme katılacak olmasıdır. Yani a = 5, b = 6 ve c = 10 değerleriyle rs, 103 değerini alacaktır. Lakin pek çok programcı “rs”nin alacağı değerle ilgili yanlış hesap yapabilir. Örneğin ilk “b”nin artıştan sonra 7 olmasına karşın ikinci “b” hala 6 olarak hesaba katılabilir. Bu gibi hatalara yol açacak şekilde kısaltılmış olan kod sadece ve sadece anlaşılmayı zorlaştırır. Çünkü kod, odaklı değildir. Bu kod odaklı olarak yazılacak olsa şöyle olurdu:

double rs = 0.0;
{
   b++;
   double d = c / a;
   rs = a + (b * d * b);
}

Odaklanma açısından bu kodun yukarıdaki tek satırlık halinden ne farkı vardır? “rs”nin hesaplanması, bu haliyle bir satırda odaklı olarak yapılabilecek bir şey değildir. Bu hesap tek satırda yapıldığında, “b”yi arttırmak, “c/a”yı hesaplamak ve nihayetinde “rs”yi hesaplamak şeklinde atomik olarak yapılması en iyi olacak üç farklı işlemi, tek satıra sığdırmış oluyor. Aslen bu kod en iyi şekilde, bir blokta halledilebilir. Bu yüzden yukarıdaki ikinci hal, yani bloklu hal, tek satırlık haline göre daha uzun ama anlaşılırdır, çünkü odak problemi yoktur.

(Bu noktada “++b” paranteze alınır diye itiraz edilebilir ama bu durum ikinci “b”nin değerindeki karmaşayı gidermez. Ya da “++b” yerine (b+1) olsaydı yine bu şekilde blok olarak mı yazmak gerekirdi diye sorulabilir. Bu durumda da blok olarak yazmak daha rahat olurdu ama yazılmasa da ikinci “b”nin değeriyle ilgili sıkıntı çıkmazdı, çünkü “++b” ile “b+1” farklı şeylerdir, ilki b’nin değerini arttırırken, ikincisi “b”nin değerini değiştirmez.)

Dolayısıyla her odaklı kod kısadır ama her kısa kod odaklı değildir. Ve asıl amaç odaklılıktır, kısalık ise sonuçtur.

Yukarıdaki anlamda basitlik ve  küçüklük çoğu zaman ya çok çalışmayla ya da dahilik ile ortaya çıkar. Çok çalışma, tecrübedir. Dahiliğin ise hem doğuştan gelmesi hem de çalışarak elde edilmesi söz konusudur. Matematiksel bir örnek vermek istersek, bir sayıya kadar olan asal sayıları bulmak için o sayıya kadar olan her tek sayının asal olup olmadığına bakmak, biraz matematikten anlayan herkesin yapabileceği türden bir işlemdir. Ama bu şekilde bulunabilecek olan yöntemler, dahilerin bulduklarından kesinlikle daha uzun ve karmaşıktır. Örneğin, Eratosthenes’in ortaya koyduğu algoritma (http://en.wikipedia.org/wiki/Sieve_of_Eratosthenes) ile bir sayıya kadar olan asal sayıları bulmak, dahiliktir. Unutmayalım ki dahi doğmasak bile çok çalışarak dahi olabiliriz.

Özetlersek, basit kod yazmak sanıldığı kadar basit değildir. Basit kod, standart ve odaklıdır. Bundan dolayı kod anlaşılır ve kısa olur. Programcı daima yazdığı kod hakkında “en basiti bu mudur?” diye sormalıdır. Basit kod yazabilecek kadar iyi programcı olabilmek dileğiyle…

Toplam görüntülenme sayısı: 1060

9 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
24 Ocak 2015

Temiz Kod Nasıl Yazılır? – Basitlik İlkesi – II

Akin Java, Yazılım Mühendisliği Ö, odaklı, single responsibility

Bir önceki yazıda ele aldığımız basit kodun özelliklerine devam edelim.

Basit kodun en temel özelliği odaklı olmasıdır. Ancak sadece bir kavramı, bir işi, bir ihtiyacı halletmeye odaklanan kodlar anlaşılır olur. Bir kod ne kadar fazla şeyi bir arada halletmeye kalkıyorsa o derece anlaşılmaz olacaktır. Odaklanmak hem anlaşılır hem de kısa kodun dolayısıyla da basit kodun en temel özelliklerindendir. Odaklanmanın kendisi de odaklanılacak bir kavram olduğundan, örneğin “bir satırda neye odaklanılır”, “bir sınıfta neye odaklanılır” gibi soruları etraflıca ele almak gerektiğinden, odaklanmanın detayları sonraki yazılarda ele alınacaktır.

Basit yazılan kodun diğer özelliği olan kısa olmasıdır. Kısa kod için şu iki şeye dikkat etmek gereklidir: Odaklanmak ve budamak.

Öncelikle kısa kod, ancak içeriğinden dolayı kısadır. Yani kod ancak küçük bir şeyi ya da bir seferde sadece bir şeyi hedefliyorsa kısa olur. Kısa kod ancak hem yapılan işin küçük olması hem de bu küçük işin kısa bir şekilde yapılmasıyla mümkün olur. Yapılacak işi ne kadar küçük seviyede tutulabilirse, yazılacak kod da o kadar kısa olacaktır. Yapılacak iş ne kadar büyük ve geniş tutulursa, kodda o kadar çok şey yapılır, bu da odaklanma prensibine terstir. Burada bahsedilen “şey” ve “iş” kavramları ise nihayetinde sorumluluklardır ve odaklanmaktan kasıt da “tek sorumluluk” (single responsibility) prensibidir.

Odaklanma olmadan kısa ve anlaşılır kod yazılamaz, uzun kod yazılır, çok kod yazılır, iç-içe geçmiş, çorba kod yazılır, dolayısıyla karmaşık kod yazılır, basit kod yazılamaz.

Örneğin aşağıdaki arayüzü odaklı olarak nasıl gerçekleştirelim?

public void login(String tckn, String password) throws 
   NoSuchCustomerException,CustomerAlreadyLoggedException, 
   WrongCustomerCredentialsException, 
   MaxNumberOfFailedLoggingAttemptExceededException, 
   CustomerLockedException;

Yukarıdaki metodun arayüzündeki sıra dışı durumlardan da anlaşıldığı gibi, aslında bu metotta bir kaç farklı şey kontrol edilmekte ve bu kontrollerin hepsi olumlu sonuçlanırsa, hiç sıra dışı durum nesnesi fırlatılmayacağından, metot başarılı bir şekilde sonlanacaktır. Dolayısıyla bu metot aşağıdaki gibi yazılabilir:

public void login(String tckn, String password) throws NoSuchCustomerException, 
                  CustomerLockedException, CustomerAlreadyLoggedException,  
                  WrongCustomerCredentialsException,   
                  MaxNumberOfFailedLoggingAttemptExceededException {
    Customer customer = customerDao.retrieveCustomer(tckn);
 
    // If passwords match, customer hasn't already been locked nor logged in
    // Customer loggs in and it is now currentCustomer
    if (customer.getPassword().equals(password) & 
                           !customer.isLocked() & !customer.isLoggedIn()) {
        // Database is updated when a customer logs in.
        customer.setLoggedIn(true);
        if (customerDao.updateCustomer(customer))
        currentCustomer = customer;
        loginAttemptCount = 0;
    } else if (customer.isLoggedIn()) {
        throw new CustomerAlreadyLoggedException("Customer is already logged in. 
                                                  Please first log out.");
    } else if (customer.isLocked()) {
        throw new CustomerLockedException("Customer is locked. 
                                           Please consult your admin.");
    } else if (!customer.getPassword().equals(password)) {
        loginAttemptCount++;
        if (loginAttemptCount == Integer.parseInt(ATMProperties.getProperty(
                                                  "customer.maxFailedLoginAttempt"))) {
            customer.setLocked(true);
            customerDao.updateCustomer(customer);
            throw new MaxNumberOfFailedLoggingAttemptExceededException("Max number of 
                                                              login attempt reached: "
                                                              + loginAttemptCount);
        }
        throw new WrongCustomerCredentialsException("TCKN/password is wrong.");
    }
}

Peki sizce bu kod odaklı mıdır? Yani “login” metodu, sadece bir şeyi mi hallediyor? Aslında bakarsanız bir şeyi hallediyor, müşterinin login olmasını. Ama belli ki bu üst seviye bir sorumluluk ve alt seviyede müşterinin bulunup getirilmesi, kilitli (locked) veya zaten sistemde (logged in) olup olmadığının belirlenmesi, passwordünün uygunluğunun kontrol edilmesi ve eğer yanlış password girilmiş ve bu şekilde yanlış password girme sayısı, belirli bir değeri aşmışsa, müşterinin kilitlenmesi (locked) sorumluluklarını içermektedir. Bu durumda aslolan şey, tüm bu alt sorumlulukların ayrı metotlarda ifade edilmesidir. Çünkü, bu alt sorumlulukların her birisi, sistemde farklı yerlerde tekrar tekrar ihtiyaç duyulabilecek ve bu yüzden metotları çağrılabilecektir. Dolayısıyla bu haliyle “login” metodunun yukarıdaki gerçekleştirilmesi, odaklı değildir, “tek sorumluluk” prensibine uygun değildir.

Yukarıdaki kodun bir diğer problemi ise, ayrık olması gereken sorumlulukları bir araya getirdiği için, copy-paste yardımıyla, tekrarlı kod yazmayı teşvik ediyor olmasıdır. Örneğin, sisteme bir başka yerde ihtiyaç duyulacak ve örneğin müşterinin kilitli olup-olmadığını kontrol eden kod, buradan copy-paste ile alınarak çoğaltılacaktır.

Bakın aşağıdaki kod ise, aynı metodun farklı sorumlulukları, farklı metotlarla halleden şeklidir ve bu yüzden herşey daha odaklıdır ve sorumluluk sahibidir.

public void checkIfCustomerAlreadyLoggedIn(Customer customer) throws CustomerAlreadyLoggedException {
    if (customer.isLoggedIn()) {
        throw new CustomerAlreadyLoggedException("Customer is already logged in. 
                                                  Please first log out.");
    }
}
public void checkIfCustomerLocked(Customer customer) throws CustomerLockedException {
    if (customer.isLocked()) {
        throw new CustomerLockedException("Customer is locked. Please consult your admin.");
    }
}
public void checkCustomerPassword(Customer customer, String password) throws 
        MaxNumberOfFailedLoggingAttemptExceededException, WrongCustomerCredentialsException {
    if (!customer.getPassword().equals(password)) {
        loginAttemptCount++;
        checkLoginAttempCount(customer);
        throw new WrongCustomerCredentialsException("Wrong password!");
    }
}
public void checkLoginAttempCount(Customer customer) throws 
                                            MaxNumberOfFailedLoggingAttemptExceededException{
    if (loginAttemptCount == Integer.parseInt(ATMProperties.getProperty(
                                                           "customer.maxFailedLoginAttempt"))) {
        lockCustomer(customer);
    }
}
public void lockCustomer(Customer customer) throws MaxNumberOfFailedLoggingAttemptExceededException{
    customer.setLocked(true);
    throw new MaxNumberOfFailedLoggingAttemptExceededException("Max number of login 
                                                                attempt reached: "
                                                                + loginAttemptCount);
}
private void loginCustomer(Customer customer, String password) throws  
   CustomerAlreadyLoggedException, 
   WrongCustomerCredentialsException, 
   MaxNumberOfFailedLoggingAttemptExceededException, 
   CustomerLockedException{
		
      boolean login = false;
      checkIfCustomerAlreadyLoggedIn(customer);
      checkIfCustomerLocked(customer);
      checkCustomerPassword(customer, password);
      customerDao.updateCustomer(customer);
}

Bu şekilde sorumluluklar, ayrı metotlarda ifade edildikten sonra gerçekleştirdiğimiz metot, sadece bu alt sorumlulukları çağırır:

public void login(String tckn, String password) throws 
   NoSuchCustomerException, CustomerAlreadyLoggedException, 
   WrongCustomerCredentialsException, 
   MaxNumberOfFailedLoggingAttemptExceededException, 
   CustomerLockedException{

      Customer customer = customerDao.retrieveCustomer(tckn);
      loginCustomer(customer, password);
}

Odaklı kod yazmak, tek sorumluluk prensibine uymaktır demiştir. Bu da sorumlulukları önce bulmak sonra da ayırmakla olur. Bu anlamda, metot seviyesini düşündüğümüzde, daha alt parçalara bölünemeyecek ve sistemde tekrar tekrar kullanılacak her sorumluluk bir metotta halledilmelidir.

Yukarıdaki örnekten de açıkça görüldüğü gibi, kısa kod ancak ve ancak odaklanmakla yazılır. Bu anlamda esas amaç kısa kod değildir, odaklı koddur. Odaklı kod her halukarda kısa olma eğilimindedir. Odaklanmadan kısa kod yazmaya çalışmak, kodu okunmaz ve anlaşılmaz hale getirir. Kod, sorumluluklar tabanında bölünmeli ve yazılmalıdır.

Sınıf seviyesindeki sorumlulukların en temel olanları ise örneğin GOF’un tasarım kalıpları ile belirlenmiştir. Örneğin bu yazıda bu sorumluluklardan bazıları kısaca ifade edilmiştir. Dolayısıyla tasarım kalıplarını bilmeden sorumlulukları bulup dağıtmaya çalışmak, hem zordur hem de tekerleği tekrardan keşfetmeye çalışmaktır.

Bir sonraki yazıda budamayı ele alalım.

Son derece odaklı kodlar dilerim 🙂

Toplam görüntülenme sayısı: 1113

6 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
17 Ocak 2015

Nitelikli Eleman Açığı mı Niteliksiz Yönetici Fazlası mı?

Akin BT, Yazılım Mühendisliği Yasad, Yazılım Sanayicileri Derneği

Sosyal mekanlarda gezinirken “Yazılım Sektörünün En Önemli Sorunu Nitelikli Eleman Açığı” başlıklı bir yazı gördüm. Aslında sık sık gördüğümüz, ezberlenmiş türden başlıklardan birisi. Nedense bu sefer farklı geldi bana ve bu yazıyı yazmaktan kendimi alıkoyamadım. Bu tür açıklamalarda sık sık BT sektöründeki sivil toplum kuruluşları öne çıkıyor. Bu haberde de Yazılım Sanayicileri Derneği‘nin (Yasad) adı geçiyordu. Bu haberi Yasad’ın sayfasında da görmek mümkün.

Bu ülkedeki yazılım sektöründeki patronların ve yöneticilerin bir araya gelip dernekler oluşturmaları ve sektörü geliştirme amaçlı faaliyetlerde bulunmaları, devleti bu konuda yönlendirmeleri güzel bir şey. Her devlet gibi bizim devletimizin de bu tür danışmanlıklara ihtiyacı var. Ama ya bu yönlendirmeyi yapanların kendilerinin yönlendirme ihtiyaçları varsa? Ya bu tür kuruluşlar, “sektörün yetişmiş nitelikli elemana ihtiyacı var” derken gerçek ihtiyacın nerede olduğunu ciddi bir şekilde atlayıp, yazılımda daha iyi durumda olan yabancıların sektör gazete ve dergilerinde gördükleri haberlerde ifade edilen problemlerinin aynısının bizde de olduğu vehmine kapılıyorlarsa? İşin açıkçası bunları yazarken “yazlılım sanayicisi”nin ne anlama geldiğine ve “eleman” kelimesine takılmamaya çalışıyorum, çünkü bu yazıyı kara mizah yapmak istemiyorum.

Yazılımın içinden birisi olarak ülkemizin en ciddi sorununun nitelikli eleman eksiği olduğuna katılmıyorum. Bu tür haberlerde, konuşmalarda geçen “eleman” kelimesiyle kastedilenin (“eleman” nitelendirmesiyle her ne kadar kelle sayısı hesabı yapan dolayısıyla da itici bir anlayışı yansıtsa da), üniversitelerden sektörümüze sunulan mezunlar olduğu açıktır. Denilen, üniversitelerden yeterince mezun gelmediği ve gelenlerin de ihtiyacı karşılamadığı iddiasıdır. Evet bu bir problem, üniversitelerden hem sayı hem de kalite olarak yeterli mezun çıkmıyor. Ama kendimizi kandırmayalım, problemin büyüğü bu değil, yani bence durum bundan daha vahim. Bakın “eleman açığı”ndan şikayet şu anlama geliyor: “Ülkemizdeki yazılım sektörünün başka problemleri olsa da en büyüğü eleman açığıdır. Yani sektör var olan elemanları düzgün bir şekilde değerlendiriyor, imkanlar elverdiğince iyi işler çıkarıyor ve daha çok yeni elemana ihtiyaç duyuyor. Dolayısıyla en büyük engelimiz eleman açığı, eleman sayımız yetse, siz görün bizi.” Tırnak içinde yazdığım bu düşünceyi ifade eden yine Yasad’ın sayfasındaki şu habere bakılabilir. Haberde sektörün eleman açığının giderilmesiyle uçuşa geçeceğimiz ifade ediliyor.

Bence yine kendimize kendimizin propagandasını yapıyoruz. Çok açık bir şey var, ülkemizdeki yazılım sektörü dişe dokunur bir şey geliştirmekten malesef uzak. Geliştirdiklerimiz kalite olarak son derece düşük, o yüzden dünya yazılım piyasasına sunulabilecek cinsten değil. Çünkü hala kahramanca savaşan yazılımcılara bağlı olarak iş yapıyoruz, süreç tabanlı yazılım geliştirmeden çok uzağız. Daha program ile yazılım arasındaki farkı kavrayabilmiş değiliz. Nasıl futbol oynuyorsak öyle yazılım geliştiriyoruz; ikisinin de en temel dinamiği kaos.

Yazılım sektörünün esas sorununun “eleman açığı” olduğunu söyleyerek, kayıp yüzüğünü, kaybettiği samanlıkta aramayıp, kapının önünde arayan ve neden böyle yaptığı sorulduğunda da “samanlık karanlık ama” diyen Nasrettin hocamızın tiye aldıklarından oluyoruz. Bence bu ülkenin yazılım sektöründeki en temel problem nitelikli eleman açığı değil, niteliksiz yönetici fazlasıdır! Var olan iş gücü potansiyelimizi bile değerlendirmekten uzağız, kaotik bir şekilde iş yapıyoruz, başarımız çoğunlukla şansa bağlı, enerjimizi ve zekamızı yanlış yerlere harcıyoruz. Ve bence bu durumun en başlıca sebebi, yazılım “elemanları” değil, yazılım yöneticileridir, karar vericileridir.

Kifayetsiz yazılım yöneticilerine sahip olmamızın bence iki sebebi vardır. İlki yazılım yöneticilerimizin bizatihi kendileri ile bir şekilde yazılım geliştirme süreçlerini yöneten ya da yön verenler (örneğin daha üst düzey “C” seviyesindeki yöneticiler), daha yazılımın ne olduğundan, tabiatından, süreçlerinden, rollerinden ve yetkinliklerinden vs. habersizler. Bu konuda en temel ayrımları bile bilmediklerine ben defalarca şahit olmuşumdur. Çünkü bu yöneticiler muhtemelen kariyerlerinin başında teknik pozisyonlarda bulunmuşlardır ama daha işlerinde ustalaşmadan yönetici oluvermişlerdir ya da daha doğru ifadeyle yapılıverilmişlerdir. Dolayısıyla henüz öğrenmedikleri bir işi yönetmeye çalışıyorlardır. Yani, tabii olarak gördüklerini uyguluyorlar. Örneğin, projelerdeki en temel problem çözme yöntemleri, fazla mesaidir. Çünkü onlar da fazla mesai ile projeleri kurtarmaya çalıştılar.

Mesleğinde yeterince olgunlaşmadan yönetici olmanın bir başka handikapı da, kendilerini yönetici yapanlara karşı çıkamama şeklinde kendini göstermektedir. Zaten kafasında henüz bir sistem oluşturacak, süreci baştan sona kavrayacak şekilde olgunlaşmamış durumda olduklarından, teknik kaliteyi öne çıkarmaları, iş yapış şekilleriyle ilgili bir yenilik yapmaları ve nihayetinde var olan düzeni değiştirmeleri, üstlerinin kararlarına karşı çıkabilmeleri mümkün değildir. Bundan dolayı bizim sektörümüzde orta düzey yönetici olmak, tokmağı başkasının elinde olan davulu sırtında taşımaktır.

Bu ülkenin, daha mesleğini öğrenmeden o mesleği yönetmeye çalışan yöneticileri var. Bu ülkenin daha 30’una gelmediği halde, hızını almış giderken, teknik olarak ilerlerken, yaptığından zevk alırken, programcılıktan tam işin mimari ve mühendislik kısımlarına atlamaya hazırlanan ya da ekran analistliğinden çıkıp sistem analistliğine doğru ilerleyen civa gibi gençlerini bulunduğu ortamdan aniden koparıp, “sen yöneticisin artık” diyen ve muhteşem mühendis adaylarını berbat yöneticilere dönüştüren bir kültürü var. O kadar çok arkadaşım var ki bu durumda olan. Hepsi çok iyi eğitim almışlar, mesleklerinin ilk 5-6-7, bilemediniz 10 yılında bu eğitimin üzerinde deli gibi bilgi ve tecrübe inşa etmişler. Bu arkadaşlarım ya da tanıdıklarım, tam mesleklerinde çıraklığı atıp, olgunluk çağlarına gelmişler, bundan dolayı da belki daha stratejik konulara ele atacaklar, iş yapış şekillerini düzeltecekler, kaliteyi arttırmaya odaklanacaklar ya da meşreplerine ve ilgilerine göre değişik konularda uzmanlaşacaklar, belki kimileri kitap yazacak, belki çok odaklı, niche, bir konuda bir gelişme sağlayacaklar ve hem ülke hem de insanlık adına bir katkıda bulunacaklar. Ama sektörün böyle insanlar yetiştirmek gibi bir derdi yok ki!  Hemen tüm bu şekilde gelişmeye çalışan arkadaşlarımın önü, daha yüksek maaşla yönetici yapılarak kesilmekte. Daha geçen gün bu şekildeki bir arkadaşım “ben bu ülke için bir kayıpım” dedi bana. Çünkü iyi bir mühendisken, sırf maddi ve sosyal şartlardan dolayı yönetici oluvermişti.

Kifayetsiz yöneticilere sahip olmamızın ikinci sebebi ise, bu yöneticilerin bu makama gelirken hatta geldikten sonra herhangi bir yöneticilik formasyonundan geçmemiş olmalarıdır. Genelde işini iyi yapan, iyi eğitim almış, zeki ve başarılı yazılımcılar, programcı olsun, analist olsun, 3-5 sene içinde bir şekilde yöneticiliğe tabii olarak geçerler. İyi mühendis, iyi programcı, iyi sistemci, iyi bir yönetici olmak için gerek sebep olabilir ama yeter sebep değildir. Yüksek empati yeteneğine sahip olmadan iyi bir sistemci olabilirsiniz, iyi bir organizatör olmadan iyi bir programcı olabilirsiniz, iyi bir arabulucu olmadan iyi bir tasarımcı olabilirsiniz ama bunlar olmadan iyi bir yönetici olamazsınız. Bu durumun benim sıklıkla gözlemlediğim, en açık göstergesi ise yazılım yöneticilerimizin ezici bir kısmının, senelerdir yöneticilik yapığı halde hala doğru detay seviyesinde bulunmayı beceremeleridir. Ya hala çok teknik davranırlar ve bu yüzden altında çalışan teknik insanlara güvenip iş teslim edemezler, bu yüzden de detayda boğulurlar, ya da işin sadece tarihleri ve maliyetiyle ilgilenirler ve üst yönetimin kararlarını altlarına uygulatmak dışında bir insiyatifleri yoktur. Her iki halde de başarılı olamazlar.

Yöneticilik, öğrenilebilir. Ama bir eğitim ve öğrenim sürecinden geçmeden bir şekilde yönetici olanlar ki buna ben de dahilim ve ne olduğunu çok iyi biliyorum, ancak hasbel kader yöneticilik yapabilirler. Yani sektörümüzdeki yöneticiler genel olarak, ne yazılımı ne de yönetimi bilmeyen insanlardır. Yöneticilik algısı ve yeteneği olanlar, uzun vadede başarılı yönetici olabilirler, örneğin hangi detayda kalacaklarını öğrenirler, teknik insanlarla nasıl konusacaklarını belirlemiş olurlar belki ama bu sırada kaç çalışan ve proje telef olur, bilinmez.

Bu ülkenin yazılım sektörünün tek sıkıntısı hakikatten üniversiteden sektöre akan mezunların sayısı olsaydı, örneğin onlara karşı da bu sektör “deneyimin yok ama” sendromunu yaşatmazdı ve bu ülkede çok daha farklı şeyler olurdu.

Ben de yöneticilik yaptım, sıkıntılarını iyi biliyorum. Bu ülkede orta düzey yazılım yöneticisi olmak çoğu zaman yukarıda da söylediğim gibi, tokmağı başkalarının elinde olan davulu taşımaktır. Sektörümüzde yönetici olmak çoğu zaman tetikçiliktir, üstte verilen kararların aşağıya uygulatılmasından sorumlu olmaktır, örneğin bitiş tarihini üstlerinin belirlediği projeyi, alttakilerin ensesinde boza pişirme pahasına bitirmektir. Dolayısıyla bence sektörümüzün sıkıntıları ne teknolojiktir, ne kişi sayısıyla ilgilidir ne de doğrudan maddidir; yoğun olarak kültüreldir. Teknik kaliteye önem vermeyen ve her şeyi insan manipulasyonu ile yapmaya çalışan zihniyetimizi değiştirmedikçe her ilçeye bir üniversite kursak bile, yazılım gibi yüksek soyutlama gerektiren disiplinlerde durum değişmeyecektir.

Toplam görüntülenme sayısı: 4199

42 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
15 Ocak 2015

İyi Programcı, Kötü Programcı

Akin Java, Yazılım Mühendisliği

Ben kendimi nihayetinde programcı olarak görme eğilimindeyim. İşin matematiksel, mühendislik, sanatsal vb. taraflarının hepsinden çok zevk alıyorum. Gerek algoritmik çözümlemeler, gerek üzerine tekrar tekrar düşünerek, daha da etkin hale getirdiğim kod yapısı, çalışma zamanı performansı, bu sırada hissettiğim estetik kaygılar vs. hepsi bana çok zevk veriyor.

Eskiden bu yana, değişik fırsatlarla, kendimi teyzeler, amcalar arasında buluyorum. (Açıkçası, artık çocuklarımın arkadaşları da bana amca diyorlar ama, o tarafa girmeyelim şimdilik 🙂 ) Memleketim Ayvalık’ta olsun, Anadolu’nun farklı yerlerinde olsun, İstanbul’da olsun, aile, eş-dost, akraba vs. ortamları kastediyorum. Eskiden böyle ortamlarda doktor ve avukat olmak problemliymiş, herkes derdini anlatırmış. Uzun zamandır bu mesleklere bizler de eklendik, herkesin bilgisayar vs. ile ilgili bir derdi var. 500-600 km araba sürüp, gittiğim misafirlikte modem-wireless tamiri yaptığımı biliyorum.

Neyse, bu amcalar ya da teyzeler benim yazılımcı ya da amiyane tabirle “programcı” olduğumu öğrendiklerinde, etraflarındaki, örneğin torunları, “programcı”lardan söz açıp, konuyu “o da seninle aynı işi yapıyor”a getirirler. “Eyvallah, çok güzel” diye cevap veririm ben de. Eskiden merak edip, “aaa öyle mi?” diye de saf saf sorardım. Sonra, 5-10 dakika sonra, o torun gelirdi: 17-18 yaşlarında, meraklı, radyoyu parçalayıp ondan bir çamaşır makinesi çıkarma ruhuna sahip, cevval ama eğitimsiz, örneğin orta okuldan terk ya da meslek lisesinde okuyan bir genç örneğin. Tanışırız, konuşuruz, o doğmadan önce benim Fortran ya da C ile uğraşmışlığımın olduğu ortaya çıkar örneğin. Bu işleri yurt dışında öğrenmiş olmam, ne bileyim Netscape tarayıcısının ya da Java’nın yayınlandığı günleri hatırlamam, büyük projelerde, GE gibi yerlerde çalışmış olmam, tecrübelerim, C# ile ilgili soru sorduğunda rahatça “bilmiyorum” demem, vs. vs. sonuçta, tüm bunlar o gençte bana karşı son derece yüksek bir saygı, imrenme vb. duygular oluşmasına sebep olur. Bunu rahatlıkla farkedersiniz.

Size bir sır vereyim mi? Yukarıda saydığım ve o gencin bende görüp de içini çektiği, imrendiği bu şeylerin hiç birisi beni ondan daha iyi bir programcı yapmaz. Yukarıdakilerin hiç birisine kanıp da siz de birisinin iyi programcı olduğuna karar vermeyin. Peki, nedir iyi programcıyla, kötü programcıyı birbirinden ayıran şey? EJBleri çok iyi bilmek mi? Ya da yüzlerce kişiden oluşan bir yazılım projesinin parçası olmak mı? Ya da C, C++, ya da Java’yı sular seller gibi bilmek mi? Örneğin yukarıda bahsettiğim genç ile bana bir algoritmik ödev verin, mesela pi’ye en hızlı şekilde ve en az bellek harcayarak yakınsamak ya da başka bir graf sorusu örneğin, muhtemelen ben daha hızlı ve güzel bir şekilde yaparım o ödevi. Ya da bir proje verin ikimize de, son derece basit, Fahrenheit-Celcius çevirisi yapacak bir web yapısı kurmamızı isteyin örneğin. Muhtemelen ben, o gencinkine göre çok daha sağlıklı bir mimari ve çok daha performanslı ve scalable olacak şekilde bu projeyi tamamlarım. Yani programlama faaliyetinin ister matematiksel ister mühendislik taraflarında muhtemelen ben çok daha iyi performans gösteririm. Ama yine de bunların hiç birisi beni ondan daha iyi programcı yapmaz. Bunların hiç birisi, birisinin diğerinden daha iyi programcı olduğunu göstermez.

Nedir peki iyi programcıyı, kötü programcıdan ayıran en temel şey? Çok basit bir cevabı var bu sorunun. İyi programcılar, yazdığı kodu her yönüyle anlarlar ve başkasının anlayacağı şekilde kod yazarlar. Kötü programcılar ise ne yazdığını her yönüyle anlamazlar, bırakın bir başkası, kendisi bile bir müddet sonra ne yazdığını zor çözer.

Yani kötü programcı şöyle kod yazar:

...
cardInfo.setIdNo(cardInfo.getTcCitizen() ?                               
 (formUtils.isNullOrEmptyString(verifyOtpWSResponse.getTckn()) ? 
  registrationForm.getTckn() : verifyOtpWSResponse.getTckn()):   
(formUtils.isNullOrEmptyString(verifyOtpWSResponse.getCustno())) ? 
  registrationForm.getTckn(): verifyOtpWSResponse.getCustno());
...

İyi programcı ise böyle kod yazar:

// Burada CardInfo’nun Idsi atanır. Id olarak eğer musteri TC vatandasi ise
// ve ya WS’den ya da fromdan gelen tckn atanır. Eğer müşteri TC vatandaşı
// değilse Id olarak customerNo alınır. 
// Burada da yine ya WS’den ya da formdan gelen customer no atanır.

String idNo = null;
Boolean isTcCitizen =  cardInfo.getTcCitizen();
String tcknFromForm = registrationForm.getTckn();
String tcknFromWS = verifyOtpWSResponse.getTckn();
boolean nullOrEmptyTcknFromWS  = formUtils.isNullOrEmptyString(tcknFromWS);
String custNoFromWS = verifyOtpWSResponse.getCustNo();
boolean nullOrEmptyCustNoFromWS  = formUtils.isNullOrEmptyString(custNoFromWS);
  
 if(isTcCitizen){
      if(nullOrEmptyTcknFromWS)
          idNo = tcknFromForm;
      else
          idNo = tcknFromWS;
 }
 else{
       if(nullOrEmptyCustNoFromWS)
          idNo = tcknFromForm;
      else
          idNo = custNoFromWS
 }
 cardInfo.setId(idNo);

Max Kanat-Alexander’ın Code Simplicity isimli kitabında dediği gibi:

İyi programcıyla kötü programcı arasındaki fark anlamadır. Yani kötü programcılar ne yaptıklarını anlamazlar, iyi programcılar ise anlarlar. İster inanın, ister inanmayın ama bu gerçekten bu kadar basittir.

(The difference between a bad programmer and a good programmer is understanding . That is, bad programmers don’t understand what they are doing, and good programmers do. Believe it or not, it really is that simple.)

Ya da Martin Fowler’ın, Refactoring isimli kitabında yazdığı gibi:

Herhangi bir insan bilgisayarın anlayabileceği kod yazabilir. İyi programcılar ise insanların anlayabileceği kod yazarlar.

(Any fool can write code that a computer can understand. Good programmers write code that humans can understand.)

Evet bu fark, hakikatten bu kadar basittir. Yukarıda bahsettiğim genç ile beni sınarken yaptığımız ödevleri bir başka programcıya verin ve ciddi bir değişiklik yapmasını isteyin. yYaptığımzı şey bir algoritma ise, bir kaç adım sıkıştırın araya, ya da bir proje yapmışsak bir süreçte ya da iş kuralında değişiklik yapılmasını isteyin. Hangimizin kodu ya da projesi en kısa sürede bu üçüncü programcı tarafından başarıyla değiştirilebilirse, bilin ki en iyi programcı odur.

Linus Torvalds’ın dediği gibi, “Konuşmak ucuzdur. Bana kodu göster.” (Talk is cheap. Show me the code.)

Toplam görüntülenme sayısı: 2296

21 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
«< 26 27 28 29 30 >»

Günlüğüme Hoşgeldiniz

Bu günlükte, Yazılım Mühendisliği, Bilgi Teknolojileri, Java, kişisel gelişim ve zaman zaman da diğer konulardaki düşüncelerimi sizlerle paylaşacağım. Umarım beğenir ve hoşça vakit geçirirsiniz.

Her türlü düşüncenizi, yorum olsun, beğeni ya da eleştiri olsun, bana iletmenizi rica ediyorum sizden. Ayrıca bana akin@javaturk.org adresinden ya da Twitter'dan ulaşabilirsiniz. Videolarıma da buradan ulaşabilirsiniz.

Teşekkür ederim.

Akın Kaldıroğlu

Rahat Okumak İçin

A Decrease font size. A Reset font size. A Increase font size.

Sosyal Medya

  • Twitter
  • Facebook
  • LinkedIn
  • Youtube

Son Twitlerim

→ Takip Etmek İçin

Abone Olun

Emalinizi girerek yazılardan haberdar olun.
Loading

Son Yazılarım

  • Udemy Eğitimlerim Üzerine
  • (başlıksız)
  • Clean Code / Temiz Kod Eğitimi Udemy’de
  • Java ile Nesne-Merkezli Programlamaya Giriş Eğitimi Udemy’de
  • Selsoft Video Eğitimleri
  • Spring ile Kurumsal Yazılım Geliştirme
  • Corona Günlerinde Design Patterns
  • Corona Günlerinde Java
  • JDK 10 ve “var” Özelliği
  • Onur Özcan
  • Analist ve İş Bilgisi
  • Farklı Dillerin Bakış Açısıyla Nesne-Merkezli Programlama
  • Java Nedir?
  • Bilgi Teknolojilerinde Yetenek Yönetimi – II: Tanımlar ve Eleştiriler – I
  • Alelade Hikayeler – II: Bir Başka Performans Problemi

Yazı Kategorileri

Yazı Takvimi

Mart 2026
P S Ç P C C P
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« May    

Yazı Arşivi

Blogroll

  • Binnur Kurt'un Günlüğü
  • Ender'in Java Blogu
  • Erdem Seherler
  • Kızımın Günlüğü
  • Kurumsal Java
  • Levent Karagöl
  • Levent'in Java Blogu
  • Mert Can Akkan’s java tips,options, news…
  • Yaşar Safkan
  • Yasin Saygılı
  • Yazı Dünyası

Yazı Etiketleri

analiz Bilmek C Desen design pattern EJB Eğitim Fortran Hibernate Java Java'ya nasil baslarim Java dersleri Java EE Java Persistence API Java SE Java Sertifika Java Öğren Java öğreniyorum Java öğrenmek JPA Kalıp Kurumsal Java nesne nesne-merkezli No Silver Bullet object object-oriented Oracle Java Certifications pattern performans programlama programlama dilleri programlama nedir sertifika singleton tasarım tasarım deseni tasarım desenleri tasarım şablonu yazılım yazılım geliştirme Yazılım Mühendisliği yazılımın doğası yazılımın zorlukları Şablon

↑

© Java Günlüğüm 2026
Powered by WordPress • Themify WordPress Themes
 

Yorumlar Yükleniyor...