Kodunuzu ana dala g\u00f6ndermeden \u00f6nce bir g\u00f6zden ge\u00e7irme s\u00fcrecinden ge\u00e7irmek, yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131ndan biridir. Peki ya ekipte sadece siz varsan\u0131z veya h\u0131zl\u0131 bir geri bildirim almak istedi\u011finizde ne yapmal\u0131? \u0130\u015fte bu noktada, ki\u015fisel projelerinizde veya k\u00fc\u00e7\u00fck ekiplerde bile verimlili\u011fi art\u0131rabilecek ‘diff-review’ gibi yerel, \u00f6n-g\u00f6nderim (pre-push) kod g\u00f6zden ge\u00e7irme ara\u00e7lar\u0131 devreye giriyor. Bu makalede, ‘diff-review’ konseptini ve nas\u0131l bir arkada\u015f\u0131n\u0131z i\u00e7in basit ama etkili bir ara\u00e7 olu\u015fturabilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz. Amac\u0131m\u0131z, kod kalitesini art\u0131rmak, hatalar\u0131 erken yakalamak ve geli\u015ftirme s\u00fcrecini daha ak\u0131c\u0131 hale getirmektir.<\/p>\n
Modern yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde kod g\u00f6zden ge\u00e7irme (code review), kalitenin sa\u011flanmas\u0131, bilginin payla\u015f\u0131lmas\u0131 ve hatalar\u0131n erken tespit edilmesi a\u00e7\u0131s\u0131ndan kritik bir \u00f6neme sahiptir. Ancak, geleneksel kod g\u00f6zden ge\u00e7irme s\u00fcre\u00e7leri genellikle bir sonraki ad\u0131ma ge\u00e7meden \u00f6nce zaman alabilir ve bazen bir engelleyici fakt\u00f6r haline gelebilir. \u00d6zellikle tek ki\u015filik projelerde veya \u00e7ok k\u00fc\u00e7\u00fck ekiplerde, bu s\u00fcreci daha h\u0131zl\u0131 ve verimli hale getirmenin yollar\u0131n\u0131 arar\u0131z. \u0130\u015fte tam bu noktada, ‘diff-review’ gibi yerel, yani geli\u015ftiricinin kendi makinesinde \u00e7al\u0131\u015fan, bir \u00f6n-g\u00f6nderim (pre-push) mekanizmas\u0131 devreye giriyor. Bu t\u00fcr bir ara\u00e7, kodunuzu uzak bir depoya (remote repository) g\u00f6ndermeden (\u00f6rne\u011fin, Git’in Peki, neden b\u00f6yle bir araca ihtiya\u00e7 duyar\u0131z? \u00d6ncelikle, geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fc h\u0131zland\u0131rmak isteriz. Bir kodu g\u00f6ndermeden \u00f6nce, kendi kendimize veya bir arkada\u015f\u0131m\u0131za h\u0131zl\u0131ca g\u00f6stermek, olas\u0131 hatalar\u0131 daha erken yakalamam\u0131za yard\u0131mc\u0131 olur. Bu, \u00f6zellikle karma\u015f\u0131k algoritmalar veya kritik i\u015f mant\u0131\u011f\u0131 i\u00e7eren kodlarda b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. \u0130kinci olarak, \u00f6\u011frenme ve bilgi payla\u015f\u0131m\u0131 a\u00e7\u0131s\u0131ndan da faydal\u0131d\u0131r. E\u011fer bir arkada\u015f\u0131n\u0131z i\u00e7in b\u00f6yle bir ara\u00e7 geli\u015ftiriyorsan\u0131z, bu s\u00fcre\u00e7 hem sizin hem de arkada\u015f\u0131n\u0131z\u0131n kodlama becerilerini geli\u015ftirmesine olanak tan\u0131r. Arkada\u015f\u0131n\u0131z\u0131n kodundaki potansiyel sorunlar\u0131 i\u015faret ederek, onun daha iyi pratikler \u00f6\u011frenmesine yard\u0131mc\u0131 olabilirsiniz. Ayn\u0131 \u015fekilde, kendi kodunuzu ba\u015fkas\u0131na inceletmek, sizin de farkl\u0131 bak\u0131\u015f a\u00e7\u0131lar\u0131 kazanman\u0131z\u0131 sa\u011flar.<\/p>\n \u00dc\u00e7\u00fcnc\u00fc olarak, kod kalitesini tutarl\u0131 tutmak \u00f6nemlidir. Herkesin kendi kodunu bir g\u00f6zden ge\u00e7irme s\u00fcrecinden ge\u00e7irmesi, projenin genel kodlama standartlar\u0131na uyulmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. Bu, zamanla projenin bak\u0131m\u0131n\u0131 ve geli\u015ftirilmesini daha y\u00f6netilebilir hale getirir. D\u00f6rd\u00fcnc\u00fc olarak, yerel bir ara\u00e7, internet ba\u011flant\u0131s\u0131 gerektirmez. Bu, \u00f6zellikle seyahat ederken veya internet eri\u015fiminin s\u0131n\u0131rl\u0131 oldu\u011fu ortamlarda \u00e7al\u0131\u015f\u0131rken b\u00fcy\u00fck bir avantajd\u0131r. Son olarak, ‘diff-review’ konsepti, daha b\u00fcy\u00fck kod g\u00f6zden ge\u00e7irme platformlar\u0131n\u0131n (GitHub Pull Requests, GitLab Merge Requests gibi) temel mant\u0131\u011f\u0131n\u0131 kendi yerel ortam\u0131n\u0131za ta\u015f\u0131man\u0131za olanak tan\u0131r. Bu, daha b\u00fcy\u00fck ekiplerde kullan\u0131lacak ara\u00e7lar\u0131n temelini anlamak i\u00e7in de iyi bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r.<\/p>\n Kod g\u00f6zden ge\u00e7irme, bir yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecinde, bir veya daha fazla geli\u015ftiricinin, bir ba\u015fka geli\u015ftiricinin yazd\u0131\u011f\u0131 kodu incelemesi ve geri bildirimde bulunmas\u0131d\u0131r. Bu s\u00fcre\u00e7, kodun kalitesini art\u0131rmak, hatalar\u0131 en aza indirmek, kodlama standartlar\u0131n\u0131 uygulamak, bilgi payla\u015f\u0131m\u0131n\u0131 te\u015fvik etmek ve yeni geli\u015ftiricilerin projeye adaptasyonunu kolayla\u015ft\u0131rmak gibi bir\u00e7ok amaca hizmet eder. Basit\u00e7e ifade etmek gerekirse, bir ba\u015fkas\u0131n\u0131n yazd\u0131\u011f\u0131 kodu okuyarak, potansiyel sorunlar\u0131, geli\u015ftirme alanlar\u0131n\u0131 veya daha iyi alternatifleri belirlemeye \u00e7al\u0131\u015fmakt\u0131r. Bu, t\u0131pk\u0131 bir metnin edit\u00f6r taraf\u0131ndan okunmas\u0131 gibi, yaz\u0131l\u0131m\u0131n daha iyi, daha g\u00fcvenli ve daha s\u00fcrd\u00fcr\u00fclebilir olmas\u0131n\u0131 sa\u011flar.<\/p>\n Kod g\u00f6zden ge\u00e7irme, modern yaz\u0131l\u0131m geli\u015ftirmenin ayr\u0131lmaz bir par\u00e7as\u0131 haline gelmi\u015ftir. Bunun birka\u00e7 temel nedeni vard\u0131r. \u0130lk olarak, insan hatas\u0131 ka\u00e7\u0131n\u0131lmazd\u0131r. Hepimiz hata yapabiliriz. Kod g\u00f6zden ge\u00e7irme, bu hatalar\u0131, kod ana dala (main branch) veya \u00fcretim ortam\u0131na (production environment) ula\u015fmadan \u00f6nce yakalamak i\u00e7in birincil savunma hatt\u0131d\u0131r. K\u00fc\u00e7\u00fck bir yaz\u0131m hatas\u0131 veya mant\u0131k hatas\u0131, b\u00fcy\u00fck sorunlara yol a\u00e7abilir. \u0130kinci olarak, kod g\u00f6zden ge\u00e7irme, ekip \u00fcyeleri aras\u0131nda bilgi payla\u015f\u0131m\u0131n\u0131 te\u015fvik eder. Bir geli\u015ftiricinin yazd\u0131\u011f\u0131 kodu inceleyen di\u011fer geli\u015ftiriciler, farkl\u0131 yakla\u015f\u0131mlar\u0131, k\u00fct\u00fcphaneleri veya en iyi pratikleri \u00f6\u011frenebilirler. Bu, ekip genelinde teknik yetkinli\u011fin artmas\u0131na yard\u0131mc\u0131 olur. \u00dc\u00e7\u00fcnc\u00fc olarak, kod g\u00f6zden ge\u00e7irme, kodun okunabilirli\u011fini ve bak\u0131m\u0131n\u0131 iyile\u015ftirir. Kodun anla\u015f\u0131l\u0131r olmas\u0131, gelecekteki de\u011fi\u015fikliklerin daha kolay yap\u0131lmas\u0131n\u0131 sa\u011flar. D\u00f6rd\u00fcnc\u00fc olarak, kod g\u00f6zden ge\u00e7irme, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n tespit edilmesine yard\u0131mc\u0131 olabilir. G\u00fcvenlik a\u00e7\u0131klar\u0131 genellikle g\u00f6zden ka\u00e7an k\u00fc\u00e7\u00fck detaylardan kaynaklan\u0131r ve bir ikinci \u00e7ift g\u00f6z, bu t\u00fcr sorunlar\u0131 daha kolay fark edebilir.<\/p>\n Kod g\u00f6zden ge\u00e7irme s\u00fcreci, farkl\u0131 \u015fekillerde uygulanabilir. En yayg\u0131n y\u00f6ntemlerden biri, Git gibi versiyon kontrol sistemleri (version control systems) \u00fczerinde \u00e7ekme istekleri (pull requests) veya birle\u015ftirme istekleri (merge requests) arac\u0131l\u0131\u011f\u0131yla ger\u00e7ekle\u015ftirilir. Bir geli\u015ftirici, yapt\u0131\u011f\u0131 de\u011fi\u015fiklikleri bir dalda (branch) tamamlar ve ard\u0131ndan bu de\u011fi\u015fiklikleri ana dala birle\u015ftirmek i\u00e7in bir istek g\u00f6nderir. Bu istek, di\u011fer ekip \u00fcyeleri taraf\u0131ndan incelenir. Ancak, bu y\u00f6ntemler genellikle merkezi bir sunucuya (\u00f6rne\u011fin, GitHub, GitLab, Bitbucket) ba\u011f\u0131ml\u0131d\u0131r ve bir miktar gecikme i\u00e7erebilir. \u0130\u015fte bu noktada, ‘diff-review’ gibi yerel, \u00f6n-g\u00f6nderim ara\u00e7lar\u0131, bu s\u00fcreci geli\u015ftiricinin kendi makinesine ta\u015f\u0131yarak daha h\u0131zl\u0131 bir ilk kontrol imkan\u0131 sunar.<\/p>\n ‘diff-review’, temel olarak, bir geli\u015ftiricinin Git deposundaki (repository) de\u011fi\u015fikliklerini (diff) analiz eden ve bu de\u011fi\u015fiklikler hakk\u0131nda bir t\u00fcr “g\u00f6zden ge\u00e7irme” \u00e7\u0131kt\u0131s\u0131 \u00fcreten bir ara\u00e7t\u0131r. Bu, genellikle kodunuzu Bu arac\u0131n mimarisi olduk\u00e7a basittir. Temelde \u015fu ad\u0131mlar\u0131 izler:<\/p>\n Bir arkada\u015f\u0131n\u0131z i\u00e7in bu arac\u0131 geli\u015ftirirken, ba\u015flang\u0131\u00e7 noktan\u0131z genellikle bir komut sat\u0131r\u0131 arac\u0131 (command-line tool) olacakt\u0131r. Bu, kurulumu ve kullan\u0131m\u0131 en kolay olan\u0131d\u0131r. \u00d6rne\u011fin, bir Python beti\u011fi veya Node.js beti\u011fi ile ba\u015flayabilirsiniz. Bu betik, Git komutlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rabilir ve \u00e7\u0131kt\u0131lar\u0131n\u0131 i\u015fleyebilir.<\/p>\n Temel olarak, ara\u00e7 \u015funlar\u0131 yapmal\u0131d\u0131r:<\/p>\n \u00d6rne\u011fin, bir Python beti\u011fi kullan\u0131larak \u015f\u00f6yle bir mant\u0131k kurulabilir:<\/p>\n Bu temel yap\u0131, farkl\u0131 analizler ekleyerek geni\u015fletilebilir. \u00d6rne\u011fin, PEP 8 uyumlulu\u011fu i\u00e7in \u015eimdi, bu konsepti daha somut hale getirelim ve bir arkada\u015f\u0131n\u0131z i\u00e7in basit bir ‘diff-review’ arac\u0131 olu\u015ftural\u0131m. Bu ara\u00e7, Git’in Git kancalar\u0131 (Git hooks), Git olaylar\u0131 tetiklendi\u011finde (commit, push, rebase vb.) otomatik olarak \u00e7al\u0131\u015fan betiklerdir. Bu kancay\u0131 kullanmak i\u00e7in, Git deposunun \u00d6rne\u011fin, bir bash beti\u011fi ile ba\u015flayabiliriz:<\/p>\n Bu beti\u011fi \u015eimdi, yukar\u0131da bahsetti\u011fimiz Python analiz beti\u011fini geli\u015ftirelim. Bu betik, sadece eklenen sat\u0131rlardaki belirli kal\u0131plar\u0131 arayacak. \u00d6rne\u011fin, “TODO:” gibi geli\u015ftirme s\u0131ras\u0131nda unutulmu\u015f notlar\u0131 veya “print(“DEBUG”)” gibi hata ay\u0131klama \u00e7\u0131kt\u0131lar\u0131n\u0131 bulabiliriz.<\/p>\n Bu beti\u011fi kaydettikten sonra, Art\u0131k bir de\u011fi\u015fiklik yap\u0131p, Diyelim ki Ay\u015fe, kendi ki\u015fisel projesi \u00fczerinde \u00e7al\u0131\u015f\u0131yor ve bu projeyi GitHub’a y\u00fcklemek istiyor. Ay\u015fe, kodunu g\u00f6ndermeden \u00f6nce h\u0131zl\u0131ca kontrol etmek istiyor. Kendi bilgisayar\u0131nda basit bir Bir g\u00fcn Ay\u015fe, karma\u015f\u0131k bir algoritma \u00fczerinde \u00e7al\u0131\u015f\u0131rken bir hata yapar ve koduna hata ay\u0131klama ama\u00e7l\u0131 birka\u00e7 Ay\u015fe hemen Bir ba\u015fka senaryoda, Ay\u015fe’nin arkada\u015f\u0131 Can, Ay\u015fe’nin projesine katk\u0131da bulunmak istiyor. Can, kendi yerel makinesinde Ay\u015fe’nin projesinin bir kopyas\u0131n\u0131 (clone) al\u0131r ve \u00fczerinde \u00e7al\u0131\u015fmaya ba\u015flar. Can da ayn\u0131 Can, bu uyar\u0131y\u0131 g\u00f6rd\u00fc\u011f\u00fcnde, b\u0131rakt\u0131\u011f\u0131 TODO yorumunu fark eder ve hemen fonksiyonun ne i\u015fe yarad\u0131\u011f\u0131n\u0131 a\u00e7\u0131klayan daha detayl\u0131 bir yorum ekler. Ard\u0131ndan tekrar push yapar ve bu sefer sorunsuz bir \u015fekilde kodunu g\u00f6nderebilir. Bu, hem Can’\u0131n kod kalitesini art\u0131rmas\u0131na hem de Ay\u015fe’nin projesinin daha d\u00fczenli kalmas\u0131na yard\u0131mc\u0131 olur.<\/p>\n Olu\u015fturdu\u011fumuz temel ara\u00e7, birka\u00e7 basit kontrolle s\u0131n\u0131rl\u0131yd\u0131. Ancak, ‘diff-review’ konsepti \u00e7ok daha fazlas\u0131n\u0131 yapabilir. Bir arkada\u015f\u0131n\u0131z i\u00e7in geli\u015ftirece\u011finiz bu arac\u0131, onun ihtiya\u00e7lar\u0131na g\u00f6re \u00f6zelle\u015ftirebilir ve daha g\u00fc\u00e7l\u00fc hale getirebilirsiniz. \u0130\u015fte baz\u0131 ileri d\u00fczey analizler ve \u00f6zelle\u015ftirme fikirleri:<\/p>\n Kod kalitesini art\u0131rman\u0131n en etkili yollar\u0131ndan biri, otomatik kod analiz ara\u00e7lar\u0131 (linters) ve kod bi\u00e7imlendiriciler (formatters) kullanmakt\u0131r. Bu ara\u00e7lar, kod stilini standartla\u015ft\u0131r\u0131r, potansiyel hatalar\u0131 tespit eder ve okunabilirli\u011fi art\u0131r\u0131r.<\/p>\n \u00d6rne\u011fin, Python projesinde Bu g\u00fcncellenmi\u015f betik, sadece de\u011fi\u015ftirilen sat\u0131rlardaki sorunlar\u0131 de\u011fil, ayn\u0131 zamanda G\u00fcvenlik, her yaz\u0131l\u0131m projesi i\u00e7in hayati \u00f6nem ta\u015f\u0131r. ‘diff-review’ arac\u0131, basit g\u00fcvenlik kontrolleri i\u00e7in de kullan\u0131labilir. \u00d6rne\u011fin, hassas bilgilerin (API anahtarlar\u0131, parolalar vb.) yanl\u0131\u015fl\u0131kla koda eklenip eklenmedi\u011fini kontrol edebilirsiniz.<\/p>\n Her proje veya ekip farkl\u0131 kurallara sahip olabilir. Arac\u0131n\u0131z\u0131, bu kurallar\u0131 kolayca yap\u0131land\u0131r\u0131labilecek \u015fekilde tasarlamak, onu daha kullan\u0131\u015fl\u0131 hale getirir. \u00d6rne\u011fin:<\/p>\n Bir yaz\u0131l\u0131m \u015firketinde \u00e7al\u0131\u015fan Mehmet, ekibinin kod kalitesini art\u0131rmak i\u00e7in kendi geli\u015ftirdi\u011fi ‘diff-review’ arac\u0131n\u0131 kullan\u0131yor. Ekip, Python dilinde \u00e7al\u0131\u015f\u0131yor ve Mehmet, bu kurallar\u0131 bir Bu t\u00fcr bir entegrasyon, hem geli\u015ftirme s\u00fcrecini h\u0131zland\u0131r\u0131r hem de projenin genel kalitesini ve g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Bu, tek ki\u015filik bir projede bile kullan\u0131labilece\u011fi gibi, k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli ekipler i\u00e7in de olduk\u00e7a faydal\u0131d\u0131r.<\/p>\n Yerel kod g\u00f6zden ge\u00e7irme ara\u00e7lar\u0131, \u00f6zellikle ‘diff-review’ gibi \u00f6n-g\u00f6nderim (pre-push) mekanizmalar\u0131, yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecine \u00f6nemli katk\u0131lar sa\u011flayabilir. Ancak her teknolojide oldu\u011fu gibi, bu yakla\u015f\u0131m\u0131n da kendine \u00f6zg\u00fc avantajlar\u0131 ve dezavantajlar\u0131 bulunmaktad\u0131r. Bu dengeyi anlamak, arac\u0131n ne zaman ve nas\u0131l kullan\u0131laca\u011f\u0131na karar vermede yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n Bu dezavantajlara ra\u011fmen, ‘diff-review’ gibi yerel ara\u00e7lar, geleneksel kod g\u00f6zden ge\u00e7irme s\u00fcre\u00e7lerini tamamlay\u0131c\u0131 olarak kullan\u0131ld\u0131\u011f\u0131nda son derece de\u011ferlidir. \u00d6zellikle tek ki\u015filik projelerde veya bir ekibin ba\u015flang\u0131\u00e7 a\u015famas\u0131nda, bu ara\u00e7lar kod kalitesini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir.<\/p>\n ‘diff-review’ konsepti, geli\u015ftiricilere kodlar\u0131n\u0131 ana dala g\u00f6ndermeden \u00f6nce kendi yerel ortamlar\u0131nda h\u0131zl\u0131 bir kontrol imkan\u0131 sunarak yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecini daha verimli hale getirme potansiyeli ta\u015f\u0131r. Bir arkada\u015f\u0131n\u0131z i\u00e7in basit bir \u00f6n-g\u00f6nderim (pre-push) arac\u0131 olu\u015fturmak, hem kod kalitesini art\u0131rman\u0131n hem de geli\u015ftirme al\u0131\u015fkanl\u0131klar\u0131n\u0131 iyile\u015ftirmenin harika bir yoludur. Temel Git komutlar\u0131 ve basit betikleme yetenekleriyle, stil hatalar\u0131n\u0131, unutulmu\u015f hata ay\u0131klama \u00e7\u0131kt\u0131lar\u0131n\u0131 ve hatta basit g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 tespit eden bir ara\u00e7 geli\u015ftirebilirsiniz.<\/p>\n Bu makalede, ‘diff-review’\u00fcn ne oldu\u011funu, neden \u00f6nemli oldu\u011funu, temel mimarisini ve ad\u0131m ad\u0131m nas\u0131l bir ara\u00e7 olu\u015fturulabilece\u011fini inceledik. Ayr\u0131ca, linterlar, bi\u00e7imlendiriciler ve g\u00fcvenlik analiz ara\u00e7lar\u0131 gibi daha geli\u015fmi\u015f \u00f6zelliklerin nas\u0131l entegre edilebilece\u011fini ele ald\u0131k. Yerel g\u00f6zden ge\u00e7irme ara\u00e7lar\u0131n\u0131n avantajlar\u0131 ve dezavantajlar\u0131 da tart\u0131\u015f\u0131ld\u0131; bu ara\u00e7lar\u0131n tek ba\u015f\u0131na bir \u00e7\u00f6z\u00fcm olmasa da, geleneksel kod g\u00f6zden ge\u00e7irme s\u00fcre\u00e7lerini g\u00fc\u00e7l\u00fc bir \u015fekilde tamamlayabilece\u011fi vurguland\u0131.<\/p>\n Gelecek ad\u0131mlar olarak, bu basit arac\u0131 daha da geli\u015ftirebilirsiniz:<\/p>\n Unutmay\u0131n, yaz\u0131l\u0131m geli\u015ftirme s\u00fcrekli bir \u00f6\u011frenme ve iyile\u015ftirme s\u00fcrecidir. ‘diff-review’ gibi ara\u00e7lar, bu s\u00fcreci daha bilin\u00e7li ve daha verimli hale getirmenize yard\u0131mc\u0131 olur. Kendi arac\u0131n\u0131z\u0131 olu\u015fturarak veya mevcut ara\u00e7lar\u0131 kullanarak, kod kalitenizi y\u00fckseltebilir ve daha sa\u011flam yaz\u0131l\u0131mlar geli\u015ftirebilirsiniz.<\/p>\n #Teknoloji #WebGeli\u015ftirme #Yaz\u0131l\u0131mM\u00fchendisli\u011fi #KodKalitesi #Git<\/p>\ngit push<\/code> komutuyla) \u00f6nce, de\u011fi\u015fikliklerinizi otomatik olarak bir g\u00f6zden ge\u00e7irme s\u00fcrecinden ge\u00e7irmenizi sa\u011flar.<\/p>\nKod G\u00f6zden Ge\u00e7irme (Code Review) Nedir ve Neden \u00d6nemlidir?<\/h3>\n
diff-review: Temel Konsept ve Mimari<\/h2>\n
git push<\/code> komutuyla uzak bir sunucuya g\u00f6ndermeden \u00f6nce \u00e7al\u0131\u015fan bir betik (script) veya k\u00fc\u00e7\u00fck bir program arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r. Ama\u00e7, kodunuzu g\u00f6ndermeden \u00f6nce olas\u0131 hatalar\u0131, stil sorunlar\u0131n\u0131 veya belirli kurallara uymayan k\u0131s\u0131mlar\u0131 tespit etmektir. Bu, bir arkada\u015f\u0131n\u0131z i\u00e7in olu\u015fturulacak basit bir arac\u0131n temelini olu\u015fturur.<\/p>\n\n
git diff<\/code> komutuyla elde edilen \u00e7\u0131kt\u0131y\u0131 analiz ederek yap\u0131l\u0131r.<\/li>\ngit push<\/code> komutu \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda otomatik olarak tetiklenmesini sa\u011flar. E\u011fer analiz sonu\u00e7lar\u0131 olumsuzsa, g\u00f6nderim i\u015flemi iptal edilebilir veya kullan\u0131c\u0131ya uyar\u0131 verilebilir.<\/li>\n<\/ul>\n\n
\nimport subprocess\n\ndef get_staged_changes():\n \"\"\"\n Staged (haz\u0131rlanm\u0131\u015f) de\u011fi\u015fiklikleri al\u0131r.\n \"\"\"\n try:\n result = subprocess.run(['git', 'diff', '--name-only', '--cached'], capture_output=True, text=True, check=True)\n return result.stdout.splitlines()\n except subprocess.CalledProcessError as e:\n print(f\"Git komutu hatas\u0131: {e}\")\n return []\n\ndef get_diff_for_file(filename):\n \"\"\"\n Belirli bir dosya i\u00e7in diff \u00e7\u0131kt\u0131s\u0131n\u0131 al\u0131r.\n \"\"\"\n try:\n result = subprocess.run(['git', 'diff', '--cached', filename], capture_output=True, text=True, check=True)\n return result.stdout\n except subprocess.CalledProcessError as e:\n print(f\"Git diff hatas\u0131: {e}\")\n return \"\"\n\ndef analyze_code_changes(diff_output):\n \"\"\"\n Basit bir analiz yapar. (Buraya ger\u00e7ek analizler gelecek)\n \"\"\"\n issues = []\n lines = diff_output.splitlines()\n for line_num, line in enumerate(lines):\n if line.startswith('+') and not line.startswith('+++'): # Sadece eklenen sat\u0131rlara bak\n if \"print(\" in line and \"DEBUG\" in line: # Basit bir hata kontrol\u00fc\n issues.append(f\"Sat\u0131r {line_num}: DEBUG \u00e7\u0131kt\u0131s\u0131 tespit edildi.\")\n return issues\n\n# Ana i\u015f ak\u0131\u015f\u0131\nif __name__ == \"__main__\":\n changed_files = get_staged_changes()\n all_issues = {}\n\n for file in changed_files:\n diff = get_diff_for_file(file)\n if diff:\n issues = analyze_code_changes(diff)\n if issues:\n all_issues[file] = issues\n\n if all_issues:\n print(\"Kod G\u00f6zden Ge\u00e7irme Raporu:\")\n for file, issues in all_issues.items():\n print(f\"\\nDosya: {file}\")\n for issue in issues:\n print(f\" - {issue}\")\n print(\"\\nG\u00f6nderim engellendi. L\u00fctfen yukar\u0131daki sorunlar\u0131 giderin.\")\n exit(1) # Hata kodu ile \u00e7\u0131k\u0131\u015f yap\n else:\n print(\"Tebrikler! Herhangi bir sorun bulunamad\u0131. G\u00f6nderim yapabilirsiniz.\")\n exit(0) # Ba\u015far\u0131l\u0131 \u00e7\u0131k\u0131\u015f\n <\/code><\/pre>\nflake8<\/code>, g\u00fcvenlik i\u00e7in bandit<\/code> gibi ara\u00e7lar\u0131n \u00e7\u0131kt\u0131s\u0131n\u0131 entegre edebilirsiniz.<\/p>\nAd\u0131m Ad\u0131m: Bir Arkada\u015f \u0130\u00e7in Basit Bir diff-review Arac\u0131 Olu\u015fturma<\/h2>\n
pre-push<\/code> kancas\u0131n\u0131 kullanarak, kodunuzu g\u00f6ndermeden \u00f6nce belirli kontrolleri yapacak. Amac\u0131m\u0131z, karma\u015f\u0131k bir kurulum gerektirmeyen, anla\u015f\u0131l\u0131r ve \u00f6zelle\u015ftirilebilir bir \u00e7\u00f6z\u00fcm sunmak.<\/p>\n1. Ortam Haz\u0131rl\u0131\u011f\u0131 ve Git Kancalar\u0131<\/h3>\n
pre-push<\/code> kancas\u0131, git push<\/code> komutu \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, g\u00f6nderim ger\u00e7ekle\u015fmeden hemen \u00f6nce \u00e7al\u0131\u015f\u0131r. E\u011fer bu kanca bir hata koduyla \u00e7\u0131k\u0131\u015f yaparsa, g\u00f6nderim i\u015flemi iptal edilir.<\/p>\n.git\/hooks\/<\/code> dizinine bir betik yerle\u015ftirmeniz gerekir. Bu beti\u011fin \u00e7al\u0131\u015ft\u0131r\u0131labilir olmas\u0131 (executable) gerekir ve ad\u0131 pre-push<\/code> olmal\u0131d\u0131r. E\u011fer pre-push<\/code> ad\u0131nda bir dosya zaten varsa, onu yedeklemeniz veya i\u00e7eri\u011fini yeni beti\u011finize dahil etmeniz gerekebilir.<\/p>\n\n#!\/bin\/bash\n\necho \"Pre-push kancas\u0131 \u00e7al\u0131\u015f\u0131yor...\"\n\n# Buraya analiz beti\u011fimizin \u00e7a\u011fr\u0131s\u0131 gelecek\n# \u00d6rne\u011fin, Python beti\u011fimiz 'check_code.py' ise:\n# python .git\/hooks\/check_code.py\n\n# E\u011fer analiz beti\u011fimiz hata koduyla \u00e7\u0131karsa (exit 1), push'u engelle\nif [ $? -ne 0 ]; then\n echo \"Kod g\u00f6zden ge\u00e7irme ba\u015far\u0131s\u0131z oldu. Push iptal edildi.\"\n exit 1\nfi\n\necho \"Kod g\u00f6zden ge\u00e7irme ba\u015far\u0131l\u0131. Push devam ediyor.\"\nexit 0\n <\/code><\/pre>\n.git\/hooks\/pre-push<\/code> olarak kaydedip, chmod +x .git\/hooks\/pre-push<\/code> komutuyla \u00e7al\u0131\u015ft\u0131r\u0131labilir hale getirin.<\/p>\n2. Kod Analiz Beti\u011fi (\u00d6rnek: Python ile)<\/h3>\n
.git\/hooks\/check_code.py<\/code> ad\u0131nda bir dosya olu\u015ftural\u0131m:<\/p>\n\nimport subprocess\nimport sys\n\ndef get_diff_lines(commit_range):\n \"\"\"\n Belirtilen commit aral\u0131\u011f\u0131 i\u00e7in diff \u00e7\u0131kt\u0131s\u0131n\u0131 sat\u0131r sat\u0131r al\u0131r.\n \"\"\"\n try:\n # commit_range: HEAD~1..HEAD gibi bir ifade olabilir\n result = subprocess.run(['git', 'diff', commit_range, '--unified=0'], capture_output=True, text=True, check=True)\n return result.stdout.splitlines()\n except subprocess.CalledProcessError as e:\n print(f\"Git diff hatas\u0131: {e}\", file=sys.stderr)\n return None\n\ndef analyze_changes(diff_lines):\n \"\"\"\n Diff sat\u0131rlar\u0131n\u0131 analiz eder ve sorunlar\u0131 listeler.\n \"\"\"\n issues = []\n current_file = None\n in_added_section = False\n\n if diff_lines is None:\n return issues\n\n for line in diff_lines:\n if line.startswith(\"diff --git\"):\n current_file = line.split(\" \")[2][2:] # 'a\/' veya 'b\/' \u00f6n ekini kald\u0131r\n in_added_section = False # Yeni dosya ba\u015flad\u0131\u011f\u0131nda resetle\n elif line.startswith(\"---\") or line.startswith(\"+++\"):\n continue # Meta sat\u0131rlar\u0131 atla\n elif line.startswith(\"@@\"):\n # Bu sat\u0131r, sat\u0131r numaras\u0131 bilgisini i\u00e7erir, \u015fimdilik pas ge\u00e7iyoruz\n # Daha geli\u015fmi\u015f analiz i\u00e7in kullan\u0131labilir\n in_added_section = True\n elif in_added_section and line.startswith(\"+\") and not line.startswith(\"+++\"):\n # Sadece eklenen sat\u0131rlar\u0131 kontrol et (ilk karakter '+')\n # \"+++ \" ile ba\u015flayan sat\u0131rlar\u0131 (yeni dosya header'\u0131) atla\n if \"TODO:\" in line:\n issues.append(f\"'{current_file}' dosyas\u0131nda TODO bulundu: {line[1:]}\")\n if \"print(\" in line and \"DEBUG\" in line:\n issues.append(f\"'{current_file}' dosyas\u0131nda DEBUG print'i bulundu: {line[1:]}\")\n # Buraya ba\u015fka kontroller eklenebilir\n # \u00d6rne\u011fin:\n # if \"import os\" in line and current_file.endswith(\".py\"):\n # issues.append(f\"'{current_file}' dosyas\u0131nda 'os' mod\u00fcl\u00fc import edildi, dikkatli kullan\u0131n.\")\n\n return issues\n\nif __name__ == \"__main__\":\n # Son commit ile \u00f6nceki commit aras\u0131ndaki fark\u0131 al\u0131yoruz\n # Daha geli\u015fmi\u015f senaryolar i\u00e7in farkl\u0131 commit aral\u0131klar\u0131 kullan\u0131labilir\n commit_range = \"HEAD~1..HEAD\"\n diff_lines = get_diff_lines(commit_range)\n\n if diff_lines is None:\n sys.exit(1) # Git hatas\u0131 durumunda \u00e7\u0131k\u0131\u015f\n\n found_issues = analyze_changes(diff_lines)\n\n if found_issues:\n print(\"\\n--- Kod G\u00f6zden Ge\u00e7irme Uyar\u0131s\u0131 ---\", file=sys.stderr)\n for issue in found_issues:\n print(f\"- {issue}\", file=sys.stderr)\n print(\"------------------------------------\", file=sys.stderr)\n print(\"L\u00fctfen yukar\u0131daki sorunlar\u0131 giderin. Push i\u015flemi engellendi.\", file=sys.stderr)\n sys.exit(1) # Hata kodu ile \u00e7\u0131k\u0131\u015f yap, push'u engelle\n else:\n print(\"Kod g\u00f6zden ge\u00e7irme ba\u015far\u0131l\u0131. Herhangi bir sorun bulunamad\u0131.\", file=sys.stdout)\n sys.exit(0) # Ba\u015far\u0131l\u0131 \u00e7\u0131k\u0131\u015f, push'a izin ver\n <\/code><\/pre>\nchmod +x .git\/hooks\/check_code.py<\/code> ile \u00e7al\u0131\u015ft\u0131r\u0131labilir hale getirin. Ard\u0131ndan, .git\/hooks\/pre-push<\/code> beti\u011fini a\u015fa\u011f\u0131daki gibi g\u00fcncelleyin:<\/p>\n\n#!\/bin\/bash\n\necho \"Pre-push kancas\u0131 \u00e7al\u0131\u015f\u0131yor...\"\n\n# Python analiz beti\u011fini \u00e7al\u0131\u015ft\u0131r\npython .git\/hooks\/check_code.py\n\n# E\u011fer analiz beti\u011fi hata koduyla \u00e7\u0131karsa (exit 1), push'u engelle\nif [ $? -ne 0 ]; then\n echo \"Kod g\u00f6zden ge\u00e7irme ba\u015far\u0131s\u0131z oldu. Push iptal edildi.\"\n exit 1\nfi\n\necho \"Kod g\u00f6zden ge\u00e7irme ba\u015far\u0131l\u0131. Push devam ediyor.\"\nexit 0\n <\/code><\/pre>\ngit add .<\/code> ve git commit -m \"Test commit\"<\/code> komutlar\u0131yla kaydedip, ard\u0131ndan git push<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, e\u011fer kodunuzda “TODO:” veya “print(“DEBUG”)” gibi ifadeler varsa, push i\u015flemi engellenecektir.<\/p>\n3. Vaka Analizi: Bir “Arkada\u015f” Senaryosu<\/h3>\n
pre-push<\/code> kancas\u0131 kuruyor. Bu kanca, sadece eklenen sat\u0131rlarda “TODO:” veya “print(“DEBUG”)” gibi ifadeler varsa push’u engelliyor.<\/p>\nprint(\"DEBUG\")<\/code> ifadesi ekler. Sonra bu de\u011fi\u015fiklikleri kaydeder ve git push<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r. Tam bu s\u0131rada pre-push<\/code> kancas\u0131 devreye girer ve Ay\u015fe’ye \u015fu mesaj\u0131 g\u00f6sterir:<\/p>\n\nPre-push kancas\u0131 \u00e7al\u0131\u015f\u0131yor...\n\n--- Kod G\u00f6zden Ge\u00e7irme Uyar\u0131s\u0131 ---\n- 'algorithm.py' dosyas\u0131nda DEBUG print'i bulundu: print(\"DEBUG: Veri i\u015fleniyor.\")\n- 'algorithm.py' dosyas\u0131nda DEBUG print'i bulundu: print(\"DEBUG: Sonu\u00e7:\", result)\n------------------------------------\nL\u00fctfen yukar\u0131daki sorunlar\u0131 giderin. Push i\u015flemi engellendi.\n <\/code><\/pre>\nalgorithm.py<\/code> dosyas\u0131n\u0131 a\u00e7ar, ekledi\u011fi print(\"DEBUG\")<\/code> ifadelerini temizler ve de\u011fi\u015fiklikleri tekrar kaydeder. Bu sefer git push<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131nda, kanca herhangi bir sorun bulmaz ve push ba\u015far\u0131yla ger\u00e7ekle\u015fir. Bu basit senaryo, diff-review<\/code> arac\u0131n\u0131n nas\u0131l zaman kazand\u0131rabilece\u011fini ve hatalar\u0131 nas\u0131l erken yakalayabilece\u011fini g\u00f6stermektedir.<\/p>\npre-push<\/code> kancas\u0131n\u0131 kullan\u0131r. Can, bir \u00f6zelli\u011fi eklerken, bir fonksiyonun amac\u0131n\u0131 tam olarak not almam\u0131\u015f ve kodun i\u00e7ine # TODO: Bu fonksiyonun amac\u0131n\u0131 daha sonra netle\u015ftirece\u011fim.<\/code> \u015feklinde bir yorum b\u0131rakm\u0131\u015ft\u0131r. Can, de\u011fi\u015fikliklerini kaydeder ve git push<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r. Kanca devreye girer ve Can’a \u015fu uyar\u0131y\u0131 verir:<\/p>\n\nPre-push kancas\u0131 \u00e7al\u0131\u015f\u0131yor...\n\n--- Kod G\u00f6zden Ge\u00e7irme Uyar\u0131s\u0131 ---\n- 'feature.py' dosyas\u0131nda TODO bulundu: # TODO: Bu fonksiyonun amac\u0131n\u0131 daha sonra netle\u015ftirece\u011fim.\n------------------------------------\nL\u00fctfen yukar\u0131daki sorunlar\u0131 giderin. Push i\u015flemi engellendi.\n <\/code><\/pre>\nGeli\u015fmi\u015f Analizler ve \u00d6zelle\u015ftirmeler<\/h2>\n
1. Linter ve Bi\u00e7imlendirici Entegrasyonu<\/h3>\n
\n
flake8<\/code> veya pylint<\/code>, JavaScript i\u00e7in eslint<\/code> gibi ara\u00e7lar, kodunuzdaki stil sorunlar\u0131n\u0131, s\u00f6zdizimi hatalar\u0131n\u0131 ve mant\u0131ksal kusurlar\u0131 bulur. Bu ara\u00e7lar\u0131n \u00e7\u0131kt\u0131lar\u0131n\u0131 pre-push<\/code> kancan\u0131zla entegre edebilirsiniz. Beti\u011finiz, bu ara\u00e7lar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131p \u00e7\u0131kt\u0131s\u0131n\u0131 alacak ve hatalar\u0131 raporlayacakt\u0131r.<\/li>\nblack<\/code> (Python), prettier<\/code> (JavaScript, CSS vb.) gibi ara\u00e7lar, kodunuzu otomatik olarak belirli bir stil k\u0131lavuzuna g\u00f6re bi\u00e7imlendirir. E\u011fer amac\u0131n\u0131z sadece stil sorunlar\u0131n\u0131 tespit etmekse, bu ara\u00e7lar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131p de\u011fi\u015fiklikleri kontrol edebilirsiniz. E\u011fer amac\u0131n\u0131z otomatik d\u00fczeltme ise, bu ara\u00e7lar\u0131 pre-commit<\/code> kancas\u0131yla (commit \u00f6ncesi \u00e7al\u0131\u015fan) entegre etmek daha uygun olabilir, ancak pre-push<\/code> ile de sadece de\u011fi\u015fiklikleri kontrol edip kullan\u0131c\u0131n\u0131n d\u00fczeltmesini isteyebilirsiniz.<\/li>\n<\/ul>\nflake8<\/code>‘i kullanmak i\u00e7in check_code.py<\/code> beti\u011finizi \u015f\u00f6yle g\u00fcncelleyebilirsiniz:<\/p>\n\nimport subprocess\nimport sys\nimport re # Regular expression mod\u00fcl\u00fc\n\n# ... (get_diff_lines fonksiyonu ayn\u0131 kal\u0131r) ...\n\ndef analyze_changes(diff_lines, filename):\n \"\"\"\n Diff sat\u0131rlar\u0131n\u0131 analiz eder ve sorunlar\u0131 listeler.\n \"\"\"\n issues = []\n if diff_lines is None:\n return issues\n\n # Sadece de\u011fi\u015ftirilen sat\u0131rlar\u0131 alal\u0131m\n modified_lines = {} # {sat\u0131r_numaras\u0131: sat\u0131r_i\u00e7eri\u011fi}\n current_file = None\n current_line_num = 0\n in_added_section = False\n\n for line in diff_lines:\n if line.startswith(\"diff --git\"):\n current_file = line.split(\" \")[2][2:]\n in_added_section = False\n elif line.startswith(\"---\") or line.startswith(\"+++\"):\n continue\n elif line.startswith(\"@@\"):\n match = re.search(r'\\+(\\d+)', line)\n if match:\n current_line_num = int(match.group(1))\n in_added_section = True\n else:\n in_added_section = False\n elif in_added_section and line.startswith(\"+\") and not line.startswith(\"+++\"):\n # Sadece eklenen sat\u0131rlar\u0131 kontrol et\n if current_file == filename: # Sadece hedef dosyadaki de\u011fi\u015fiklikleri al\n modified_lines[current_line_num] = line[1:]\n current_line_num += 1\n\n # Flake8'i sadece de\u011fi\u015ftirilen dosyalar \u00fczerinde \u00e7al\u0131\u015ft\u0131r\n if modified_lines:\n try:\n # Flake8'i sadece ilgili sat\u0131rlara odaklanacak \u015fekilde \u00e7al\u0131\u015ft\u0131rmak karma\u015f\u0131k olabilir.\n # Basitlik i\u00e7in, t\u00fcm dosyay\u0131 analiz edip, \u00e7\u0131kt\u0131daki sat\u0131r numaralar\u0131n\u0131 kontrol edece\u011fiz.\n flake8_result = subprocess.run(['flake8', filename], capture_output=True, text=True, check=False)\n for flake_issue in flake8_result.stdout.splitlines():\n # \u00c7\u0131kt\u0131 format\u0131: dosya:sat\u0131r:s\u00fctun: kod mesaj\n match = re.match(r'([^:]+):(\\d+):(\\d+): (.*)', flake_issue)\n if match:\n issue_file, issue_line, issue_col, issue_code = match.groups()\n issue_line_num = int(issue_line)\n # E\u011fer bu sorun, de\u011fi\u015ftirilen sat\u0131rlardan birindeyse ekle\n if issue_line_num in modified_lines:\n issues.append(f\"'{issue_file}' dosyas\u0131nda Flake8 hatas\u0131 (Sat\u0131r {issue_line}): {issue_code}\")\n except FileNotFoundError:\n issues.append(\"Flake8 kurulu de\u011fil veya PATH'te bulunmuyor. L\u00fctfen kurun.\")\n except subprocess.CalledProcessError as e:\n issues.append(f\"Flake8 \u00e7al\u0131\u015ft\u0131r\u0131l\u0131rken hata olu\u015ftu: {e}\")\n\n # Eski kontrolleri de ekleyelim\n for line_num, line_content in modified_lines.items():\n if \"TODO:\" in line_content:\n issues.append(f\"'{filename}' dosyas\u0131nda TODO bulundu (Sat\u0131r {line_num}): {line_content}\")\n if \"print(\" in line_content and \"DEBUG\" in line_content:\n issues.append(f\"'{filename}' dosyas\u0131nda DEBUG print'i bulundu (Sat\u0131r {line_num}): {line_content}\")\n\n return issues\n\nif __name__ == \"__main__\":\n commit_range = \"HEAD~1..HEAD\"\n diff_lines = get_diff_lines(commit_range)\n\n if diff_lines is None:\n sys.exit(1)\n\n # De\u011fi\u015ftirilen dosyalar\u0131 bulal\u0131m\n changed_files_output = subprocess.run(['git', 'diff', '--name-only', commit_range], capture_output=True, text=True, check=True).stdout.splitlines()\n \n all_issues = []\n for file in changed_files_output:\n # Sadece Python dosyalar\u0131n\u0131 analiz et (\u00f6rnek olarak)\n if file.endswith(\".py\"):\n issues_in_file = analyze_changes(diff_lines, file)\n all_issues.extend(issues_in_file)\n\n if all_issues:\n print(\"\\n--- Kod G\u00f6zden Ge\u00e7irme Uyar\u0131s\u0131 ---\", file=sys.stderr)\n for issue in all_issues:\n print(f\"- {issue}\", file=sys.stderr)\n print(\"------------------------------------\", file=sys.stderr)\n print(\"L\u00fctfen yukar\u0131daki sorunlar\u0131 giderin. Push i\u015flemi engellendi.\", file=sys.stderr)\n sys.exit(1)\n else:\n print(\"Kod g\u00f6zden ge\u00e7irme ba\u015far\u0131l\u0131. Herhangi bir sorun bulunamad\u0131.\", file=sys.stdout)\n sys.exit(0)\n <\/code><\/pre>\nflake8<\/code>‘in de bu de\u011fi\u015ftirilen sat\u0131rlar i\u00e7in buldu\u011fu sorunlar\u0131 raporlar. Bu, analizlerin daha hedefe y\u00f6nelik olmas\u0131n\u0131 sa\u011flar.<\/p>\n2. G\u00fcvenlik Analizi<\/h3>\n
\n
bandit<\/code> (Python i\u00e7in) gibi ara\u00e7lar, yayg\u0131n g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 tespit etmek i\u00e7in \u00f6zel olarak tasarlanm\u0131\u015ft\u0131r. Bu t\u00fcr ara\u00e7lar\u0131 da pre-push<\/code> kancan\u0131za entegre edebilirsiniz.<\/li>\n<\/ul>\n3. \u00d6zel Kurallar ve Yap\u0131land\u0131rma<\/h3>\n
\n
.diffreviewrc<\/code> veya pyproject.toml<\/code> i\u00e7inde bir b\u00f6l\u00fcm) kullanabilirsiniz.<\/li>\n4. Vaka Analizi: Bir Ekip \u0130\u00e7in \u00d6zelle\u015ftirilmi\u015f Kurallar<\/h3>\n
flake8<\/code>, black<\/code> ve bandit<\/code> ara\u00e7lar\u0131n\u0131 standart olarak kullan\u0131yor. Mehmet, arac\u0131n\u0131 bu ara\u00e7larla entegre ediyor ve ayr\u0131ca ekibin kendi belirledi\u011fi baz\u0131 \u00f6zel kurallar\u0131 da ekliyor:<\/p>\n\n
TODO:<\/code> yorumlar\u0131 push’u engellemeyecek ama bir uyar\u0131 olarak g\u00f6sterilecek.<\/li>\nprint(\"DEBUG\")<\/code> ifadeleri ise push’u kesinlikle engelleyecek.<\/li>\n.env<\/code> dosyalar\u0131n\u0131n veya gizli anahtar kal\u0131plar\u0131n\u0131n koda eklenmesi push’u engelleyecek.<\/li>\nbandit<\/code>‘in buldu\u011fu y\u00fcksek ve orta seviye g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 da push’u engelleyecek \u015fekilde raporlayacak.<\/li>\n<\/ul>\n.diffreviewrc<\/code> dosyas\u0131 ile yap\u0131land\u0131r\u0131yor. Art\u0131k ekipteki her geli\u015ftirici, kodunu g\u00f6ndermeden \u00f6nce bu kurallara tabi tutuluyor. Bu sayede, ekip \u00fcyeleri daha temiz, daha g\u00fcvenli ve daha standart kodlar yaz\u0131yor. \u00d6rne\u011fin, bir geli\u015ftirici yanl\u0131\u015fl\u0131kla bir API anahtar\u0131n\u0131 koda yap\u0131\u015ft\u0131r\u0131p push yapmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, ara\u00e7 \u015fu \u015fekilde bir \u00e7\u0131kt\u0131 verebilir:<\/p>\n\nPre-push kancas\u0131 \u00e7al\u0131\u015f\u0131yor...\n\n--- Kod G\u00f6zden Ge\u00e7irme Uyar\u0131s\u0131 ---\n- 'config.py' dosyas\u0131nda gizli anahtar kal\u0131b\u0131 tespit edildi. L\u00fctfen hassas bilgileri koda eklemeyin.\n- 'utils.py' dosyas\u0131nda bandit taraf\u0131ndan orta seviye g\u00fcvenlik a\u00e7\u0131\u011f\u0131 tespit edildi (B305: urllib version check).\n------------------------------------\nL\u00fctfen yukar\u0131daki sorunlar\u0131 giderin. Push i\u015flemi engellendi.\n <\/code><\/pre>\nYerel G\u00f6zden Ge\u00e7irme Ara\u00e7lar\u0131n\u0131n Avantajlar\u0131 ve Dezavantajlar\u0131<\/h2>\n
Avantajlar\u0131<\/h3>\n
\n
Dezavantajlar\u0131<\/h3>\n
\n
Sonu\u00e7 ve Gelecek Ad\u0131mlar<\/h2>\n
\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n
\n
\n Cevap:<\/strong> Hay\u0131r, tam olarak yerini alamaz. Yerel ara\u00e7lar, kodunuzu g\u00f6ndermeden \u00f6nceki ilk kontrol katman\u0131d\u0131r. PR\/MR’lar ise ekip \u00fcyeleri aras\u0131ndaki i\u015fbirli\u011fi, bilgi payla\u015f\u0131m\u0131 ve daha kapsaml\u0131 geri bildirim i\u00e7in gereklidir. Yerel ara\u00e7lar, bu s\u00fcreci daha verimli hale getirir, ancak onun yerini tutmaz.\n <\/li>\n
\n
\n Cevap:<\/strong> Temel olarak herhangi bir programlama dili i\u00e7in olu\u015fturulabilir. Git’in diff \u00e7\u0131kt\u0131s\u0131n\u0131 analiz edebilen ve s\u00f6z konusu dilin statik analiz ara\u00e7lar\u0131na eri\u015febilen herhangi bir betik dili (Python, Node.js, Ruby, Bash vb.) kullan\u0131labilir.\n <\/li>\n
\n
\n Cevap:<\/strong> Basit bir ‘diff-review’ arac\u0131 kurmak olduk\u00e7a kolayd\u0131r. Genellikle sadece bir beti\u011fi Git deposunun .git\/hooks\/<\/code> dizinine kopyalamak ve \u00e7al\u0131\u015ft\u0131r\u0131labilir hale getirmek yeterlidir. Daha geli\u015fmi\u015f ara\u00e7lar i\u00e7in ek k\u00fct\u00fcphanelerin veya analiz ara\u00e7lar\u0131n\u0131n kurulumu gerekebilir.\n <\/li>\n
\n
\n Cevap:<\/strong> Genellikle stil hatalar\u0131 (kod format\u0131), basit s\u00f6zdizimi hatalar\u0131, kullan\u0131lmayan de\u011fi\u015fkenler, unutulmu\u015f hata ay\u0131klama \u00e7\u0131kt\u0131lar\u0131 (print, console.log), basit g\u00fcvenlik a\u00e7\u0131klar\u0131 (gizli anahtarlar vb.) ve kodunuzdaki \u00f6zel olarak belirledi\u011finiz di\u011fer kurallara uymayan durumlar\u0131 yakalayabilirsiniz.\n <\/li>\n<\/ul>\n