Merhaba,
Özel sektörde "aynı standartlarda" kod yazabileceğiniz bir ekip olduğu zaman değişken, fonksiyon isimlendirmelerinden hangi fonksiyonun hangi sınıfta, datamodule'de veya pas dosyasında doğrudan implement edildiğini öğretmenize gerek kalmaz.
Aynı standartlara yükselteceğiniz yazılımcılar için ise yapmanız gereken tek şey; "empati"
@
Fesih ARSLAN bey'in söylediği gibi; "nasıl bulmak istiyorsan öyle bırak" felsefesi bu alandaki en büyük yaklaşımdır. Nitekim aynı doğruyu ben de şu sözlerle söylerim hep; "bu kodu birisi bana bıraksa nasıl en çabuk anlardım?" sorusu üzerine bana soru sorabileceği tüm karmaşık noktaları yorum satırları, summary blokları ve açıklayıcı dokümanı olan proje varsa fonksiyonun ne işe yaradığını, argümanları ve return değerlerini açık açık belirtirim.
Yeni birisini mevcut projeye dahil ettiğiniz zaman birçok noktaya dependency (bağımlılık) olan kütüphanelere ilk aşamada dokunması riskli olur. Eğer yeni kişinin kodlarını birleştirdikten sonra testlerini yapacak vaktiniz veya planınız yoksa. Bu yüzden başka modüllerle ilişkisi olmayan veya en az ilişkisi olan veya en az riskli bulduğunuz modüllerde yapılacak iyileştirmeleri yada tamamen modülün geliştirilmesini devrederek başlarsınız.
Biz genellikle Database-First prensibi ile uygulama üretiyoruz. Yani database-driven application dediğimiz veritabanı uygulamalarında koda dokunacak kişinin önce veritabanına hakim olması veya en azından tablolara dair aklındaki birçok sorunun ortadan kalkması gerekir. Bu da projenin içindeki etkisine doğrudan katkısını etkileyen bir unsur. Öncelikle neyi kodlayacağını bilmeli.
OOP yaklaşımında üreteceğiniz projelerde DB-First prensibinden ötürü tüm tablolar, viewler, stored prosedürler için varlıklar tanımlanır. Böylelikle ihtiyaç doğrutulsunda neye ne zaman ne şekilde ihtiyacının olacağını da kestirebilir.
Tam bu noktada çok katmanlı yapılar ortaya çıkıyor. Design Pattern (tasarım deseni) kavramı, yazılımınızın ihtiyaçlarını tespit ettikten sonra çıkartacağınız şablonu belirlemenizi kolaylaştırır. Belirleyeceğiniz şablona göre katmanlar ve neyi nerede tutacağınızı belirlersiniz. Örn: veritabanına erişim sadece Data Access Layer için mümkün olmalı. Uygulama içinde herhangi bir yerde bir (select-insert-update-delete) vt işlemi olursa işlemi yönetecek sınıf kesinlikle ilgili tablonun (veya varlığın) data access sınıfı olmalıdır. Bu sınıftan alınan ham veriyi taşıyan, try catch ve kontrollerden geçiren bir iş katmanı Business Logic Layer olmalı. Presentation (sunum) katmanı ise soyut olarak business katmanından beslenmeli. Böylelikle uygulamadaki veri akışının temel bir mantığı oluşur.
Bu kadar şeyi neden anlattım? Oluşturacağınız disiplin, prensip, kavram, şablon, tasarım, desen, veya ne demek isterseniz, sizin belirlediğiniz standartları kendisi oluşturur. Yeni birisine en azından girip mevcut bir modül için tüm yapıyı görmesi, kısa sürede sizin stilinize ayak uydurmasını sağlayacaktır.
50+ satırlık kod blokları olduğu yerde kesinlikle region kullanırım. Bazen bazı fonksiyonlarda 5 satır kod bile olsa region kullanırım. Bir projede assembly kütüphanesinin topladığı bir veriyi işleme ve manipülasyon işlemleri için 3 satırı region yapmışlığım vardır. Bunun sebebi kodun okunurluğunu arttırmaktır.
"İyi/temiz bir kod, başka geliştirici/ler tarafından rahatlıkla okunabilen ve geliştirilebilen koddur."
) hocalarımın taktiklerini çok merak ediyorum.