Boilerplate Kâbusuna Son: NestJS Geliştirmeyi Otomatikleştiren Kod Üretici Nasıl Geliştirdim?
Modern yazılım geliştirme süreçleri, hız ve verimlilik odaklıdır. Ancak, bu süreçlerde sıkça karşılaşılan bir engel var: boilerplate kodlar. Özellikle NestJS gibi yapılandırılmış framework’lerde, belirli bir standartta proje geliştirmek, tekrar eden birçok dosya ve kod bloğu yazmayı gerektirebilir. Bu makalede, NestJS projelerinde bu tekrarlayan iş yükünü ortadan kaldırmak için nasıl bir kod üretici geliştirdiğimi, bu sürecin arkasındaki motivasyonu, kullanılan teknolojileri ve elde edilen faydaları adım adım anlatacağım. Amacım, geliştiricilerin daha yaratıcı ve problem çözme odaklı çalışmasına olanak tanımak.
Boilerplate Nedir ve Neden Sorunlu?
Yazılım dünyasında “boilerplate” terimi, bir projenin veya modülün çalışması için gerekli olan, ancak iş mantığına doğrudan katkıda bulunmayan, sıkça tekrarlayan kod parçacıklarını ifade eder. Genellikle dosya yapılandırmaları, temel sınıf tanımları, import ifadeleri ve standart metot iskeletleri bu kategoriye girer.
Tekrarlayan Kodun Tanımı
Boilerplate, her yeni özellik veya kaynak (resource) eklediğinizde aynı veya çok benzer şekilde tekrar tekrar yazmak zorunda kaldığınız kodlardır. Örneğin, bir kullanıcı modülü için user.module.ts, user.service.ts, user.controller.ts, create-user.dto.ts, update-user.dto.ts gibi dosyaları oluşturmak ve içlerine standart import’ları, sınıf tanımlarını eklemek bir boilerplate örneğidir.
Geliştirme Hızına Etkisi
Her yeni özellik için bu tekrarlayan kodları manuel olarak yazmak, geliştirme sürecini önemli ölçüde yavaşlatır. Geliştiriciler, asıl iş mantığına odaklanmak yerine, temel yapılandırma ve dosya oluşturma işlemleriyle zaman kaybederler. Bu durum, özellikle büyük ve hızlı tempolu projelerde ciddi bir verimlilik düşüşüne yol açar.
Hata Potansiyeli ve Bakım Zorluğu
Manuel olarak yazılan tekrarlayan kodlar, insan hatasına açıktır. Yanlış bir dosya adı, eksik bir import veya hatalı bir sınıf tanımı, projenin derlenmemesine veya beklenmedik davranışlara neden olabilir. Ayrıca, bir standartta değişiklik yapıldığında, bu değişikliği projenin her yerinde manuel olarak uygulamak, bakım maliyetini artırır ve tutarlılığı bozabilir.
NestJS’te Boilerplate Neden Daha Belirgin?
NestJS, modüler ve katmanlı mimarisiyle bilinen, güçlü bir Node.js framework’üdür. Bu yapı, projelere düzen ve ölçeklenebilirlik kazandırırken, beraberinde belirli bir düzeyde boilerplate getirme potansiyeli taşır.
Modüler Yapının Getirdikleri
NestJS’in her şeyin bir modül olduğu felsefesi, uygulamanın temiz ve düzenli kalmasını sağlar. Ancak, her yeni birim (örneğin, bir “ürün” veya “sipariş” kaynağı) için ayrı bir modül, servis, kontrolcü ve ilgili DTO’lar oluşturmak, belirli bir kalıp içinde tekrarlayan dosya ve kod blokları anlamına gelir. NestJS CLI, bu süreçte başlangıçta yardımcı olsa da, daha karmaşık ve özelleştirilmiş şablonlar için yetersiz kalabilir.
// products.module.ts import { Module } from '@nestjs/common'; import { ProductsService } from './products.service'; import { ProductsController } from './products.controller'; @Module({ controllers: [ProductsController], providers: [ProductsService], }) export class ProductsModule {}
Yukarıdaki gibi basit bir modül tanımı bile, her yeni kaynak için tekrarlanır.
CRUD İşlemleri ve Katmanlı Mimari
Çoğu web uygulaması, temel CRUD (Create, Read, Update, Delete) operasyonlarına dayanır. NestJS'in kontrolcü, servis ve veritabanı (repository/entity) katmanları arasındaki ayrımı, bu işlemler için her katmanda ayrı ayrı kod yazmayı gerektirir. Örneğin, bir "ürün" kaynağı için createProduct, findAllProducts, findOneProduct, updateProduct, removeProduct metotlarını hem kontrolcüde hem de serviste tanımlamak standart bir uygulamadır.
DTO'lar, Entity'ler ve Validator'lar
Veri transfer nesneleri (DTO'lar) ve veritabanı varlıkları (Entity'ler), NestJS uygulamalarında veri doğrulama ve tip güvenliği için kritik öneme sahiptir. class-validator ve class-transformer gibi kütüphanelerle birlikte kullanıldığında, her DTO ve Entity için property'leri ve doğrulama kurallarını tanımlamak, oldukça fazla tekrarlayan kod demektir. Özellikle, CreateDTO ve UpdateDTO arasındaki farklar genellikle küçüktür, ancak yine de ayrı ayrı tanımlanmaları gerekir.
Kod Üretici Fikri Nasıl Doğdu?
Her geliştirici gibi, ben de tekrarlayan görevlerden sıkıldığım ve daha verimli yollar aradığım anlar yaşadım. NestJS projelerimde sürekli aynı dosya yapılarını oluşturmak, benzer metotları yazmak, bir süre sonra "Bunun daha kolay bir yolu olmalı!" dedirtti.
Sürekli Tekrarlayan Görevler
Bir projede yeni bir özellik geliştirmeye başlarken, ilk adım genellikle ilgili dosyaları ve temel yapılandırmayı oluşturmaktır. Bu, modül, kontrolcü, servis, DTO'lar ve bazen de entity dosyalarını manuel olarak oluşturup, içlerine temel şablonları kopyala-yapıştır yapmak anlamına geliyordu. Bu, hem zaman alıcı hem de sıkıcı bir süreçti.
Proje Başlangıç Süreçleri
Yeni bir NestJS projesine başlarken veya mevcut bir projeye büyük bir modül eklerken, baştan sona tüm bu boilerplate'ı kurmak, projenin ilk aşamalarında bile yavaşlamaya neden oluyordu. Bu durum, geliştirme motivasyonunu düşürebiliyordu.
Verimlilik Arayışı
Ana motivasyonum, geliştirme sürecini hızlandırmak ve beni asıl iş mantığına odaklanmaya teşvik etmekti. Eğer bir CLI komutuyla tüm bu temel yapıyı saniyeler içinde oluşturabilirsem, hem zamandan tasarruf edecek hem de daha az hata yapacaktım. Bu fikir, bir kod üretici geliştirme yolculuğumun başlangıcı oldu.
Temel Mimari ve Kullanılan Teknolojiler
Kod üret