G\u00fcn\u00fcm\u00fcz\u00fcn karma\u015f\u0131k yaz\u0131l\u0131m ve i\u015f s\u00fcre\u00e7leri d\u00fcnyas\u0131nda, her bir g\u00f6revi m\u00fcmk\u00fcn oldu\u011funca k\u00fc\u00e7\u00fck, odakl\u0131 ve tek bir amaca hizmet eden par\u00e7alara ay\u0131rmak, adeta bir can simidi gibidir. Bu yakla\u015f\u0131m, “tek beceri, tek eylem” olarak adland\u0131r\u0131l\u0131r ve geli\u015ftirme s\u00fcre\u00e7lerinde kar\u015f\u0131la\u015f\u0131lan zorluklar\u0131 minimize ederek g\u00fcvenli bir \u00e7al\u0131\u015fma alan\u0131 sunar. Peki, bu basit g\u00f6r\u00fcnen prensip, projelerinizin ba\u015far\u0131s\u0131 i\u00e7in neden bu kadar kritik bir \u00f6neme sahiptir ve uygulamada bize hangi avantajlar\u0131 sa\u011flar?<\/p>\n
Modern yaz\u0131l\u0131m mimarilerinden g\u00fcnl\u00fck i\u015f ak\u0131\u015flar\u0131na kadar pek \u00e7ok alanda, karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netmek en b\u00fcy\u00fck zorluklardan biridir. Tek bir eyleme tek bir beceriyi atamak, yani her bir par\u00e7an\u0131n yaln\u0131zca bir i\u015fi en iyi \u015fekilde yapmas\u0131n\u0131 sa\u011flamak, bu karma\u015f\u0131kl\u0131\u011f\u0131 anlaml\u0131 \u00f6l\u00e7\u00fcde azalt\u0131r. Bu sayede, hatalar\u0131 tespit etmek, sorunlar\u0131 gidermek ve sistemleri geli\u015ftirmek \u00e7ok daha kolay hale gelir. Bu makalede, “tek beceri, tek eylem” prensibinin temelini, yaz\u0131l\u0131m geli\u015ftirmedeki pratik uygulamalar\u0131n\u0131, kar\u015f\u0131la\u015f\u0131labilecek zorluklar\u0131 ve ileri d\u00fczey optimizasyon ipu\u00e7lar\u0131n\u0131 detayl\u0131 bir \u015fekilde inceleyece\u011fiz. Amac\u0131m\u0131z, bu g\u00fc\u00e7l\u00fc prensibi projelerinize nas\u0131l entegre edebilece\u011finizi ad\u0131m ad\u0131m g\u00f6stermek ve dijital d\u00fcnyadaki g\u00fcvenli s\u0131n\u0131r\u0131n\u0131z\u0131 in\u015fa etmenize yard\u0131mc\u0131 olmakt\u0131r.<\/p>\n
“Tek beceri, tek eylem” prensibi, temelde bir g\u00f6revin veya fonksiyonun yaln\u0131zca tek bir sorumlulu\u011fu olmas\u0131 gerekti\u011fini savunan Sorumluluk \u0130lkesi (Single Responsibility Principle – SRP) ile yak\u0131ndan ili\u015fkilidir. Bu ilke, bir mod\u00fcl\u00fcn, s\u0131n\u0131f\u0131n veya fonksiyonun de\u011fi\u015ftirilmesi i\u00e7in yaln\u0131zca tek bir nedeni olmas\u0131 gerekti\u011fini belirtir. Yani, bir kod par\u00e7as\u0131 sadece bir i\u015ften sorumlu olmal\u0131 ve o i\u015fi en iyi \u015fekilde yapmal\u0131d\u0131r. Bu, yaz\u0131l\u0131m m\u00fchendisli\u011finin temel ta\u015flar\u0131ndan biri olup, kodun okunabilirli\u011fini, bak\u0131m\u0131n\u0131 ve test edilebilirli\u011fini do\u011frudan etkiler.<\/p>\n
Bu prensibi benimsemek, asl\u0131nda karma\u015f\u0131k bir problemi daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara b\u00f6lme sanat\u0131d\u0131r. \u00d6rne\u011fin, bir e-ticaret uygulamas\u0131nda kullan\u0131c\u0131 kayd\u0131 i\u015flemi d\u00fc\u015f\u00fcnelim. Bu i\u015flem, kullan\u0131c\u0131 bilgilerini almak, \u015fifreyi hash’lemek, veritaban\u0131na kaydetmek, onay e-postas\u0131 g\u00f6ndermek ve kullan\u0131c\u0131ya ho\u015f geldin mesaj\u0131 g\u00f6stermek gibi bir\u00e7ok alt ad\u0131mdan olu\u015fabilir. E\u011fer t\u00fcm bu ad\u0131mlar tek bir b\u00fcy\u00fck fonksiyon i\u00e7inde toplan\u0131rsa, o fonksiyonun birden fazla sorumlulu\u011fu olur. Bu durum, hem kodun anla\u015f\u0131lmas\u0131n\u0131 zorla\u015ft\u0131r\u0131r hem de bir ad\u0131mda yap\u0131lacak bir de\u011fi\u015fiklik t\u00fcm fonksiyonu etkileyebilir. Oysa, bu ad\u0131mlar\u0131 ayr\u0131 ayr\u0131 fonksiyonlara b\u00f6lmek, her bir fonksiyonun tek bir eylemden sorumlu olmas\u0131n\u0131 sa\u011flar: Bu prensibin faydalar\u0131 olduk\u00e7a \u00e7e\u015fitlidir. \u0130lk olarak, hata azaltma konusunda b\u00fcy\u00fck bir rol oynar. Bir fonksiyonun yaln\u0131zca tek bir i\u015fi varsa, o fonksiyonda hata yapma olas\u0131l\u0131\u011f\u0131 azal\u0131r ve olas\u0131 hatalar\u0131n tespiti kolayla\u015f\u0131r. \u0130kinci olarak, test edilebilirlik artar. Her bir atomik eylem ba\u011f\u0131ms\u0131z olarak test edilebilir; bu da entegrasyon testlerinin ve birim testlerinin (unit tests) yaz\u0131lmas\u0131n\u0131 ve s\u00fcrd\u00fcr\u00fclmesini basitle\u015ftirir. \u00dc\u00e7\u00fcnc\u00fc olarak, kodun okunabilirli\u011fi ve anla\u015f\u0131labilirli\u011fi \u00f6nemli \u00f6l\u00e7\u00fcde geli\u015fir. Daha k\u00fc\u00e7\u00fck ve odakl\u0131 fonksiyonlar, ne i\u015f yapt\u0131klar\u0131n\u0131 daha net bir \u015fekilde ifade eder, bu da yeni geli\u015ftiricilerin projeye adaptasyonunu h\u0131zland\u0131r\u0131r. Son olarak, bak\u0131m ve geni\u015fletilebilirlik kolayla\u015f\u0131r. Bir fonksiyonun sorumlulu\u011fu tek oldu\u011funda, o fonksiyonda yap\u0131lacak bir de\u011fi\u015fiklik veya yeni bir \u00f6zellik eklenmesi, sistemin di\u011fer par\u00e7alar\u0131n\u0131 etkileme riskini minimize eder. Bu da, yaz\u0131l\u0131m\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca maliyetleri d\u00fc\u015f\u00fcr\u00fcr ve geli\u015ftirme h\u0131z\u0131n\u0131 art\u0131r\u0131r. K\u0131sacas\u0131, “tek beceri, tek eylem” prensibi, yaz\u0131l\u0131m\u0131n sadece bug\u00fcn de\u011fil, gelecekte de sa\u011fl\u0131kl\u0131 kalmas\u0131n\u0131 sa\u011flayan temel bir yap\u0131 ta\u015f\u0131d\u0131r.<\/p>\n Yaz\u0131l\u0131m geli\u015ftirmede “tek beceri, tek eylem” prensibini uygulamak, kod taban\u0131n\u0131z\u0131n (codebase) sa\u011fl\u0131\u011f\u0131 ve s\u00fcrd\u00fcr\u00fclebilirli\u011fi i\u00e7in hayati \u00f6neme sahiptir. Bu yakla\u015f\u0131m, \u00f6zellikle fonksiyonlar, metotlar, mod\u00fcller ve API (Uygulama Programlama Aray\u00fcz\u00fc) tasar\u0131mlar\u0131nda kendini g\u00f6sterir. Her bir kod par\u00e7as\u0131n\u0131n yaln\u0131zca bir i\u015fi yapmas\u0131n\u0131 sa\u011flamak, karma\u015f\u0131kl\u0131\u011f\u0131 azalt\u0131r ve geli\u015ftirme s\u00fcre\u00e7lerini h\u0131zland\u0131r\u0131r.<\/p>\n Bir fonksiyon veya metot, belirli bir g\u00f6revi yerine getirmek \u00fczere tasarlanm\u0131\u015f kod blo\u011fudur. “Tek beceri, tek eylem” prensibi gere\u011fi, bir fonksiyon yaln\u0131zca bir i\u015flemi ger\u00e7ekle\u015ftirmelidir. \u00d6rne\u011fin, bir kullan\u0131c\u0131dan veri alan bir fonksiyon, ayn\u0131 zamanda o veriyi do\u011frulama veya veritaban\u0131na kaydetme i\u015fini yapmamal\u0131d\u0131r. Her biri ayr\u0131 bir fonksiyonda ele al\u0131nmal\u0131d\u0131r. Bu sayede, bir fonksiyonda bir hata olu\u015ftu\u011funda, hatan\u0131n kayna\u011f\u0131n\u0131 bulmak \u00e7ok daha kolay hale gelir. Ayr\u0131ca, bu fonksiyonlar farkl\u0131 yerlerde tekrar kullan\u0131labilir, bu da kod tekrar\u0131n\u0131 (code duplication) azalt\u0131r.<\/p>\n Basit bir \u00f6rnekle a\u00e7\u0131klayal\u0131m. Bir e-ticaret uygulamas\u0131nda yeni bir \u00fcr\u00fcn ekleme senaryosunu ele alal\u0131m. E\u011fer t\u00fcm i\u015flem tek bir fonksiyonda olsayd\u0131, \u015f\u00f6yle g\u00f6r\u00fcnebilirdi:<\/p>\n Bu fonksiyonda birden fazla sorumluluk var: do\u011frulama, veritaban\u0131 i\u015flemi ve loglama. Oysa, “tek beceri, tek eylem” prensibini uygulayarak bu i\u015flemi daha mod\u00fcler hale getirebiliriz:<\/p>\n Bu ayr\u0131\u015ft\u0131rma, her bir fonksiyonun yaln\u0131zca tek bir i\u015fi yapmas\u0131n\u0131 sa\u011flar. Fonksiyonlar\u0131n \u00f6tesinde, bu prensip mod\u00fcl ve bile\u015fen seviyesinde de uygulan\u0131r. Bir mod\u00fcl (\u00f6rne\u011fin bir JavaScript dosyas\u0131 veya Python paketi) belirli bir i\u015flevsellik grubunu kapsar ve di\u011fer mod\u00fcllerden ba\u011f\u0131ms\u0131z olmal\u0131d\u0131r. \u00d6rne\u011fin, bir kullan\u0131c\u0131 y\u00f6netim mod\u00fcl\u00fc, sadece kullan\u0131c\u0131larla ilgili i\u015flemleri (kay\u0131t, giri\u015f, profil g\u00fcncelleme) ele almal\u0131, \u00f6deme i\u015flemleriyle ilgilenmemelidir. Bu mod\u00fcler yap\u0131, kodun yeniden kullan\u0131labilirli\u011fini art\u0131r\u0131r, ba\u011f\u0131ml\u0131l\u0131klar\u0131 azalt\u0131r ve farkl\u0131 geli\u015ftiricilerin ayn\u0131 anda farkl\u0131 mod\u00fcller \u00fczerinde \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r.<\/p>\n API tasar\u0131m\u0131 (Application Programming Interface – Uygulama Programlama Aray\u00fcz\u00fc) da “tek beceri, tek eylem” prensibinden b\u00fcy\u00fck \u00f6l\u00e7\u00fcde faydalan\u0131r. Bir RESTful API’deki her u\u00e7 nokta (endpoint) belirli bir kayna\u011f\u0131n (resource) belirli bir eylemini temsil etmelidir. \u00d6rne\u011fin, Bir e-ticaret uygulamas\u0131nda sepet y\u00f6netimi, “tek beceri, tek eylem” prensibinin g\u00fczel bir \u00f6rne\u011fidir. Sepete \u00fcr\u00fcn ekleme, \u00fcr\u00fcn miktar\u0131n\u0131 g\u00fcncelleme, sepetten \u00fcr\u00fcn \u00e7\u0131karma ve sepeti temizleme gibi i\u015flevler, ayr\u0131 ayr\u0131 ele al\u0131nmal\u0131d\u0131r. E\u011fer t\u00fcm bu i\u015flevler tek bir “sepetYonetimi” ad\u0131nda devasa bir fonksiyonda birle\u015ftirilseydi, bu fonksiyonun bak\u0131m\u0131 ve test edilmesi kabusa d\u00f6n\u00fc\u015febilirdi. Oysa, bu i\u015flevleri atomik eylemlere b\u00f6lmek, her birinin kendi i\u00e7inde tutarl\u0131 ve ba\u011f\u0131ms\u0131z olmas\u0131n\u0131 sa\u011flar:<\/p>\n Bu ayr\u0131\u015ft\u0131rma sayesinde, \u00f6rne\u011fin \u00fcr\u00fcn miktar\u0131n\u0131 g\u00fcncelleme mant\u0131\u011f\u0131nda bir de\u011fi\u015fiklik yap\u0131ld\u0131\u011f\u0131nda, bu sadece “Tek beceri, tek eylem” prensibi, sadece soyut yaz\u0131l\u0131m kodlama pratikleriyle s\u0131n\u0131rl\u0131 kalmay\u0131p, modern yaz\u0131l\u0131m mimarilerinden i\u015f s\u00fcre\u00e7leri y\u00f6netimine kadar bir\u00e7ok ger\u00e7ek d\u00fcnya senaryosunda kendini g\u00f6sterir. Bu yakla\u015f\u0131m, \u00f6zellikle karma\u015f\u0131k sistemlerin geli\u015ftirilmesinde ve y\u00f6netilmesinde kritik bir rol oynar, \u00e7\u00fcnk\u00fc b\u00fcy\u00fck problemleri k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara ay\u0131rarak \u00e7\u00f6z\u00fcmlemeyi kolayla\u015ft\u0131r\u0131r.<\/p>\n Mikroservis mimarisi, “tek beceri, tek eylem” prensibinin en somut ve pop\u00fcler uygulamalar\u0131ndan biridir. Bu mimaride, b\u00fcy\u00fck bir uygulama, ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilen, da\u011f\u0131t\u0131labilen ve \u00f6l\u00e7eklenebilen k\u00fc\u00e7\u00fck, odakl\u0131 hizmetler (servisler) b\u00fct\u00fcn\u00fc olarak in\u015fa edilir. Her bir mikroservis, belirli bir i\u015f alan\u0131na veya i\u015flevselli\u011fe (\u00f6rne\u011fin, kullan\u0131c\u0131 y\u00f6netimi, \u00fcr\u00fcn katalo\u011fu, \u00f6deme i\u015flemleri) odaklan\u0131r ve bu alandaki t\u00fcm sorumluluklar\u0131 \u00fcstlenir. \u00d6rne\u011fin, bir e-ticaret platformunda:<\/p>\n Bu ayr\u0131m sayesinde, \u00f6rne\u011fin \u00f6deme sisteminde bir de\u011fi\u015fiklik yap\u0131lmas\u0131 gerekti\u011finde, sadece \u00d6deme Servisi \u00fczerinde \u00e7al\u0131\u015f\u0131l\u0131r. Di\u011fer servislerin etkilenme riski minimuma iner. Bu durum, ekiplerin daha h\u0131zl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131, hatalar\u0131n daha kolay izole edilmesini ve sistemin genel olarak daha esnek ve \u00f6l\u00e7eklenebilir olmas\u0131n\u0131 sa\u011flar. Her servis kendi “tek becerisine” odakland\u0131\u011f\u0131 i\u00e7in, geli\u015ftirme, test etme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7leri de basitle\u015fir.<\/p>\n DevOps (Geli\u015ftirme ve Operasyonlar) k\u00fclt\u00fcr\u00fcnde ve \u00f6zellikle CI\/CD (Continuous Integration\/Continuous Delivery) i\u015flem hatlar\u0131nda (pipeline), “tek beceri, tek eylem” prensibi, otomasyonun ve verimlili\u011fin temelini olu\u015fturur. CI\/CD i\u015flem hatlar\u0131, kodun geli\u015ftirilmesinden \u00fcretime da\u011f\u0131t\u0131m\u0131na kadar olan s\u00fcreci otomatikle\u015ftiren bir dizi ad\u0131mdan olu\u015fur. Bu ad\u0131mlar\u0131n her biri, tek bir amaca hizmet eden atomik g\u00f6revler olarak tasarlan\u0131r:<\/p>\n Bu ad\u0131mlar\u0131n her birinin tek bir sorumlulu\u011fu olmas\u0131, i\u015flem hatt\u0131n\u0131n daha g\u00fcvenilir olmas\u0131n\u0131 sa\u011flar. E\u011fer bir ad\u0131mda hata olu\u015fursa (\u00f6rne\u011fin, birim testleri ba\u015far\u0131s\u0131z olursa), i\u015flem hatt\u0131 durur ve sorunlu ad\u0131m kolayca tespit edilebilir. Bu, sorunun nerede oldu\u011funu anlamak i\u00e7in t\u00fcm i\u015flem hatt\u0131n\u0131 ba\u015ftan sona incelemek yerine, yaln\u0131zca ilgili ad\u0131ma odaklanmay\u0131 m\u00fcmk\u00fcn k\u0131lar. B\u00f6ylece, hata ay\u0131klama s\u00fcresi k\u0131sal\u0131r ve geli\u015ftiriciler daha h\u0131zl\u0131 geri bildirim alarak sorunlar\u0131 daha \u00e7abuk \u00e7\u00f6zebilirler. Bu atomik g\u00f6revler sayesinde, CI\/CD i\u015flem hatlar\u0131 daha esnek, bak\u0131m\u0131 daha kolay ve daha verimli hale gelir.<\/p>\n Bir bankac\u0131l\u0131k sisteminde para transferi gibi kritik bir i\u015flem onaylama s\u00fcrecini d\u00fc\u015f\u00fcnelim. Bu s\u00fcre\u00e7, genellikle birden fazla ad\u0131mdan olu\u015fur ve her ad\u0131m\u0131n kendine \u00f6zg\u00fc bir sorumlulu\u011fu vard\u0131r. “Tek beceri, tek eylem” prensibi burada da g\u00fcvenli\u011fi ve tutarl\u0131l\u0131\u011f\u0131 art\u0131rmak i\u00e7in kullan\u0131l\u0131r:<\/p>\n Bu ayr\u0131\u015ft\u0131rma sayesinde, her bir ad\u0131m ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilir, test edilebilir ve \u00f6l\u00e7eklenebilir. \u00d6rne\u011fin, yeni bir kimlik do\u011frulama y\u00f6ntemi (y\u00fcz tan\u0131ma gibi) eklendi\u011finde, sadece Kullan\u0131c\u0131 Kimlik Do\u011frulama Servisi g\u00fcncellenir. Di\u011fer servisler bundan etkilenmez. E\u011fer bir i\u015flem s\u0131ras\u0131nda bir hata olu\u015fursa (\u00f6rne\u011fin, bakiye yetersizse), bu durum sadece ilgili servisten d\u00f6ner ve t\u00fcm sistemin \u00e7\u00f6kmesine neden olmaz. Bu mod\u00fcler yap\u0131, bankac\u0131l\u0131k gibi y\u00fcksek g\u00fcvenlik ve tutarl\u0131l\u0131k gerektiren sekt\u00f6rlerde sistemin sa\u011flaml\u0131\u011f\u0131n\u0131 ve g\u00fcvenilirli\u011fini art\u0131r\u0131r. Bu \u00f6rnekler, “tek beceri, tek eylem” yakla\u015f\u0131m\u0131n\u0131n sadece teorik bir kavram olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda karma\u015f\u0131k sistemlerin ba\u015far\u0131l\u0131 bir \u015fekilde in\u015fa edilmesi ve s\u00fcrd\u00fcr\u00fclmesi i\u00e7in pratik ve etkili bir yol g\u00f6sterici oldu\u011funu a\u00e7\u0131k\u00e7a ortaya koymaktad\u0131r.<\/p>\n “Tek beceri, tek eylem” prensibi, yaz\u0131l\u0131m geli\u015ftirmeye bir\u00e7ok fayda sa\u011flasa da, beraberinde baz\u0131 zorluklar\u0131 da getirebilir. Bu zorluklar\u0131 anlamak ve bunlara y\u00f6nelik etkili \u00e7\u00f6z\u00fcm \u00f6nerileri geli\u015ftirmek, prensibin ba\u015far\u0131l\u0131 bir \u015fekilde uygulanmas\u0131 i\u00e7in kritik \u00f6neme sahiptir. Aksi takdirde, iyi niyetli bir mod\u00fclerle\u015ftirme \u00e7abas\u0131, y\u00f6netimi zor bir karma\u015faya d\u00f6n\u00fc\u015febilir.<\/p>\n Bu prensibi a\u015f\u0131r\u0131ya ka\u00e7arak uygulamak, kod taban\u0131nda \u00e7ok fazla say\u0131da k\u00fc\u00e7\u00fck dosya, fonksiyon veya mikroservis olu\u015fmas\u0131na neden olabilir. Her bir i\u015flevi en k\u00fc\u00e7\u00fck par\u00e7alar\u0131na ay\u0131rmak, ba\u015flang\u0131\u00e7ta mant\u0131kl\u0131 g\u00f6r\u00fcnse de, zamanla bu k\u00fc\u00e7\u00fck par\u00e7alar\u0131n say\u0131s\u0131 o kadar artabilir ki, sistemi bir b\u00fct\u00fcn olarak anlamak ve y\u00f6netmek zorla\u015f\u0131r. \u00d6rne\u011fin, bir i\u015flem i\u00e7in 100 farkl\u0131 k\u00fc\u00e7\u00fck fonksiyonunuz oldu\u011funda, bu fonksiyonlar aras\u0131ndaki ili\u015fkileri ve veri ak\u0131\u015f\u0131n\u0131 takip etmek karma\u015f\u0131k bir hal alabilir. Bu durum, geli\u015ftiricilerin kod taban\u0131nda gezinirken kaybolmas\u0131na ve genel mimariyi g\u00f6zden ka\u00e7\u0131rmas\u0131na yol a\u00e7abilir.<\/p>\n Anahtar, do\u011fru gran\u00fclariteyi (par\u00e7alama d\u00fczeyini) bulmakt\u0131r. Her bir fonksiyon veya servis, mant\u0131ksal olarak bir b\u00fct\u00fcn olan ve tek bir sorumlulu\u011fu yerine getiren bir i\u015fi temsil etmelidir. “Tek sorumluluk” tan\u0131m\u0131n\u0131 \u00e7ok dar tutmak yerine, bir “i\u015f ba\u011flam\u0131” (business context) i\u00e7inde tek bir sorumlulu\u011fu hedeflemek daha sa\u011fl\u0131kl\u0131d\u0131r. \u00d6rne\u011fin, “kullan\u0131c\u0131 kayd\u0131” tek bir sorumluluk olabilir ve bu sorumluluk alt\u0131nda birden fazla atomik alt eylem (do\u011frulama, kaydetme, e-posta g\u00f6nderme) bar\u0131nd\u0131rabilir. Bu alt eylemler kendi i\u00e7lerinde atomik kalsa da, \u00fcst d\u00fczeyde tek bir i\u015f ak\u0131\u015f\u0131 olarak gruplanabilirler. Ayr\u0131ca, iyi belgelendirme ve mod\u00fcl\/servis haritalar\u0131 (\u00f6rne\u011fin, mimari diyagramlar) bu par\u00e7alar\u0131 anlamay\u0131 ve y\u00f6netmeyi kolayla\u015ft\u0131r\u0131r.<\/p>\n Sistemi k\u00fc\u00e7\u00fck, ba\u011f\u0131ms\u0131z par\u00e7alara ay\u0131rd\u0131\u011f\u0131n\u0131zda, bu par\u00e7alar\u0131n birbiriyle ileti\u015fim kurmas\u0131 ve veri al\u0131\u015fveri\u015finde bulunmas\u0131 gerekir. Mikroservisler \u00f6rne\u011finde, farkl\u0131 servisler HTTP, mesaj kuyruklar\u0131 (message queues) veya olay odakl\u0131 mimariler (event-driven architectures) arac\u0131l\u0131\u011f\u0131yla ileti\u015fim kurar. Bu ileti\u015fim mekanizmalar\u0131n\u0131n y\u00f6netimi, hata i\u015fleme, veri tutarl\u0131l\u0131\u011f\u0131 ve a\u011f gecikmeleri gibi konularda ek karma\u015f\u0131kl\u0131k yarat\u0131r. Bir servisin di\u011ferine ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 artt\u0131k\u00e7a, bu ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek ve olas\u0131 “domino etkisi” hatalar\u0131n\u0131 \u00f6nlemek daha zor hale gelir.<\/p>\n Ba\u011f\u0131ml\u0131l\u0131klar\u0131 en aza indirmek ve ileti\u015fimi kolayla\u015ft\u0131rmak i\u00e7in, her servisin veya mod\u00fcl\u00fcn a\u00e7\u0131k ve iyi tan\u0131mlanm\u0131\u015f aray\u00fczler (API’ler) sunmas\u0131 \u00f6nemlidir. Servisler aras\u0131 ileti\u015fimde senkron yerine asenkron yakla\u015f\u0131mlar\u0131 (\u00f6rne\u011fin, RabbitMQ, Kafka gibi mesaj kuyruklar\u0131) tercih etmek, ba\u011f\u0131ml\u0131l\u0131klar\u0131 azalt\u0131r ve sistemin daha esnek olmas\u0131n\u0131 sa\u011flar. Olay odakl\u0131 mimarilerde (event-driven architecture), servisler birbirlerinin olaylar\u0131na abone olur ve olaylar\u0131 yay\u0131nlar; bu, do\u011frudan ba\u011f\u0131ml\u0131l\u0131k yerine dolayl\u0131 bir ba\u011f\u0131ml\u0131l\u0131k yarat\u0131r ve esnekli\u011fi art\u0131r\u0131r. Ayr\u0131ca, da\u011f\u0131t\u0131lm\u0131\u015f izleme (distributed tracing) ara\u00e7lar\u0131 (\u00f6rne\u011fin, OpenTelemetry, Jaeger) servisler aras\u0131 ileti\u015fimi ve hatalar\u0131 takip etmeyi kolayla\u015ft\u0131r\u0131r.<\/p>\n \u00c7ok say\u0131da k\u00fc\u00e7\u00fck fonksiyon \u00e7a\u011fr\u0131s\u0131 veya mikroservisler aras\u0131 a\u011f \u00e7a\u011fr\u0131s\u0131, tek bir b\u00fcy\u00fck monolitik (monolithic) uygulamaya g\u00f6re daha fazla performans ek y\u00fck\u00fc (overhead) yaratabilir. Her bir fonksiyon \u00e7a\u011fr\u0131s\u0131 veya a\u011f iste\u011fi belirli bir i\u015flem s\u00fcresi ve kaynak (CPU, bellek) t\u00fcketimi anlam\u0131na gelir. Bu durum, \u00f6zellikle y\u00fcksek performans gerektiren sistemlerde veya d\u00fc\u015f\u00fck gecikmeli (low-latency) uygulamalarda bir sorun te\u015fkil edebilir.<\/p>\n Performans kayg\u0131lar\u0131n\u0131 gidermek i\u00e7in, sistemin d\u00fczenli olarak profillenmesi (profiling) ve darbo\u011fazlar\u0131n (bottlenecks) tespit edilmesi \u015fartt\u0131r. Kritik performans yollar\u0131ndaki atomik eylemlerin dikkatlice optimize edilmesi gerekebilir. Mikroservis mimarilerinde, servisler aras\u0131 ileti\u015fimi azaltmak i\u00e7in veri \u00f6nbellekleme (caching) mekanizmalar\u0131 kullan\u0131labilir. Ayr\u0131ca, baz\u0131 durumlarda, belirli bir i\u015flem i\u00e7in birden fazla k\u00fc\u00e7\u00fck servisi birle\u015ftiren bir “API Gateway” veya “BFF (Backend for Frontend)” katman\u0131 kullan\u0131larak istemci taraf\u0131ndaki \u00e7a\u011fr\u0131 say\u0131s\u0131 azalt\u0131labilir. Bu, istemci ile servisler aras\u0131ndaki do\u011frudan ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 azalt\u0131rken, servislerin kendi i\u00e7lerindeki atomik yap\u0131s\u0131n\u0131 korumaya yard\u0131mc\u0131 olur. Unutulmamal\u0131d\u0131r ki, performans optimizasyonu her zaman bir denge i\u015fidir ve her zaman “tek beceri, tek eylem” prensibinden tamamen vazge\u00e7mek yerine, ak\u0131ll\u0131ca optimizasyon stratejileri uygulanmal\u0131d\u0131r.<\/p>\n \u00d6zetle, “tek beceri, tek eylem” prensibinin getirdi\u011fi zorluklar, do\u011fru tasar\u0131m kararlar\u0131, uygun ara\u00e7lar ve s\u00fcrekli iyile\u015ftirme ile a\u015f\u0131labilir. Bu zorluklar, prensibin kendisinin yanl\u0131\u015f oldu\u011fu anlam\u0131na gelmez, aksine, onu daha bilin\u00e7li ve etkili bir \u015fekilde uygulamak i\u00e7in bize yol g\u00f6sterir.<\/p>\n “Tek beceri, tek eylem” prensibini temel d\u00fczeyde anlamak ve uygulamak, kod kalitesini ve sistemin s\u00fcrd\u00fcr\u00fclebilirli\u011fini art\u0131rman\u0131n ilk ad\u0131m\u0131d\u0131r. Ancak, bu prensibi daha ileri seviyede benimseyerek ve modern geli\u015ftirme metodolojileriyle birle\u015ftirerek, yaz\u0131l\u0131m s\u00fcre\u00e7lerinizde \u00f6nemli optimizasyonlar sa\u011flayabilirsiniz. Bu b\u00f6l\u00fcmde, deneyimli geli\u015ftiriciler i\u00e7in bu prensibi daha da g\u00fc\u00e7lendirecek ipu\u00e7lar\u0131na ve p\u00fcf noktalar\u0131na de\u011finece\u011fiz.<\/p>\n Test Odakl\u0131 Geli\u015ftirme (TDD), yaz\u0131l\u0131m geli\u015ftirmede \u00f6nce testleri yaz\u0131p sonra bu testleri ge\u00e7ecek kodu yazma yakla\u015f\u0131m\u0131d\u0131r. Bu metodoloji, “tek beceri, tek eylem” prensibiyle m\u00fckemmel bir uyum i\u00e7indedir. Neden mi? \u00c7\u00fcnk\u00fc TDD, do\u011fal olarak k\u00fc\u00e7\u00fck, odakl\u0131 ve test edilebilir kod birimleri yazmay\u0131 te\u015fvik eder. Her bir test, bir fonksiyonun veya metodun tek bir davran\u0131\u015f\u0131n\u0131 do\u011frulamal\u0131d\u0131r. Bu da bizi do\u011frudan tek sorumlulu\u011fa sahip atomik eylemler olu\u015fturmaya y\u00f6nlendirir.<\/p>\n TDD uygularken, bir fonksiyonun tek bir i\u015fi yapmas\u0131, o fonksiyon i\u00e7in test senaryolar\u0131 yazmay\u0131 \u00e7ok daha basit hale getirir. \u00d6rne\u011fin, bir veri do\u011frulama fonksiyonu i\u00e7in sadece do\u011frulama kurallar\u0131n\u0131 test edersiniz; veritaban\u0131 kayd\u0131 veya loglama gibi ba\u015fka endi\u015feleriniz olmaz. Bu durum, testlerin daha h\u0131zl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131, daha g\u00fcvenilir olmas\u0131n\u0131 ve kodda bir de\u011fi\u015fiklik yap\u0131ld\u0131\u011f\u0131nda hangi testlerin etkilendi\u011fini anlamay\u0131 kolayla\u015ft\u0131r\u0131r. Ayr\u0131ca, TDD sayesinde, kodun tasar\u0131m\u0131 en ba\u015ftan itibaren test edilebilirli\u011fi g\u00f6z \u00f6n\u00fcnde bulundurularak yap\u0131l\u0131r, bu da daha mod\u00fcler ve “tek beceri, tek eylem” prensibine uygun bir yap\u0131ya yol a\u00e7ar.<\/p>\n Davran\u0131\u015f Odakl\u0131 Geli\u015ftirme (BDD), TDD’nin bir uzant\u0131s\u0131d\u0131r ve i\u015f birimleri ile geli\u015ftiriciler aras\u0131ndaki ileti\u015fimi g\u00fc\u00e7lendirmeye odaklan\u0131r. BDD, yaz\u0131l\u0131m\u0131n davran\u0131\u015f\u0131n\u0131 do\u011fal dil kullanarak tan\u0131mlayan senaryolar (\u00f6rne\u011fin, Gherkin syntax’\u0131 ile “Given-When-Then” format\u0131nda) yazmay\u0131 i\u00e7erir. Bu senaryolar, sistemin belirli bir “eyleme” nas\u0131l tepki vermesi gerekti\u011fini a\u00e7\u0131k\u00e7a belirtir.<\/p>\n BDD, “tek beceri, tek eylem” prensibini daha \u00fcst d\u00fczeyde, yani i\u015flevsellik seviyesinde destekler. Her bir senaryo, kullan\u0131c\u0131 veya sistem a\u00e7\u0131s\u0131ndan tek bir davran\u0131\u015f\u0131 tan\u0131mlar. Bu da, geli\u015ftiricilerin kodu yazarken belirli bir i\u015flevin tam olarak ne yapmas\u0131 gerekti\u011fini anlamalar\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, “Kullan\u0131c\u0131 sepete \u00fcr\u00fcn ekledi\u011finde, sepet toplam\u0131 g\u00fcncellenmeli ve stok azalmal\u0131” gibi bir BDD senaryosu, ilgili kod par\u00e7alar\u0131n\u0131n sadece bu davran\u0131\u015f\u0131 yerine getirmesini gerektirir. Bu, kodun gereksiz sorumluluklar \u00fcstlenmesini engeller ve her bir par\u00e7an\u0131n kendi odaklanm\u0131\u015f i\u015fini yapmas\u0131n\u0131 te\u015fvik eder. BDD, i\u015f gereksinimlerini atomik davran\u0131\u015flara d\u00f6n\u00fc\u015ft\u00fcrmede g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r.<\/p>\n Domain-Driven Design (DDD), karma\u015f\u0131k i\u015f alanlar\u0131n\u0131 (domain) modellemeye odaklanan bir yaz\u0131l\u0131m geli\u015ftirme yakla\u015f\u0131m\u0131d\u0131r. DDD, i\u015f alan\u0131n\u0131 (\u00f6rne\u011fin, bankac\u0131l\u0131k, e-ticaret) k\u00fc\u00e7\u00fck, iyi tan\u0131mlanm\u0131\u015f “s\u0131n\u0131rl\u0131 ba\u011flamlara” (bounded contexts) ay\u0131r\u0131r. Her bir s\u0131n\u0131rl\u0131 ba\u011flam, kendi i\u00e7inde tutarl\u0131 bir i\u015f modelini ve ilgili i\u015flevselli\u011fi bar\u0131nd\u0131r\u0131r.<\/p>\n Bu yakla\u015f\u0131m, “tek beceri, tek eylem” prensibini mimari d\u00fczeyde uygular. Her bir s\u0131n\u0131rl\u0131 ba\u011flam, belirli bir i\u015f alan\u0131 becerisine odaklan\u0131r ve o beceriyle ilgili t\u00fcm eylemleri (mod\u00fcller, servisler, varl\u0131klar) kendi i\u00e7inde tutar. \u00d6rne\u011fin, bir e-ticaret uygulamas\u0131nda “Sipari\u015f Y\u00f6netimi” ve “\u00dcr\u00fcn Katalogu” ayr\u0131 s\u0131n\u0131rl\u0131 ba\u011flamlar olabilir. Sipari\u015f Y\u00f6netimi ba\u011flam\u0131, sipari\u015f olu\u015fturma, g\u00fcncelleme, iptal etme gibi eylemlere odaklan\u0131rken; \u00dcr\u00fcn Katalogu ba\u011flam\u0131, \u00fcr\u00fcn listeleme, arama, detay g\u00f6r\u00fcnt\u00fcleme gibi eylemlere odaklan\u0131r. Bu ayr\u0131m, her bir ba\u011flam\u0131n kendi i\u00e7inde tutarl\u0131 ve ba\u011f\u0131ms\u0131z olmas\u0131n\u0131 sa\u011flar, b\u00f6ylece bir ba\u011flamdaki de\u011fi\u015fiklikler di\u011ferini minimum d\u00fczeyde etkiler. DDD, i\u015f mant\u0131\u011f\u0131n\u0131 atomik, y\u00f6netilebilir birimlere ay\u0131rarak b\u00fcy\u00fck ve karma\u015f\u0131k sistemlerin tasarlanmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n Mevcut bir kod taban\u0131nda (legacy code) “tek beceri, tek eylem” prensibini uygulamak, genellikle yeniden d\u00fczenleme (refactoring) s\u00fcreciyle ger\u00e7ekle\u015fir. Yeniden d\u00fczenleme, kodun d\u0131\u015f davran\u0131\u015f\u0131n\u0131 de\u011fi\u015ftirmeden i\u00e7 yap\u0131s\u0131n\u0131 iyile\u015ftirme i\u015flemidir. Bu, b\u00fcy\u00fck, karma\u015f\u0131k fonksiyonlar\u0131 daha k\u00fc\u00e7\u00fck, odakl\u0131 fonksiyonlara b\u00f6lmek, s\u0131n\u0131flar\u0131n veya mod\u00fcllerin sorumluluklar\u0131n\u0131 netle\u015ftirmek anlam\u0131na gelebilir.<\/p>\n Yeniden d\u00fczenleme yaparken, “Extract Method” (Metot \u00c7\u0131karma) veya “Extract Class” (S\u0131n\u0131f \u00c7\u0131karma) gibi teknikler, mevcut kodda “tek beceri, tek eylem” prensibini uygulamak i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, \u00e7ok uzun ve birden fazla i\u015f yapan bir fonksiyonu, her bir i\u015fi ayr\u0131 bir metot haline getirerek daha y\u00f6netilebilir hale getirebilirsiniz. Bu s\u00fcre\u00e7, testlerin varl\u0131\u011f\u0131yla desteklendi\u011finde daha g\u00fcvenli hale gelir, \u00e7\u00fcnk\u00fc testler, yeniden d\u00fczenleme s\u0131ras\u0131nda herhangi bir i\u015flevsellik kayb\u0131 olup olmad\u0131\u011f\u0131n\u0131 do\u011frulamaya yard\u0131mc\u0131 olur. Yeniden d\u00fczenleme, zamanla biriken teknik borcu (technical debt) azalt\u0131r ve kod taban\u0131n\u0131 daha esnek ve bak\u0131m\u0131 kolay bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fcr\u00fcr.<\/p>\n \u00d6zetle, “tek beceri, tek eylem” prensibini ileri d\u00fczeyde uygulamak, TDD ve BDD gibi test odakl\u0131 metodolojileri benimsemeyi, DDD ile i\u015f mant\u0131\u011f\u0131n\u0131 mimari d\u00fczeyde b\u00f6l\u00fcmlere ay\u0131rmay\u0131 ve mevcut kodda s\u00fcrekli yeniden d\u00fczenleme yapmay\u0131 gerektirir. Bu yakla\u015f\u0131mlar bir araya geldi\u011finde, sadece fonksiyonlar\u0131n\u0131z\u0131 de\u011fil, t\u00fcm sisteminizi daha mod\u00fcler, anla\u015f\u0131l\u0131r, test edilebilir ve s\u00fcrd\u00fcr\u00fclebilir hale getirir, b\u00f6ylece geli\u015ftirme s\u00fcre\u00e7lerinizde ger\u00e7ek bir g\u00fcvenli s\u0131n\u0131r olu\u015fturursunuz.<\/p>\n “Tek beceri, tek eylem” prensibi, modern yaz\u0131l\u0131m geli\u015ftirmede ve genel i\u015f s\u00fcre\u00e7leri y\u00f6netiminde bir felsefe olmaktan \u00f6te, pratik bir zorunluluk haline gelmi\u015ftir. Bu prensip, karma\u015f\u0131k sistemleri daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir ve odakl\u0131 par\u00e7alara ay\u0131rarak, geli\u015ftirme s\u00fcrecindeki belirsizlikleri ve riskleri \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Adeta bir in\u015faat projesinde her ustan\u0131n sadece kendi uzmanl\u0131k alan\u0131na odaklanmas\u0131 gibi, yaz\u0131l\u0131mda da her kod par\u00e7as\u0131n\u0131n veya servisin tek bir sorumlulu\u011fu olmas\u0131, sa\u011flam ve g\u00fcvenilir yap\u0131lar in\u015fa etmemizi sa\u011flar.<\/p>\n Bu makalede g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, “tek beceri, tek eylem” yakla\u015f\u0131m\u0131, kodun okunabilirli\u011fini, bak\u0131m\u0131n\u0131 ve test edilebilirli\u011fini art\u0131rarak geli\u015ftiricilerin hayat\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. Hatalar\u0131n izole edilmesini ve daha h\u0131zl\u0131 \u00e7\u00f6z\u00fclmesini sa\u011flar. Mikroservis mimarileri ve CI\/CD s\u00fcre\u00e7leri gibi modern yakla\u015f\u0131mlar\u0131n temelini olu\u015fturur. Elbette, a\u015f\u0131r\u0131 par\u00e7alama veya ba\u011f\u0131ml\u0131l\u0131k y\u00f6netimi gibi zorluklar ortaya \u00e7\u0131kabilir, ancak do\u011fru gran\u00fclariteyi bulmak, a\u00e7\u0131k aray\u00fczler tasarlamak ve s\u00fcrekli profilleme ile bu zorluklar\u0131n \u00fcstesinden gelinebilir. TDD, BDD ve DDD gibi ileri d\u00fczey metodolojilerle birle\u015fti\u011finde ise, bu prensip sadece bir kodlama kural\u0131 olmaktan \u00e7\u0131kar, t\u00fcm bir geli\u015ftirme k\u00fclt\u00fcr\u00fcn\u00fc d\u00f6n\u00fc\u015ft\u00fcren g\u00fc\u00e7l\u00fc bir ara\u00e7 haline gelir.<\/p>\n Sonu\u00e7 olarak, “tek beceri, tek eylem”, yaz\u0131l\u0131m geli\u015ftirme yolculu\u011funuzda size rehberlik eden g\u00fcvenli bir s\u0131n\u0131rd\u0131r. Bu s\u0131n\u0131r, projenizin karma\u015f\u0131kl\u0131k kar\u015f\u0131s\u0131nda ezilmesini engeller, de\u011fi\u015fikliklere kar\u015f\u0131 daha diren\u00e7li olmas\u0131n\u0131 sa\u011flar ve uzun vadede s\u00fcrd\u00fcr\u00fclebilir ba\u015far\u0131ya ula\u015fman\u0131z i\u00e7in sa\u011flam bir temel sunar. Bu prensibi benimsemek, sadece daha iyi kod yazmakla kalmaz, ayn\u0131 zamanda daha verimli, daha az stresli ve daha keyifli bir geli\u015ftirme deneyimi ya\u015faman\u0131z\u0131 sa\u011flar. Unutmay\u0131n, b\u00fcy\u00fck i\u015fler her zaman k\u00fc\u00e7\u00fck, odakl\u0131 ad\u0131mlarla ba\u015far\u0131l\u0131r.<\/p>\n Hay\u0131r, bu prensip yaz\u0131l\u0131m geli\u015ftirmenin \u00f6tesine ge\u00e7er. Herhangi bir karma\u015f\u0131k g\u00f6revi veya i\u015f s\u00fcrecini daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir ve odakl\u0131 ad\u0131mlara b\u00f6lme ihtiyac\u0131 olan her alanda uygulanabilir. \u00d6rne\u011fin, proje y\u00f6netimi, \u00fcretim s\u00fcre\u00e7leri veya hatta g\u00fcnl\u00fck ya\u015fam g\u00f6revleri bile bu yakla\u015f\u0131mdan faydalanabilir.<\/p>\n<\/li>\n A\u015f\u0131r\u0131 par\u00e7alama, birimlerin (fonksiyonlar, mod\u00fcller, servisler) o kadar k\u00fc\u00e7\u00fck ve \u00e7ok say\u0131da oldu\u011fu durumlarda ba\u015flar ki, bunlar\u0131 y\u00f6netmek, aralar\u0131ndaki ili\u015fkileri anlamak ve genel sistemi bir b\u00fct\u00fcn olarak kavramak zorla\u015f\u0131r. Do\u011fru gran\u00fclariteyi bulmak, bir birimin mant\u0131ksal olarak tek bir i\u015f ba\u011flam\u0131nda anlaml\u0131 bir sorumlulu\u011fu yerine getirmesiyle ilgilidir. “Tek bir de\u011fi\u015fiklik nedeni” ilkesi burada iyi bir rehberdir.<\/p>\n<\/li>\n Mevcut kodda bu prensibi uygulamaya ba\u015flaman\u0131n en iyi yolu, yeniden d\u00fczenleme (refactoring) tekniklerini kullanmakt\u0131r. K\u00fc\u00e7\u00fck ad\u0131mlarla ba\u015flay\u0131n: Uzun, karma\u015f\u0131k fonksiyonlar\u0131 daha k\u00fc\u00e7\u00fck, odakl\u0131 fonksiyonlara ay\u0131r\u0131n. Sorumluluklar\u0131 kar\u0131\u015fm\u0131\u015f s\u0131n\u0131flar\u0131 veya mod\u00fclleri daha net sorumluluklara sahip yeni birimlere b\u00f6l\u00fcn. Bu s\u00fcre\u00e7te, kodun davran\u0131\u015f\u0131n\u0131 bozmad\u0131\u011f\u0131n\u0131zdan emin olmak i\u00e7in mevcut testleri kullan\u0131n veya yeni testler yaz\u0131n.<\/p>\n<\/li>\n Potansiyel olarak evet, \u00f6zellikle mikroservisler aras\u0131 a\u011f \u00e7a\u011fr\u0131lar\u0131 veya \u00e7ok say\u0131da k\u00fc\u00e7\u00fck fonksiyon \u00e7a\u011fr\u0131s\u0131, tek bir monolitik yap\u0131ya g\u00f6re ek y\u00fck (overhead) yaratabilir. Ancak bu genellikle iyi bir tasar\u0131m, \u00f6nbellekleme (caching) ve ak\u0131ll\u0131 optimizasyon stratejileriyle y\u00f6netilebilir bir durumdur. \u00c7o\u011fu durumda, elde edilen bak\u0131m kolayl\u0131\u011f\u0131, \u00f6l\u00e7eklenebilirlik ve esneklik faydalar\u0131, k\u00fc\u00e7\u00fck performans maliyetlerinden \u00e7ok daha de\u011ferlidir.<\/p>\n<\/li>\n Anahtar faydalar aras\u0131nda daha y\u00fcksek kod kalitesi, daha kolay bak\u0131m, art\u0131r\u0131lm\u0131\u015f test edilebilirlik, daha h\u0131zl\u0131 hata tespiti ve \u00e7\u00f6z\u00fcm\u00fc, daha iyi \u00f6l\u00e7eklenebilirlik ve daha esnek bir mimari yer al\u0131r. Ayr\u0131ca, geli\u015ftirme ekiplerinin daha ba\u011f\u0131ms\u0131z \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r ve yeni geli\u015ftiricilerin projeye adaptasyonunu h\u0131zland\u0131r\u0131r.<\/p>\n<\/li>\n<\/ol>\n #Teknoloji #Yaz\u0131l\u0131mGeli\u015ftirme #Mod\u00fclerTasar\u0131m #SRP #KodKalitesi #Mikroservisler #DevOps<\/p>\nkullaniciBilgileriniAl()<\/code>, sifreyiHashle()<\/code>, veritabaninaKaydet()<\/code>, onayEpostasiGonder()<\/code> gibi. Bu \u015fekilde, her fonksiyon kendi “becerisine” odaklanm\u0131\u015f olur.<\/p>\nYaz\u0131l\u0131m Geli\u015ftirmede Atomik Eylemler Nas\u0131l Uygulan\u0131r?<\/h2>\n
Fonksiyonlar ve Metotlar: Tek Odakl\u0131l\u0131k<\/h3>\n
\nfunction urunEkle(urunAdi, fiyat, stokAdedi, aciklama) {\n \/\/ 1. Girdi verilerini do\u011frula\n if (!urunAdi || fiyat <= 0 || stokAdedi < 0) {\n console.error(\"Ge\u00e7ersiz \u00fcr\u00fcn bilgileri.\");\n return false;\n }\n\n \/\/ 2. Veritaban\u0131na kaydet\n const sql = INSERT INTO Urunler (ad, fiyat, stok, aciklama) VALUES (?, ?, ?, ?)<\/code>;\n db.query(sql, [urunAdi, fiyat, stokAdedi, aciklama], (err, result) => {\n if (err) {\n console.error(\"Veritaban\u0131na kaydederken hata olu\u015ftu:\", err);\n return false;\n }\n console.log(\"\u00dcr\u00fcn ba\u015far\u0131yla eklendi.\");\n \/\/ 3. Loglama yap\n logIslem(\"Yeni \u00fcr\u00fcn eklendi: \" + urunAdi);\n return true;\n });\n}\n <\/code><\/pre>\n<\/p><\/div>\n\nfunction urunBilgileriniDogrula(urun) {\n if (!urun.ad || urun.fiyat <= 0 || urun.stokAdedi < 0) {\n throw new Error(\"Ge\u00e7ersiz \u00fcr\u00fcn bilgileri.\");\n }\n return true;\n}\n\nfunction urunuVeritabaninaKaydet(urun) {\n return new Promise((resolve, reject) => {\n const sql = INSERT INTO Urunler (ad, fiyat, stok, aciklama) VALUES (?, ?, ?, ?)<\/code>;\n db.query(sql, [urun.ad, urun.fiyat, urun.stokAdedi, urun.aciklama], (err, result) => {\n if (err) {\n return reject(new Error(\"Veritaban\u0131na kaydederken hata olu\u015ftu: \" + err.message));\n }\n resolve(result);\n });\n });\n}\n\nfunction islemLogla(mesaj) {\n console.log(\"[LOG]\", mesaj);\n \/\/ Ger\u00e7ek bir uygulamada bu log dosyas\u0131na veya log servisine yaz\u0131labilir\n}\n\nasync function yeniUrunEkle(urun) {\n try {\n urunBilgileriniDogrula(urun);\n await urunuVeritabaninaKaydet(urun);\n islemLogla(\"Yeni \u00fcr\u00fcn ba\u015far\u0131yla eklendi: \" + urun.ad);\n return { success: true, message: \"\u00dcr\u00fcn ba\u015far\u0131yla eklendi.\" };\n } catch (error) {\n islemLogla(\"\u00dcr\u00fcn ekleme hatas\u0131: \" + error.message);\n return { success: false, message: error.message };\n }\n}\n\n\/\/ Kullan\u0131m \u00f6rne\u011fi\n\/\/ yeniUrunEkle({ ad: \"Laptop\", fiyat: 12000, stokAdedi: 50, aciklama: \"G\u00fc\u00e7l\u00fc bir diz\u00fcst\u00fc bilgisayar\" });\n <\/code><\/pre>\n<\/p><\/div>\nurunBilgileriniDogrula<\/code> sadece do\u011frulamadan, urunuVeritabaninaKaydet<\/code> sadece veritaban\u0131 i\u015fleminden ve islemLogla<\/code> sadece loglamadan sorumludur. yeniUrunEkle<\/code> fonksiyonu ise bu atomik eylemleri bir araya getirerek \u00fcst d\u00fczey bir i\u015f ak\u0131\u015f\u0131 sa\u011flar.<\/p>\nMod\u00fcller ve Bile\u015fenler: Ba\u011f\u0131ms\u0131zl\u0131k<\/h3>\n
API Tasar\u0131m\u0131: A\u00e7\u0131k ve Odakl\u0131 U\u00e7 Noktalar<\/h3>\n
\/api\/urunler<\/code> u\u00e7 noktas\u0131 t\u00fcm \u00fcr\u00fcnleri listelemek i\u00e7in kullan\u0131l\u0131rken, \/api\/urunler\/{id}<\/code> belirli bir \u00fcr\u00fcn\u00fc getirmek veya g\u00fcncellemek i\u00e7in kullan\u0131l\u0131r. Bir u\u00e7 noktan\u0131n hem \u00fcr\u00fcn listeleme hem de sipari\u015f olu\u015fturma gibi alakas\u0131z iki i\u015flevi yerine getirmesi, API’nin anla\u015f\u0131lmas\u0131n\u0131 ve kullan\u0131lmas\u0131n\u0131 zorla\u015ft\u0131r\u0131r. \u0130yi tasarlanm\u0131\u015f API’ler, her bir iste\u011fin net bir amac\u0131 olmas\u0131n\u0131 sa\u011flayarak entegrasyonu kolayla\u015ft\u0131r\u0131r ve hata potansiyelini d\u00fc\u015f\u00fcr\u00fcr.<\/p>\nVaka Analizi: E-ticaret Sepet Y\u00f6netimi<\/h3>\n
\n
sepeteUrunEkle(sepetId, urunId, miktar)<\/code>: Sadece sepete \u00fcr\u00fcn ekler. Miktar kontrol\u00fc, \u00fcr\u00fcn stok kontrol\u00fc gibi detaylar\u0131 kendi i\u00e7inde veya ba\u015fka atomik fonksiyonlar arac\u0131l\u0131\u011f\u0131yla halleder.<\/li>\nsepetUrunMiktarGuncelle(sepetId, urunId, yeniMiktar)<\/code>: Sadece belirli bir \u00fcr\u00fcn\u00fcn miktar\u0131n\u0131 g\u00fcnceller.<\/li>\nsepettenUrunCikar(sepetId, urunId)<\/code>: Sadece belirli bir \u00fcr\u00fcn\u00fc sepetten kald\u0131r\u0131r.<\/li>\nsepetiTemizle(sepetId)<\/code>: Sadece sepetin i\u00e7eri\u011fini bo\u015falt\u0131r.<\/li>\nsepetToplaminiHesapla(sepetId)<\/code>: Sadece sepetin toplam fiyat\u0131n\u0131 hesaplar.<\/li>\n<\/ul>\nsepetUrunMiktarGuncelle<\/code> fonksiyonunu etkiler, sepetten \u00fcr\u00fcn \u00e7\u0131karma veya sepete \u00fcr\u00fcn ekleme i\u015flevlerini bozma riski ta\u015f\u0131maz. Bu, hem geli\u015ftirme h\u0131z\u0131n\u0131 art\u0131r\u0131r hem de yaz\u0131l\u0131m\u0131n genel kalitesini y\u00fckseltir. Sonu\u00e7 olarak, yaz\u0131l\u0131m geli\u015ftirmede atomik eylemlerin uygulanmas\u0131, daha y\u00f6netilebilir, test edilebilir ve s\u00fcrd\u00fcr\u00fclebilir bir kod taban\u0131 olu\u015fturman\u0131n anahtar\u0131d\u0131r.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131nda “Tek Beceri, Tek Eylem” Yakla\u015f\u0131m\u0131<\/h2>\n
Mikroservisler (Microservices) Mimarisi: Ba\u011f\u0131ms\u0131z Hizmetler<\/h3>\n
\n
DevOps S\u00fcre\u00e7leri: CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Teslimat) Ad\u0131mlar\u0131nda Atomik G\u00f6revler<\/h3>\n
\n
Vaka Analizi: Bankac\u0131l\u0131k Sisteminde \u0130\u015flem Onaylama S\u00fcreci<\/h3>\n
\n
Bu Yakla\u015f\u0131m\u0131n Getirdi\u011fi Zorluklar ve \u00c7\u00f6z\u00fcm \u00d6nerileri Nelerdir?<\/h2>\n
A\u015f\u0131r\u0131 Par\u00e7alama (Over-fragmentation) ve Y\u00f6netim Zorlu\u011fu<\/h3>\n
\u00c7\u00f6z\u00fcm \u00d6nerisi: Do\u011fru Gran\u00fclariteyi Bulmak<\/h4>\n
Ba\u011f\u0131ml\u0131l\u0131k Y\u00f6netimi ve \u0130leti\u015fim Zorluklar\u0131<\/h3>\n
\u00c7\u00f6z\u00fcm \u00d6nerisi: A\u00e7\u0131k Aray\u00fczler ve Olay Odakl\u0131 Mimari<\/h4>\n
Performans Kayg\u0131lar\u0131 ve Ek Y\u00fck (Overhead)<\/h3>\n
\u00c7\u00f6z\u00fcm \u00d6nerisi: Profilleme ve Optimizasyon<\/h4>\n
“Tek Beceri, Tek Eylem” \u0130le \u0130leri D\u00fczey Optimizasyon \u0130pu\u00e7lar\u0131<\/h2>\n
Test Odakl\u0131 Geli\u015ftirme (Test-Driven Development – TDD): Atomik Eylemler \u0130\u00e7in M\u00fckemmel Uyum<\/h3>\n
Davran\u0131\u015f Odakl\u0131 Geli\u015ftirme (Behavior-Driven Development – BDD): \u0130\u015flevselli\u011fi Daha Net Tan\u0131mlama<\/h3>\n
Domain-Driven Design (Alan Odakl\u0131 Tasar\u0131m – DDD): \u0130\u015f Mant\u0131\u011f\u0131n\u0131 Atomik Birimlere Ay\u0131rma<\/h3>\n
Refactoring (Yeniden D\u00fczenleme): Mevcut Kodu \u0130yile\u015ftirme<\/h3>\n
Sonu\u00e7: Neden “Tek Beceri, Tek Eylem” G\u00fcvenli Bir S\u0131n\u0131rd\u0131r?<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n