kirpit

PHP ile bakımı imkansız yazılım geliştirme sanatı

Güncel işsizlik oranlarına bakıldığı zaman hemen herkesin derdi sahip olduğu işi kaybetmemektir, hatta bilişim sektöründe bile. İşinizi korumanın en iyi yolu ise değiştirilemez çalışan olmaktır. Eğer hiç kimse yazdığınız kodun bakımını yapamaz durumdaysa ömür boyu bir işe sahipsiniz demektir. Bakımı imkansız kod yazmak bazı yazılım geliştiricilerine doğuştan verilen özel bir yetenektir. Bu yazıda siz, geri kalanlarınız; bu özel yetiye sahip olmak için bir takım ipuçları ve ustalıklar bulacaksınız.

İlk iş; ilk olmak

Her şey iş başvuruları ile başlar. Kanatlarını açıp bakımı imkansız geliştirme potansiyelini açığa çıkaracağın doğru şirketlere bakmalısın. PHP gurusu olmak zorunda değilsin ama eğer öyleysen oldukça yardımı olacaktır. Başka bir teknolojiden PHP’ye geçiş yapmayı düşünen veya yeni kurulan (start-up) şirketler, tüm hünerlerini sergileyebileceğin en güzel yerlerdir. Bu yönde iş tanımları veya ne istediğini bilmeyen iş ilanları tam sana göredir. Örneğin; “10 yıllık PHP 5 tecrübesi + FrontPage ve Office programlarında uzman”

İşi aldığın ve altın fırsatı yakaladığın ilk günden itibaren konuşkan ol. Toplantılarda söz al; fikirlerinin herkes tarafından duyulduğuna emin ol. Nesneye yönelimli tasarım mimarisinden, design pattern‘lerden, kurumsal yük dengeleme paradigmalarından, “yeteri kadar iyi” olan şeylerin neden yeterli olmadığından ve mutlaka senin bu sürece olacak fedakarlık ve adanmışlığından bahset. Herkesin önemli öncelikler ve başlıklarda senin fikirlerine danışacağından emin ol.

Bakımı zorlaştıran altyapı temelleri

Bakımı imkansız Java kodu yazma konusunda şu ana kadar bulabildiğim en iyi kaynaktan – unmaintainable code – esinlenerek; şu iki prensibi adın gibi öğrenmen ve hiç aklından çıkarmaman gerekiyor:

i. Herhangi birinin projenin başka bir tarafını yıkmadan kolayca değişiklik yapabilmesini imkansız hale getir. Junior veya yazılım bakımı / hata düzeltme yapan meslektaşının senin yazdığın kodu anlamak için zamanı olmamalı. Kolay bakım yapılabilen kodlama, bu işten biraz anlayan birinin elini koymuş gibi çalışan yeri bulma, nasıl çalıştığını anlama  ve başka yerleri patlatmadan değişiklik yapabilmesi demektir. Buna kesinlikle izin veremezsin. Hiç kimseye proje içerisinde basitçe arama ve tahmin ettiği yerde bulma imkanı tanıma.

ii. Yazdığın kod içenden çıkılmaz halde gözükmemelidir, birileri şüphelenebilir. Sadece içinden çıkılamaz halde olmalıdır. Kod, hata düzeltme ve bakım yapan zavallı geliştiricilere tamamıyla normal gözükmeli ama en az tahmin ettikleri yerlerde sürprizlerden sürprizlere sürüklemelidir.

En iyi uyarlama yöntemleri

i. Kodlama standartları ve kurallarını yasakla. Kodlama ve isimlendirme standartları arasında sonu hiç gelmeyen anlamsız ve gereksiz bir savaş var. Sen, yapılmayı bekleyen harika bir projeye sahipsin ve uzun saatlerini “tab mı yoksa boşluk mu?” gibi gereksiz sorulara harcamamalısın. Ayrıca standartların kesin kuralları vardır. Eğer projeye yeni katılacak takım arkadaşların bu kuralları uygulayamazlarsa başarılı ve üretken olamamalarına sen neden olacaksın. Mutsuz programcılar, üretken olamayan programcılardır; neden böyle olması gerektiğini merak eden herkese açıkla. Herkesin canının çektiği standartlarda, günün psikolojisinin getirdiği tarzda yazmasına izin ver. Konu senin kendi yazdığın koda gelince kodlama standartlarını düzenli olarak değiştir. Pazartesi günleri camelCase ile, Salı günleri hepsi_kucuk_harf ile, Cuma günleri hepsinin_karisimiVe-YeniTarz ile ve her Şubat 29′da fnHungarianNotation ile yazabilirsin.

