Her yaz\u0131l\u0131m projesinde, ba\u015flang\u0131\u00e7ta belirlenen hedefler ile biti\u015f noktas\u0131nda elde edilen \u00fcr\u00fcn aras\u0131nda bir gerilim ya\u015fan\u0131r. Bu gerilimin en yayg\u0131n nedenlerinden ikisi, “gereksinim kaymas\u0131” ve “pasif kay\u0131tlar\u0131n hala say\u0131lmas\u0131” sorunudur. Yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bu durumlar, hem proje b\u00fct\u00e7elerini ve zaman \u00e7izelgelerini alt\u00fcst edebilir hem de nihai \u00fcr\u00fcn\u00fcn kalitesini ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ciddi \u015fekilde tehlikeye atabilir. \u00d6zellikle T\u00fcrkiye’deki dinamik i\u015f ortam\u0131nda, h\u0131zla de\u011fi\u015fen pazar ko\u015fullar\u0131 ve m\u00fc\u015fteri beklentileri, gereksinimlerin s\u00fcrekli evrilmesine zemin haz\u0131rlarken, mevcut sistemlerdeki “silinmi\u015f” veya “pasif” olarak i\u015faretlenmi\u015f verilerin yanl\u0131\u015fl\u0131kla aktif veri k\u00fcmeleriyle birlikte i\u015flenmesi, i\u015fletmeler i\u00e7in kritik operasyonel ve raporlama hatalar\u0131na yol a\u00e7abilir. Bu makalede, bu iki temel sorunu derinlemesine inceleyecek, nedenlerini analiz edecek, somut \u00f6rnekler ve kod pratikleriyle \u00e7\u00f6z\u00fcm yollar\u0131n\u0131 sunacak ve geli\u015ftiricilerin bu tuzaklardan nas\u0131l ka\u00e7\u0131nabilece\u011fine dair kapsaml\u0131 bir rehber sunaca\u011f\u0131z.<\/p>\n
Gereksinim kaymas\u0131, di\u011fer ad\u0131yla kapsam kaymas\u0131 (scope creep), bir projenin ba\u015flang\u0131\u00e7taki tan\u0131m\u0131n\u0131n, projenin ilerleyen a\u015famalar\u0131nda kontrols\u00fcz bir \u015fekilde geni\u015flemesi ve ek gereksinimlerin s\u00fcrekli olarak eklenmesi durumudur. Bu durum, “her yapt\u0131\u011f\u0131m d\u00fczeltme yeni bir gereksinim ekledi” ifadesiyle \u00f6zetlenebilir ve proje ekipleri i\u00e7in ciddi bir kabusa d\u00f6n\u00fc\u015febilir. Gereksinim kaymas\u0131n\u0131n ard\u0131nda yatan bir\u00e7ok neden bulunmaktad\u0131r. En ba\u015fta, projenin ba\u015flang\u0131c\u0131nda gereksinimlerin yeterince net ve detayl\u0131 bir \u015fekilde tan\u0131mlanmamas\u0131 gelir. Payda\u015flar\u0131n (stakeholder) beklentilerinin tam olarak anla\u015f\u0131lmamas\u0131 veya zamanla de\u011fi\u015fen i\u015f ihtiya\u00e7lar\u0131 da bu duruma zemin haz\u0131rlar. Bazen de m\u00fc\u015fteri, \u00fcr\u00fcn\u00fc kulland\u0131k\u00e7a yeni fikirler edinir ve bunlar\u0131n hemen sisteme eklenmesini talep ederken, geli\u015ftirme ekibi bu talepleri yeterli bir de\u011fi\u015fim y\u00f6netimi s\u00fcreci olmadan kabul edebilir. Ayr\u0131ca, teknolojik geli\u015fmelerin h\u0131zla ilerlemesi, rakiplerin yeni \u00f6zellikler sunmas\u0131 gibi d\u0131\u015f fakt\u00f6rler de gereksinimlerin s\u00fcrekli revize edilmesine neden olabilir. T\u00fcrkiye’deki bir\u00e7ok k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli i\u015fletmenin (KOB\u0130) dijitalle\u015fme s\u00fcre\u00e7lerinde, ba\u015flang\u0131\u00e7ta basit bir web sitesi veya e-ticaret platformu olarak planlanan projelerin, s\u00fcre\u00e7 i\u00e7erisinde CRM entegrasyonu, geli\u015fmi\u015f raporlama mod\u00fclleri ve hatta mobil uygulama talepleriyle nas\u0131l b\u00fcy\u00fcd\u00fc\u011f\u00fcne s\u0131k\u00e7a \u015fahit olunur. Bu durum, ba\u015flang\u0131\u00e7ta belirlenen b\u00fct\u00e7eyi ve zaman \u00e7izelgesini a\u015farak, projenin tamamlanmas\u0131n\u0131 geciktirir ve hatta baz\u0131 durumlarda iptaline yol a\u00e7abilir. Ekibin moralini d\u00fc\u015f\u00fcr\u00fcr, geli\u015ftiriciler s\u00fcrekli de\u011fi\u015fen hedefler kar\u015f\u0131s\u0131nda motivasyonlar\u0131n\u0131 kaybedebilirler. Kalite d\u00fc\u015f\u00fc\u015f\u00fc, artan maliyetler ve son teslim tarihlerinin ka\u00e7\u0131r\u0131lmas\u0131 gibi olumsuz etkiler, gereksinim kaymas\u0131n\u0131n ka\u00e7\u0131n\u0131lmaz sonu\u00e7lar\u0131d\u0131r.<\/p>\n
Gereksinim kaymas\u0131n\u0131 etkin bir \u015fekilde y\u00f6netmek i\u00e7in \u00e7e\u015fitli stratejiler mevcuttur. \u00d6ncelikle, \u00e7evik metodolojiler (Agile methodologies) bu konuda olduk\u00e7a ba\u015far\u0131l\u0131d\u0131r. Scrum veya Kanban gibi yakla\u015f\u0131mlar, k\u0131sa sprintler ve s\u00fcrekli geri bildirim d\u00f6ng\u00fcleri sayesinde de\u011fi\u015fen gereksinimlere daha esnek bir \u015fekilde uyum sa\u011flamay\u0131 m\u00fcmk\u00fcn k\u0131lar. Her sprint sonunda \u00e7al\u0131\u015fan bir \u00fcr\u00fcn par\u00e7as\u0131 sunularak, payda\u015flar\u0131n geri bildirimleri erken a\u015famada al\u0131n\u0131r ve olas\u0131 kaymalar daha ba\u015flamadan \u00f6nlenebilir. \u0130kinci olarak, gereksinimlerin net bir \u015fekilde belgelenmesi hayati \u00f6nem ta\u015f\u0131r. Kullan\u0131c\u0131 hikayeleri (user stories), kabul kriterleri (acceptance criteria) ve prototipler, t\u00fcm payda\u015flar\u0131n ayn\u0131 \u015feyi anlad\u0131\u011f\u0131ndan emin olman\u0131n en iyi yollar\u0131d\u0131r. \u00dc\u00e7\u00fcnc\u00fc olarak, resmi bir de\u011fi\u015fim kontrol s\u00fcreci (change control process) olu\u015fturulmal\u0131d\u0131r. Yeni bir gereksinim talebi geldi\u011finde, bunun projenin kapsam\u0131na, b\u00fct\u00e7esine ve zaman \u00e7izelgesine etkileri de\u011ferlendirilmeli, onay mekanizmalar\u0131ndan ge\u00e7irilmelidir. MoSCoW (Must have, Should have, Could have, Won’t have) gibi \u00f6nceliklendirme teknikleri, hangi gereksinimlerin ger\u00e7ekten kritik oldu\u011funu belirlemede yard\u0131mc\u0131 olabilir. Son olarak, payda\u015flarla d\u00fczenli ve \u015feffaf ileti\u015fim kurmak, beklentileri y\u00f6netmek ve projenin mevcut durumu hakk\u0131nda bilgi vermek, gereksinim kaymas\u0131n\u0131n \u00f6n\u00fcne ge\u00e7mek i\u00e7in kritik bir ad\u0131md\u0131r. \u00d6rne\u011fin, \u0130zmir’de faaliyet g\u00f6steren bir yaz\u0131l\u0131m firmas\u0131n\u0131n, m\u00fc\u015fterisinin talebi \u00fczerine geli\u015ftirdi\u011fi envanter y\u00f6netim sistemi projesinde, ba\u015flang\u0131\u00e7ta sadece \u00fcr\u00fcn takibi \u00f6ng\u00f6r\u00fcl\u00fcrken, s\u00fcre\u00e7 i\u00e7erisinde depo optimizasyonu ve tedarik\u00e7i entegrasyonu gibi ek talepler gelmi\u015ftir. Firma, \u00e7evik metodolojileri benimseyerek ve her yeni talebi resmi bir de\u011fi\u015fim talebi olarak de\u011ferlendirerek, projenin kontrol alt\u0131nda kalmas\u0131n\u0131 sa\u011flam\u0131\u015f ve beklenmedik maliyet art\u0131\u015flar\u0131n\u0131n \u00f6n\u00fcne ge\u00e7mi\u015ftir.<\/p>\n
Yaz\u0131l\u0131m sistemlerinde kar\u015f\u0131la\u015f\u0131lan bir di\u011fer \u00f6nemli sorun ise, “pasif kay\u0131tlar\u0131n hala say\u0131lmas\u0131” problemidir. Bu durum, genellikle bir veritaban\u0131nda “silinmi\u015f” veya “pasif” olarak i\u015faretlenmi\u015f verilerin, uygulama katman\u0131ndaki sorgular veya raporlama mekanizmalar\u0131 taraf\u0131ndan yanl\u0131\u015fl\u0131kla aktif verilerle birlikte i\u015flenmesiyle ortaya \u00e7\u0131kar. Bu problem, \u00f6zellikle “soft delete” (mant\u0131ksal silme) yakla\u015f\u0131m\u0131n\u0131n kullan\u0131ld\u0131\u011f\u0131 sistemlerde yayg\u0131nd\u0131r. “Hard delete” (fiziksel silme) durumunda veri tamamen veritaban\u0131ndan silinirken, “soft delete” y\u00f6nteminde veri fiziksel olarak kal\u0131r ancak bir bayrak (\u00f6rne\u011fin, Pasif kay\u0131tlar\u0131n do\u011fru \u015fekilde filtrelenmemesi, i\u015fletmeler i\u00e7in \u00e7ok \u00e7e\u015fitli ve ciddi sonu\u00e7lar do\u011furabilir. En belirgin sonu\u00e7, yanl\u0131\u015f raporlama ve hatal\u0131 analizlerdir. \u00d6rne\u011fin, bir e-ticaret platformunda sat\u0131\u015f\u0131 durdurulmu\u015f (pasif) \u00fcr\u00fcnlerin hala envanterde say\u0131lmas\u0131, stok y\u00f6netimini ve sipari\u015f s\u00fcre\u00e7lerini aksat\u0131r. Bir finans uygulamas\u0131nda kapat\u0131lm\u0131\u015f (pasif) hesaplar\u0131n toplam aktif hesap say\u0131s\u0131na dahil edilmesi, finansal tablolar\u0131 ve \u015firket de\u011ferlemesini yan\u0131lt\u0131c\u0131 hale getirir. Bu durum, stratejik kararlar\u0131n yanl\u0131\u015f verilmesine, kaynaklar\u0131n hatal\u0131 tahsis edilmesine ve hatta yasal d\u00fczenlemelere (KVKK, GDPR gibi) uyumsuzluk nedeniyle a\u011f\u0131r para cezalar\u0131na yol a\u00e7abilir. Kullan\u0131c\u0131lar a\u00e7\u0131s\u0131ndan ise, pasif i\u00e7eri\u011fin hala arama sonu\u00e7lar\u0131nda g\u00f6r\u00fcnmesi veya sistemde aktifmi\u015f gibi listelenmesi, kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131na ve k\u00f6t\u00fc bir kullan\u0131c\u0131 deneyimine neden olabilir. \u0130stanbul’daki bir bankan\u0131n kredi ba\u015fvuru sisteminde, ge\u00e7mi\u015fte reddedilmi\u015f veya iptal edilmi\u015f ba\u015fvurular\u0131n, yeni ba\u015fvuru istatistiklerine dahil edilmesi, bankan\u0131n risk analizi modellerini bozmu\u015f ve yanl\u0131\u015f kredi politikalar\u0131 olu\u015fturmas\u0131na neden olmu\u015ftur. Bu t\u00fcr hatalar, sadece finansal kay\u0131plara de\u011fil, ayn\u0131 zamanda kurumun itibar\u0131na da zarar verebilir. Bu nedenle, soft delete mekanizmas\u0131 kullan\u0131l\u0131rken, veritaban\u0131 tasar\u0131m\u0131 ve uygulama katman\u0131 kodlamas\u0131nda veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flamak i\u00e7in titizlikle hareket etmek gerekmektedir. Pasif kay\u0131t y\u00f6netimi, sadece teknik bir konu olman\u0131n \u00f6tesinde, i\u015f s\u00fcre\u00e7lerinin do\u011frulu\u011funu ve yasal uyumlulu\u011fu do\u011frudan etkileyen stratejik bir konudur.<\/p>\n Veritaban\u0131 d\u00fczeyinde soft delete mekanizmalar\u0131n\u0131 do\u011fru bir \u015fekilde tasarlamak yeterli de\u011fildir; uygulama katman\u0131nda da bu pasif kay\u0131tlar\u0131n tutarl\u0131 bir \u015fekilde y\u00f6netilmesi ve filtrelenmesi esast\u0131r. Geli\u015ftiricilerin bu konuda benimseyebilece\u011fi \u00e7e\u015fitli g\u00fcvenli kod pratikleri ve otomasyon stratejileri bulunmaktad\u0131r. Modern yaz\u0131l\u0131m geli\u015ftirme yakla\u015f\u0131mlar\u0131nda, nesne-ili\u015fkisel e\u015fleyici (ORM – Object-Relational Mapping) k\u00fct\u00fcphaneleri (\u00f6rne\u011fin C# i\u00e7in Entity Framework, Java i\u00e7in Hibernate) s\u0131k\u00e7a kullan\u0131l\u0131r. Bu ORM’ler, soft delete mant\u0131\u011f\u0131n\u0131 uygulama genelinde merkezi bir yerden y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc \u00f6zellikler sunar. \u00d6rne\u011fin, Entity Framework’te “Global Query Filters” (Global Sorgu Filtreleri) \u00f6zelli\u011fi sayesinde, bir varl\u0131k (entity) i\u00e7in tan\u0131mlanan filtre, o varl\u0131\u011fa yap\u0131lan t\u00fcm sorgulara otomatik olarak uygulan\u0131r. Bu, geli\u015ftiricinin her sorguda manuel olarak Benzer \u015fekilde, Repository (veri deposu) tasar\u0131m deseni, veri eri\u015fim mant\u0131\u011f\u0131n\u0131 bir araya toplayarak soft delete filtrelemesini merkezile\u015ftirmek i\u00e7in ideal bir yap\u0131d\u0131r. Bir Bu \u00f6rnekte, Otomasyon, pasif kay\u0131t y\u00f6netiminde kilit bir rol oynar. Birim testleri (unit tests), entegrasyon testleri (integration tests) ve u\u00e7tan uca testler (end-to-end tests) yazmak, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fcn sa\u011flanmas\u0131nda kritik \u00f6neme sahiptir. \u00d6zellikle, soft-deleted kay\u0131tlar\u0131n do\u011fru bir \u015fekilde filtrelendi\u011fini ve yanl\u0131\u015fl\u0131kla raporlara veya kullan\u0131c\u0131 aray\u00fczlerine yans\u0131mad\u0131\u011f\u0131n\u0131 do\u011frulayan test senaryolar\u0131 olu\u015fturulmal\u0131d\u0131r. \u00d6rne\u011fin, bir \u00fcr\u00fcn silindi\u011finde, \u00fcr\u00fcn listeleme sayfas\u0131nda g\u00f6r\u00fcnmedi\u011fini, ancak y\u00f6netici panelinde “silinmi\u015f” olarak i\u015faretlenmi\u015f halde listelendi\u011fini test eden senaryolar geli\u015ftirilebilir. Kod incelemeleri (code reviews) de bu s\u00fcre\u00e7te \u00f6nemli bir ad\u0131md\u0131r; di\u011fer geli\u015ftiriciler, veri eri\u015fim katman\u0131ndaki sorgular\u0131n ve filtrelemelerin do\u011fru yap\u0131ld\u0131\u011f\u0131ndan emin olmak i\u00e7in kodu g\u00f6zden ge\u00e7irmelidir. Ayr\u0131ca, CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) s\u00fcre\u00e7lerine entegre edilmi\u015f otomatik veri denetim ara\u00e7lar\u0131, potansiyel veri tutars\u0131zl\u0131klar\u0131n\u0131 erken a\u015famada tespit edebilir. Bu pratiklerin benimsenmesi, uygulama genelinde veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flaman\u0131n ve pasif kay\u0131t sorunlar\u0131n\u0131n \u00f6n\u00fcne ge\u00e7menin en etkili yollar\u0131ndand\u0131r.<\/p>\n “Her d\u00fczeltme yeni bir gereksinim ekledi” ve “pasif kay\u0131tlar hala say\u0131l\u0131yor” sorunlar\u0131, ilk bak\u0131\u015fta farkl\u0131 gibi g\u00f6r\u00fcnse de, asl\u0131nda yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecinin temelinde yatan gereksinim y\u00f6netimi ve veri ya\u015fam d\u00f6ng\u00fcs\u00fc tan\u0131mlar\u0131n\u0131n yetersizli\u011finden kaynaklanan iki farkl\u0131 semptomdur. Bu iki problemin kesi\u015fim noktas\u0131, genellikle projenin ba\u015flang\u0131\u00e7 a\u015famalar\u0131nda yap\u0131lan eksik veya belirsiz spesifikasyonlard\u0131r. Bir “silme” i\u015fleminin ne anlama geldi\u011fi, verinin fiziksel olarak m\u0131 kald\u0131r\u0131laca\u011f\u0131, yoksa sadece mant\u0131ksal olarak m\u0131 pasif hale getirilece\u011fi gibi kritik detaylar, gereksinim toplama a\u015famas\u0131nda net bir \u015fekilde tan\u0131mlanmad\u0131\u011f\u0131nda, geli\u015ftiriciler kendi yorumlar\u0131n\u0131 katmak zorunda kal\u0131r. Bu da farkl\u0131 ekiplerin veya farkl\u0131 mod\u00fcllerin ayn\u0131 veri \u00fczerinde farkl\u0131 silme mant\u0131klar\u0131 uygulayarak veri tutars\u0131zl\u0131\u011f\u0131na yol a\u00e7mas\u0131na neden olabilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n hesab\u0131n\u0131 “silme” talebi, bir sistemde kullan\u0131c\u0131n\u0131n t\u00fcm bilgilerini fiziksel olarak kald\u0131r\u0131rken, ba\u015fka bir sistemde sadece Bu t\u00fcr sorunlar\u0131 \u00f6nlemek i\u00e7in, gereksinim m\u00fchendisli\u011fi (requirements engineering) s\u00fcrecinde veri ya\u015fam d\u00f6ng\u00fcs\u00fcne \u00f6zel bir vurgu yap\u0131lmal\u0131d\u0131r. \u0130\u015f analistleri (business analysts) ve sistem mimarlar\u0131, bir verinin nas\u0131l olu\u015fturulaca\u011f\u0131n\u0131, g\u00fcncellenece\u011fini, okunaca\u011f\u0131n\u0131 ve \u00f6zellikle nas\u0131l “silinece\u011fini” veya “pasif hale getirilece\u011fini” net bir \u015fekilde tan\u0131mlamal\u0131d\u0131r. Bu tan\u0131mlar, sadece teknik detaylar\u0131 de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcre\u00e7leri ve yasal uyumluluk gereksinimlerini de i\u00e7ermelidir. \u00d6rne\u011fin, bir veri tipinin ne kadar s\u00fcreyle saklanmas\u0131 gerekti\u011fi, pasif hale geldikten sonra hangi raporlarda g\u00f6r\u00fcnmeyece\u011fi ve hangi raporlarda g\u00f6r\u00fcnmeye devam edece\u011fi gibi konular, spesifikasyonlara dahil edilmelidir. Bursa’daki bir lojistik firmas\u0131n\u0131n takip sisteminde, sevkiyatlar\u0131n tamamlanmas\u0131ndan sonra “kapanan” sevkiyatlar\u0131n, performans raporlar\u0131nda hala “bekleyen” veya “devam eden” sevkiyatlar aras\u0131nda say\u0131lmas\u0131, operasyonel verimlilik analizlerini yanl\u0131\u015f y\u00f6nlendirmi\u015ftir. Bu hatan\u0131n temelinde, “kapanan sevkiyat” tan\u0131m\u0131n\u0131n, hem i\u015f birimleri hem de yaz\u0131l\u0131m ekibi taraf\u0131ndan farkl\u0131 anla\u015f\u0131lmas\u0131 yatm\u0131\u015ft\u0131r. \u0130\u015f birimi, kapanan sevkiyat\u0131n art\u0131k hi\u00e7bir raporda g\u00f6r\u00fcnmemesini beklerken, yaz\u0131l\u0131m ekibi sadece durumunu g\u00fcncelleyip filtreleme mekanizmas\u0131n\u0131 atlam\u0131\u015ft\u0131r.<\/p>\n \u00c7\u00f6z\u00fcm odakl\u0131 yakla\u015f\u0131mlar, payda\u015flar aras\u0131 i\u015f birli\u011fini ve ileti\u015fimi g\u00fc\u00e7lendirmeyi gerektirir. \u0130\u015f analistleri, geli\u015ftiriciler ve kalite g\u00fcvence (QA) ekipleri, veri silme ve pasifle\u015ftirme s\u00fcre\u00e7leri hakk\u0131nda ortak bir anlay\u0131\u015fa sahip olmal\u0131d\u0131r. Geli\u015ftiriciler, i\u015f kurallar\u0131n\u0131 tam olarak anlamadan kod yazmaktan ka\u00e7\u0131nmal\u0131, belirsiz durumlarda i\u015f analistleriyle proaktif bir \u015fekilde ileti\u015fim kurmal\u0131d\u0131r. Kalite g\u00fcvence ekipleri ise, test senaryolar\u0131n\u0131 tasarlarken, soft-deleted kay\u0131tlar\u0131n sistemin farkl\u0131 noktalar\u0131nda do\u011fru bir \u015fekilde i\u015flenip i\u015flenmedi\u011fini \u00f6zellikle kontrol etmelidir. Bu disiplinli yakla\u015f\u0131m, gereksinimlerin netle\u015ftirilmesi ve veri y\u00f6netiminin ba\u015ftan sona tutarl\u0131 bir \u015fekilde ele al\u0131nmas\u0131yla, hem gereksinim kaymas\u0131n\u0131n hem de pasif kay\u0131tlar\u0131n yanl\u0131\u015f say\u0131lmas\u0131 sorununun \u00f6n\u00fcne ge\u00e7ebilir.<\/p>\n Yaz\u0131l\u0131m geli\u015ftirme, s\u00fcrekli bir \u00f6\u011frenme ve iyile\u015ftirme s\u00fcrecidir. Gereksinim kaymas\u0131 ve pasif kay\u0131tlar\u0131n yanl\u0131\u015f say\u0131lmas\u0131 gibi sorunlar\u0131 k\u00f6kten \u00e7\u00f6zmek, sadece ba\u015flang\u0131\u00e7taki iyi planlamayla de\u011fil, ayn\u0131 zamanda projenin t\u00fcm ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca g\u00fc\u00e7l\u00fc test stratejileri ve s\u00fcrekli iyile\u015ftirme mekanizmalar\u0131yla m\u00fcmk\u00fcnd\u00fcr. Kalite g\u00fcvence (QA) ekipleri, bu s\u00fcre\u00e7te kritik bir rol oynar. Sadece kodun i\u015flevselli\u011fini de\u011fil, ayn\u0131 zamanda veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve gereksinimlerin do\u011fru bir \u015fekilde kar\u015f\u0131lan\u0131p kar\u015f\u0131lanmad\u0131\u011f\u0131n\u0131 da do\u011frulamalar\u0131 gerekir. Otomatik testler, bu do\u011frulamay\u0131 tutarl\u0131 ve verimli bir \u015fekilde yapman\u0131n en etkili yoludur. Birim testleri (unit tests), kodun en k\u00fc\u00e7\u00fck par\u00e7alar\u0131n\u0131n (metotlar, fonksiyonlar) beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 garanti ederken, entegrasyon testleri (integration tests) farkl\u0131 mod\u00fcllerin veya sistemlerin birbiriyle uyumlu \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 kontrol eder. \u00d6zellikle, veri eri\u015fim katman\u0131ndaki filtreleme mant\u0131\u011f\u0131n\u0131n do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 do\u011frulayan birim ve entegrasyon testleri yazmak hayati \u00f6neme sahiptir.<\/p>\n U\u00e7tan uca testler (end-to-end tests), kullan\u0131c\u0131n\u0131n bir i\u015f ak\u0131\u015f\u0131n\u0131 ba\u015ftan sona sim\u00fcle ederek, sistemin ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l davrand\u0131\u011f\u0131n\u0131 test eder. Bu testler, bir kullan\u0131c\u0131n\u0131n bir kayd\u0131 pasif hale getirmesi ve ard\u0131ndan bu kayd\u0131n sistemin farkl\u0131 aray\u00fczlerinde (raporlar, arama sonu\u00e7lar\u0131, listeler) do\u011fru bir \u015fekilde g\u00f6r\u00fcnmedi\u011fini veya belirli bir \u015fekilde i\u015faretlendi\u011fini do\u011frulamak i\u00e7in idealdir. \u00d6rne\u011fin, bir kullan\u0131c\u0131 bir \u00fcr\u00fcn\u00fc “yay\u0131ndan kald\u0131r” d\u00fc\u011fmesine t\u0131klad\u0131\u011f\u0131nda, bu \u00fcr\u00fcn\u00fcn web sitesinin ana sayfas\u0131nda veya kategori listelerinde g\u00f6r\u00fcnmedi\u011fini, ancak y\u00f6netici panelinde “pasif” etiketiyle hala eri\u015filebilir oldu\u011funu do\u011frulayan bir u\u00e7tan uca test senaryosu olu\u015fturulabilir. Bu t\u00fcr testler, “pasif kay\u0131tlar\u0131n hala say\u0131lmas\u0131” gibi sorunlar\u0131 canl\u0131ya \u00e7\u0131kmadan \u00f6nce yakalamak i\u00e7in son derece de\u011ferlidir.<\/p>\n Kod incelemeleri (code reviews), geli\u015ftirme s\u00fcrecinin vazge\u00e7ilmez bir par\u00e7as\u0131 olmal\u0131d\u0131r. Deneyimli geli\u015ftiriciler, veri eri\u015fim katman\u0131ndaki sorgular\u0131 ve soft delete filtrelemelerini dikkatlice g\u00f6zden ge\u00e7irmeli, olas\u0131 mant\u0131k hatalar\u0131n\u0131 veya eksik filtreleri tespit etmelidir. Ayr\u0131ca, DevOps (Geli\u015ftirme ve Operasyon) prensipleri, test otomasyonunu, s\u00fcrekli entegrasyonu (CI) ve s\u00fcrekli da\u011f\u0131t\u0131m\u0131 (CD) bir araya getirerek, yaz\u0131l\u0131m\u0131n daha h\u0131zl\u0131, daha g\u00fcvenilir ve daha kaliteli bir \u015fekilde yay\u0131nlanmas\u0131n\u0131 sa\u011flar. Bu s\u00fcre\u00e7lerde, otomatik veri denetimleri ve performans testleri de entegre edilerek, veri b\u00fct\u00fcnl\u00fc\u011f\u00fc sorunlar\u0131n\u0131n erken a\u015famada tespit edilmesi hedeflenir. D\u00fczenli veri denetimleri (data audits), canl\u0131 sistemdeki verilerin beklenen kurallara uygun olup olmad\u0131\u011f\u0131n\u0131 periyodik olarak kontrol etmek i\u00e7in kullan\u0131labilir. \u00d6rne\u011fin, pasif olarak i\u015faretlenmi\u015f kay\u0131tlar\u0131n ger\u00e7ekten hi\u00e7bir aktif raporda yer almad\u0131\u011f\u0131n\u0131 do\u011frulayan otomatik denetimler \u00e7al\u0131\u015ft\u0131r\u0131labilir. Geri bildirim d\u00f6ng\u00fcleri ve s\u00fcrekli \u00f6\u011frenme k\u00fclt\u00fcr\u00fc, ekibin ge\u00e7mi\u015f hatalardan ders \u00e7\u0131karmas\u0131n\u0131 ve s\u00fcre\u00e7lerini s\u00fcrekli olarak iyile\u015ftirmesini te\u015fvik eder. Bu sayede, hem gereksinim kaymas\u0131n\u0131n etkileri azalt\u0131l\u0131r hem de veri b\u00fct\u00fcnl\u00fc\u011f\u00fc sorunlar\u0131 minimize edilir, b\u00f6ylece daha sa\u011flam ve g\u00fcvenilir yaz\u0131l\u0131m sistemleri in\u015fa edilebilir.<\/p>\n Yaz\u0131l\u0131m geli\u015ftirme projelerinde kar\u015f\u0131la\u015f\u0131lan “her d\u00fczeltme yeni bir gereksinim ekledi” ve “pasif kay\u0131tlar hala say\u0131l\u0131yor” gibi sorunlar, asl\u0131nda daha derinlemesine yatan planlama, ileti\u015fim ve teknik uygulama eksikliklerinin birer yans\u0131mas\u0131d\u0131r. Ba\u015far\u0131l\u0131 bir yaz\u0131l\u0131m projesi, sadece kod yazmaktan ibaret de\u011fildir; ayn\u0131 zamanda net gereksinim tan\u0131mlar\u0131, etkili de\u011fi\u015fim y\u00f6netimi, sa\u011flam bir veri stratejisi ve titiz bir kalite g\u00fcvence s\u00fcreci gerektirir. Gereksinim kaymas\u0131, projenin kapsam\u0131n\u0131 belirsizle\u015ftirerek zaman ve maliyet a\u015f\u0131mlar\u0131na yol a\u00e7arken, pasif kay\u0131tlar\u0131n yanl\u0131\u015f y\u00f6netimi, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc bozarak operasyonel hatalara ve yanl\u0131\u015f i\u015f kararlar\u0131na neden olur. Bu makalede ele ald\u0131\u011f\u0131m\u0131z gibi, bu iki sorun birbiriyle yak\u0131ndan ili\u015fkilidir ve \u00e7o\u011fu zaman k\u00f6t\u00fc tan\u0131mlanm\u0131\u015f spesifikasyonlar, veri y\u00f6netimindeki hatalar\u0131 tetikler.<\/p>\n \u00c7\u00f6z\u00fcm, \u00e7evik metodolojileri benimseyerek gereksinimleri esnek ve y\u00f6netilebilir k\u0131lmak, veri ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc net bir \u015fekilde tan\u0131mlayan detayl\u0131 spesifikasyonlar haz\u0131rlamak ve uygulama katman\u0131nda soft delete gibi mekanizmalar\u0131 tutarl\u0131 kod pratikleri (ORM global filtreleri, Repository deseni) ve g\u00fc\u00e7l\u00fc test otomasyonu ile desteklemekten ge\u00e7mektedir. Payda\u015flar aras\u0131 s\u00fcrekli ileti\u015fim, cross-functional (\u00e7apraz fonksiyonlu) ekip \u00e7al\u0131\u015fmas\u0131 ve d\u00fczenli kod incelemeleri, bu s\u00fcre\u00e7lerin olmazsa olmazlar\u0131d\u0131r. Unutulmamal\u0131d\u0131r ki, yaz\u0131l\u0131m geli\u015ftirme s\u00fcrekli bir evrimdir ve hatalardan ders \u00e7\u0131kararak s\u00fcre\u00e7leri iyile\u015ftirmek, uzun vadeli ba\u015far\u0131 i\u00e7in anahtard\u0131r. Bu yakla\u015f\u0131mlar sayesinde, geli\u015ftiriciler hem proje y\u00f6netiminde daha \u00e7evik olabilir hem de veri b\u00fct\u00fcnl\u00fc\u011f\u00fcnden \u00f6d\u00fcn vermeden g\u00fcvenilir ve y\u00fcksek kaliteli yaz\u0131l\u0131mlar \u00fcretebilirler.<\/p>\n #Yaz\u0131l\u0131mGeli\u015ftirme #VeriY\u00f6netimi #GereksinimY\u00f6netimi #Veritaban\u0131Tasar\u0131m\u0131 #Teknoloji<\/p>\n","protected":false},"excerpt":{"rendered":"\/\/ Entity Framework Core’da Global Query Filter Tan\u0131m\u0131 protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder. Entity<Product>().","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-44698","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nIsDeleted<\/code>) veya bir zaman damgas\u0131 (\u00f6rne\u011fin, DeletedAt<\/code>) ile pasif hale getirilir. Soft delete yakla\u015f\u0131m\u0131, verilerin yanl\u0131\u015fl\u0131kla silinmesi durumunda geri kurtar\u0131labilmesi, ge\u00e7mi\u015fe d\u00f6n\u00fck denetim (auditing) yap\u0131lmas\u0131, yasal d\u00fczenlemelere uyum sa\u011flanmas\u0131 veya performans nedenleriyle tercih edilebilir. \u00d6rne\u011fin, bir e-devlet projesinde vatanda\u015fl\u0131k bilgilerinin tamamen silinmesi yerine pasif hale getirilmesi, hem yasal zorunluluklar hem de veri b\u00fct\u00fcnl\u00fc\u011f\u00fc a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir. Ancak, bu yakla\u015f\u0131m beraberinde ciddi bir sorumluluk getirir: her veri eri\u015fim noktas\u0131nda pasif kay\u0131tlar\u0131n filtrelenmesi.<\/p>\nUygulama Katman\u0131nda Pasif Kay\u0131t Y\u00f6netimi: G\u00fcvenli Kod Pratikleri ve Otomasyon<\/h2>\n
WHERE IsDeleted = false<\/code> ifadesini yazma zorunlulu\u011funu ortadan kald\u0131r\u0131r ve hata yapma olas\u0131l\u0131\u011f\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n\n\/\/ Entity Framework Core'da Global Query Filter Tan\u0131m\u0131\nprotected override void OnModelCreating(ModelBuilder modelBuilder)\n{\n modelBuilder.Entity<Product>().HasQueryFilter(p => !p.IsDeleted);\n \/\/ Bu filtre, Product tablosuna yap\u0131lan t\u00fcm sorgulara otomatik olarak eklenecektir.\n}\n <\/code><\/pre>\n<\/div>\nIRepository<\/code> aray\u00fcz\u00fc ve onu uygulayan somut s\u0131n\u0131flar arac\u0131l\u0131\u011f\u0131yla, t\u00fcm veri okuma i\u015flemleri, aktif kay\u0131tlar\u0131 getirecek \u015fekilde standartla\u015ft\u0131r\u0131labilir.<\/p>\n\n\/\/ C# ile Repository Deseni \u00d6rne\u011fi\npublic interface IRepository<T> where T : class, ISoftDelete\n{\n IQueryable<T> GetAllActive();\n T GetActiveById(int id);\n \/\/ ... di\u011fer metotlar\n}\n\npublic class EfRepository<T> : IRepository<T> where T : class, ISoftDelete\n{\n private readonly DbContext _context;\n\n public EfRepository(DbContext context)\n {\n _context = context;\n }\n\n public IQueryable<T> GetAllActive()\n {\n return _context.Set<T>().Where(e => !e.IsDeleted);\n }\n\n public T GetActiveById(int id)\n {\n return _context.Set<T>().FirstOrDefault(e => e.Id == id && !e.IsDeleted);\n }\n}\n <\/code><\/pre>\n<\/div>\nISoftDelete<\/code> aray\u00fcz\u00fcn\u00fc uygulayan t\u00fcm varl\u0131klar, otomatik olarak IsDeleted<\/code> \u00f6zelli\u011fine sahip olacak ve EfRepository<\/code> i\u00e7indeki metotlar bu \u00f6zelli\u011fi kullanarak aktif kay\u0131tlar\u0131 getirecektir. Bu t\u00fcr bir yakla\u015f\u0131m, kod tekrar\u0131n\u0131 \u00f6nler ve hata riskini minimize eder.<\/p>\nGereksinimler ve Veri Y\u00f6netiminin Kesi\u015fim Noktas\u0131: Kapsaml\u0131 Bir Yakla\u015f\u0131m<\/h2>\n
IsActive=false<\/code> olarak i\u015faretleyebilir. E\u011fer bu farkl\u0131l\u0131klar ba\u015flang\u0131\u00e7ta netle\u015ftirilmezse, “silinmi\u015f” kullan\u0131c\u0131lar\u0131n hala raporlarda veya istatistiklerde aktif olarak g\u00f6r\u00fcnmesi gibi sorunlar ka\u00e7\u0131n\u0131lmaz hale gelir.<\/p>\nS\u00fcrekli \u0130yile\u015ftirme ve G\u00fc\u00e7l\u00fc Test Stratejileriyle Sorunlar\u0131 \u00d6nlemek<\/h2>\n
Sonu\u00e7: \u00c7evik Geli\u015fim, Veri B\u00fct\u00fcnl\u00fc\u011f\u00fc ve S\u00fcrekli \u00d6\u011frenme<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n
\n Evet, soft delete kullan\u0131lan tablolarda sorgulara s\u00fcrekli olarak WHERE IsDeleted = false<\/code> gibi filtreler eklenmesi, \u00f6zellikle \u00e7ok b\u00fcy\u00fck tablolarda indeksleme (indexing) do\u011fru yap\u0131lmad\u0131\u011f\u0131nda performans d\u00fc\u015f\u00fc\u015flerine yol a\u00e7abilir. Ancak, uygun indeksleme, veritaban\u0131 optimizasyonlar\u0131 ve ORM’lerdeki global filtreleme mekanizmalar\u0131 ile bu etki minimize edilebilir.\n <\/li>\n
\n Hay\u0131r, kontroll\u00fc ve y\u00f6netilebilir bir de\u011fi\u015fim, projenin pazar ihtiya\u00e7lar\u0131na daha iyi uyum sa\u011flamas\u0131na yard\u0131mc\u0131 olabilir. \u00d6nemli olan, her yeni gereksinimin projenin kapsam\u0131na, zaman \u00e7izelgesine ve b\u00fct\u00e7esine olan etkilerinin \u015feffaf bir \u015fekilde de\u011ferlendirilmesi ve payda\u015flar\u0131n onay\u0131yla ilerlenmesidir. Kontrols\u00fcz kayma, k\u00f6t\u00fc bir durumdur.\n <\/li>\n
\n En g\u00fcvenli y\u00f6ntem, veritaban\u0131 d\u00fczeyinde IsDeleted<\/code> veya DeletedAt<\/code> gibi bir bayrak kullanmak ve uygulama katman\u0131nda (tercihen bir ORM’in global sorgu filtreleri veya merkezi bir Repository deseni arac\u0131l\u0131\u011f\u0131yla) bu bayra\u011f\u0131 otomatik olarak t\u00fcm okuma sorgular\u0131na dahil etmektir. Ek olarak, kapsaml\u0131 birim ve entegrasyon testleri ile bu filtrelemenin do\u011frulu\u011funu s\u00fcrekli olarak kontrol etmek gerekir.\n <\/li>\n
\n Eski veya pasif verilerin saklanma s\u00fcresi, i\u015f gereksinimleri, yasal d\u00fczenlemeler (\u00f6rne\u011fin KVKK, GDPR, finansal denetim kurallar\u0131) ve sekt\u00f6r standartlar\u0131 taraf\u0131ndan belirlenir. Bu s\u00fcreler, veri t\u00fcr\u00fcne g\u00f6re de\u011fi\u015fiklik g\u00f6sterebilir ve proje ba\u015flang\u0131c\u0131nda net bir \u015fekilde tan\u0131mlanmal\u0131d\u0131r.\n <\/li>\n
\n Evet, k\u00fc\u00e7\u00fck projelerde bile gereksinim kaymas\u0131 ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fc sorunlar\u0131 ortaya \u00e7\u0131kabilir ve genellikle erken a\u015famada \u00e7\u00f6z\u00fclmesi daha kolay ve maliyeti daha d\u00fc\u015f\u00fckt\u00fcr. Temel prensipleri (net gereksinimler, soft delete’in do\u011fru y\u00f6netimi, temel testler) uygulamak, projenin \u00f6l\u00e7e\u011finden ba\u011f\u0131ms\u0131z olarak her zaman faydal\u0131d\u0131r.\n <\/li>\n<\/ul>\n