Yeni bir web projesinde en heyecan verici an genellikle kod yazmaya başladığımız andır. Proje klasörü oluşturulur, kullanılacak paketler kurulur, veritabanı bağlantısı hazırlanır ve ilk ekran yavaş yavaş ortaya çıkmaya başlar.

Ortada çalışan bir şey görmek insana ilerlediğini hissettirir.

Bu nedenle proje henüz tam olarak anlaşılmadan geliştirmeye başlamak çoğu zaman hız kazanmak gibi görünür. Müşteri de geliştirici de ekranda bir sonuç görmek ister. Ana sayfa hazırlanır, yönetim paneline birkaç alan eklenir ve sistemin geri kalanının ilerledikçe şekilleneceği düşünülür.

Fakat web projelerinde en pahalı hatalardan biri tam olarak budur: Ne yapılacağı yeterince anlaşılmadan nasıl yapılacağını belirlemeye başlamak.

Çünkü projenin başında cevaplanmayan sorular ortadan kaybolmaz. Yalnızca kodun içine taşınır. Daha sonra bu soruların cevapları ortaya çıktığında da birkaç satır değiştirmek yetmez; veritabanını, kullanıcı akışını, yönetim panelini ve bazen bütün arayüzü yeniden ele almak gerekir.

Koda erken başlamak ilk günlerde zaman kazandırabilir. Ancak projenin devamında aynı işi birkaç kez yapmaya neden oluyorsa ortada gerçek bir hız yoktur.

Belirsizlik Kod Yazmaya Başlayınca Çözülmez

Bir projeye başlamadan önce bütün ayrıntıların eksiksiz biçimde bilinmesi her zaman mümkün değildir. Geliştirme sırasında yeni ihtiyaçlar ortaya çıkabilir, bazı kararlar değişebilir ve başlangıçta doğru görünen bir yöntem uygulama aşamasında yetersiz kalabilir.

Bu normaldir.

Sorun, değişiklik ihtimalinin bulunması değil; henüz temel kararlar bile verilmeden geliştirmeye başlanmasıdır.

Örneğin bir sistemde “müşteri” kaydı tutulacağı söylenebilir. İlk bakışta ad, telefon, e-posta ve adres alanlarından oluşan basit bir tablo yeterli görünür. Ancak biraz daha konuşulduğunda aynı müşterinin birden fazla şirketi olabileceği, şirketlerde farklı yetkililerin bulunabileceği, her yetkilinin ayrı iletişim bilgileriyle saklanacağı ve kullanıcıların yalnızca kendilerine atanan müşterileri görebileceği anlaşılabilir.

Başlangıçta tek tablo üzerinden kurulan yapı artık yeterli değildir.

Müşteri, şirket, yetkili, kullanıcı ve yetkilendirme ilişkilerinin ayrılması gerekir. Daha önce oluşturulan formlar, sorgular, filtreler ve yönetim ekranları bu yeni yapıya göre yeniden düzenlenir.

Kodun hatalı yazılmış olması gerekmez. Geliştirici, kendisine verilen bilgiye göre temiz ve düzgün bir yapı kurmuş olabilir. Fakat problem yanlış anlaşıldığı için doğru kod yanlış çözümün üzerine yazılmıştır.

Bu yüzden projeye başlamadan önce yalnızca hangi ekranların olacağı değil, sistemde hangi bilgilerin tutulacağı ve bu bilgilerin birbiriyle nasıl ilişki kuracağı da anlaşılmalıdır.

Yanlış Veri Yapısı Projenin Her Yerine Yayılır

Bir web projesinde sonradan değiştirilmesi en maliyetli konulardan biri veri modelidir.

Tasarımda bir rengin, yazı boyutunun veya boşluğun değiştirilmesi çoğu zaman sınırlı bir müdahaledir. Ancak verinin yanlış modellenmesi projenin neredeyse bütün katmanlarını etkileyebilir.

Veritabanı tabloları, model ilişkileri, doğrulama kuralları, yönetim paneli formları, listeleme sorguları, filtreler, raporlar ve yetkilendirme kontrolleri aynı veri yapısına bağlıdır.

Örneğin bir rezervasyon sisteminde toplam ücretin yalnızca tek bir para birimiyle tutulacağı varsayılabilir. Daha sonra sistemde farklı para birimleri, rezervasyon tarihine ait kur bilgisi, kapora, kalan ödeme ve farklı ödeme yöntemlerinin desteklenmesi gerektiği ortaya çıkabilir.