ii. Yorum yazma. Yazdığın kod zaten şairane, kod içerisinde yorum – açıklama yazıp inline dökümantasyon yapmana ne gerek var? Eğer birileri karşısında olan bitenleri anlayamıyorsa, yeteri kadar becerikli olmadıklarından kaynaklanıyor olamaz mı? Yine de herhangi bir nedenle kod içerisinde yorum yazmak zorunda kalırsan, basitçe senden isteneni abartarak yap. Kodun en açık, net ve önemsiz kısımlarını tanımla ve gerisini salla.

// Takip eden kod blogunda,
// iki adet degisken tanimliyoruz,
// degisken a ve degisken b.
// Her ikisi de integer tipinde.

// Degisken a'yi tanimla,
// ve bir degerini ata.
$a = 1;

// Simdi degisken b'yi tanimla,
// ve 2 degerini ata.
$b = 2;

// Asagida tanimlandigi uzere,
// a ve b degiskenlerini topla,
// ve olusan degeri c degiskenine ata.
$c = $a + $b;

iii. Notepad’i standartlaştır. Diğerlerinin sürünmesine ve sonuçta takımı bırakacak duruma gelmesine izin ver. Onların şikayetlerini dinleyerek kafanı şişirmek zorunda değilsin. Ama eğer biri neden Notepad’in standart editör olduğunu sormaya teşebbüs ederse her an açıklama yapabilmeye hazırlıklı ol. Öncelikle Windows ile geliyor – günümüzün üretken programcıları için tek alternatif işletim sistemi – ve tamamen ücretsiz. Eminim internette Word gibi diğer editörleri kullanarak nasıl kod yazılacağını açıklayan bir sürü makale vardır, ama Notepad gerçek gurular içindir. Ayrıca şirketiniz her şeyden önce yalnızca guruları işe alır.

iv. Test yapma. Neden yapmadığını soranlara ise yüksek kalitede kod yazmak için bu işe alındığını ve iyi yazılmış bir kodda hatalara yer olmadığını, modular unit testing’e gerek kalmadığı açıkla. (Biraz terimsel konuşmak seni her zaman işinde daha yetenekli gösterir.) Neden aklı başında biri gereksiz testlerle zaten açıkça ortada olan kodların çalıştığını onaylamak için zaman harcasın ki? Hayatta bazı şeyler, gökyüzünün mavi olması, güneşin doğudan doğması ve yazdığın kodun çalışıyor olması kadar kesindir. Durma, işine devam et. (Kod içerisine yorum yazma konusunda olduğu gibi eğer test yapmak zorunda kalırsan, en basit ve açıkça ihtiyaç duyulan fonksiyonları test edip gerisini boş ver.)

v. Şablon sistemlerine (templating) izin verme. Templating sistemleri iş akış mantığını sunum katmanından ayırmaya yarar. Bu ise kodun bakımını, arananı bulmayı kolaylaştırır ve kesinlikle müsaade etmemelisin. Rasmus Lerdorf‘un da söylediği gibi; “PHP bir templating motorudur”. Eğer yine de bu tarz sistemleri kullanmak zorunda bırakılırsan amaçtan saptıran kullanım yollarını ara, sunum katmanına azar azar iş akışı ile ilgili kod parçacıkları ekle, HTML, CSS, JavaScript ve veritabanı erişim katmanını ustalıkla harmanla.  Hatta mümkünse PHP, HTML, CSS ve JavaScript kodlarının sağlıklı bir karışımını tek satır kodda halletmeye çalış. Inline CSS stil tanımlamaları olan HTML kodlarını üreten JavaScript kodunu PHP tarafından yazdır. Eğer biri neden böyle yaptığını sorarsa, bu yöntemi “encapsulation” diye adlandır – senin kodun yalnızca kendisinden sorumlu ne de olsa.

