Hi\u00e7, “Bu kod nas\u0131l \u00e7al\u0131\u015f\u0131yor?” diye merak ederek bir projeye ba\u015flad\u0131n\u0131z m\u0131? Ya da belki de siz, sadece sizin anlayabilece\u011finiz, kendi i\u00e7inde bir mant\u0131\u011f\u0131 olan ama ba\u015fkalar\u0131 i\u00e7in adeta bir bilmeceye d\u00f6n\u00fc\u015fm\u00fc\u015f bir Python beti\u011fi yazd\u0131n\u0131z. \u0130\u015fte bu durum, yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda olduk\u00e7a yayg\u0131n bir senaryodur. \u00d6zellikle h\u0131zl\u0131 prototipleme veya ki\u015fisel projelerde, kodun okunabilirli\u011fi ve s\u00fcrd\u00fcr\u00fclebilirli\u011fi g\u00f6z ard\u0131 edilebilir. Ancak, bir projeyi ekip arkada\u015flar\u0131n\u0131zla payla\u015fman\u0131z, bir m\u00fc\u015fteriye teslim etmeniz veya gelecekte kendi ba\u015f\u0131n\u0131za bile kodunuzu tekrar anlaman\u0131z gerekti\u011finde, bu “da\u011f\u0131n\u0131k” kodlar ciddi sorunlara yol a\u00e7abilir. Peki, bu karma\u015fadan nas\u0131l kurtulabilir ve hem sizin hem de ba\u015fkalar\u0131n\u0131n anlayabilece\u011fi, temiz ve teslim edilebilir bir Python beti\u011fi nas\u0131l ortaya \u00e7\u0131karabiliriz? Bu makalede, karma\u015f\u0131k ve d\u00fczensiz bir Python beti\u011fini bile anla\u015f\u0131l\u0131r, bak\u0131m\u0131 yap\u0131labilir ve nihayetinde ba\u015far\u0131l\u0131 bir \u015fekilde teslim edilebilir hale getiren 10 ad\u0131ml\u0131k bir kontrol listesini sizlerle payla\u015faca\u011f\u0131m. Bu liste, sadece kodunuzu d\u00fczenlemekle kalmayacak, ayn\u0131 zamanda proje y\u00f6netimi ve ekip \u00e7al\u0131\u015fmas\u0131 a\u00e7\u0131s\u0131ndan da size de\u011ferli kazan\u0131mlar sa\u011flayacakt\u0131r.<\/p>\n
Bir Python beti\u011finin “da\u011f\u0131n\u0131k” olarak nitelendirilmesi genellikle birka\u00e7 temel nedene dayan\u0131r. Bunlar\u0131n ba\u015f\u0131nda, kodun amac\u0131na hizmet etse de okunabilirli\u011finin d\u00fc\u015f\u00fck olmas\u0131 gelir. Bu, uzun ve karma\u015f\u0131k fonksiyonlar, anla\u015f\u0131lmaz de\u011fi\u015fken isimleri, yetersiz yorum sat\u0131rlar\u0131, tutars\u0131z girintileme ve genel bir yap\u0131sal d\u00fczensizlik \u015feklinde kendini g\u00f6sterebilir. H\u0131zl\u0131 bir \u015fekilde bir \u015feyler \u00fcretme bask\u0131s\u0131 alt\u0131nda, genellikle en kolay ve en h\u0131zl\u0131 \u00e7\u00f6z\u00fcme odaklan\u0131l\u0131r. Bu da, kodun daha sonraki a\u015famalarda yeniden d\u00fczenlenmesi veya ba\u015fkalar\u0131 taraf\u0131ndan anla\u015f\u0131lmas\u0131 gibi konular\u0131n ertelenmesine yol a\u00e7ar. \u00d6rne\u011fin, bir veri analizi projesinde, ilk ba\u015fta sadece belirli bir grafi\u011fi olu\u015fturmak i\u00e7in yaz\u0131lan bir betik, zamanla yeni veri kaynaklar\u0131 eklendik\u00e7e, farkl\u0131 analiz y\u00f6ntemleri denendik\u00e7e ve g\u00f6rselle\u015ftirmeler \u00e7e\u015fitlendik\u00e7e i\u00e7inden \u00e7\u0131k\u0131lmaz bir hale gelebilir. Bu noktada, sadece birka\u00e7 g\u00fcn \u00f6nce yazd\u0131\u011f\u0131n\u0131z kodu bile anlamakta zorlanabilirsiniz.<\/p>\n
Temiz kodun \u00f6nemi ise sadece estetik bir kayg\u0131dan ibaret de\u011fildir. Bak\u0131m\u0131 yap\u0131labilir (maintainable) kod, projenin ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc uzat\u0131r. Bir yaz\u0131l\u0131m projesinde yap\u0131lan hatalar\u0131n (bug) tespiti ve d\u00fczeltilmesi, yeni \u00f6zelliklerin eklenmesi veya mevcut \u00f6zelliklerin g\u00fcncellenmesi, kodun ne kadar temiz ve anla\u015f\u0131l\u0131r oldu\u011funa do\u011frudan ba\u011fl\u0131d\u0131r. Da\u011f\u0131n\u0131k bir kod taban\u0131nda, bir hatay\u0131 bulmak saatler hatta g\u00fcnler s\u00fcrebilirken, temiz bir kodda bu s\u00fcre dakikalara inebilir. Dahas\u0131, ekip \u00e7al\u0131\u015fmas\u0131nda temiz kod, i\u015fbirli\u011fini kolayla\u015ft\u0131r\u0131r. Bir geli\u015ftirici, ba\u015fka bir geli\u015ftiricinin yazd\u0131\u011f\u0131 kodu kolayca anlay\u0131p \u00fczerinde \u00e7al\u0131\u015fabilir. Bu da, projelerin daha h\u0131zl\u0131 ilerlemesini sa\u011flar ve genel verimlili\u011fi art\u0131r\u0131r. Python’\u0131n esnekli\u011fi ve okunabilirli\u011fi ile bilinmesi, temiz kod yazma potansiyelini art\u0131r\u0131r. Ancak bu potansiyelin realize edilmesi, bilin\u00e7li bir \u00e7aba gerektirir. Python’\u0131n PEP 8 stil rehberi gibi standartlar\u0131, bu temiz kod k\u00fclt\u00fcr\u00fcn\u00fc te\u015fvik etmek i\u00e7in olu\u015fturulmu\u015ftur. Bu rehber, kodun sadece i\u015flevsel olmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda g\u00f6rsel olarak da tutarl\u0131 ve okunabilir olmas\u0131n\u0131 hedefler.<\/p>\n
Bir projeye ba\u015flarken veya mevcut bir projeyi ele al\u0131rken, ilk ve en kritik ad\u0131m, kodunuzun neyi ba\u015farmay\u0131 ama\u00e7lad\u0131\u011f\u0131n\u0131 ve bu amac\u0131n s\u0131n\u0131rlar\u0131n\u0131n nerede \u00e7izildi\u011fini netle\u015ftirmektir. Bu, \u00f6zellikle karma\u015f\u0131k veya uzun s\u00fcredir \u00fczerinde \u00e7al\u0131\u015f\u0131lan projelerde hayati \u00f6nem ta\u015f\u0131r. E\u011fer bir betik, ilk ba\u015fta k\u00fc\u00e7\u00fck bir problemi \u00e7\u00f6zmek i\u00e7in yaz\u0131lm\u0131\u015f ve zamanla farkl\u0131 \u00f6zellikler eklenerek b\u00fcy\u00fcm\u00fc\u015fse, amac\u0131n\u0131n ilk g\u00fcnk\u00fc haliyle ayn\u0131 kalmad\u0131\u011f\u0131n\u0131 fark etmek \u00f6nemlidir. Bu ad\u0131m, projenin “neden”ini anlamakla ilgilidir. Hangi sorunu \u00e7\u00f6z\u00fcyor? Hangi veriyi i\u015fliyor? Hangi \u00e7\u0131kt\u0131y\u0131 \u00fcretiyor? Bu sorular\u0131n cevaplar\u0131, kodun genel yap\u0131s\u0131n\u0131 ve mod\u00fclerli\u011fini belirlemede bize yol g\u00f6sterecektir.<\/p>\n
\u00d6rne\u011fin, bir web kaz\u0131ma (web scraping) beti\u011fi d\u00fc\u015f\u00fcnelim. Ba\u015flang\u0131\u00e7ta sadece belirli bir siteden \u00fcr\u00fcn fiyatlar\u0131n\u0131 \u00e7ekmek i\u00e7in yaz\u0131lm\u0131\u015f olabilir. Ancak zamanla, farkl\u0131 sitelerden veri \u00e7ekme, veriyi bir veritaban\u0131na kaydetme, fiyat de\u011fi\u015fimlerini takip etme gibi ek \u00f6zellikler eklenebilir. Bu noktada, beti\u011fin amac\u0131n\u0131 yeniden tan\u0131mlamak gerekir. E\u011fer betik hala sadece tek bir siteden fiyat \u00e7ekiyorsa, eklenen di\u011fer \u00f6zellikler “kapsam d\u0131\u015f\u0131” kalm\u0131\u015f demektir ve ayr\u0131 bir betik veya mod\u00fcl olarak ele al\u0131nmal\u0131d\u0131r. E\u011fer ama\u00e7 geni\u015flediyse, bu yeni ama\u00e7 do\u011frultusunda beti\u011fin yap\u0131s\u0131 ve fonksiyonlar\u0131 yeniden d\u00fczenlenmelidir. Bu netle\u015ftirme s\u00fcreci, ayn\u0131 zamanda proje y\u00f6netiminin temelini olu\u015fturur. Bir projenin ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131 anlamak i\u00e7in, ba\u015flang\u0131\u00e7ta belirlenen ama\u00e7lara ne kadar ula\u015f\u0131ld\u0131\u011f\u0131na bak\u0131l\u0131r. Bu nedenle, kodunuzun amac\u0131n\u0131 ve kapsam\u0131n\u0131 belirlemek, sadece kodun kendisini de\u011fil, projenin genel ba\u015far\u0131s\u0131n\u0131 da etkileyen stratejik bir ad\u0131md\u0131r. Bu a\u015famada, bir proje plan\u0131 veya en az\u0131ndan bir “gereksinimler listesi” olu\u015fturmak, ilerleyen ad\u0131mlarda rehberlik edecektir.<\/p>\n
Da\u011f\u0131n\u0131k kodun en belirgin \u00f6zelliklerinden biri, genellikle tek bir devasa fonksiyonda veya birbirine s\u0131k\u0131 s\u0131k\u0131ya ba\u011fl\u0131 kod bloklar\u0131nda toplanm\u0131\u015f olmas\u0131d\u0131r. Ba\u015far\u0131l\u0131 bir betik, iyi tan\u0131mlanm\u0131\u015f, tek bir g\u00f6revi yerine getiren ve yeniden kullan\u0131labilir fonksiyonlardan olu\u015fur. Bu ilkeye “fonksiyonel ayr\u0131\u015ft\u0131rma” (functional decomposition) denir. Her fonksiyonun tek bir sorumlulu\u011fu olmal\u0131d\u0131r. Bu, hem kodun okunabilirli\u011fini art\u0131r\u0131r hem de hata ay\u0131klama (debugging) s\u00fcrecini kolayla\u015ft\u0131r\u0131r. E\u011fer bir fonksiyonun birden fazla g\u00f6revi varsa, bu fonksiyonu daha k\u00fc\u00e7\u00fck, daha spesifik g\u00f6revlere b\u00f6lebiliriz.<\/p>\n
\u00d6rne\u011fin, bir kullan\u0131c\u0131dan veri alan, bu veriyi i\u015fleyen ve ard\u0131ndan bir rapor olu\u015fturan bir betik d\u00fc\u015f\u00fcnelim. Bu betik tek bir b\u00fcy\u00fck fonksiyonda yaz\u0131lm\u0131\u015f olsayd\u0131, onu anlamak ve de\u011fi\u015ftirmek zor olurdu. Ancak, bu beti\u011fi \u00fc\u00e7 ayr\u0131 fonksiyona b\u00f6lebiliriz: Vaka Analizi: Bir e-ticaret platformu i\u00e7in stok takibi yapan bir betik d\u00fc\u015f\u00fcnelim. Ba\u015flang\u0131\u00e7ta t\u00fcm i\u015flemler (veri taban\u0131ndan stoklar\u0131 \u00e7ekme, sipari\u015fleri i\u015fleme, stoklar\u0131 g\u00fcncelleme) tek bir betikte yap\u0131l\u0131yordu. Bu durum, yeni bir \u00fcr\u00fcn t\u00fcr\u00fc eklendi\u011finde veya stok g\u00fcncelleme mant\u0131\u011f\u0131nda bir de\u011fi\u015fiklik gerekti\u011finde b\u00fcy\u00fck zorluklar yarat\u0131yordu. Betik, yakla\u015f\u0131k 1000 sat\u0131ra ula\u015fm\u0131\u015ft\u0131 ve her de\u011fi\u015fiklik, ba\u015fka bir yeri bozma riski ta\u015f\u0131yordu. Fonksiyonel ayr\u0131\u015ft\u0131rma ile betik \u015fu mod\u00fcllere b\u00f6l\u00fcnd\u00fc:<\/p>\n Bu ayr\u0131\u015ft\u0131rma sayesinde, her mod\u00fcl kendi i\u00e7inde daha anla\u015f\u0131l\u0131r hale geldi. Bir geli\u015ftirici, sadece stok g\u00fcncelleme mant\u0131\u011f\u0131nda bir de\u011fi\u015fiklik yapmak istedi\u011finde, sadece Kodun okunabilirli\u011fini en \u00e7ok etkileyen fakt\u00f6rlerden biri, kullan\u0131lan de\u011fi\u015fken ve fonksiyon isimleridir. K\u0131salt\u0131lm\u0131\u015f, anlams\u0131z veya birden fazla anlama gelebilecek isimler, kodu okuyan ki\u015fiyi (bu ki\u015fi siz bile olsan\u0131z) ciddi anlamda zorlar. Python’da de\u011fi\u015fken ve fonksiyon isimleri i\u00e7in belirli kurallar vard\u0131r, ancak en \u00f6nemlisi, bu isimlerin neyi temsil etti\u011fini a\u00e7\u0131k\u00e7a belirtmesidir. PEP 8 stil rehberi, de\u011fi\u015fkenler i\u00e7in k\u00fc\u00e7\u00fck harf ve alt \u00e7izgi (snake_case) kullan\u0131m\u0131n\u0131 \u00f6nerir. Fonksiyonlar i\u00e7in de ayn\u0131 kural ge\u00e7erlidir. S\u0131n\u0131f isimleri ise genellikle CamelCase ile ba\u015flar.<\/p>\n \u00d6rne\u011fin, bir listedeki say\u0131lar\u0131n toplam\u0131n\u0131 bulan bir fonksiyon yaz\u0131yorsunuz. E\u011fer bu fonksiyonun ad\u0131 Vaka Analizi: Bir finansal analiz beti\u011finde, de\u011fi\u015fken isimleri ba\u015flang\u0131\u00e7ta olduk\u00e7a k\u0131sayd\u0131. \u00d6rne\u011fin, Bu basit de\u011fi\u015fiklik bile, beti\u011fin okunabilirli\u011fini ve anla\u015f\u0131l\u0131rl\u0131\u011f\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rd\u0131. Art\u0131k geli\u015ftiriciler, kodun farkl\u0131 b\u00f6l\u00fcmlerini okurken ne ile kar\u015f\u0131la\u015ft\u0131klar\u0131n\u0131 kolayca anlayabiliyor ve de\u011fi\u015fiklikleri daha g\u00fcvenli bir \u015fekilde yapabiliyorlar.<\/p>\n Kodun kendisi bir hikaye anlat\u0131r, ancak yorum sat\u0131rlar\u0131 ve dok\u00fcmantasyon bu hikayeyi daha anla\u015f\u0131l\u0131r hale getiren anlat\u0131c\u0131d\u0131r. Her ne kadar anla\u015f\u0131l\u0131r de\u011fi\u015fken ve fonksiyon isimleri kullanmak \u00f6nemli olsa da, karma\u015f\u0131k mant\u0131klar, \u00f6zel algoritmalar veya belirli bir amaca hizmet eden ince ayarlar i\u00e7in yorum sat\u0131rlar\u0131 vazge\u00e7ilmezdir. Python’da yorum sat\u0131rlar\u0131, Bir fonksiyonun veya kod blo\u011funun neden belirli bir \u015fekilde yaz\u0131ld\u0131\u011f\u0131n\u0131 a\u00e7\u0131klamak, gelecekteki geli\u015ftiriciler (veya kendiniz) i\u00e7in b\u00fcy\u00fck bir kolayl\u0131k sa\u011flar. \u00d6rne\u011fin, bir matematiksel form\u00fcl\u00fcn neden kullan\u0131ld\u0131\u011f\u0131n\u0131, bir veri temizleme ad\u0131m\u0131n\u0131n hangi \u00f6zel durumu ele ald\u0131\u011f\u0131n\u0131 yorum sat\u0131rlar\u0131yla a\u00e7\u0131klayabilirsiniz. Dok\u00fcmantasyon stringleri (docstring’ler) ise, kodunuzu kullanacak ki\u015filer i\u00e7in bir k\u0131lavuz g\u00f6revi g\u00f6r\u00fcr. Otomatik dok\u00fcmantasyon ara\u00e7lar\u0131 (\u00f6rne\u011fin Sphinx), bu docstring’leri okuyarak proje i\u00e7in kapsaml\u0131 bir dok\u00fcmantasyon olu\u015fturabilir. Bu, \u00f6zellikle b\u00fcy\u00fck projelerde veya k\u00fct\u00fcphane geli\u015ftirmede standart bir uygulamad\u0131r. Yetersiz yorumlama, kodun “kara kutu” gibi alg\u0131lanmas\u0131na neden olur. Bir geli\u015ftirici, bir fonksiyonu sadece i\u00e7eri\u011fini okuyarak anlamaya \u00e7al\u0131\u015fmak yerine, bir docstring’e bakarak h\u0131zla ne i\u015fe yarad\u0131\u011f\u0131n\u0131 kavrayabilir. Bu, zaman kazand\u0131r\u0131r ve yanl\u0131\u015f anlamalar\u0131 \u00f6nler. Python’\u0131n “Zen of Python” felsefesinde de belirtildi\u011fi gibi, “Okunabilirlik \u00f6nemlidir.” Yorumlar ve dok\u00fcmantasyon, okunabilirli\u011fi art\u0131ran temel unsurlard\u0131r.<\/p>\n Kod \u00d6rne\u011fi:<\/p>\n Her ne kadar kodumuz m\u00fckemmel olsa da, d\u0131\u015f etkenler veya beklenmedik kullan\u0131c\u0131 girdileri nedeniyle hatalar olu\u015fabilir. Bu hatalar\u0131n program\u0131n \u00e7\u00f6kmesine neden olmas\u0131 yerine, kontroll\u00fc bir \u015fekilde y\u00f6netilmesi \"hata y\u00f6netimi\" (error handling) olarak adland\u0131r\u0131l\u0131r. Python'da bu genellikle \u00d6rne\u011fin, bir kullan\u0131c\u0131dan say\u0131sal bir de\u011fer girmesini bekleyen bir kodunuz var. E\u011fer kullan\u0131c\u0131 metin girerse, program bir Vaka Analizi: Bir veri y\u00fckleme beti\u011fi, b\u00fcy\u00fck bir CSV dosyas\u0131n\u0131 okuyordu. Dosya, bazen bozuk sat\u0131rlar veya eksik s\u00fctunlar i\u00e7eriyordu. Ba\u015flang\u0131\u00e7ta, bu t\u00fcr sorunlarda betik tamamen \u00e7\u00f6k\u00fcyordu. Bu durum, \u00f6nemli verilerin i\u015flenememesine ve manuel m\u00fcdahale gerektirmesine neden oluyordu. Hata y\u00f6netimi eklenmesiyle, betik art\u0131k \u015fu \u015fekilde \u00e7al\u0131\u015f\u0131yor:<\/p>\n Bu iyile\u015ftirme sayesinde, betik art\u0131k bozuk verilerle kar\u015f\u0131la\u015ft\u0131\u011f\u0131nda bile \u00e7al\u0131\u015fmaya devam edebiliyor, hatal\u0131 verileri atlay\u0131p loglayarak daha sonra incelenmesini sa\u011fl\u0131yor ve genel veri i\u015fleme s\u00fcrecinin kesintisiz ilerlemesini sa\u011fl\u0131yor.<\/p>\n Daha \u00f6nce de bahsetti\u011fimiz gibi, Python'\u0131n PEP 8 stil rehberi, kodun okunabilirli\u011fi ve tutarl\u0131l\u0131\u011f\u0131 i\u00e7in \u00f6nemli bir k\u0131lavuzdur. Bu rehber, girintileme (indentation), sat\u0131r uzunlu\u011fu, bo\u015fluk kullan\u0131m\u0131, isimlendirme kurallar\u0131 gibi bir\u00e7ok konuda standartlar belirler. Kendi kodunuzda ve ekibinizle \u00e7al\u0131\u015f\u0131rken PEP 8'e uymak, kodun daha profesyonel g\u00f6r\u00fcnmesini sa\u011flar ve farkl\u0131 geli\u015ftiricilerin yazd\u0131\u011f\u0131 kodlar\u0131n bir arada uyumlu bir \u015fekilde \u00e7al\u0131\u015fmas\u0131na yard\u0131mc\u0131 olur.<\/p>\n PEP 8'in temel \u00f6nerilerinden baz\u0131lar\u0131 \u015funlard\u0131r:<\/p>\n Bu kurallara uymak, ba\u015flang\u0131\u00e7ta biraz daha fazla \u00e7aba gerektirse de, uzun vadede kodun bak\u0131m\u0131n\u0131 ve anla\u015f\u0131l\u0131rl\u0131\u011f\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131r. G\u00fcn\u00fcm\u00fczde bir\u00e7ok kod edit\u00f6r\u00fc ve IDE (Entegre Geli\u015ftirme Ortam\u0131), PEP 8 uyumlulu\u011funu kontrol eden ve otomatik olarak d\u00fczelten \u00f6zelliklere sahiptir. \u00d6rne\u011fin, VS Code, PyCharm gibi edit\u00f6rlerde linting (kod analizi) ara\u00e7lar\u0131 bulunur. Bu ara\u00e7lar, kodunuzu yazarken PEP 8 ihlallerini otomatik olarak i\u015faretler ve hatta bazen d\u00fczeltme \u00f6nerileri sunar. Otomatik kod bi\u00e7imlendiriciler (formatters) de mevcuttur. Black, yapay zeka destekli bir kod bi\u00e7imlendirici olarak, sizin i\u00e7in kodunuzu otomatik olarak PEP 8'e uygun hale getirebilir. Bu t\u00fcr ara\u00e7lar\u0131n kullan\u0131m\u0131, manuel olarak her detay\u0131 kontrol etme y\u00fck\u00fcn\u00fc ortadan kald\u0131r\u0131r ve tutarl\u0131l\u0131\u011f\u0131 garanti eder.<\/p>\n Vaka Analizi: Bir ekipte \u00e7al\u0131\u015f\u0131rken, farkl\u0131 geli\u015ftiriciler kendi stil tercihleri nedeniyle kodda tutars\u0131zl\u0131klar olu\u015fturuyordu. Baz\u0131lar\u0131 2 bo\u015fluk girinti kullan\u0131rken, baz\u0131lar\u0131 4 bo\u015fluk kullan\u0131yordu. Sat\u0131r uzunluklar\u0131 de\u011fi\u015fkenlik g\u00f6steriyordu ve operat\u00f6rlerin etraf\u0131ndaki bo\u015fluklar rastgeleydi. Bu durum, kod incelemeleri (code reviews) s\u0131ras\u0131nda gereksiz tart\u0131\u015fmalara yol a\u00e7\u0131yordu ve kodun genel g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc bozuyordu. \u00c7\u00f6z\u00fcm olarak, ekibe Black kod bi\u00e7imlendirici entegre edildi. Her geli\u015ftirici, kodunu kaydetti\u011finde veya bir pull request (kod de\u011fi\u015fikli\u011fi talebi) olu\u015fturmadan \u00f6nce Black ile bi\u00e7imlendirme i\u015flemini otomatik olarak yap\u0131yordu. Bu basit ad\u0131m, kodun g\u00f6r\u00fcn\u00fcm\u00fcnde b\u00fcy\u00fck bir tutarl\u0131l\u0131k sa\u011flad\u0131 ve kod incelemelerinin daha verimli hale gelmesine yard\u0131mc\u0131 oldu.<\/p>\n Zamanla, projelerimizde kullanmad\u0131\u011f\u0131m\u0131z, denedi\u011fimiz ama sonra vazge\u00e7ti\u011fimiz veya art\u0131k ge\u00e7erli olmayan kod par\u00e7ac\u0131klar\u0131 birikir. Bu \"\u00f6l\u00fc kod\" (dead code), projenin boyutunu art\u0131r\u0131r ve kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131na yol a\u00e7abilir. Bu nedenle, d\u00fczenli olarak kodunuzu g\u00f6zden ge\u00e7irerek gereksiz k\u0131s\u0131mlar\u0131 temizlemek \u00f6nemlidir. Bu, sadece \u00e7al\u0131\u015fan kodu de\u011fil, ayn\u0131 zamanda yorumlanm\u0131\u015f ama asla kullan\u0131lmam\u0131\u015f kod bloklar\u0131n\u0131 da kapsar.<\/p>\n Refactoring (yeniden d\u00fczenleme), kodun d\u0131\u015fsal davran\u0131\u015f\u0131n\u0131 de\u011fi\u015ftirmeden i\u00e7 yap\u0131s\u0131n\u0131 iyile\u015ftirme s\u00fcrecidir. Bu, daha \u00f6nce bahsetti\u011fimiz fonksiyonel ayr\u0131\u015ft\u0131rma, anla\u015f\u0131l\u0131r isimler kullanma ve kodu daha mod\u00fcler hale getirme gibi ad\u0131mlar\u0131 kapsar. Refactoring'in amac\u0131, kodun daha okunabilir, daha verimli ve daha bak\u0131m\u0131 yap\u0131labilir olmas\u0131n\u0131 sa\u011flamakt\u0131r. \u00d6rne\u011fin, tekrar eden bir kod blo\u011funu bir fonksiyona d\u00f6n\u00fc\u015ft\u00fcrmek bir refactoring i\u015flemidir. Veya \u00e7ok uzun bir fonksiyonu, daha k\u00fc\u00e7\u00fck ve odaklanm\u0131\u015f fonksiyonlara b\u00f6lmek de bir refactoring \u00f6rne\u011fidir. Refactoring yaparken dikkat edilmesi gereken en \u00f6nemli nokta, kodun mevcut i\u015flevselli\u011fini bozmamakt\u0131r. Bu nedenle, refactoring \u00f6ncesinde ve sonras\u0131nda kapsaml\u0131 testler yapmak \u00e7ok \u00f6nemlidir. Otomatik testler (unit tests, integration tests), refactoring s\u00fcrecini \u00e7ok daha g\u00fcvenli hale getirir. E\u011fer bir refactoring i\u015flemi sonras\u0131nda testler ba\u015far\u0131s\u0131z olursa, bu, bir hata yap\u0131ld\u0131\u011f\u0131 anlam\u0131na gelir ve de\u011fi\u015fiklik geri al\u0131nabilir. Bu s\u00fcre\u00e7, kodun s\u00fcrekli olarak iyile\u015ftirilmesini sa\u011flar ve zamanla olu\u015fabilecek karma\u015fay\u0131 \u00f6nler.<\/p>\n Vaka Analizi: Bir web uygulamas\u0131n\u0131n arka u\u00e7 (backend) servisinde, ba\u015flang\u0131\u00e7ta h\u0131zl\u0131ca geli\u015ftirilen ve daha sonra hi\u00e7 kullan\u0131lmayan bir dizi API u\u00e7 noktas\u0131 (endpoint) vard\u0131. Bu u\u00e7 noktalar, kod taban\u0131nda yer kapl\u0131yor ve gereksiz yere kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131na neden oluyordu. Ayr\u0131ca, baz\u0131 i\u015f mant\u0131klar\u0131 birden fazla yerde tekrar ediliyordu. Yap\u0131lan refactoring \u00e7al\u0131\u015fmas\u0131nda:<\/p>\n Bu refactoring, kod taban\u0131n\u0131n boyutunu %20 oran\u0131nda azaltt\u0131, okunabilirli\u011fi art\u0131rd\u0131 ve yeni \u00f6zelliklerin eklenmesini kolayla\u015ft\u0131rd\u0131.<\/p>\n Da\u011f\u0131n\u0131k bir Python beti\u011fini teslim etmenin en \u00f6nemli ad\u0131mlar\u0131ndan biri, onu bir versiyon kontrol sistemi (version control system - VCS) ile y\u00f6netmektir. Git, g\u00fcn\u00fcm\u00fczde en pop\u00fcler ve yayg\u0131n kullan\u0131lan versiyon kontrol sistemidir. Git, kodunuzdaki t\u00fcm de\u011fi\u015fiklikleri izlemenizi, farkl\u0131 s\u00fcr\u00fcmleri kaydetmenizi, \u00f6nceki s\u00fcr\u00fcmlere geri d\u00f6nmenizi ve ekip \u00fcyeleriyle i\u015fbirli\u011fi yapman\u0131z\u0131 sa\u011flar. Bir proje ne kadar k\u00fc\u00e7\u00fck veya ne kadar da\u011f\u0131n\u0131k olursa olsun, Git kullanmak, kodunuzun g\u00fcvenli\u011fini ve y\u00f6netilebilirli\u011fini art\u0131r\u0131r.<\/p>\n Git'in temel komutlar\u0131 ( Vaka Analizi: Bir veri bilimci, bir makine \u00f6\u011frenmesi modelini e\u011fitmek i\u00e7in kapsaml\u0131 bir Python beti\u011fi yazd\u0131. Ancak, farkl\u0131 hiperparametre denemeleri, veri \u00f6n i\u015fleme y\u00f6ntemleri ve model mimarileri sonucunda betik olduk\u00e7a karma\u015f\u0131k bir hale geldi. Veri bilimci, hangi parametrenin en iyi sonucu verdi\u011fini veya hangi denemenin ba\u015far\u0131s\u0131z oldu\u011funu takip etmekte zorlanmaya ba\u015flad\u0131. Betik, yerel makinesinde rastgele kaydedilmi\u015f dosya adlar\u0131yla (\u00f6rne\u011fin, Bu yakla\u015f\u0131m, projenin tekrarlanabilirli\u011fini sa\u011flad\u0131 ve gelecekteki geli\u015ftirmeler i\u00e7in sa\u011flam bir temel olu\u015fturdu.<\/p>\n Temiz kodun en \u00f6nemli g\u00f6stergelerinden biri, otomatik testlerin (automated tests) varl\u0131\u011f\u0131d\u0131r. Unit testler (birim testleri), Integration testler (entegrasyon testleri) ve hatta End-to-end testler (u\u00e7tan uca testler), kodunuzun beklendi\u011fi gibi \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 do\u011frulamak i\u00e7in kullan\u0131l\u0131r. Python'da Da\u011f\u0131n\u0131k bir beti\u011fi iyile\u015ftirirken, test yazmak, yapt\u0131\u011f\u0131n\u0131z de\u011fi\u015fikliklerin mevcut i\u015flevselli\u011fi bozmad\u0131\u011f\u0131n\u0131 garanti etmenin en g\u00fcvenilir yoludur. E\u011fer beti\u011finizde \u00f6nemli fonksiyonlar varsa, bu fonksiyonlar i\u00e7in unit testler yazarak ba\u015flayabilirsiniz. \u00d6rne\u011fin, bir hesaplama yapan fonksiyonunuz varsa, farkl\u0131 girdilerle bu fonksiyonu \u00e7a\u011f\u0131r\u0131p beklenen \u00e7\u0131kt\u0131y\u0131 m\u0131 verdi\u011fini kontrol eden bir test yazabilirsiniz. Vaka Analizi: Bir finansal raporlama beti\u011finde, farkl\u0131 para birimlerini d\u00f6n\u00fc\u015ft\u00fcren ve vergileri hesaplayan bir mod\u00fcl bulunuyordu. Bu mod\u00fcl, karma\u015f\u0131k kurallara ve g\u00fcncel d\u00f6viz kurlar\u0131na dayan\u0131yordu. Mod\u00fcl\u00fcn ilk hali, yeterince test edilmemi\u015fti ve bazen yanl\u0131\u015f hesaplamalar yapabiliyordu. Bir geli\u015ftirici, bu mod\u00fcl i\u00e7in Son ad\u0131m, yazd\u0131\u011f\u0131n\u0131z ve iyile\u015ftirdi\u011finiz kodu ba\u015fkalar\u0131na inceletmektir. Kod incelemesi (code review), projenizin kalitesini art\u0131rman\u0131n, hatalar\u0131 erken tespit etmenin ve bilgi payla\u015f\u0131m\u0131n\u0131 te\u015fvik etmenin en etkili yollar\u0131ndan biridir. Ekip arkada\u015flar\u0131n\u0131z veya g\u00fcvendi\u011finiz bir ba\u015fka geli\u015ftirici, kodunuzu farkl\u0131 bir g\u00f6zle inceleyerek potansiyel sorunlar\u0131, iyile\u015ftirme alanlar\u0131n\u0131 veya daha iyi yakla\u015f\u0131mlar\u0131 fark edebilir. Bu, \u00f6zellikle da\u011f\u0131n\u0131k bir beti\u011fi temizlerken \u00e7ok de\u011ferlidir, \u00e7\u00fcnk\u00fc ba\u015fka bir ki\u015fi sizin g\u00f6remedi\u011finiz mant\u0131k hatalar\u0131n\u0131 veya okunabilirlik sorunlar\u0131n\u0131 fark edebilir.<\/p>\n Kod incelemesi sadece hata bulmakla ilgili de\u011fildir; ayn\u0131 zamanda \u00f6\u011frenme ve geli\u015fim i\u00e7in de harika bir f\u0131rsatt\u0131r. Ba\u015fkalar\u0131n\u0131n kodunuz hakk\u0131nda yapt\u0131\u011f\u0131 geri bildirimler, sizin daha iyi bir geli\u015ftirici olman\u0131za yard\u0131mc\u0131 olur. Python toplulu\u011funda \"Pythonic\" (Python'a \u00f6zg\u00fc, idiomatik) olarak adland\u0131r\u0131lan yakla\u015f\u0131mlar\u0131 \u00f6\u011frenmek i\u00e7in kod incelemeleri \u00e7ok faydal\u0131d\u0131r. Kod incelemeleri genellikle Git platformlar\u0131 \u00fczerinden Pull Request (PR) mekanizmas\u0131 ile yap\u0131l\u0131r. Bir geli\u015ftirici, yapt\u0131\u011f\u0131 de\u011fi\u015fiklikleri bir PR ile sunar ve di\u011fer ekip \u00fcyeleri bu PR'\u0131 inceleyerek yorumlar yapar. Bu yorumlar do\u011frultusunda geli\u015ftirici kodunda gerekli d\u00fczeltmeleri yapar ve PR onayland\u0131ktan sonra kod ana dala birle\u015ftirilir. Kendi kodunuzu incelerken de benzer bir s\u00fcreci uygulayabilirsiniz. Birka\u00e7 g\u00fcn sonra kodunuza tekrar bakt\u0131\u011f\u0131n\u0131zda, \"Ben bunu neden b\u00f6yle yapm\u0131\u015f\u0131m?\" diyece\u011finiz durumlar olabilir. Bu nedenle, m\u00fcmk\u00fcnse kodunuzu bir s\u00fcre bekletip sonra tekrar incelemek de faydal\u0131d\u0131r. Bu, bir nevi kendi kendine kod incelemesi yapmakt\u0131r.<\/p>\n Vaka Analizi: Bir proje y\u00f6neticisi, bir geli\u015ftiricinin teslim etti\u011fi karma\u015f\u0131k bir analiz beti\u011fini incelemek \u00fczereydi. Betik, bir\u00e7ok farkl\u0131 veri setini i\u015fliyor ve karma\u015f\u0131k istatistiksel analizler yap\u0131yordu. Geli\u015ftirici, beti\u011fi PEP 8'e uygun hale getirmi\u015f, fonksiyonlara ay\u0131rm\u0131\u015f ve Git'te versiyonlam\u0131\u015ft\u0131. Ancak, proje y\u00f6neticisi kod incelemesi s\u0131ras\u0131nda, beti\u011fin baz\u0131 b\u00f6l\u00fcmlerinin hala gereksiz yere karma\u015f\u0131k oldu\u011funu ve daha basit bir matematiksel yakla\u015f\u0131mla ayn\u0131 sonucun elde edilebilece\u011fini fark etti. Ayr\u0131ca, betikte kullan\u0131lan baz\u0131 de\u011fi\u015fken isimleri hala tam olarak a\u00e7\u0131klay\u0131c\u0131 de\u011fildi. Geli\u015ftirici, proje y\u00f6neticisinin geri bildirimleri do\u011frultusunda kodunda gerekli g\u00fcncellemeleri yapt\u0131. Bu inceleme sayesinde, hem kodun daha verimli hale gelmesi sa\u011fland\u0131 hem de geli\u015ftirici, daha iyi matematiksel yakla\u015f\u0131mlar konusunda bilgi sahibi oldu.<\/p>\n Da\u011f\u0131n\u0131k bir Python beti\u011fini teslim edilebilir hale getirmek, sadece birka\u00e7 ad\u0131m\u0131 takip etmekle biten bir s\u00fcre\u00e7 de\u011fildir. Bu, s\u00fcrekli \u00f6\u011frenme ve iyile\u015ftirme gerektiren bir yolculuktur. Yukar\u0131da payla\u015ft\u0131\u011f\u0131m 10 ad\u0131ml\u0131k kontrol listesi, bu yolculukta size rehberlik edecek temel prensipleri i\u00e7ermektedir. Amac\u0131 netle\u015ftirmekten, kodu mod\u00fcler hale getirmeye, anla\u015f\u0131l\u0131r isimler kullanmaktan, yorumlarla desteklemeye, hatalar\u0131 y\u00f6netmekten, temiz kod standartlar\u0131na uymaya, gereksiz kodlar\u0131 temizlemekten, versiyon kontrol sistemlerinden yararlanmaya, testler yazmaktan ve son olarak kod incelemesi yapmaya kadar her ad\u0131m, projenizin kalitesini art\u0131racakt\u0131r. Unutmay\u0131n, temiz kod sadece sizin i\u00e7in de\u011fil, gelecekte sizinle veya ba\u015fkalar\u0131yla birlikte \u00e7al\u0131\u015facak herkes i\u00e7in bir yat\u0131r\u0131md\u0131r. Bu prensipleri benimseyerek, daha s\u00fcrd\u00fcr\u00fclebilir, daha bak\u0131m\u0131 yap\u0131labilir ve daha ba\u015far\u0131l\u0131 Python projeleri geli\u015ftirebilirsiniz.<\/p>\n C: Kodunuzun \u00e7al\u0131\u015f\u0131yor olmas\u0131, onun \"iyi\" oldu\u011fu anlam\u0131na gelmez. Temiz kod, gelecekteki de\u011fi\u015fiklikleri, hata ay\u0131klamay\u0131 ve yeni \u00f6zellikler eklemeyi kolayla\u015ft\u0131r\u0131r. Bu, uzun vadede zaman ve maliyet tasarrufu sa\u011flar. Ayr\u0131ca, ba\u015fkalar\u0131yla i\u015fbirli\u011fi yaparken veya projeyi ba\u015fkas\u0131na devretti\u011finizde anla\u015f\u0131l\u0131rl\u0131k kritik \u00f6neme sahiptir.<\/p>\n<\/li>\n C: Python i\u00e7in pop\u00fcler ara\u00e7lar aras\u0131nda PEP 8 uyumlulu\u011funu kontrol eden linting ara\u00e7lar\u0131 (\u00f6rne\u011fin, Flake8, Pylint), otomatik kod bi\u00e7imlendiriciler (\u00f6rne\u011fin, Black, autopep8) ve test framework'leri (\u00f6rne\u011fin, pytest, unittest) bulunur. Ayr\u0131ca, Git gibi versiyon kontrol sistemleri de kod y\u00f6netimini kolayla\u015ft\u0131r\u0131r.<\/p>\n<\/li>\n C: Yorum sat\u0131rlar\u0131n\u0131n amac\u0131, kodun \"neden\"ini a\u00e7\u0131klamak, karma\u015f\u0131k mant\u0131klar\u0131 ayd\u0131nlatmak ve belirsizlikleri gidermektir. Kodun ne yapt\u0131\u011f\u0131n\u0131 zaten a\u00e7\u0131k\u00e7a anlatan sat\u0131rlar i\u00e7in yorum yazmak gereksizdir. \"K\u00f6t\u00fc kod, iyi yorumla kurtar\u0131lamaz.\" prensibini unutmay\u0131n. \u00d6nce kodu anla\u015f\u0131l\u0131r hale getirmeye \u00e7al\u0131\u015f\u0131n, sonra gerekti\u011finde yorum ekleyin.<\/p>\n<\/li>\n C: Refactoring, s\u00fcrekli bir s\u00fcre\u00e7 olmal\u0131d\u0131r. Yeni bir \u00f6zellik eklerken, bir hata d\u00fczeltirken veya sadece kodu g\u00f6zden ge\u00e7irirken bile refactoring f\u0131rsatlar\u0131 ortaya \u00e7\u0131kabilir. En \u00f6nemlisi, refactoring yaparken kodun mevcut i\u015flevselli\u011fini korudu\u011funuzdan emin olmak i\u00e7in testler kullanmakt\u0131r.<\/p>\n<\/li>\n C: Ekip i\u00e7inde net kodlama standartlar\u0131 belirleyin (\u00f6rne\u011fin, PEP 8'e uyum), bu standartlar\u0131 belgeleyin ve t\u00fcm ekip \u00fcyelerinin bu standartlara uymas\u0131n\u0131 sa\u011flay\u0131n. Otomatik ara\u00e7lar (linters, formatters) ve kod incelemeleri (code reviews), bu standartlar\u0131n uygulanmas\u0131na yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n<\/li>\n<\/ul>\n #Python #Yaz\u0131l\u0131mGeli\u015ftirme #TemizKod #Kodlama #Programlama<\/p>\nveri_al()<\/code>, veriyi_islem()<\/code> ve rapor_olustur()<\/code>. Her fonksiyonun kendi g\u00f6revi netle\u015fir. veri_al()<\/code> fonksiyonu sadece kullan\u0131c\u0131dan giri\u015fleri toplar, veriyi_islem()<\/code> fonksiyonu bu veriyi al\u0131r ve hesaplamalar\u0131 yapar, rapor_olustur()<\/code> fonksiyonu ise i\u015flenmi\u015f veriyi kullanarak nihai raporu \u00fcretir. Bu mod\u00fcler yap\u0131, kodun yeniden kullan\u0131labilirli\u011fini de art\u0131r\u0131r. Belki ileride, farkl\u0131 bir rapor t\u00fcr\u00fc olu\u015fturmak istersiniz; bu durumda sadece rapor_olustur()<\/code> fonksiyonunu de\u011fi\u015ftirmeniz yeterli olabilir. Bu yakla\u015f\u0131m, Python’\u0131n “DRY” (Don’t Repeat Yourself – Kendini Tekrar Etme) prensibiyle de uyumludur. Fonksiyonlar, tekrar eden kod bloklar\u0131n\u0131 ortadan kald\u0131rarak kodun daha k\u0131sa ve y\u00f6netilebilir olmas\u0131n\u0131 sa\u011flar. Mod\u00fclerlik, ayn\u0131 zamanda test edilebilirli\u011fi (testability) de art\u0131r\u0131r. Her bir fonksiyonu ayr\u0131 ayr\u0131 test etmek, t\u00fcm beti\u011fi ba\u015ftan sona \u00e7al\u0131\u015ft\u0131rmaktan \u00e7ok daha verimlidir.<\/p>\n\n
veritabani_baglantisi.py<\/code>: Veritaban\u0131 ba\u011flant\u0131s\u0131n\u0131 y\u00f6neten fonksiyonlar.<\/li>\nstok_cek.py<\/code>: Stoklar\u0131 veritaban\u0131ndan \u00e7eken fonksiyonlar.<\/li>\nsiparis_islem.py<\/code>: Gelen sipari\u015fleri i\u015fleyen ve stoklar\u0131 d\u00fc\u015f\u00fcren fonksiyonlar.<\/li>\nstok_guncelle.py<\/code>: Stoklar\u0131 veritaban\u0131nda g\u00fcncelleyen fonksiyonlar.<\/li>\nraporlama.py<\/code>: G\u00fcnl\u00fck stok raporlar\u0131n\u0131 olu\u015fturan fonksiyonlar.<\/li>\n<\/ul>\nstok_guncelle.py<\/code> dosyas\u0131na odaklanabiliyor. Bu da hata yapma olas\u0131l\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcyor ve geli\u015ftirme s\u00fcresini k\u0131salt\u0131yor.<\/p>\n3. Ad\u0131m: Anla\u015f\u0131l\u0131r De\u011fi\u015fken ve Fonksiyon \u0130simleri Kullan\u0131n<\/h2>\n
hesapla()<\/code> ve kullan\u0131lan liste de\u011fi\u015fkeninin ad\u0131 l<\/code> olursa, bu kod par\u00e7ac\u0131\u011f\u0131n\u0131 g\u00f6ren bir ki\u015fi, bu fonksiyonun tam olarak ne yapt\u0131\u011f\u0131n\u0131 ve l<\/code>‘nin neyi temsil etti\u011fini anlamakta zorlanabilir. Bunun yerine, fonksiyonun ad\u0131n\u0131 toplam_hesapla()<\/code> ve liste de\u011fi\u015fkeninin ad\u0131n\u0131 sayilar_listesi<\/code> olarak belirlemek, kodun amac\u0131n\u0131 an\u0131nda ortaya koyar. Benzer \u015fekilde, bir kullan\u0131c\u0131n\u0131n ya\u015f\u0131n\u0131 saklayan bir de\u011fi\u015fkenin ad\u0131 y<\/code> yerine kullanici_yasi<\/code> olmal\u0131d\u0131r. Bu, \u00f6zellikle b\u00fcy\u00fck projelerde veya uzun s\u00fcreli projelerde kodun bak\u0131m\u0131n\u0131 inan\u0131lmaz derecede kolayla\u015ft\u0131r\u0131r. Bir de\u011fi\u015fkenin veya fonksiyonun ne i\u015fe yarad\u0131\u011f\u0131n\u0131 anlamak i\u00e7in onlarca sat\u0131r kod geriye gitmek yerine, sadece ismine bakarak fikir edinmek m\u00fcmk\u00fcnd\u00fcr. Bu, “anlamsal zenginlik” (semantic richness) ilkesinin bir par\u00e7as\u0131d\u0131r; yani kullan\u0131lan isimler, kodun anlam\u0131n\u0131 zenginle\u015ftirmelidir.<\/p>\na<\/code>, b<\/code>, c<\/code> gibi isimler kullan\u0131l\u0131yordu. Bu durum, betik b\u00fcy\u00fcd\u00fck\u00e7e ve farkl\u0131 analiz y\u00f6ntemleri eklendik\u00e7e, hangi de\u011fi\u015fkenin hangi veriyi temsil etti\u011fini anlamay\u0131 neredeyse imkans\u0131z hale getirmi\u015fti. Beti\u011fin bak\u0131m\u0131 i\u00e7in atanm\u0131\u015f olan yeni geli\u015ftirici, ilk hafta boyunca bu de\u011fi\u015fkenlerin anlamlar\u0131n\u0131 \u00e7\u00f6zmeye \u00e7al\u0131\u015ft\u0131. Sonras\u0131nda yap\u0131lan iyile\u015ftirmede, de\u011fi\u015fken isimleri \u015fu \u015fekilde de\u011fi\u015ftirildi:<\/p>\n\n
a<\/code> -> gelir_tutari<\/code><\/li>\nb<\/code> -> gider_tutari<\/code><\/li>\nc<\/code> -> kar_zarar_durumu<\/code><\/li>\nk_f<\/code> -> karsilastirma_faktoru<\/code><\/li>\n<\/ul>\n4. Ad\u0131m: Yorum Sat\u0131rlar\u0131 ve Dok\u00fcmantasyon: Kodunuzu Konu\u015fturun<\/h2>\n
#<\/code> karakteri ile ba\u015flar ve sat\u0131r\u0131n sonuna kadar devam eder. Fonksiyonlar, s\u0131n\u0131flar ve mod\u00fcller i\u00e7in ise docstring ad\u0131 verilen \u00f6zel dok\u00fcmantasyon stringleri kullan\u0131l\u0131r. Bu docstring’ler, \"\"\"...\"\"\"<\/code> veya '''...'''<\/code> ile \u00e7evrelenir ve fonksiyonun veya mod\u00fcl\u00fcn ne yapt\u0131\u011f\u0131n\u0131, hangi parametreleri ald\u0131\u011f\u0131n\u0131 ve ne d\u00f6nd\u00fcrd\u00fc\u011f\u00fcn\u00fc a\u00e7\u0131klar.<\/p>\n\ndef fibonacci_serisi_hesapla(n):\n \"\"\"\n Belirtilen 'n' say\u0131s\u0131na kadar olan Fibonacci serisini hesaplar.\n\n Fibonacci serisi, her say\u0131n\u0131n kendinden \u00f6nceki iki say\u0131n\u0131n toplam\u0131 oldu\u011fu\n bir say\u0131 dizisidir (\u00f6rne\u011fin: 0, 1, 1, 2, 3, 5, 8, ...).\n\n Args:\n n (int): Fibonacci serisinin hesaplanaca\u011f\u0131 \u00fcst s\u0131n\u0131r.\n\n Returns:\n list: 'n' say\u0131s\u0131na kadar olan Fibonacci serisini i\u00e7eren bir liste.\n E\u011fer n negatifse bo\u015f liste d\u00f6ner.\n \"\"\"\n if n < 0:\n # Negatif say\u0131lar i\u00e7in Fibonacci serisi tan\u0131ml\u0131 de\u011fildir.\n return []\n elif n == 0:\n # 0 i\u00e7in sadece 0 eleman\u0131n\u0131 i\u00e7eren liste d\u00f6ner.\n return [0]\n \n seri = [0, 1]\n # 2'den ba\u015flayarak n'e kadar olan say\u0131lar\u0131 kontrol et\n while seri[-1] + seri[-2] <= n:\n sonraki_sayi = seri[-1] + seri[-2]\n seri.append(sonraki_sayi)\n \n # E\u011fer en son eklenen say\u0131 n'den b\u00fcy\u00fckse, onu \u00e7\u0131karmam\u0131z gerekebilir.\n # Ancak bu \u00f6rnekte <= n ko\u015fuluyla bu durum olu\u015fmaz.\n \n return seri\n\n# \u00d6rnek kullan\u0131m:\n# print(fibonacci_serisi_hesapla(50))\n <\/code><\/pre>\n<\/p><\/div>\n5. Ad\u0131m: Hata Y\u00f6netimi (Error Handling): Beklenmedik Durumlara Haz\u0131rl\u0131kl\u0131 Olmak<\/h2>\n
try...except<\/code> bloklar\u0131 kullan\u0131larak yap\u0131l\u0131r. Bir kod blo\u011funu try<\/code> i\u00e7ine al\u0131r\u0131z ve bu blok \u00e7al\u0131\u015f\u0131rken bir hata olu\u015fursa, except<\/code> blo\u011fu bu hatay\u0131 yakalar ve uygun bir i\u015flem ger\u00e7ekle\u015ftirir. Bu i\u015flem, kullan\u0131c\u0131ya bilgilendirici bir mesaj vermek, hatay\u0131 bir log dosyas\u0131na kaydetmek veya programa g\u00fcvenli bir \u015fekilde devam etmek olabilir.<\/p>\nValueError<\/code> hatas\u0131 verebilir. Bu durumu try...except ValueError<\/code> blo\u011fu ile y\u00f6neterek, kullan\u0131c\u0131ya \"L\u00fctfen ge\u00e7erli bir say\u0131 girin.\" gibi bir mesaj g\u00f6sterebilirsiniz. Bu, kullan\u0131c\u0131 deneyimini iyile\u015ftirir ve program\u0131n aniden kapanmas\u0131n\u0131 engeller. Hata y\u00f6netimi, sadece kullan\u0131c\u0131dan gelen girdilerle s\u0131n\u0131rl\u0131 de\u011fildir. A\u011f ba\u011flant\u0131s\u0131 sorunlar\u0131, dosya eri\u015fim izinleri, veritaban\u0131 ba\u011flant\u0131 hatalar\u0131 gibi bir\u00e7ok farkl\u0131 senaryoda hata y\u00f6netimi gerekebilir. Her hata t\u00fcr\u00fc i\u00e7in \u00f6zel except<\/code> bloklar\u0131 yazmak, sorunun kayna\u011f\u0131n\u0131 daha h\u0131zl\u0131 tespit etmeye yard\u0131mc\u0131 olur. \u00d6rne\u011fin, except FileNotFoundError<\/code>, except ConnectionError<\/code> gibi bloklar, spesifik hatalar\u0131 yakalamak i\u00e7in kullan\u0131l\u0131r. Genel bir except Exception as e<\/code> ise, yakalanmayan di\u011fer t\u00fcm hatalar\u0131 yakalamak i\u00e7in kullan\u0131labilir, ancak bu, hatan\u0131n nedenini gizleyebilece\u011fi i\u00e7in dikkatli kullan\u0131lmal\u0131d\u0131r. Etkili hata y\u00f6netimi, kodunuzun daha sa\u011flam (robust) olmas\u0131n\u0131 sa\u011flar.<\/p>\n\n
try<\/code> blo\u011fu i\u00e7inde dosya okuma ve veri i\u015fleme ad\u0131mlar\u0131 yer al\u0131yor.<\/li>\nexcept pd.errors.EmptyDataError<\/code>: Bo\u015f dosya hatas\u0131 yakalan\u0131yor ve loglan\u0131yor.<\/li>\nexcept IndexError<\/code>: Sat\u0131rda beklenen s\u00fctun say\u0131s\u0131ndan az s\u00fctun varsa bu hata yakalan\u0131yor ve ilgili sat\u0131r atlan\u0131p loglan\u0131yor.<\/li>\nexcept Exception as e<\/code>: Di\u011fer beklenmedik hatalar yakalan\u0131yor, detayl\u0131 loglama yap\u0131l\u0131yor ve betik i\u015fleme devam ediyor.<\/li>\n<\/ul>\n6. Ad\u0131m: Kod Bi\u00e7imlendirme ve Tutarl\u0131l\u0131k: PEP 8'e Uyun<\/h2>\n
\n
=<\/code>, +<\/code>, -<\/code> vb.) etraf\u0131nda birer bo\u015fluk kullan\u0131n.<\/li>\n7. Ad\u0131m: Gereksiz Kodlar\u0131 Temizleyin ve Refactoring Yap\u0131n<\/h2>\n
\n
8. Ad\u0131m: Versiyon Kontrol Sistemi (Git) Kullan\u0131n<\/h2>\n
init<\/code>, add<\/code>, commit<\/code>, push<\/code>, pull<\/code>, branch<\/code>, merge<\/code>) ile kodunuzun farkl\u0131 s\u00fcr\u00fcmlerini kaydedebilirsiniz. \u00d6rne\u011fin, bir de\u011fi\u015fiklik yapmadan \u00f6nce yeni bir \"dal\" (branch) olu\u015fturabilir, de\u011fi\u015fikliklerinizi bu dalda yapabilir ve her \u015fey yolunda giderse ana dala (main\/master branch) birle\u015ftirebilirsiniz (merge). Bu, ana kod taban\u0131n\u0131n her zaman stabil kalmas\u0131n\u0131 sa\u011flar. E\u011fer bir de\u011fi\u015fiklik soruna yol a\u00e7arsa, kolayca \u00f6nceki stabil s\u00fcr\u00fcme geri d\u00f6nebilirsiniz. Da\u011f\u0131n\u0131k bir betikte, Git kullanmak, bu beti\u011fi ad\u0131m ad\u0131m iyile\u015ftirme s\u00fcrecinizi kaydetmenize olanak tan\u0131r. Her bir iyile\u015ftirme ad\u0131m\u0131 (\u00f6rne\u011fin, bir fonksiyonu ay\u0131rma, bir de\u011fi\u015fkeni yeniden adland\u0131rma) ayr\u0131 bir commit olarak kaydedilebilir. Bu, projenin geli\u015fimini izlemek i\u00e7in harika bir yoldur. Ayr\u0131ca, GitHub, GitLab veya Bitbucket gibi platformlar, Git depolar\u0131n\u0131z\u0131 bar\u0131nd\u0131rman\u0131za ve ekip \u00fcyeleriyle kolayca payla\u015fman\u0131za olanak tan\u0131r. Kod incelemeleri (code reviews) de Git'in sundu\u011fu \u00f6nemli bir \u00f6zelliktir. Ba\u015fka bir geli\u015ftirici, yapt\u0131\u011f\u0131n\u0131z de\u011fi\u015fiklikleri inceleyebilir ve geri bildirimde bulunabilir. Bu, kod kalitesini art\u0131rman\u0131n ve hatalar\u0131 erken tespit etmenin en etkili yollar\u0131ndan biridir.<\/p>\nmodel_v3_final_son.py<\/code>, deneme_yeni_parametreler.py<\/code>) bir y\u0131\u011f\u0131n haline gelmi\u015fti. Git kullanmaya ba\u015flad\u0131ktan sonra:<\/p>\n\n
9. Ad\u0131m: Otomatik Testler Yaz\u0131n<\/h2>\n
unittest<\/code> ve pytest<\/code> gibi pop\u00fcler test framework'leri bulunmaktad\u0131r. Bu testler, kodunuzdaki belirli fonksiyonlar\u0131n, s\u0131n\u0131flar\u0131n veya mod\u00fcllerin girdilere kar\u015f\u0131 do\u011fru \u00e7\u0131kt\u0131lar\u0131 \u00fcretip \u00fcretmedi\u011fini kontrol eder.<\/p>\npytest<\/code> gibi framework'ler, test yazmay\u0131 olduk\u00e7a kolayla\u015ft\u0131r\u0131r. Testleri \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, t\u00fcm testlerin ge\u00e7mesi, kodunuzun b\u00fcy\u00fck olas\u0131l\u0131kla stabil oldu\u011funu g\u00f6sterir. E\u011fer bir test ba\u015far\u0131s\u0131z olursa, bu, ya kodunuzda bir hata oldu\u011funu ya da yapt\u0131\u011f\u0131n\u0131z bir de\u011fi\u015fikli\u011fin beklenmedik bir etkiye sahip oldu\u011funu g\u00f6sterir. Bu, hatalar\u0131 erken tespit etmenizi sa\u011flar ve manuel testlere harcanan zaman\u0131 azalt\u0131r. S\u00fcrekli entegrasyon (Continuous Integration - CI) ara\u00e7lar\u0131 (\u00f6rne\u011fin Jenkins, GitHub Actions, GitLab CI), kodunuz her de\u011fi\u015ftirildi\u011finde otomatik olarak testleri \u00e7al\u0131\u015ft\u0131rabilir. Bu, kod kalitesini s\u00fcrekli y\u00fcksek tutmaya yard\u0131mc\u0131 olur.<\/p>\npytest<\/code> kullanarak kapsaml\u0131 unit testler yazd\u0131. Testler, farkl\u0131 para birimi kombinasyonlar\u0131, farkl\u0131 vergi oranlar\u0131 ve d\u00f6viz kuru dalgalanmalar\u0131 gibi \u00e7e\u015fitli senaryolar\u0131 kaps\u0131yordu. Testlerin yaz\u0131lmas\u0131 ve \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 sonras\u0131nda, mod\u00fclde bulunan birka\u00e7 kritik hata tespit edildi ve d\u00fczeltildi. Bu sayede, raporlama beti\u011finin do\u011frulu\u011fu \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131ld\u0131 ve finansal verilerin g\u00fcvenilirli\u011fi sa\u011fland\u0131.<\/p>\n10. Ad\u0131m: Kod \u0130ncelemesi (Code Review) ve Geri Bildirim Al\u0131n<\/h2>\n
Sonu\u00e7: Temiz Kod Bir Yolculuktur<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n