Bu talep yalnızca forma bir “para birimi” alanı eklemekten ibaret değildir.

Toplamların nasıl hesaplandığı, kur değerinin hangi aşamada sabitlendiği, ödeme kayıtlarının rezervasyonla nasıl ilişkilendirildiği ve raporlarda hangi değerin gösterileceği yeniden düşünülmelidir. Önceden yazılmış hesaplamalar ve sorgular yeni yapıya göre değiştirilebilir.

Benzer durum ürün varyantlarında, çoklu dil sistemlerinde, kullanıcı rollerinde ve içerik yönetiminde de görülür.

Bir ürünün yalnızca adı ve fiyatı olacağı düşünülerek kurulan sistem, renk ve beden seçenekleri eklendiğinde değişir. Her varyantın ayrı stok, fiyat ve görsele sahip olması istendiğinde ise yapı tekrar büyür.

Başlangıçta birkaç soru sorularak anlaşılabilecek bu ihtiyaçlar, kodlama başladıktan sonra ortaya çıktığında projenin temelini değiştirebilir.

Bu nedenle veri modeli, teknik ekibin kendi içinde çözeceği soyut bir konu değildir. Projenin gerçek çalışma biçiminin teknik karşılığıdır.

Tasarıma Başlamak da Kodlamaya Başlamak Kadar Erken Olabilir

Koda erken başlama hatası yalnızca arka uç geliştirmede yaşanmaz. Projenin amacı ve içerik yapısı anlaşılmadan arayüz tasarlamak da benzer bir sonuç oluşturur.

Hazır içerikler olmadan hazırlanan bir ana sayfa, kısa başlıklar ve dengeli metin bloklarıyla oldukça iyi görünebilir. Gerçek içerikler eklendiğinde başlıklar uzar, hizmet açıklamaları farklı boyutlara ulaşır ve bazı bölümlerin aslında beklenenden daha fazla bilgi taşıması gerektiği anlaşılır.

Bu durumda sorun yalnızca birkaç metnin kutuya sığmaması değildir. Tasarım, gerçek içeriğin ihtiyaçlarına göre değil; örnek metinlerin oluşturduğu yapay dengeye göre hazırlanmıştır.

Aynı şekilde bir listeleme sayfasının tasarımı yapılırken kullanıcıların hangi bilgilere göre karar vereceği bilinmelidir. Bir araç ilanında marka ve model yeterli olmayabilir. Kilometre, model yılı, yakıt tipi, hasar bilgisi veya satış durumu kart üzerinde görünmek zorunda olabilir.

Bu bilgiler proje ilerledikten sonra eklendiğinde kart tasarımı değişir. Kart genişliği, görsel oranı, filtreleme alanları ve mobil görünüm yeniden ele alınır.

Doğru tasarım yalnızca estetik bir ekran hazırlamak değildir. İçeriğin önceliğini, kullanıcının karar verme biçimini ve sistemin sunduğu işlevleri görsel bir düzene dönüştürmektir.

Bu bilgiler netleşmeden oluşturulan arayüz güzel görünebilir. Ancak projenin gerçek ihtiyacını taşımayabilir.

“Sonradan Ekleriz” Her Zaman Küçük Bir İş Değildir

Web projelerinde bazı özelliklerin ilk sürüme yetişmesi gerekmeyebilir. Sistemin önce temel işlevlerle yayına alınması ve zaman içinde geliştirilmesi oldukça mantıklı bir yöntemdir.

Ancak “sonradan ekleriz” kararı verilirken o özelliğin bugünkü yapıyı etkileyip etkilemediğine bakmak gerekir.

Çoklu dil desteği buna iyi bir örnektir. İkinci dil birkaç ay sonra yayınlanacak olabilir. Buna rağmen veritabanı, URL yapısı, içerik modelleri ve SEO alanları en başından çoklu dile uygun tasarlanabilir.

Aksi hâlde ikinci dil eklenirken yalnızca metinlerin çevrilmesi yetmez. Veritabanındaki alanların yapısı, slug üretimi, yönlendirmeler, canonical ve hreflang etiketleri, yönetim paneli formları ve site haritası yeniden düzenlenebilir.

