Yaz\u0131l\u0131m projelerinde “kuca\u011f\u0131m\u0131zda bir bomba bulduk” hissinden, “art\u0131k bu sistemi d\u00fc\u015f\u00fcnmemize gerek yok” rahatl\u0131\u011f\u0131na giden yolu ve sahiplenme (ownership) k\u00fclt\u00fcr\u00fcn\u00fc ke\u015ffedin.<\/p>\n
Yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda hepimizin en az bir kez kar\u015f\u0131la\u015ft\u0131\u011f\u0131, adeta kabus gibi \u00e7\u00f6ken o an\u0131 hat\u0131rlayal\u0131m. \u015eirkete yeni kat\u0131ld\u0131n\u0131z veya mevcut ekibinizde yeni bir projeye dahil oldunuz. \u00d6n\u00fcn\u00fcze konulan kod taban\u0131 (codebase) tamamen belirsizliklerle dolu, dok\u00fcmantasyonu olmayan, her an \u00e7\u00f6kmeye haz\u0131r ve en ufak bir de\u011fi\u015fiklikte zincirleme hatalar zinciri (regression) ba\u015flatan bir yap\u0131ya sahip. Portekizcede bu duruma tam olarak “temos um roj\u00e3o na m\u00e3o”<\/strong> yani “elimizde patlamak \u00fczere olan bir havai fi\u015fek\/bomba var” denir. T\u00fcrk\u00e7ede ise biz buna genellikle “kuca\u011f\u0131m\u0131zda saatli bir bomba bulduk” veya “ate\u015ften g\u00f6mlek giymek” deriz.<\/p>\n Peki, bu tehlikeli ve stresli durumdan, sistemin t\u0131k\u0131r t\u0131k\u0131r \u00e7al\u0131\u015ft\u0131\u011f\u0131 ve geli\u015ftiricilerin arkas\u0131na yaslan\u0131p “n\u00e3o precisa mais pensar nisso”<\/strong> (art\u0131k bunu d\u00fc\u015f\u00fcnmemize gerek yok) dedi\u011fi o huzurlu a\u015famaya nas\u0131l ge\u00e7ebiliriz? Bu d\u00f6n\u00fc\u015f\u00fcm\u00fcn anahtar\u0131, teknik ara\u00e7lardan ziyade bir zihniyet de\u011fi\u015fimi olan “Ownership” yani sahiplenme kavram\u0131nda gizlidir. Bu makalede, bir yaz\u0131l\u0131m sisteminin sorumlulu\u011funu s\u0131f\u0131rdan al\u0131p onu tamamen otonom, g\u00fcvenilir ve zihinsel y\u00fck olu\u015fturmayan bir yap\u0131ya nas\u0131l d\u00f6n\u00fc\u015ft\u00fcrece\u011fimizi ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n Yaz\u0131l\u0131m projelerinde sahiplenme (ownership), sadece kod yaz\u0131p g\u00f6revi tamamlamakla ilgili bir durum de\u011fildir. Ger\u00e7ek sahiplenme; bir sistemin tasar\u0131m\u0131, kalitesi, hatalar\u0131, performans\u0131, bak\u0131m\u0131 ve en \u00f6nemlisi de i\u015fe katt\u0131\u011f\u0131 de\u011fer \u00fczerinde u\u00e7tan uca sorumluluk hissetmektir. Bir\u00e7ok organizasyonda geli\u015ftiriciler kendilerini sadece “bilet kapatan” (ticket closer) makineler olarak g\u00f6r\u00fcrler. Bu durum, sistemlerin zamanla sahipsiz kalmas\u0131na ve teknik bor\u00e7 (technical debt) bata\u011f\u0131na saplanmas\u0131na yol a\u00e7ar.<\/p>\n Bununla birlikte, sahiplenme bilinci y\u00fcksek olan ekiplerde s\u00fcre\u00e7ler \u00e7ok daha farkl\u0131 i\u015fler. Bir hata olu\u015ftu\u011funda “bu benim kodum de\u011fil” demek yerine, “bu sorunu sistem genelinde nas\u0131l kal\u0131c\u0131 olarak \u00e7\u00f6zeriz?” sorusu sorulur. Sahiplenme k\u00fclt\u00fcr\u00fc, mikro y\u00f6netim (micromanagement) ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r. \u00c7\u00fcnk\u00fc ekip \u00fcyeleri, sistemin sa\u011fl\u0131\u011f\u0131n\u0131 kendi ki\u015fisel prestijleri ve profesyonel standartlar\u0131 olarak g\u00f6r\u00fcrler. Sonu\u00e7 olarak, y\u00fcksek sahiplenme duygusu do\u011frudan daha kaliteli yaz\u0131l\u0131mlar, daha az kesinti s\u00fcresi (downtime) ve daha mutlu bir m\u00fchendislik ekibi anlam\u0131na gelir.<\/p>\n Sahiplenmeyi \u00fc\u00e7 temel seviyede inceleyebiliriz:<\/p>\n Bir sistemin “bomba” olarak nitelendirilmesinin arkas\u0131nda genellikle y\u0131llar\u0131n birikimi olan ihmaller yatar. Bu a\u015famada, sistemin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 kimse tam olarak bilmez. Kod taban\u0131nda gezinmek, may\u0131n tarlas\u0131nda y\u00fcr\u00fcmek gibidir. En k\u00fc\u00e7\u00fck bir ba\u011f\u0131ml\u0131l\u0131k (dependency) g\u00fcncellemesi bile t\u00fcm uygulamay\u0131 \u00e7\u00f6kertebilir. Bu durum, ekipler \u00fczerinde inan\u0131lmaz bir bili\u015fsel y\u00fck (cognitive load) yarat\u0131r.<\/p>\n \u00d6rne\u011fin, eski bir \u00f6deme entegrasyonu d\u00fc\u015f\u00fcn\u00fcn. Ne zaman bir kampanya d\u00f6nemi olsa bu sistem kilitleniyor, veri taban\u0131nda kilitlenmelere (deadlock) yol a\u00e7\u0131yor ve m\u00fc\u015fterilerden \u015fikayet ya\u011fmas\u0131na neden oluyor. Ekipteki herkes bu servise dokunmaktan korkuyor \u00e7\u00fcnk\u00fc kodun i\u00e7inde y\u00fczlerce sat\u0131rl\u0131k “spagetti” fonksiyonlar bulunuyor. \u0130\u015fte bu, tam anlam\u0131yla elimizde patlamak \u00fczere olan bir bombad\u0131r. Bu a\u015famada geli\u015ftiricilerin hissetti\u011fi ba\u015fl\u0131ca duygular \u00e7aresizlik, stres ve s\u00fcrekli tetikte olma (on-call n\u00f6beti korkusu) halidir.<\/p>\n Bu a\u015famadan kurtulman\u0131n ilk ad\u0131m\u0131, panik yapmay\u0131 b\u0131rak\u0131p durum tespiti yapmakt\u0131r. Bombay\u0131 etkisiz hale getirmek i\u00e7in \u00f6nce onun nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, kablolar\u0131n\u0131n nereye gitti\u011fini anlamam\u0131z gerekir. Bu da bizi bir sonraki a\u015famaya, yani kaosun anatomisini \u00e7\u0131karmaya g\u00f6t\u00fcr\u00fcr.<\/p>\n Bir sistemin zamanla kontrol edilemez bir canavara d\u00f6n\u00fc\u015fmesinin belirli ve tekrarlayan sebepleri vard\u0131r. Bu sebepleri bilmek, te\u015fhis koymam\u0131z\u0131 kolayla\u015ft\u0131r\u0131r. A\u015fa\u011f\u0131daki tabloda, sahipsiz b\u0131rak\u0131lm\u0131\u015f bir sistemin \u00f6zellikleri ile sahiplenilmi\u015f, sa\u011fl\u0131kl\u0131 bir sistemin \u00f6zelliklerini kar\u015f\u0131la\u015ft\u0131rmal\u0131 olarak g\u00f6rebilirsiniz.<\/p>\n G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere, aradaki fark sadece teknik beceri de\u011fil, ayn\u0131 zamanda sisteme g\u00f6sterilen \u00f6zen ve disiplindir. Bombay\u0131 etkisiz hale getirmek i\u00e7in bu tablodaki sol s\u00fctundan sa\u011f s\u00fctuna do\u011fru planl\u0131 bir ge\u00e7i\u015f yapmam\u0131z \u015fartt\u0131r.<\/p>\n Kuca\u011f\u0131m\u0131zdaki bombay\u0131 etkisiz hale getirmek ve sistemi kontrol alt\u0131na almak i\u00e7in sistematik bir yakla\u015f\u0131m uygulamal\u0131y\u0131z. Bu s\u00fcreci \u00fc\u00e7 ana ad\u0131ma ay\u0131rabiliriz: G\u00f6zlemle, Koruma Alt\u0131na Al ve Yeniden Yap\u0131land\u0131r (Refactor).<\/p>\n Karanl\u0131kta neyle sava\u015ft\u0131\u011f\u0131n\u0131z\u0131 g\u00f6remezsiniz. Bu nedenle, ilk i\u015fimiz sisteme \u0131\u015f\u0131k tutmakt\u0131r. Uygulaman\u0131n nerede hata verdi\u011fini, hangi isteklerin yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak i\u00e7in loglama (logging) ve metrik izleme ara\u00e7lar\u0131n\u0131 entegre etmeliyiz. APM (Application Performance Monitoring) ara\u00e7lar\u0131 kullanarak sistemin r\u00f6ntgenini \u00e7ekmeliyiz. B\u00f6ylece, kullan\u0131c\u0131lar hatay\u0131 fark etmeden \u00f6nce biz nerede sorun oldu\u011funu g\u00f6rebiliriz.<\/p>\n Koda dokunmaya korkmam\u0131z\u0131n sebebi, yapaca\u011f\u0131m\u0131z de\u011fi\u015fikli\u011fin neleri bozaca\u011f\u0131n\u0131 bilmememizdir. Bu korkuyu yenmenin tek yolu test yazmakt\u0131r. Ancak, t\u00fcm sistemi ba\u015ftan sona test etmek ger\u00e7ek\u00e7i de\u011fildir. Bunun yerine, en kritik i\u015f ak\u0131\u015flar\u0131n\u0131 (happy path) belirleyip buralara entegrasyon testleri yazarak ba\u015flamal\u0131y\u0131z. Bu testler bizim emniyet kemerimiz olacakt\u0131r.<\/p>\n B\u00fcy\u00fck ve radikal de\u011fi\u015fiklikler (big bang rewrite) genellikle ba\u015far\u0131s\u0131zl\u0131kla sonu\u00e7lan\u0131r. Sistemi tamamen \u00e7\u00f6pe at\u0131p ba\u015ftan yazmak yerine, k\u00fc\u00e7\u00fck par\u00e7alar halinde iyile\u015ftirmeler yapmal\u0131y\u0131z. Her dokundu\u011fumuz fonksiyonu, buldu\u011fumuzdan biraz daha temiz b\u0131rakmal\u0131y\u0131z (\u0130zci Kural\u0131 – Boy Scout Rule).<\/p>\n \u015eimdi, g\u00fcvensiz ve her an hata vermeye a\u00e7\u0131k bir kod blo\u011funun, sahiplenme s\u00fcreciyle nas\u0131l daha g\u00fcvenli ve y\u00f6netilebilir hale getirildi\u011fini bir kod \u00f6rne\u011fi \u00fczerinden inceleyelim.<\/p>\n Yukar\u0131daki kod tam bir saatli bombad\u0131r. Veri taban\u0131 ba\u011flant\u0131s\u0131 koptu\u011funda veya kullan\u0131c\u0131 bulunamad\u0131\u011f\u0131nda t\u00fcm uygulama \u00e7\u00f6kebilir. \u015eimdi bu kodu, sahiplenilmi\u015f ve g\u00fcvenli bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fcrelim:<\/p>\n G\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi, ikinci \u00f6rnekte neyin nerede yanl\u0131\u015f gitti\u011fini an\u0131nda g\u00f6rebiliriz. Hatalar yakalan\u0131yor, loglan\u0131yor ve sistemin \u00e7\u00f6kmesi engelleniyor. Bu basit d\u00f6n\u00fc\u015f\u00fcm bile ekibin \u00fczerindeki stres y\u00fck\u00fcn\u00fc inan\u0131lmaz derecede azaltacakt\u0131r.<\/p>\n Yang\u0131n\u0131 s\u00f6nd\u00fcrd\u00fckten sonra, gelecekte yeni yang\u0131nlar\u0131n \u00e7\u0131kmas\u0131n\u0131 \u00f6nlemek i\u00e7in teknik bor\u00e7lar\u0131 y\u00f6netilebilir bir seviyede tutmal\u0131y\u0131z. Teknik bor\u00e7, h\u0131zl\u0131 teslimat yapmak ad\u0131na bilin\u00e7li veya bilin\u00e7siz olarak yap\u0131lan k\u00f6t\u00fc tasar\u0131m tercihleridir. T\u0131pk\u0131 finansal bor\u00e7lar gibi, teknik bor\u00e7lar\u0131n da faizi vard\u0131r ve bu faiz zamanla geli\u015ftirme h\u0131z\u0131m\u0131z\u0131 yava\u015flat\u0131r.<\/p>\n Teknik bor\u00e7la m\u00fccadele ederken \u00fcr\u00fcn y\u00f6neticileri (product managers) ile ortak bir dil konu\u015fmak \u00e7ok \u00f6nemlidir. Onlara “bu kod \u00e7ok k\u00f6t\u00fc, yeniden yazmal\u0131y\u0131z” demek yerine, “bu teknik bor\u00e7 y\u00fcz\u00fcnden yeni \u00f6zellikleri eklememiz normalden iki kat daha uzun s\u00fcr\u00fcyor” \u015feklinde i\u015f \u00e7\u0131kt\u0131s\u0131 odakl\u0131 a\u00e7\u0131klamalar yapmal\u0131y\u0131z. Her sprint (geli\u015ftirme d\u00f6nemi) i\u00e7inde teknik bor\u00e7lar\u0131 temizlemek i\u00e7in %15-20 oran\u0131nda bir b\u00fct\u00e7e ay\u0131rmak, sistemin sa\u011fl\u0131\u011f\u0131n\u0131 korumak i\u00e7in en s\u00fcrd\u00fcr\u00fclebilir y\u00f6ntemdir.<\/p>\n Sahiplenme s\u00fcrecinin nihai hedefi, bir sistemi tamamen g\u00f6r\u00fcnmez k\u0131lmakt\u0131r. \u0130yi tasarlanm\u0131\u015f, testleri tam, g\u00f6zlemlenebilirli\u011fi y\u00fcksek ve kendi kendini iyile\u015ftirebilen (self-healing) bir sistem, geli\u015ftiricilerin zihninde yer kaplamaz. \u0130\u015fte bu a\u015fama, Portekizce ifadesiyle “n\u00e3o precisa mais pensar nisso”<\/strong> a\u015famas\u0131d\u0131r.<\/p>\n Bu a\u015famaya ula\u015ft\u0131\u011f\u0131m\u0131zda neler de\u011fi\u015fir?<\/p>\n Bu seviyeye ula\u015fmak zaman ve sab\u0131r ister ancak ula\u015f\u0131ld\u0131\u011f\u0131nda sa\u011flad\u0131\u011f\u0131 i\u015f g\u00fcc\u00fc ve motivasyon kazanc\u0131 paha bi\u00e7ilemezdir.<\/p>\n Konuyu daha iyi somutla\u015ft\u0131rmak i\u00e7in ger\u00e7ek bir vaka analizine (case study) g\u00f6z atal\u0131m. T\u00fcrkiye’nin \u00f6nde gelen e-ticaret platformlar\u0131ndan birinde ya\u015fanan ger\u00e7ek bir d\u00f6n\u00fc\u015f\u00fcm hikayesini inceleyelim.<\/p>\n Sorun:<\/strong> \u015eirketin eski \u00f6deme mikro servisi, her cuma ak\u015fam\u0131 yap\u0131lan indirim kampanyalar\u0131nda a\u015f\u0131r\u0131 y\u00fck alt\u0131nda eziliyor ve \u00e7\u00f6k\u00fcyordu. Sistem \u00e7\u00f6kt\u00fc\u011f\u00fcnde sipari\u015fler yar\u0131da kal\u0131yor, veri taban\u0131nda tutars\u0131zl\u0131klar olu\u015fuyordu. Yaz\u0131l\u0131m ekibi her cuma gecesini ofiste sabahlayarak, manuel olarak veri taban\u0131n\u0131 d\u00fczeltmekle ge\u00e7iriyordu. Ekip tam anlam\u0131yla “kuca\u011f\u0131nda bir bomba” ile ya\u015f\u0131yordu.<\/p>\n \u00c7\u00f6z\u00fcm S\u00fcreci:<\/strong> Yeni atanan bir teknik lider, “ownership” prensiplerini uygulamaya karar verdi. \u0130lk olarak, sisteme detayl\u0131 metrikler eklendi ve darbo\u011faz\u0131n (bottleneck) veri taban\u0131 ba\u011flant\u0131 havuzunun (connection pool) t\u00fckenmesi oldu\u011fu tespit edildi. Ard\u0131ndan, \u00f6deme istekleri bir kuyruk yap\u0131s\u0131na (message queue – RabbitMQ) y\u00f6nlendirilerek asenkron hale getirildi. Kritik \u00f6deme ad\u0131mlar\u0131 i\u00e7in entegrasyon testleri yaz\u0131ld\u0131.<\/p>\n Sonu\u00e7:<\/strong> Alt\u0131 ayl\u0131k planl\u0131 bir \u00e7al\u0131\u015fma sonucunda, \u00f6deme sistemi saniyede 10.000 iste\u011fi sorunsuz kar\u015f\u0131layabilir hale geldi. Bir sonraki b\u00fcy\u00fck kampanya d\u00f6neminde sistem tek bir hata bile vermedi. Geli\u015ftirici ekibi cuma ak\u015fam\u0131 ofisten saat 18:00’de ayr\u0131ld\u0131 ve hafta sonunu aileleriyle ge\u00e7irdi. Sistem art\u0131k “d\u00fc\u015f\u00fcn\u00fclmesine gerek olmayan” g\u00fcvenli bir limana d\u00f6n\u00fc\u015fm\u00fc\u015ft\u00fc.<\/p>\n Sahiplenme k\u00fclt\u00fcr\u00fc yukar\u0131dan a\u015fa\u011f\u0131ya dikte edilemez; a\u015fa\u011f\u0131dan yukar\u0131ya do\u011fru te\u015fvik edilmelidir. \u0130lk ad\u0131m olarak, ekiplere kendi sistemleri \u00fczerinde karar alma \u00f6zg\u00fcrl\u00fc\u011f\u00fc (autonomy) verilmelidir. Hata yap\u0131ld\u0131\u011f\u0131nda su\u00e7luyu aramak yerine (blameless post-mortem), sistemdeki a\u00e7\u0131klar\u0131 bulmaya odaklan\u0131lmal\u0131d\u0131r.<\/p>\n Neredeyse her zaman refakt\u00f6r etmek daha mant\u0131kl\u0131d\u0131r. Sistemi ba\u015ftan yazmak (rewrite) \u00e7ok b\u00fcy\u00fck bir risk bar\u0131nd\u0131r\u0131r ve genellikle eski sistemin t\u00fcm gizli bug’lar\u0131n\u0131 yeni sisteme de ta\u015f\u0131makla sonu\u00e7lan\u0131r. K\u00fc\u00e7\u00fck, g\u00fcvenli ad\u0131mlarla mevcut sistemi iyile\u015ftirmek daha az riskli ve daha \u00f6\u011freticidir.<\/p>\n \u00dcr\u00fcn y\u00f6neticisine teknik terimlerle de\u011fil, i\u015f \u00e7\u0131kt\u0131lar\u0131yla yakla\u015fmal\u0131s\u0131n\u0131z. Teknik bor\u00e7lar\u0131n temizlenmesinin yeni \u00f6zellikleri ne kadar h\u0131zland\u0131raca\u011f\u0131n\u0131, hata oranlar\u0131n\u0131 nas\u0131l d\u00fc\u015f\u00fcrece\u011fini ve sunucu maliyetlerini nas\u0131l azaltaca\u011f\u0131n\u0131 somut verilerle sunmal\u0131s\u0131n\u0131z.<\/p>\n #Yaz\u0131l\u0131mGeli\u015ftirme #Ownership #Yaz\u0131l\u0131mMimarisi #CleanCode #Teknoloji<\/p>\nYaz\u0131l\u0131mda Ownership (Sahiplenme) Nedir ve Neden Hayatidir?<\/h2>\n
\n
“Kuca\u011f\u0131m\u0131zda Bir Saatli Bomba Var!” A\u015famas\u0131 (Temos um roj\u00e3o na m\u00e3o)<\/h2>\n
Kaosun Anatomisi: Bir Kod Neden “Bomba” Haline Gelir?<\/h2>\n
\n\n
\n \n\u00d6zellik<\/th>\n Bomba Sistem (Sahipsiz)<\/th>\n G\u00fcvenli Liman (Sahiplenilmi\u015f)<\/th>\n<\/tr>\n<\/thead>\n \n Test Kapsam\u0131<\/strong><\/td>\n Yok denecek kadar az veya sadece “ye\u015fil g\u00f6r\u00fcns\u00fcn” diye yaz\u0131lm\u0131\u015f i\u015flevsiz testler.<\/td>\n Y\u00fcksek birim (unit) ve entegrasyon (integration) test kapsam\u0131, kritik yollar\u0131n test edilmesi.<\/td>\n<\/tr>\n \n G\u00f6zlemlenebilirlik<\/strong><\/td>\n Hatalar sadece kullan\u0131c\u0131lar \u015fikayet etti\u011finde veya sunucu \u00e7\u00f6kt\u00fc\u011f\u00fcnde fark edilir.<\/td>\n Geli\u015fmi\u015f loglama, metrik takibi ve anl\u0131k alarm (alerting) mekanizmalar\u0131.<\/td>\n<\/tr>\n \n Dok\u00fcmantasyon<\/strong><\/td>\n Ya hi\u00e7 yok ya da 3 y\u0131l \u00f6ncesinden kalma, g\u00fcncelli\u011fini yitirmi\u015f belgeler.<\/td>\n G\u00fcncel README dosyalar\u0131, mimari karar kay\u0131tlar\u0131 (ADR) ve API dok\u00fcmanlar\u0131.<\/td>\n<\/tr>\n \n Ba\u011f\u0131ml\u0131l\u0131klar<\/strong><\/td>\n Y\u0131llard\u0131r g\u00fcncellenmemi\u015f, g\u00fcvenlik a\u00e7\u0131klar\u0131yla dolu k\u00fct\u00fcphaneler.<\/td>\n D\u00fczenli olarak g\u00fcncellenen ve otomatik ara\u00e7larla taranan ba\u011f\u0131ml\u0131l\u0131klar.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Ad\u0131m Ad\u0131m Sahiplenme: Yang\u0131n\u0131 S\u00f6nd\u00fcrme Plan\u0131 Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
1. G\u00f6zlemlenebilirlik (Observability) Kurulumu<\/h3>\n
2. Test A\u011f\u0131n\u0131 \u00d6rmek<\/h3>\n
3. K\u00fc\u00e7\u00fck Ad\u0131mlarla Yeniden Yap\u0131land\u0131rma (Refactoring)<\/h3>\n
\/\/ K\u00d6T\u00dc \u00d6RNEK: Hata y\u00f6netimi olmayan, g\u00f6zlemlenemeyen ve k\u0131r\u0131lgan kod\nasync function processPayment(orderId, amount) {\n const user = await db.getUserByOrderId(orderId);\n \/\/ Hata kontrol\u00fc yok, user null gelirse sistem \u00e7\u00f6ker\n const paymentResult = await paymentGateway.charge(user.email, amount);\n \n if (paymentResult.success) {\n await db.updateOrderStatus(orderId, 'PAID');\n return true;\n }\n \/\/ Ba\u015far\u0131s\u0131zl\u0131k durumu sessizce ge\u00e7i\u015ftiriliyor, loglama yok\n return false;\n}\n<\/code><\/pre>\n<\/div>\n\/\/ \u0130Y\u0130 \u00d6RNEK: Hata y\u00f6netimi geli\u015fmi\u015f, loglama bar\u0131nd\u0131ran ve test edilebilir kod\nasync function processPayment(orderId, amount) {\n logger.info(\u00d6deme i\u015flemi ba\u015flat\u0131ld\u0131. Sipari\u015f ID: ${orderId}, Tutar: ${amount}<\/code>);\n \n try {\n const user = await db.getUserByOrderId(orderId);\n if (!user) {\n logger.error(\u00d6deme ba\u015far\u0131s\u0131z: Sipari\u015f ID ${orderId} i\u00e7in kullan\u0131c\u0131 bulunamad\u0131.<\/code>);\n throw new UserNotFoundError(orderId);\n }\n\n const paymentResult = await paymentGateway.charge(user.email, amount);\n \n if (paymentResult.success) {\n await db.updateOrderStatus(orderId, 'PAID');\n logger.info(\u00d6deme ba\u015far\u0131yla tamamland\u0131. Sipari\u015f ID: ${orderId}<\/code>);\n return { success: true };\n }\n\n logger.warn(\u00d6deme reddedildi. Sipari\u015f ID: ${orderId}, Sebep: ${paymentResult.errorMessage}<\/code>);\n return { success: false, reason: paymentResult.errorMessage };\n\n } catch (error) {\n logger.error(\u00d6deme i\u015flemi s\u0131ras\u0131nda kritik hata olu\u015ftu. Sipari\u015f ID: ${orderId}<\/code>, { error: error.message });\n \/\/ Hata izleme sistemine (\u00f6rne\u011fin Sentry) bildiriliyor\n errorTracker.captureException(error);\n throw error; \/\/ Hatan\u0131n yukar\u0131 f\u0131rlat\u0131lmas\u0131 sa\u011flan\u0131yor\n }\n}\n<\/code><\/pre>\n<\/div>\nTeknik Bor\u00e7 (Technical Debt) Nas\u0131l Y\u00f6netilir?<\/h2>\n
“Art\u0131k Bunu D\u00fc\u015f\u00fcnmemize Gerek Yok” A\u015famas\u0131na Ge\u00e7i\u015f (N\u00e3o precisa mais pensar nisso)<\/h2>\n
\n
Ger\u00e7ek D\u00fcnya Senaryosu: Bir E-Ticaret \u00d6deme Sisteminin D\u00f6n\u00fc\u015f\u00fcm\u00fc<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (FAQ)<\/h2>\n
1. Sahiplenme (Ownership) k\u00fclt\u00fcr\u00fc bir ekipte nas\u0131l ba\u015flat\u0131l\u0131r?<\/h3>\n
2. Legacy (eski) bir sistemi ba\u015ftan yazmak m\u0131 yoksa refakt\u00f6r etmek mi daha mant\u0131kl\u0131d\u0131r?<\/h3>\n
3. Teknik bor\u00e7lar\u0131 temizlemek i\u00e7in \u00fcr\u00fcn y\u00f6neticisini (Product Owner) nas\u0131l ikna edebiliriz?<\/h3>\n