vi. Versiyon kontrolü kullanma. Vazgeçmek zordur ama buna değer. Soğuk yüzlü versiyon kontrol yazılımlarının dosya değişikliklerindeki çakışmaları düzeltmesini beklemek yerine, geliştiricilerin birbiriyle konuşmasının takım içi iletişimi ve takım çalışmasını ne denli arttırdığını herkese göster. Eğer herkesi ikna etme konusunda başarısız olursan ümitsizliğe kapılma. Yaptığın bütün değişiklikleri versiyon kontrol sistemine commit etmek zorunda değilsin. Kodun küçük ama ölümcül parçacıklarını kendine sakla – eğer senden başka biri aynı kodu build ve deploy etmeyi denerse proje tamamıyla patlayacaktır. Yakalanırsan, bu kodun henüz tamamlanmadığını ve neden sana sorulmadan değişiklik yapıldığının hesabını sorabilirsin. Tüm bunlarla birlikte junior takım üyelerini eğitici, yalnızca istisnai kalitede ve zekice çözümlerini versiyon sistemine commit et. Çocuklar senin yazdığın kodlara göz atıp mümkün olanın en iyisinin yalnızca senin tarafından yapılabileceğini anlasın.

vii. Kendi kod kütüphaneni (framework) yaz. Şirket adına bir framework yaptığın zaman kaçınılmaz olarak “mimar” sıfatını alırsın ve artık senin hakimiyet ve otoriten sorgulanamaz. Bu ayrıca kendi gizli kurallarını da ekleyebilmeni sağlar – istediğin kadar, hatta bazen kendi içinde çelişkili olanları bile. Böylece bakım konusunda en tecrübeli yazılımcıya bile takla attırabilirsin. Yaptığın framework her şeyin çaresine bakacaktır. Hiç kimsenin onu anlamak için uğraşmasına gerek kalmamalı; hatta tüm şirket için daha verimli ve kolay geliştirme yöntemlerini tek kişilik kaynakla sunduğun için mutlu olmalılar. Asla framework’unu açık kaynak olarak dışarıya sunma, çünkü framework şirketine ait bir demirbaştır ve daha kötüsü açık kaynak camiası seninle veya framework’ünle dalga geçebilir ki bu senin blöfünün sonu olur.

İsimlendirme

Değişkenlerinin isimlendirmeleri tam anlamıyla gizem taşımalı, hatta çoğunlukla tek harfli olmalı. Buradaki amaç tamamen bir başkasının aradığı şeyi imkansız hale getirmektir.

Sınıf isimleri ve fonksiyonlar da tek karakterli olmalı. Eğer insan gözüyle anlaşılır bir isim vermek zorundaysan da o ismi her yerde aynı kullan – bazen bir bilgiyi saklamanın en iyi yolu o bilgiyi gereksizce çoğaltmaktır. Aynı ismi defalarca kullanma metodunu uygularken – buna örneğin “özneye odaklı/yönelimli programlama” tekniği diyebiliriz – parantezleri ve süslü parantezleri yeni satıra indirmek pek çok konuda yardımcı olacaktır. Topu okunabilirliği arttırmak amacına atabilir; aynı zamanda takım arkadaşların eğer gerçekten projede bir şeyler bulmak istiyorlarsa düzenli ifadeleri (regular expressions) kullanmak zorunda bırakabilirsin. Aşağıdaki örneği inceleyelim:

$spagetti = 1;
class
spagetti
{
    var $spagetti= 2;
    function
        spagetti
        ()
    {
        $spagetti['spagetti'] = 'spagetti';
    }
}
function
    spagetti() {
        return new spagetti;
    }
$spagetti = spagetti();
var_dump($spagetti);

Bu arada değişkenleri isimlendirirken farklı karakter setlerinden ilginç olanları kullanabilirsin. Kiril alfabesi bu iş için biçilmiş kaftandır, çünkü bazı harfler tıpkı Latin alfabesindeki gibi görünür ama farklıdır. Örneğin, aşağıdaki koddan hangi çıktı alınır?

$alert = 1;
$аlert = 2;
echo $alert;

Sonucu 2 mi tahmin ettin? Eğer ikinci $alert değişkeni Kiril alfabesindeki а harfiyle başlamasaydı haklı olabilirdin! (Kodu memnuniyetle deneyebilirsin)