Benzer durum kullanıcı rolleri için de geçerlidir. İlk aşamada sistemi yalnızca tek bir yöneticinin kullanacağı düşünülebilir. Daha sonra çalışan, editör, müşteri ve bayi gibi farklı kullanıcıların sisteme erişmesi istendiğinde mevcut sorguların ve işlemlerin yetkilendirme mantığıyla yeniden ele alınması gerekebilir.

Bir özellik ileride geliştirilebilir. Fakat o özelliğin ileride geleceği biliniyorsa sistemin temeli buna göre hazırlanmalıdır.

Buradaki amaç kullanılmayacak her ihtimali projeye eklemek değildir. Aksine, gereksiz geliştirmeden kaçınırken yakın gelecekte beklenen ihtiyaçların önünü kapatmamaktır.

Proje Planlamak Yüzlerce Sayfalık Doküman Hazırlamak Değildir

Planlama denildiğinde bazen aylarca toplantı yapılan, her butonun davranışının uzun dokümanlarla tarif edildiği ağır bir süreç anlaşılıyor.

Her web projesinin böyle bir hazırlığa ihtiyacı yoktur.

Beş sayfalık kurumsal bir site ile farklı kullanıcı rolleri, ödeme akışları, raporlar ve harici entegrasyonlar içeren bir yazılım aynı şekilde planlanmaz. Planlamanın kapsamı projenin büyüklüğüne ve riskine göre belirlenmelidir.

Fakat proje küçük de olsa bazı temel soruların cevaplanması gerekir:

  • Web sitesi veya yazılım hangi problemi çözecek? Projenin temel amacı açık değilse geliştirilen özelliklerin gerekli olup olmadığı değerlendirilemez.

  • Sistemi kimler kullanacak? Ziyaretçi, yönetici, editör, çalışan, müşteri veya bayi gibi kullanıcıların yetkileri ve ihtiyaçları birbirinden farklıdır.

  • Hangi veriler tutulacak? İçerikler, kullanıcılar, ürünler, rezervasyonlar veya işlemler arasındaki ilişkiler belirlenmelidir.

  • Temel kullanıcı akışları nasıl ilerleyecek? Kullanıcı sisteme nereden girecek, hangi adımları tamamlayacak ve işlem sonucunda ne olacak?

  • Hangi alanlar yönetim panelinden değiştirilecek? Her içeriğin kod üzerinden güncellenmesi beklenemeyeceği gibi, hiçbir zaman değişmeyecek alanları da gereksiz yere dinamikleştirmek doğru değildir.

  • Harici servis bağlantıları bulunacak mı? Ödeme sistemi, CRM, kargo, muhasebe, harita, e-posta veya farklı bir API kullanılacaksa sınırları baştan bilinmelidir.

  • İlk sürümde neler yer alacak? Zorunlu özelliklerle daha sonra geliştirilebilecek özellikler ayrılmalıdır.

  • Başarı neye göre değerlendirilecek? Projenin tamamlandığını yalnızca bütün sayfaların açılması değil, belirlenen işlemlerin doğru biçimde çalışması göstermelidir.

Bu sorular için her zaman uzun bir teknik doküman hazırlamak gerekmez. Bazen doğru hazırlanmış bir özellik listesi, birkaç kullanıcı akışı ve temel veri ilişkilerini gösteren bir şema yeterlidir.

Önemli olan belge üretmek değil, geliştirilecek sistemi ortak biçimde anlamaktır.

İlk Ekrandan Önce Görülmesi Gerekenler

Ben bir projeyi değerlendirirken önce ekranda ne görüneceğine değil, o ekranın hangi işleyişin parçası olduğuna bakmayı daha doğru buluyorum.

Bir kayıt formu hazırlanacaksa formun hangi alanları içereceği kadar, kaydın sonrasında ne olacağı da önemlidir. Veri yalnızca saklanacak mı, bir yöneticiye bildirim mi gönderilecek, başka bir servise mi aktarılacak veya belirli bir onay sürecinden mi geçecek?

Bir listeleme sayfası hazırlanacaksa yalnızca kartların tasarımı değil, verilerin nereden geleceği, nasıl filtreleneceği, hangi sırayla gösterileceği ve kullanıcıya göre değişip değişmeyeceği düşünülmelidir.

Bir yönetim paneli oluşturulacaksa yöneticinin içerik ekleyebilmesi tek başına yeterli olmayabilir. Kayıtları toplu olarak düzenleme, dışa aktarma, arama, filtreleme veya farklı çalışanlara atama ihtiyacı bulunabilir.

