Spolsky'nin yazısını çok önceleri okumuştum. 4 sene kadar önce de acizane şöyle bir şeyler karalamıştım. http://yuxel.net/?module=news&action=show_id&id=501

Son 8 aydır, Dubai'de bir şirkette çalışıyorum. Bundan 6 ay kadar önce bir proje geliştirmeye başladık. Biz ilk versiyonu 2 kişi ile, 2 ayda tamamladık ve 2 ayda site yayına çıktı. Bunu geliştirirken 2 kişiydik. Bazı yerleri hız baskısı yüzünden "pataküte" yazdığımız oldu. Ancak bunların hepsi kodda TODO veya Jira'da "technical debt" olarak açıldı. Velhasıl, planda ekibe yeni katılanlar olunca bu "boktan" yerleri periodik olarak düzenleyeceğimiz refactoring hackathon'ları ile düzenleyecektik.

Projeyi 2 ay içinde çıktık, 1 ay kadar da yavaş yavaş geliştirmesine devam ettik. Satışlar falan gayet iyiydi, site ufak tefek sorunlar haricinde "yağ gibi akıyordu". Marketing ekibi ve "üsttekiler" bize "magician" flan diyordu.

Bu 1 aylık süreçte ekibe 5 yeni developer katıldı. Neredeyse hepsinin iş görüşmesini ben yaptım. Aralarından bir tanesi "zehir" gibi bir çocuktu. Ancak yetkiliye "bu çocuk zehir gibi, ama burada sıkılır, oturur kodu baştan yazmaya kalkar" diye de ilettim. Yönetici "bırakalım yazsın o zaman :)" diye gülümsedi.

Çocuklar ekibe katıldı, ilk iki haftalık süreçte oryante oldular. Ve 2 hafta sonra içerden "bu kod çok kötü, neden burada şu şu işleri yaptık, burada daha 'hipster' teknolojiler kullanabilirdik" gibi yakarışlar doğmaya başladı. Bir oturum yaptık, yönetici, ben ve yeni gelen 5 arkadaş arasında bir oylama ile kodun yeniden yazılmasına karar verildi.

Kodun yeniden yazılmasına gerek olmadığını, o hata diye belirtilen yerlerin hepsinin zaten todo listemizde olduğunu ve bunların hepsini benim tek başıma iki haftada düzeltebileceğimi söylemiştim.

Ancak içerdeki ben hariç herkes "biz zaten hep beraber girersek kodu 2 haftada cillop gibi yaparız" demişlerdi. Demokrasi hakim geldi kodun yeniden yazılımı başladı. Ben ise bu fail içinde yer almak istemiyorum diye rewrite projesinde yer almadım.

Rewrite'dan önce, kodun testleri, code style guide'ları, continous delivery'si ve continous integration'ları her şeyi hazırdı. Ve bunu 2 ayda, hiçbir bussiness gereksinimi netleşmemiş koşullarda yapmıştık. Şu anda, kodda tüm business logic, uygulanan tüm teknolojiler vs vardı. Ve site, üzerinden çok sayıda siparişin geçtiği bir yapıyla, 20ms gibi bir sürede performans verecek şekilde çalışıyordu. Bölgedeki en hızlı site idi.

Rewrite'a başladılar. Vaadettikleri "2 haftada cillop gibi yazarız"ın 9. haftasında kodu yayına alabildiler. Tahmin edebileceğiniz gibi her yeri patlayan bir ürün ortaya çıktı. Gelirler marketing ekibinin dediğine göre %80 azaldı.

Şu anda "rewite"ın 12. haftasındayız; hala continous delivery'miz yok. Kodu elle deploy ediyorlar. Hala bir sürü bug'ımız var. Ve sitemiz 600ms'de render oluyor.

Şu anda, içerdeki ekip, deadline'ı 2 hafta sonra olan, aslında 1.5 ay önce testlerine başlanması gereken bir sistemi yetiştirmeye çalışıyor. Sistemin yayına girmediği her hafta şirketin kaybedeceği para milyon dolar civarında.

Günün sonunda; 3-5 developer'ın egosunu okşaması için heba olan milyon dolar; ve bu stres altında çalışmaya mahkum kalan (ben hariç) 6 developer, "gelirler %80 düştü, naptınız siteye" diyen bir marketing ekibi var.

"İyi kod" diye bir şey her zaman geçerli bir sebep değil. Çünkü o "iyi" dediğiniz kodlama şekli, o "iyi" dediğiniz "hipster teknolojiler" 6 ay sonra değişecek. Önemli olan, kodu temel yazılım prensiplerine uygun şekilde, bakımı kolay, katmanlı mimari ile vs yazmak.

Yazılımcıda aranan en büyük kriterlerden birisinin ise "iyi kod yazmak"tan ziyade "kötü kodu refactor edebilme" olması gerektiğini düşündüğümü belirtir, bu yorumuma burada son veririm.

âlâ :)