Referans silahı

Eğer bir şeyi normal olarak tanımlamış olsan bile, bu senin ilginç yöntemlerle onu kullanamayacağın anlamına gelmez. Üzerinde bolca pratik yapılması gereken silahlar şunlardır:

• eval()
• değişken değişkenleri (variable variables)
• değişken sınıf isimleri, ör; $elmaliTurta = ‘spagetti’; $s = new $elmaliTurta;
• call_user_func()

Çalıştırmak istenilen kodu string olarak da kabul edebilen herhangi bir kod yapısı senin dostundur;

// calling abc();
$z = 'A';
call_user_func($z .'bC');

Büyük küçük harf duyarlılığı

Büyük-küçük harf kullanımının hangi durumlarda duyarlı (case-sensitive), hangi durumlarda duyarsız (case-insensitive) olduğunu baştan sona öğren. Fonksiyon isimleri büyük-küçük harf duyarsızdır. Bunu mutlaka suistimal et.

function abc(){
    echo 'abc';
}
AbC();

Diğer taraftan dizi (array) değişkenleri duyarlıdır. Bunu da sonuna kadar suistimal et.

$a['UseConvetionsOnlyTobreakThem'] = 1;
if (isset($a['UseConvetionsOnlyToBreakThem'])) {
    // Bir suru kafa karistiran
    // ve hic calismayacak kod
}

Değişken üzerine yazma

Global değişkenlerin üzerine yaz, özellikle süper globallerin. Hatta onları nesneden fonksiyona, fonksiyondan diğer dosyaya veri aktarmak için kullan. $_GET dizisindeki elemanların üzerine daha kod başlamadan yaz, hatta bunu sıklıkla yap. Aynı yöntemi $_POST için de uygula. İnceden ufaktan, sessizce $_REQUEST içerisine de bir şeyler serpiştirmeyi unutma. Eğer biri sorarsa, XSS, injections, infections ve diğer bulaşıcı hastalıklara karşı kullanıcıdan gelen her türlü verinin filtrelemesi gerektiğini söyle.

Kontrol ve döngü yapıları

if, while, for, foreach ve switch yapılarının tüm alternatiflerini birbiriyle karıştır ve birlikte kullan. Eğer soran olursa junior elemanları eğittiğini, dili gerçek anlamda her özelliğiyle öğrenmeleri için yaptığını söyle.

if ($a > 5):
    if ($a > 4) {
        while ($a > 0):
            echo --$a;
        endwhile;
    }
endif;

Üç terimli işleç (ternary operators) karşılaştırma operatörünü iç içe kullan. Kısa ve öz koddan daha iyisi yoktur.

// Ciktiyi tahmin et bakalim.
echo TRUE ? 'true' : FALSE ? 't' : 'f';

for döngülerinin koşul satırında $i değişken değerini hiç arttırmamak bütün milleti aptallaştıracaktır. Döngü içerisinde bir yerlerde hatta variable variables ile beraber gizemli şekilde bunun üstesinden gelinebilir.

for ($i = 0; $i < 10;) {
	// bir suru karmasik kod
	$temp = chr(105);
	// diger kod
	${$temp}++;
}

Döngüleri iç içe kullan. Hem de derinlemesine, gittiği yere kadar. Sonra hiç beklenmedik bir anda aniden tüm döngüleri bitir. break 2 ve continue 3 tarzı kesmelerle oynamak bile tek başına eğlence kaynağıdır, özellikle nerede hangisinin başladığı belli olmayacak şekilde girintili yazılmış bir döngü kodunda.

Şimdi başla!

Bugünlük bu kadar. Umarım bu yazıyı okuduktan sonra alternatifsiz, yeri başkasıyla değiştirilemeyen yazılımcı olabileceğine ikna olmuşsundur. Emin ol sen de, bakımı ve başkası tarafından geliştirmesi tamamen imkansız projeler yapabilirsin. Geleceğin senin ellerinde! Ne yapacağı, nasıl davranacağı kolayca tahmin edilen, değişikliği en fazla dakikalar süren kod yazarak kendi işini şansa bırakabilir misin?

Stoyan Stefanov, Unmaintainable PHP