Bunların hepsi ilk günden kodlanmak zorunda değildir. Ancak sistemin ileride nereye büyüyebileceğini anlamak, bugünkü teknik kararların daha sağlıklı verilmesini sağlar.

Projenin ilk aşamasında harcanan birkaç saat bazen ileride günlerce sürecek yeniden geliştirmeyi engeller. Buna karşılık aceleyle yazılan yüzlerce satır kod, yanlış bir varsayım üzerine kurulduysa ilerleme değil teknik borç üretir.

Her Değişiklik Planlama Hatası Değildir

Proje başladıktan sonra yeni taleplerin ortaya çıkması her zaman başlangıç planının kötü olduğu anlamına gelmez.

Kullanıcılar sistemi kullanmaya başladığında daha önce düşünülmeyen ihtiyaçlar fark edilebilir. İşletmenin çalışma biçimi değişebilir. Harici bir servis yeni şartlar getirebilir veya ilk sürümden alınan veriler farklı bir geliştirme yönü gösterebilir.

Yazılım yaşayan bir yapıdır ve değişmesi doğaldır.

Burada önemli olan normal gelişimle temel belirsizliği birbirinden ayırmaktır.

Mevcut kullanıcı akışının küçük bir bölümünü iyileştirmek revizyon olabilir. Başlangıçta yalnızca yönetici kullanımına göre hazırlanan sistemi çok kullanıcılı ve yetkilendirmeli bir yapıya dönüştürmek ise kapsam değişikliğidir.

Bir formdaki alanların sırasını değiştirmek revizyondur. Forma eklenen yeni bilginin ayrı bir tablo, raporlama yapısı ve onay süreci gerektirmesi yeni geliştirmedir.

Bu ayrım açık yapılmadığında proje boyunca eklenen her talep küçük bir düzenleme gibi görülür. Ancak teknik tarafta bu değişiklikler birikerek sistemin temelini etkileyebilir.

Sağlıklı planlama değişiklikleri tamamen ortadan kaldırmaz. Değişikliklerin etkisini ölçülebilir hâle getirir.

Gerçek Hız, İlk Commit’i Erken Atmak Değildir

Bir web projesinde hızlı ilerlemek değerlidir. Ancak hızın ölçüsü ilk gün kaç ekran hazırlandığı veya kaç satır kod yazıldığı olmamalıdır.

Asıl hız, doğru yapıyı mümkün olduğunca az geri dönüşle kurabilmektir.

Projenin başında kullanıcıları, verileri ve temel akışları anlamak dışarıdan bakıldığında üretim yapılmıyormuş gibi görünebilir. Ortada henüz bir ana sayfa, yönetim paneli veya çalışan form yoktur. Buna rağmen projenin en kritik kararları o aşamada verilir.

Hangi verinin nerede tutulacağı, hangi işlemin kim tarafından yapılacağı, sistemin hangi sınırlar içinde çalışacağı ve gelecekte hangi yönlere büyüyebileceği netleştikçe kodlama süreci yavaşlamaz. Tam tersine, geliştirici sürekli karar değiştirmek zorunda kalmadan ilerleyebilir.

Planlama yapılmadan başlanan projede kod hızla büyür fakat belirsizlik de kodla birlikte büyür. Her yeni bilgi eski bir varsayımı bozar. Bir sayfada yapılan değişiklik yönetim paneline, veritabanına ve diğer kullanıcı akışlarına yayılır. Proje ilerliyor gibi görünürken aynı bölümler tekrar tekrar geliştirilir.

İyi planlanan projede ise bütün ayrıntılar baştan bilinmese bile temel yön bellidir. Hangi konuların kesinleştiği, hangi alanların değişebileceği ve hangi özelliklerin sonraki sürüme bırakıldığı anlaşılır durumdadır.

Bu yüzden koda başlamadan önce geçirilen süreyi gecikme olarak görmüyorum. O süre, yanlış çözümü hızlı biçimde üretmemek için yapılan ilk teknik çalışmadır.

İlk commit birkaç saat veya birkaç gün geç atılabilir. Fakat doğru problem üzerine atılıyorsa projenin geri kalanında bu zaman fazlasıyla geri kazanılır.

Çünkü bir web projesinde en pahalı kod, yazılması uzun süren kod değildir.

İhtiyaç olmadığı hâlde yazılan veya yanlış anlaşılan bir ihtiyacı kusursuz biçimde çözen koddur.