İlk çalışan sürümü yazmak gerçekten kolay; kimse bunun aksini iddia etmiyor. Asıl maliyet, sayfa yapısı her değiştiğinde tekrar eden bakım ve bu maliyet takvime yayıldığı için baştan görünmüyor.
Bu yazının amacı sizi kod yazmaktan vazgeçirmek değil. Aksine: ilk çalışan sürümü yazmanın gerçekten kolay olduğunu ve bazı durumlarda doğru karar olduğunu baştan kabul ediyorum. Anlatmak istediğim şey, kararı verirken hesaba katılmayan kalemin ilk yazım değil, sonrasındaki bakım olduğu. O kalem takvime yayıldığı için görünmüyor ve tam da bu yüzden insanlar kendi çözümlerini bir yıl sonra terk ediyor. İlk sürümün bu kadar kolay görünmesinin sebebi basit: gerçekten kolay. Liste sayfasını açarsınız, tarayıcının geliştirici araçlarıyla başlık ve fiyat alanlarının nerede durduğunu bulursunuz, bir döngü kurarsınız, sonucu bir dosyaya yazarsınız. Temel bilgisi olan biri için bu bir akşamlık iş ve sonunda gerçekten çalışan bir şey elde edersiniz. İlk çıktıyı açıp içinde doğru fiyatları gördüğünüz an güçlü bir tatmin verir; "bu kadarmış" dersiniz. O andaki değerlendirmeniz yanlış değil, sadece eksik: elinizdeki şey bir ürün değil, bir prototip. Aradaki farkı sonraki bölümdeki liste anlatıyor. Prototipi kullanılabilir hale getiren yedi ek iş Sayfalama: ikinci, üçüncü, ellinci sayfaya geçiş ve son sayfanın nerede bittiğini anlama. Sonradan yüklenen içerik: kaydırıldıkça gelen kartlar ilk yanıtta yoktur, beklemek veya farklı bir yol izlemek gerekir. Oturum ve çerez yönetimi: giriş gerektiren sayfalarda oturumun taşınması ve süresi dolduğunda yenilenmesi. Tempo ayarı: istekler arasına bekleme koymak, sitenin normal kullanımını zorlamamak ve yanıt yavaşladığında geri çekilmek. Karakter kodlaması: Türkçe karakterlerin dosyada bozulmaması, CSV ayracının Excel'de doğru okunması. Hata yönetimi: tek bir sayfanın beklenmedik yanıtı bütün işi düşürmesin, yeniden deneme ve atlama mantığı olsun. Kaldığı yerden devam: nereye kadar gidildiğini diske yazmak, kesinti sonrası baştan başlamamak. Asıl maliyet: seçiciler kırılır, hem de sessizce Yukarıdaki maddelerin hiçbiri tek başına zor değil; sorun hepsinin toplamının artık bir akşamlık iş olmaması ve daha da önemlisi, o liste bittiğinde işin bitmemesi. Saydıklarım bir kereliktir, asıl tekrar eden kalem şudur: kendi yazdığınız kod, hedef sayfanın bugünkü yapısına bağlıdır. Site tasarımını güncellediğinde, bir alanı başka bir kutuya taşıdığında ya da sınıf isimlerini değiştirdiğinde kodunuz o alanı bulamaz. Beklenen senaryo, programın hata verip durmasıdır; gerçek senaryo çoğu zaman daha kötüdür. Kod çalışmaya devam eder, satırları üretir, dosyayı yazar; sadece bir sütun baştan sona boş gelir. Hiçbir hata mesajı görmezsiniz. Bunu genellikle iki hafta sonra, o sütunu kullanacağınız raporu hazırlarken fark edersiniz ve o iki haftalık veri artık geri getirilemez, çünkü ilanların o günkü hali artık yerinde değildir. Sessiz kırılma, gürültülü çökmeden pahalıdır Programın durması can sıkıcıdır ama en fazla bir günlük gecikmedir. Sessizce eksik veri üretmesi ise fark edilene kadar biriken ve geriye dönük telafi edilemeyen bir kayıptır. Kendi kodunuzu yazacaksanız, ilk yazacağınız şey toplama mantığı değil, çıktıyı denetleyen kontroller olmalı. Sessiz kırılmayı yakalayan doğrulama katmanı Satır sayısı: bu çalıştırmada gelen kayıt sayısı bir önceki çalıştırmanın belirgin biçimde altında mı? Boş oranı: her sütun için boş hücre yüzdesi belirlediğiniz eşiği aşıyor mu? Tip kontrolü: fiyat sütunundaki değerler gerçekten sayı mı, tarih sütunu tarihe çevrilebiliyor mu? Aralık kontrolü: fiyat ve metrekare gibi alanlarda mantık dışı uç değerler var mı? Örnek karşılaştırma: rastgele seçilen beş kaydı sayfadaki haliyle gözle karşılaştırma. Hesabı kendi saat ücretinizle kurun Yukarıdaki kontroller karmaşık değil ama yazılması ve kendisi de bakım isteyen ek koddur; hesabınıza dahil edin. Karşılaştırmayı duyguyla değil sayıyla yapmanın yolu, iki tarafı da aynı birime çevirmek: saat. Aşağıdaki şablonu kendi rakamlarınızla doldurun. Rakamları ben vermiyorum çünkü sizin işinizi bilmiyorum; şablon boş kaldığı sürece karar da havada kalır ve havada kalan kararlar genellikle en kolay görünen seçenek lehine, yani "ben yazarım" diyerek sonuçlanır. Bu hesapta en çok tartışılan satır C, yani aylık ortalama bakım. Kendi deneyiminiz yoksa tahmin etmek zor; pratik bir yaklaşım, ilk üç ayı ölçmek ve gerçek rakamı kullanmaktır. Kodu yazın, her müdahalede harcadığınız süreyi bir yere not edin ve üç ay sonra ortalamayı alın. Bu üç aylık ölçüm, bir yıllık kararı tahmine dayanmaktan kurtarır. İkinci dikkat noktası, bakım saatlerinin takvime düzgün dağılmamasıdır: aylarca hiç dokunmazsınız, sonra bir arayüz değişikliğinde iki gününüzü verirsiniz. Ortalama makul görünse bile, o iki günün tam olarak ne zaman geleceğini seçemezsiniz ve genellikle en yoğun döneminizde gelir. Hesaba girmeyen üçüncü kalem: devir riski Kendi yazdığınız çözüm tek bir kişinin kafasında yaşar. O kişi sizseniz ve işi siz yürütüyorsanız sorun görünmez. Ama kodu ofisteki teknik bilgisi olan bir arkadaşınız yazdıysa, o kişi izne çıktığında ya da işten ayrıldığında elinizde çalışan ama kimsenin dokunamadığı bir program kalır. Bu noktada seçenekleriniz ya baştan yazdırmak ya da hazır bir araca geçmektir; ikisi de aceleye geldiği için pahalıya patlar. Bu riski azaltmanın yolu, kodun yanına iki sayfalık bir not bırakmaktır: hangi sayfalardan hangi alanların alındığı, hangi dosyanın nereye yazıldığı ve bozulduğunda ilk bakılacak yer. Bu notu yazmak da hesaba katılması gereken bir saattir. Yan yana karşılaştırma Konu Kendi kodunuz Hazır program Başlangıç maliyeti Para yok, saat var Lisans bedeli, saat az İlk çalışan sürüme kadar Genellikle bir ila birkaç gün Kurulum ve öğrenme, birkaç saat Arayüz değiştiğinde Siz düzeltirsiniz Sürüm güncellemesiyle gelir Sessiz kırılma koruması Yazarsanız var Genellikle hazır gelir Özel dönüşüm mantığı Sınırsız esneklik Araç ne veriyorsa o Devir edilebilirlik Yazan kişiye bağlı Kılavuz ve destek üzerinden Yeni bir kaynak eklemek Baştan yazmak gerekir Destekliyorsa hazır, desteklemiyorsa yok En büyük risk Bakımın en yoğun günde gelmesi İhtiyacınızın araç kapsamı dışına çıkması Kod yazmanın gerçekten doğru olduğu durumlar Bu bölümü dürüstçe teslim ediyorum, çünkü aşağıdaki durumlarda hazır araç önermek yanlış olur. Veriyi kendi sisteminizden ya da size özel bir arayüzden alıyorsanız, hiçbir hazır program o kaynağı bilmez; kod yazmaktan başka yol yoktur. İhtiyacınız toplama değil de çok özel bir dönüşüm mantığıysa, örneğin kendi fiyatlandırma formülünüzü uygulayıp sonucu kendi veritabanınıza yazmaksa, esneklik hazır aracın kapsamını aşar. Kaynak sizin kontrolünüzdeyse ve sayfa yapısı değişmiyorsa, bakım kalemi neredeyse sıfırdır ve yukarıdaki hesabın en pahalı satırı ortadan kalkar. Bir de öğrenme amacı vardır: bu işin nasıl çalıştığını anlamak için yazılan kodun getirisi çıktı değil, bilgidir ve o bilgi sonraki her kararınızı iyileştirir. Çoğu zaman en dayanıklı çözüm: melez yol İki tarafı da kullanan bir düzen genellikle en az bakım isteyen düzendir. Toplama katmanı, yani sayfaların gezilmesi, oturum yönetimi, tempo ayarı ve arayüz değişikliklerine uyum, en kırılgan kısımdır; bunu hazır bir araca bırakırsınız. Dönüşüm katmanı, yani çıkan tabloyu kendi kurallarınıza göre işleme, kendi kategorilerinizle eşleştirme ve kendi sisteminize yazma kısmı ise sizin kontrolünüzdeki bir dosya biçimi üzerinde çalıştığı için nadiren bozulur; onu kendiniz yazarsınız. Böylece esnekliği kaybetmeden, bakımın en pahalı kısmını üzerinizden atmış olursunuz. Pratikte bu, hazır programın ürettiği Excel veya CSV dosyasını okuyan kırk satırlık bir betikten ibaret olabilir. Hangi yolu seçerseniz seçin, karardan önce şu beş soruyu cevaplayın: Bu veriyi kaç ay boyunca ve hangi sıklıkta toplayacağım? Süre kısaysa bakım kalemi küçülür. Kaynak sayfa benim kontrolümde mi? Değilse değişecek varsayımıyla plan yapın. Kod bozulduğunda düzeltecek kişi ben miyim? Değilse o kişinin müsaitliği artık sizin riskiniz. Çıktı eksik gelirse bunu nasıl fark ederim? Cevabınız yoksa önce doğrulama kontrollerini yazın. Bir saatimin bedeli ne? Bu sayı olmadan iki seçeneği karşılaştıramazsınız. Kendi kodunuzda da yasal çerçeve değişmiyor Aracı kendiniz yazmış olmanız, topladığınız veriye ilişkin yükümlülükleri hafifletmez. Bir gerçek kişiyi belirlenebilir kılan alanlar KVKK kapsamındadır; amaç belirlemek, amaç dışı alan toplamamak ve saklama süresi tanımlamak sizin sorumluluğunuzdadır. Kaynak platformun kullanım şartlarını okuyun ve istekler arasına makul bekleme koyarak sitenin normal işleyişini zorlamayın; kendi kodunuzda bu tempo ayarını hazır bir araç sizin için yapmaz. Sonuç olarak: kendi kodunuzu yazmak ne saçma bir fikir ne de her zaman doğru cevap. Ayrımı belirleyen tek sayı, bakım saatlerinin toplamı. O sayıyı tahminle değil, ilk üç ayı ölçerek bulun; sonra iki seçeneği de saat cinsinden yan yana koyun. Hesap yapıldıktan sonra hangi tarafı seçerseniz seçin, kararınızın arkasında durabilirsiniz. Yapılmadığında olan şey ise şu: bir yıl sonra terk edilen, kimsenin dokunmak istemediği ve o süre boyunca kaç saat yediği hiç hesaplanmamış bir çözüm.
İlk çalışan sürüm, temel bilgisi olan biri için genellikle bir akşamlık iştir. Ama o sürüm bir prototiptir. Sayfalama, sonradan yüklenen içerik, oturum yönetimi, tempo ayarı, karakter kodlaması, hata yönetimi ve kaldığı yerden devam etme eklendiğinde iş birkaç güne çıkar. Gerçek soru "ne kadar sürede yazılır" değil, "yazdıktan sonra ayda kaç saat yiyor" sorusudur; kararı belirleyen ikincisidir.
Kimse güvenilir bir sıklık veremez; siteler tasarım güncellemelerini kendi takvimlerine göre yapar ve önceden duyurmaz. Planlamayı sıklık tahmini üzerine değil, hazırlık üzerine kurun: her çalıştırmadan sonra satır sayısı ve sütun boşluk oranını kontrol eden bir doğrulama adımı ekleyin. Böylece değişiklik ne zaman gelirse gelsin, aynı gün haberiniz olur ve iki haftalık eksik veriyle karşılaşmazsınız.
İlk yazım süresi belirgin biçimde kısalır, bu doğru. Ama bakım kalemi yazma hızıyla değil, kodun neye bağımlı olduğuyla ilgilidir. Sayfa yapısı değiştiğinde kodun hangi kısmının neden bozulduğunu anlamak, düzeltmek ve çıktının doğruluğunu tekrar sınamak yine sizin işiniz olur. Kodu kendiniz yazmadıysanız bu adım genellikle daha uzun sürer, çünkü önce kodu okumanız gerekir.
Çalışıyorsa ve bakımı sizi yormuyorsa bakmanıza gerek yok; bu yazının amacı çalışan bir düzeni bozmak değil. Tekrar değerlendirmeyi tetikleyen üç durum var: bakım saatleri artmaya başladıysa, kodu yazan kişi artık ulaşılabilir değilse ya da yeni bir kaynak eklemek gerektiğinde işin baştan yazılacağını fark ettiyseniz. Bu üçünden biri olmadıkça mevcut çözümünüzde kalmak makul.
Toplama işini hazır bir araca bırakırsınız; o araç sayfaları gezer, oturumu yönetir, tempoyu ayarlar ve size bir Excel veya CSV dosyası verir. Dönüşüm işini kendiniz yazarsınız: o dosyayı okuyan, kendi kategori eşlemenizi uygulayan ve kendi sisteminize yazan bir betik. Bu betik sayfa yapısına değil, sizin kontrolünüzdeki dosya biçimine bağlı olduğu için arayüz değişikliklerinden etkilenmez ve nadiren bakım ister.
Karmaşık bir yönteme gerek yok. Kodu yazdıktan sonra bir metin dosyası açın ve her müdahalede tarih ile harcadığınız süreyi yazın: hangi sütun bozuldu, ne yaptınız, kaç dakika sürdü. Üç ay sonra bu dosyadaki toplamı üçe bölün, aylık ortalamanızı elde edin. Bu ölçüm hem karar hesabınızı tahmine dayanmaktan kurtarır hem de kodu devretmeniz gerektiğinde en değerli belge olur.
Hayır, aracın kim tarafından yazıldığı yükümlülükleri değiştirmez. Kodun sizin olması çıktının içeriğini değiştirmiyor: tabloya ilan sahibinin adı ya da telefonu giriyorsa kişisel veri işliyorsunuz demektir ve amacı, kapsamı ve saklama süresini önceden belirlemeniz gerekir. Kaynak platformun kullanım şartları da geçerliliğini korur. Kendi kodunuzda ek olarak dikkat etmeniz gereken bir nokta var: istek temposunu makul tutmak hazır araçlarda genellikle varsayılan olarak gelirken, sizin kodunuzda bunu bilinçli olarak eklemeniz gerekir.