|
 "Yavaş yazın, saçınız başınız dağılmasın!" dedim "Baştan yazalım!" diyen arkadaşlara...
Geçen gün yaptığım bir danışmanlık görüşmesi ve sonrasında da bu gece birkaç arkadaşımla yaptığımız feyizli sohbet sonrasında. ben dahil, tüm yazılımcıların, yeni bir yere gittiğinde yaptığı ilk işlerden birisi olan, mevcut kodu haklı(!) olarak eleştirip "abi bu ne biçim kod, baştan yazalım!" sendromuna değinmek istiyorum.
Arkadaşlarımın bir kısmı, yeni girdikleri işteki kodun, haklı gerekçelerle çok kötü olduğunu söyleyip "abi, yöneticilere söyleyelim, bu kod böyle olmaz, oturup tekrar yazalım" diyeceklerini söylediler. Ben ve bir arkadaşım, daha önce çalıştığımız bir kaç yerde bu tip süreçlerden geçtiğimiz için güldük. Bunu başarmalarının neredeyse imkansız olduğundan bahsetmeye çalıştık. Bundan 2.5 sene önce istifa ettiğim bir yer, 2.5 yıl önce verilen "baştan yazalım" kararını gerçekleştirmeye uğraşıyor hâla(ki bunun başarılamayacağını anladığımla istifa etmem paralellik göstermişti). Zira bu iş, düşündüğünüz kadar kolay bir iş değil.
Ne kadar "kötü" de olsa, 3-4 yıldır geliştirilmesi ve testi devam eden bir kodu "abi bir odaya kapanır 3 ayda baştan yazarız" gibi bir inançla koda dalıp yapmaya çalışmanız muhtemelen 3-4 yıl sonunda, elinizde hâla tamamlanmamış, biraz daha iyi ama eski kötü kod kadar iyi çalışmayan, ve muhtemelen çalışan sistemin büyük çoğunluğunun hâla eski kod ile çalıştığı bir sistemle baş başa kalacaksınız.
Bize bunu yapabileceğimize inandıran birkaç şey var tabi;
* Mevcut kodun, 10 sene önceki kod yazım stilinde yazılması (spagetti?)
* 3-4 sene önce geliştirilmesi başlamış kodun, artık "eskimesi". Yeni "diller", yeni metodolojiler, yeni teknolojiler ile daha "çağdaş" bir uygulama geliştirme isteği "Abi bu ne Java'yla yazmışsınız, Ruby diye bişey var ben onla tüm sistemi 2 ayda yazarım" sendromu olarak da bilinir
* Muhtemelen, 10 sene önceki metodolojilerle geliştirilen kodu geliştiren ekipten kendimizi daha iyi görmemiz
* Koda yeni bir feature eklemenin çok zor olması, bunu yeni geliştireceğimiz sistemle daha kısa sürede yapabileceğimize inanmamız (ki başarabilirsek, daha kısa sürede yazılabilir)
* "abi sql_getir() diye fonksiyon adı var ya, oyle isimlendirme mi olur?" gibi haklı bir serzeniş
* Başkasının yazdığı kodu okumanın, onu anlamanın (ki muhtemelen bu kodu herhangi bir yazım standardında göre yazmamış, "How to write unmaintainable code"a ilham olmuş birileri yazmıştır o kodu) o kodu yeniden yazmaktan daha sıkıcı olması
* Performans iyileştirmeleri
* Arama motoru optimizasyonları ile daha çok kullanıcıya ulaşabilme isteği
* Yaptığımız işi düzgün yapmak istememiz. Yazılımcıyı en mutlu eden şeylerden birisi, kazandığı paradan daha çok yaşadığı mesleki tatmindir (dark-side'a geçenler için farklı tabi durum :p)
Peki bunu yapAMAmanızın önündeki en büyük engeller nelerdir;
* Dökümantasyonu, spec'leri, testi olmayan, veya bunların "tümüne" hakim birilerinin(ki öyle bir insan yok :p) içeride olmadığı bir sistemi, aynı özellikler ile tekrar yazmanız çok zor.
Yazabilmeniz için, baya baya kodu "satır satır" okumanız gerekecek. Satır satır okusanız bile gözünüzden kaçan bir sürü "test senaryosu" olacak.
Siz sayfanın içinde tümden inline yazılmış JavaScript'leri "abi bu ne böyle, bunları ayrı dosyaya taşımak lazım" dediğinizde, o "kötü" inline JavaScript kodunun hangi "testlerden" geçtiğini bile bilmeden o kodun çalışıp çalışmadığından emin olamayacaksınız ve belki o kod, siz onu ayrı dosyaya alıp yeniden yazdığınızda Explorer 6'da çalışmayacak. Ki bu "en zararsız" gibi görünen "kod taşıma" sürecinde bile başınıza gelebilecek bir sorun.
Tüm sistemi, hiç bir yerde yazılı olmayan test senaryolarıyla, tüm tarayıcılarda, tüm ortamlarda düzgün çalıştırabileceğinize gerçekten inanıyor musunuz? Ben açıkcası inanmıyorum :) Web/e-ticaret scope'undaki CMMI seviyesinin de çoğu zaman 2'nin üstünde olmadığını, doğru düzgün "tanımlamanın" bile yapılmadığını varsaydığımda da, teoride, "eski kodu, aynı şekilde çalışacak şekilde yeniden yazmak" çok ama çook zor bir süreç.
* Bu iş tahmin ettiğinizden çoook daha uzun sürecek (bkz: 2.5 ayda yeniden yazılması planlanan sistem, 2.5 senedir tamamlanamadı). Ve bu 2.5 yıllık süreyi geçelim, 2.5 aylık sürede bile sektör çok değişecek. Kullanıcıların talepleri değişecek, pazara yeni rakipler girecek ve siz "iyi ihtimalle" 2.5 ay boyunca duracaksınız. Bunun yanında, geliştiricileriniz 2.5 ay sonunda "release ile mutlu olmayı" (evet evet, biz geliştiriciler, kodumuzu insanlar kullanınca mutlu oluruz, öyle garip organizmalarız) beklerken bu süre 2.5 seneye çıkınca mutsuz olacak (ve muhtemelen işten ayrılacak) .
* "Her şey tamam, bitti bu!" dediğinizde de aslında o iş bitmeyecek. Çünkü yukarıda da bahsettiğim gibi bir çok testi yapmayı unutacaksınız, beklediğinizden fazla ziyaret alacaksınız ve belki bu yüzden şirketiniz para ve prestij kaybedecek. Neredeyse eski sistemdeki her koşulu test etmek zorunda kalacaksınız, ama neyi test edeceğinizi bilmiyor olacaksınız ve muhtemelen eski sistemin otomatize edilmiş bir test süreci de olmayacak. Olsa belki onu alıp yeni sisteme uyarlarsınız ama :)
* Eski sistemin, yeni sistem ile örtüşEMEyen bir çok yanı olacaktır. En basit örneklerinden bir tanesi de URL yapınız. 3-4 senedir çeşitli sitelerde, arama motorlarında paylaşılan içerik, artık o URL ile erişilemez olacaktır, siz URL yapınızı değiştirdiğinizde arama motorlarında değer kaybedeceksiniz (bunların tabii ki çözümleri var ama bunlar la da uğraşmanız gerekecek)
Kendinize "baştan yazmadan bu işi çözmek mümkün mü?" sorusunu sorduğunuzda da aslında güzel cevaplar alabilirsiniz;
* "spagetti" dediğimiz; veri, görünüm ve kontrol katmanlarının iç içe geçtiği 5000 satırlık "murtaza.php" dosyasını(evet evet buna benzer isimde dosyalar var koca koca şirketlerde) da, bir şekilde ufak parçalara ayırarak, ilgili kodları ilgili yerlere taşıyarak ilerleyebilrisiniz.
* "sql_getir()" kullanan tum methodlari, bir sinifa tasiyip daha moduler yapma gibi bir isi, sanırım bir stajer bile bir kaç haftada bitirebilir. Refactoring için oturmuş bir test sürecinizin olmaması burada da nispeten elinizi kolunuzu bağlasa da "riski" azaltarak daha "korkusuzca" ilerleyebilrisiniz. sql_getir()'leri refactor etmek, muhtemelen tüm siteyi baştan yazmaktan daha az soruna sebep olacaktır.
* "X dili ile yazılmış bu projeyi ben Scala'yla 2.5 ayda yazarım" diyen birileri gerçekten o işi 2.5 ayda daha düzgün yazabilir, ama muhtemelen o kişiye kamyon çarpsa Türkiye'de Scala geliştiren 2. bir kişiyi bulamayabilirsiniz :p Dolayısı ile mevcut dil veya "yaygın dillerden birisi" ile devam etmeniz daha doğru bir karar olacaktır.
* "X sayfası çok yavaş çalışıyor, bunu daha hızlı yapmamız lazım" için çözüm baştan yazmak olmayabilir. Muhtemelen bir kaç ufak optimizasyonla bu sorunu aşacaksınızdır.
Gönül ister ki işler en azından dökümante edilse, otomatize testleri yazılsa ve korkmadan refactor edebilsek, ama maalesef gerçek dünyada, özellikle web/e-ticaret domainin'de pek mümkün değil. Bu süreçleri oturtmamış sistemler için de bence "baştan yazmak doğru yol mu?" diye ciddi şekilde düşünmek gerekir.
Bu arada, "yeniden yazmak" imkansız değil, sadece "zor". Ama düşündüğünüzden daha da zor. Benim bildiğim örneklerinden bir tanesi de HurriyetEmlak.com . PHP ile olan eski yapı, yaklaşık 1.5 senede 10'dan fazla geliştiricinin dedike olarak ayrılması ile .NET'e aktarıldı ve sanırım şu anda gayet mutlular.
Ek: Aldığım bir habere göre, HurriyetEmlak.com'un olayı tam bir "yeniden yazma" vak'ası değilmiş. Aldıkları hazır bir CMS'i değiştirerek 1.5 senede bitirebilmişler. Yamuluyorsam düzeltin.
Henüz http://martinfowler.com/books/refactoring.html okumadım. Eğer okuduktan sonra fikirlerim değişirse tekrar bir blog yazısı patlatırım ;)
Yazının anlam ve önemine binaen de şunu paylaşayım :
 |
|
| 21.Eylül.2012 Cuma
:: 17:14:14 |
84214 kere okundu |
|
 |
Takvim |
 |
|
| < Kasım 2024 > |
|---|
| P | S | Ç | P | C | Ct | Pz |
|---|
| | | | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 |
|
|
 |
|
 |
|