Merhaba ve hoş geldiniz.
Bu derste hata ayıklama hakkında konuşmak istiyorum.
Bu, özellikle anlamanız gereken çok önemli bir kavramdır, hataları bulmak ve düzeltmek için kullanabileceğiniz
bazı araçları ve bazı yöntemleri anlamanız gerekir.
Yani hata ayıklama, bir programdaki hataları bulma ve düzeltme sürecidir.
Genellikle mantık hataları.
Size mantık ve sözdizimi hataları arasındaki farkı anlatacağım, ancak derleyici sözdizimi hatalarını
da içerebilir.
Sözdizimi hataları için tüm süreç.
Hata ayıklama, derleyicinin size ne söylediğini anlamaktır.
Her zaman tespit edilen ilk sorunu çözmeye odaklanmak istersiniz.
Alabileceğiniz yaygın derleyici hatalarından ve uyarılarından bazılarını gözden geçirmek istiyorum, ancak
derleyici hakkında her zaman bilmek isteyeceğiniz şeylerden biri de derleyicinin size bir dizi hata
verebileceğidir.
Her zaman ilk hataya odaklanmak istersiniz çünkü bu ilk hata başka hatalara yol açabilir.
Bu nedenle, derleyicinin size söylediği bir programda beş hata görüyorsanız, yalnızca bir hatanız olabilir
ve bu ilk hata diğer hatalara neden olabilir.
Bu nedenle, her zaman en üstteki ilk hataya bakmak ve önce bunu düzeltmek önemlidir.
Bu çok basit örnekte, bu kodda birden fazla hatamız var.
Bizde yok.
Başlangıç sol parantezimiz, küme parantezimiz yok.
Noktalı virgülümüz yok.
Bir dize döndürüyoruz.
Bunu kaydettiğimizde ve derlemeye gittiğimizde aslında bazı kırmızı hatalar görüyorsunuz,
derlemeye gittiğimizde aslında bize üç hatamız olduğunu söylüyor.
Bu durumda gerçek bir hata olsa bile, asla sadece yedinci satırdaki son hatayı seçmek istemezsiniz.
Her zaman sadece ilk hatayı düzeltmek istersiniz.
Burada listelenen ilk hatayı görürsünüz ve bu ilk hatayı düzeltirsiniz ve ardından yeniden derleyip tekrar çalıştırırsınız.
Ancak bunu yapmanın nedeni yalnızca üst düzey hatayı düzeltmektir çünkü bu hata başka sorunlara neden
olabilir.
Bu nedenle her zaman ilk hatayı düzeltmeye odaklanın Hata ayıklama ve hataları bulma ve düzeltme süreci, basit
hataları bulmaktan analiz için büyük miktarda veri toplamaya kadar çok karmaşık olabilir.
Her şey değişir.
Bazen günlük kaydı dışında yanınızda herhangi bir bilgi bulunmaz ve bu durumda bazı şeyleri analiz
etmeniz gerekir.
Bazen tekrarlanamayan hatalarınız olabilir.
Bunu yeniden üretemezsiniz çünkü bu çok nadir bir durumdur.
Bu genellikle günlükleri analiz etmeniz veya bunun bir çeşidini yapmanız gereken zamandır.
Bir programcı tarafından hata ayıklama yeteneği önemli bir beceridir.
Bu gerçekten de size muazzam miktarda zaman ve para kazandırabilecek bir sorun çözme becerisidir.
Bu yüzden öğrenilmesi gereken önemli bir beceridir.
Bu, geliştirilmesi gereken önemli bir beceridir.
Bu pratik gerektirir.
Bu sadece sizin ayağınıza gelmeyecek.
Hata ayıklama konusunda daha iyi olmanızı sağlamak için uygulayabileceğiniz belirli teknikler ve
yöntemler vardır.
Kod yazma konusunda gerçekten iyi olan çok az sayıda yazılımcı tanıyorum.
Dili çok iyi anlıyorlar, ancak hata ayıklama becerileri çok zayıf.
Bir hata bulabilirler ve bu hatayı çözmeye yönelik ilk eğilimleri gerçekten yoldan çıkmış olabilir.
Ve yine, bu pratikle gelir.
Hata ayıklama ve sorunları nasıl bulup çözeceğinizi anlama konusunda gittikçe daha iyi olacaksınız,
ancak bu sizin de öğrenmeniz gereken bir şey.
Bakım aşaması, yazılım yaşam döngüsünün en pahalı aşamasıdır.
Bakım aşaması, ürününüzü piyasaya sürdükten sonra gerçekleşir ve artık onu korumak zorundasınızdır.
Bakımı, ortaya çıkan yeni hataları düzeltmek ve yeni özellikler eklemek anlamına gelir.
Örneğin Windows, Windows 10 gibi yeni bir işletim sistemi yayınladığında, bu yazılımı üretmeyi
bitirmiş olmuyor.
Muhtemelen on yıl boyunca sahada olacak.
Ve yeni hatalar ortaya çıktığında ya da bu yazılım için yeni hatalar bulduklarında bunları düzeltmek hala Microsoft'un sorumluluğundadır.
İşte bu yüzden otomatik güncellemeler yayınlıyorlar ve bunun gibi şeyler yapıyorlar.
Ayrıca, pazar değiştikçe ve teknoloji geliştikçe işletim sisteminin de yeni özellikler sunacağını
fark edeceklerdir.
Bu yüzden bakım çok önemlidir.
Sonuç olarak, hatalarınızı bulmak ve düzeltmek çok önemlidir.
Yine de hataların kaçınılmaz olduğunu anlayın.
Tüm yazılımlarda hatalar vardır.
Kimse mükemmel kod yazamaz ve hatta mesele mükemmel kod yazmak da değildir.
Zamanla bazı şeyler değişiyor.
Bu da hatalara yol açabilir.
Bir yazılımda hata olmasının, onun kötü yazılmış bir kod olduğu anlamına gelmediğini anlamalısınız.
Bu kaçınılmaz bir şey.
Bu yüzden hataların olması sorun değil, onları bulup düzelttiğinizde daha da güzel oluyor çünkü gerçekten bir şeyler
başardığınızı hissediyorsunuz.
Yaygın sorunlar.
Ve daha çok görmeyle ilgili belirli sorunlar hakkında konuşacağız.
Ancak hata ayıklamaya çalışırken sık karşılaşılan sorunlar mantık hatalarıdır.
Mantık hataları, kodunuzun gerçekte derlediği sözdizimi hatalarının tersi ile ilgili değildir.
İşe yarıyor ama yapması gereken şeyi yapmıyor.
Yani yanlış olan bir tür mantık veya amaçlanan işlevsellik var.
Belki bir IF deyiminiz vardır ve bu if deyimine yanlış koşulda atlıyorsunuzdur.
Belki bir döngünüz vardır ve döngü doğru sayıda yürütülmüyordur ya da doğru sıralama yapmıyorsunuzdur.
İşlevsellik bozuk, ancak derleyici diyor ki, Hey, her şey iyi görünüyor.
İşte bir mantık hatası örneği.
Mantık hatası, sözdiziminin doğru olduğu, ancak bir tür mantık sorunu nedeniyle istenen sonuçların doğru olmadığı
durumdur.
Bu kodda, for döngüsünün sonunda sözdizimsel olarak doğru olan bir noktalı virgül olduğunu görüyorsunuz.
Ancak bu for döngüsünün beş kez çalışmasını bekliyorsunuz.
Ama öyle değil.
Sadece bir kez yayınlanacak.
Eğer build dersek ve bu projeyi build edersek, bir uyarı görürüz ki bu güzel bir şeydir ve her zaman tüm uyarılarınızı düzeltmelisiniz.
Ancak başarılı bir şekilde derlendi.
Bu projeyi çalıştırdığımızda, aslında sadece bir kez çalıştığını ve Hello World'ü bir kez yazdırdığını
fark edeceksiniz.
Yani bu bir mantık hatası örneğidir.
Sözdizimi hataları doğrudan derleyici ile ilgilidir.
Bunlar dilin kurallarına uymayan şeylerdir.
Bir ifadenin sonunda noktalı virgül yok.
Senin bir sonun yok, değil mi?
Parantezler sola, parantezler sağa.
Bir parantez eksik.
Doğru anahtar kelimeyi kullanmıyorsunuz, bunun gibi şeyler.
Sözdizimi hataları genellikle derleyiciden kaynaklanır Mantık Hataları test aşamasında programcıdan
kaynaklanacaktır.
Bellek bozulması da özellikle C'de yaygın bir sorundur.
Belleğinizi doğru şekilde ayırdıktan sonra serbest bırakmıyorsanız, sarkan
referanslar gibi şeylere sahip olabilirsiniz ve ayrıca kullanılmayan bellekle ilgili bellek sorunları yaşayabilirsiniz.
Bellek sızıntıları olabilir.
İşte bir bellek hatası örneği.
Bu özel kodda, aslında bir bellek sızıntımız var, bu yüzden henüz işaretçilerden bahsetmedik.
Dinamik bellek tahsisi hakkında konuşmadık.
Ancak C'de programınız çalışırken bellek ayırabilirsiniz.
Bir malloc işlevi kullanabilirsiniz.
Ve burada işaretleme yapıyoruz, bellek ayırıyoruz ama asla boşaltmıyoruz.
Yani bu kodu oluşturabiliriz, çalıştırabiliriz ve her şey yolunda gider, ancak aslında bu hatadan kurtulmuş
olmayız.
Dolayısıyla, bu bellek hatasını düzeltmek için yapmamız gereken şey free dememiz ve ardından bu işaretçiyi serbest
bırakmak için free ve X dememiz gerekir.
Ancak ne zaman bellek ayırsanız, onu boşaltmazsınız.
Bu bir bellek sızıntısı.
Bir başka örnek de, belleği ayırmazsak, bir işaretçi oluşturup sonra da onu atamaya çalışırsak,
bellek bozulması yaşayacağız çünkü o bellek için herhangi bir ayırma yapılmamış ve biz
ona bir değer atamaya çalışıyoruz.
Bu, bellek, bozulma, performans ve ölçeklenebilirlik için bazı örneklerin küçük bir parçasıdır.
Bu, işlevselliğinizin olduğu gibi tasarlandığı ve kodunuzun sözdizimsel olarak doğru olduğu, ancak çok verimli
olmadığı veya onu destekleyecek donanıma sahip olmadığınız bir sorun olabilir.
Yani bir sunucu çalıştırıyorsanız ve tüm istekleri desteklemek için yeterli donanımınız yoksa, gerçekten
çok yavaş çalışacaktır.
Ya da programınızı on kullanıcıyla çalışacak şekilde yazdıysanız, ancak çok sayıda kullanıcı olduğunda, veritabanı
tıkandığından veya durum ne olursa olsun, belki de o kadar hızlı değildir.
Kod çalışıyor, ancak çok fazla sayıda kullanıcıyı veya durum her neyse onu idare etmek için doğru şekilde tasarlanmamış.
Uyum eksikliği.
Bu, kodunuzda kaliteyi düşüren bir sorun olabilir; kodunuz çok fazla şey yapıyor veya bir işlev çok fazla
şey yapıyor olabilir.
Tek bir odak noktası değil, hatta bir uygulama çok fazla işlevselliğe sahip, hiç kullanılmayan
özelliklere sahip ve bu nedenle muhtemelen yeniden tasarlanması gerekecek.
İşte modülerleştirilmemiş, uyumlu olmayan bir program örneği.
Çok fazla şey yapan büyük bir fonksiyonunuz var, yüzlerce satır kod, binlerce satır
kod.
Bir işlevi yardımcı işlevlere, ayrı modüllere ayırmak istersiniz.
Bu, programınızı çok daha uyumlu ve bakımı daha kolay hale getirir.
Böylece, giriş okuma, bazı bulma, fark bulma, çarpım bulma, bölüm bulma gibi başlatma işlemlerini yapan
büyük bir ana metoda sahip olmak yerine, tüm bu kodu oluşturabilir ve yardımcı modüllere koyabilir ve kodu
ayırabilirsiniz ve böylece ayırma, hatalarınızı çok daha kolay bulmanıza ve düzeltmenize yardımcı olabilir.
Bağdaşıklık C'de her zaman önemlidir ve genellikle yüksek bağdaşıklığa sahip olduğunuz yerlerde yardımcı yöntemler sağlayarak
çözülür.
Sıkı bağlantı.
Bu aynı zamanda kod kalitesiyle de ilgilidir.
Burada çok fazla bağımlılığınız var.
Bağlantı, uyumdan farklıdır.
Uyum sizin tek odak noktanızdır.
Bağlama, belki işlevler arasında veya nesneler arasında bağımlılıkların olduğu durumdur.
Bağlama hakkında konuştuk, global değişkenler hakkında konuştuk.
Eğer global bir değişken birçok farklı fonksiyonda kullanılıyorsa, bu fonksiyonlar arasında bağımlılıklara
neden olabilir.
Dolayısıyla, kod yazarken ve yüksek kaliteli kod yazarken çabalamak istediğiniz şey, çok
yüksek uyum ve çok düşük bağlantıya sahip olmak istemenizdir.
Hata ayıklama süreci.
Herhangi bir hatayı bulmadan ve düzeltmeden önce yapmanız gereken ilk şey, sorunu
anlamaktır.
Bu, sadece dalıp koda bakmaya başlamayın, test uzmanıyla oturun, gereksinimleri anlayın, neler olup
bittiğini anlayın ile ilişkilendirilebilir.
Çünkü neler olup bittiğini anlamazsanız, anlamanız da mümkün olmayacaktır.
Bunu çözmeye çalışmamalısınız bile.
Hatayı anladıktan sonra yeniden üretmeye çalışın çünkü hatayı yeniden üretmek daha fazla bilgi toplamanıza yardımcı
olabilir.
Hataları yeniden üretmek her zaman mümkün değildir, çünkü gerçekten nadir durumlarda ortaya çıkabilirler.
Örneğin, yarış koşulları veya hatta bellek bozulması gibi hatalar yalnızca çok özel kullanım durumlarında
ortaya çıkabilir ve bunlar aralıklı sorunlar olabilir.
Peki durum bu mu?
Ve bunu yeniden üretemezsiniz.
Hata ayıklamak gittikçe zorlaşacak.
Sorunu yeniden üretebilirseniz, genellikle düzeltmek için yeterli bilgi toplayabilirsiniz.
Çoğu sorun çözülebilir.
Ayrıca, çok iş parçacıklı bir ortam, paralel işlemler veya iş parçacığı sorunları varsa, bir sorunu yeniden
üretememe konusunda sorun yaşayabilirsiniz.
Bunların hata ayıklaması da çok zordur, ancak sorunun gerçekte ne olduğunu anladıktan
sonra kesinlikle yeniden üretmeye çalışın, bir kez yeniden üretebildiğinizi anlayabiliyorsanız,
o zaman bir tür böl ve fethet yaklaşımı uygulamak istersiniz.
Hatayı izole etmeye, sorunu basitleştirmeye çalışmak istersiniz, çünkü azaltabilmek size geri bilgi
verecektir, ancak hatanın kodun hangi bölümünde olduğunu söylemeyebilir.
Bu nedenle, sorunu basitleştirmeye çalışmak için yapabileceğiniz şey, orijinal test senaryosunun bazı kısımlarını kaldırmaktır, böylece çok
fazla test yapmamış olursunuz.
"Ah, bu sadece bu özel durumda oluyor" diyerek sorunu daha da küçük boyutlara indirgeyebilirsiniz.
Kodu yorumlayarak da çıkarabilirsiniz.
Fonksiyonların sadece taslaklara sahip olduğundan ve uygulamaya sahip olmadığından bahsetmiştik.
Bazen bu, sorun kümesini sınırlayabilmek için testlerde kullanılır.
Ayrıca, kodu yorumlarsanız, hatanın gerçekten meydana gelebileceği daha az kodunuz olacaktır.
Dolayısıyla, kodu yorumlarken veya değişiklikleri geri alırken, hata ortadan kalkabilir ve hata ortadan kalkarsa, bu
size yorumladığınız kodun buna neden olmuş olabileceğini söyler.
Esasen yapmak istediğiniz şey, büyük bir programı test ederek ya da yorumlayarak çok sayıda küçük
programa dönüştürmektir.
Bir başka yaygın teknik de kodunuzun etrafında birim testleri bulundurmaktır.
Bir birim testi başarısız olursa, bu size kodunuzdaki mantığın veya sorunun tam olarak nerede olabileceğini söyleyebilir.
Hatayı izole ettiğinizde, bu size koddaki sorunun kaynağını, soruna neden olan belirli kodu bulmanıza
yardımcı olacaktır.
Bazen bu, hata ayıklayıcı gibi hata ayıklama araçlarının kullanılmasını gerektirir.
Özel olarak bir hata ayıklayıcıdan bahsedeceğiz, ancak genellikle kullandığınız entegre geliştirme IDE'sine bağlı
olarak, IDE ile birlikte gelen hata ayıklayıcılar vardır.
Bağımsız olarak inebilen hata ayıklayıcılar da vardır.
C programlama için kullanacağımız en önemli hata ayıklayıcının adı GDB'dir.
Bu GNU hata ayıklayıcısıdır, bu yüzden aslında programınızın yürütülmesini durdurabileceğiniz ve kesme noktaları
ekleyebileceğiniz grafiksel bir araç olan güzel bir araçtır.
Ve sonra yürütmeyi durdurduğunuzda, kodunuzda satır satır ilerleyebilir ve değişkenlerin değerine bakabilirsiniz.
Böylece kodunuz çalışırken tam olarak neler olup bittiğini görebilirsiniz.
Paha biçilmez bir araç.
Sadece çok kullanışlı.
Hata ayıklayıcıyı çalıştıracağız.
Size kesme noktalarını nasıl ekleyeceğinizi göstereceğim.
Değişkenlere değiştikçe bakabilmeniz için nasıl bir saat kuracağınızı göstereceğim ve ardından kodu adım adım inceleyeceğim.
Sorunun kaynağını tespit ettikten sonra, sorunu çözmeniz gerekir.
Bu çok fazla deneyim ve pratik gerektirir.
Sorunun kaynağını bulmuş olsanız bile, sadece deneyiminize dayanarak sorunu
çözemeyebilirsiniz.
Bu bazen, özellikle ölçeklenebilirlik sorunları veya performans sorunları olan diğer kodların yeniden tasarlanmasını veya yeniden
düzenlenmesini içerir, yazılımınızın daha ölçeklenebilir olmasını sağlamak için yeniden tasarlamanız gerekebilir.
Yani sorunu bulup düzeltmek her zaman kolay değildir.
Bazen sorun, özellikle de iş parçacığı veya paralel işleme gibi daha da zor sorunların
düzeltilmesi daha da zordur.
Ancak daha fazla kod yazdıkça, bunu yapmak daha kolay hale gelecektir.
Ve son olarak, deli gibi test yapmalısınız.
Her zaman birçok farklı sınırı test edin.
Sorunu gerçekten çözdüğünüzü doğrulamak için iyi vakalar, kötü vakalar.
Mevcut teknik ve araçlardan bazıları.
Yaygın ve çok kullanılan bir araç print deyimlerini kullanmaktır.
Kodunuzu temel olarak izlemek için print deyimlerini kullanabilirsiniz.
Yani C'de print F deyimini kullanabilir ve nerede olduğunuzu belirtmek için kodunuzda birden fazla satıra
koyabilirsiniz.
Bu, programınız çöktüğünde de çok yararlıdır.
Nerede çöktüğünü belirlemeye yardımcı olabilir.
Kodunuzu takip eden bu yazdırma ifadelerini eklerken, değişkenlerin değerini görmek için yazdırma
ifadelerine çıktı ekleyebilirsiniz çünkü değişkenlerin değeri durumu etkiliyor olabilir ve mantık
sorunlarına neden olabilir.
Bu yüzden sadece print deyimleri eklemek çok ama çok faydalıdır.
Yürütme akışını gösterebilir ve hatayı izole etmeye yardımcı olabilir.
GDB'de bahsettiğim gibi hata ayıklayıcılar, bunlar programın yürütülmesini izleyebilir.
Durdurabilir, satır satır çalıştırabilir, yeniden başlatabilir, kesme noktaları ayarlayabilir, değişkenleri ve belleği izleyebilirsiniz.
Bir sorunun nerede olduğunu teşhis etmeye çalışırken çok ama çok yardımcı oluyor.
Günlük dosyaları.
Günlük dosyaları da özellikle yeniden oluşturulamayan hatalar için çok kullanışlıdır.
Hata oluştuğunda tam olarak neler olduğunu görmek için bunları daha sonraki bir tarihte analiz edebilirsiniz.
Yani bu, bunun yararlı olabilmesi için kodunuzda iyi günlük ifadeleri sağlamanız gerektiği
anlamına gelir.
Böylece kendi günlük dosyanızı oluşturabilir ve program çalışırken bu günlüğe yazabilirsiniz, böylece bir hata alırsanız
bu günlükleri geliştiricilere gönderebilirsiniz.
Xerox'ta bunu oldukça sık kullanıyoruz çünkü sorunlarla karşılaştığımızda bunları her zaman yeniden üretemiyoruz
veya sahada karşılaşabiliyoruz.
Bu hata meydana geldiğinde neler olduğunu görmek için bu günlüklere erişebilmemiz gerekir.
İzleme yazılımı.
Bellek kullanımı, ağ trafiği tehdidi ve nesne bilgilerini izleyebilen ve çalışma zamanı analizi yapabilen
yazılımlar vardır.
Bu size çok fazla bellek ayırıp silmediğinizi söyleyebilir.
Bellek kullanımı ağ trafiği için bir aracınız varsa, çok fazla paket gönderip göndermediğinizi
veya yazılımınızın ölçeklenebilir olup olmadığını size söyleyebilir, ağ trafiğinizde bir
artış varsa ve yanıt sürenizin azaldığını görürseniz.
Ayrıca, belirli iş parçacıklarında neler olup bittiğini ve başka bir iş parçacığında neler olup bittiğini görmek için paralel işleme için iş
parçacıklarını ve nesne bilgilerini izleyebilirsiniz.
Bu, her türlü iplik sorununu teşhis etmenize yardımcı olacaktır.
Hatalarınızı bulmak ve düzeltmek için kullanabileceğiniz diğer bazı yaygın hata ayıklama araçları.
İstisna işlemeyi kullanabilirsiniz.
Birçok programlama dilinde istisna işleme vardır.
Ne yazık ki, C'de bir istisna işleyici aslında çökmeleri önleyecek ve çalışma zamanında birçok şey
yapacaktır.
Görmek için geçerli değil, ama yine de anlamak için iyi bir şey.
Trycatch blokları, bunun gibi şeyler.
Statik analizörler.
C statik analizörleri için birçok statik analizör mevcuttur.
Gerçek çalıştırılabilir dosya olmadan kaynak kodunu analiz edin.
Programın çalıştırılmasına gerek yoktur.
Satır satır gider ve kaynak koduna bakar.
Ve kaynak kodu ayrıştırırken, bilinen herhangi bir sorun olup olmadığına bakar.
Böylece semantiği kontrol edebilir.
Şundan emin olabilirsiniz.
Bu kadar.
Eğer yeni bir bellek ayırıyorsanız ve onu siliyorsanız, başlatılmamış değişkeniniz olmaz.
Kodun gerçekte yürütülmediği herhangi bir ölü kodunuz varsa, bu kodu silebilirsiniz.
Ayrıca yarış koşulları ve kilitlenmeler gibi şeyleri de analiz eder.
Çalıştığım yerde birkaç statik analizci kullanıyoruz.
Oldukça popüler olan Coverity adında bir aracımız var ve bizim de kullandığımız bir kod sonar aracı var ve bunu tüm taban
çizgimiz, tüm kaynak setimiz üzerinde çalıştıracağız.
Yeni dosyalar ve yeni kodlar eklediğimizde, bu araç bu kod üzerinde çalıştırılacak ve başlatılmamış değişkenler,
bellek sızıntıları vb. gibi kodla ilgili sorunları anında tespit edebilecektir.
Sözdizimini analiz etmez.
Derleyici bunun için vardır.
Ayrıca, yazılımınız üzerinde çalıştırabileceğiniz bir dizi kapsamlı sistem uçtan uca testleri çalıştıran
bir dizi test paketi de vardır.
Test her zaman önemlidir, ancak örneğin her yeni derleme yaptığınızda belirli testleri çalıştırmak için bunu bir şekilde
otomatikleştirebilirseniz, bu çok yararlı olabilir ve bu aslında hataları önleyebilir, ancak aynı zamanda
hataları teşhis etmeye de yardımcı olur.
Program çöktükten sonra hata ayıklama.
Çağrı yığını adı verilen bir şeyden bahsedeceğiz.
Bu, özellikle C gibi bir dilde, bir çökme yaşadığınızda ve elde ettiğiniz tek bilginin segmentasyon hatası gibi bir şey
olduğu durumlarda görmek için çok yararlı bir mekanizmadır.
Bu çökmeyi yaşadığınızda, nasıl çöktüğüne bağlı olarak çoğu zaman olan şey, bir çekirdek dosyası oluşturulur
ve programın tam olarak nerede öldüğünü görmek için çağrı yığınına bakmak için çekirdek dosyasını analiz edebilirsiniz.
Programın öldüğü kod satırını size söyleyecektir.
Bu yüzden çağrı yığını hakkında bilgi edineceğiz.
Çekirdek dosyaları analiz etmeye gelince, bu daha ileri bir tekniktir.
Ancak C'de bir çekirdek dosyası oluşturulabilir ve bunu analiz edebilirsiniz.
Bu biraz daha gelişmiş bir tekniktir, ancak yazılımınızda hata ayıklama yapmanın başka bir yoludur.
Peki ya hataları önlemeye ne dersiniz?
Hata ayıklamanın hataları bulmak ve düzeltmek olduğunu biliyoruz, ancak hataları önleyebilirseniz, bu daha da iyidir.
Hataları önlemenin yollarından biri de yüksek kalitede kod yazmaktır.
Bu, pek çok yazılım mühendisinin odaklandığı bir konu değildir.
Pek çok yazılım mühendisi kodu yazar ve çalıştığı sürece tek ilgilendikleri
şey budur ya da çıktı doğru olduğu sürece işlerinin bittiğini düşünürler.
Ancak kalitesiz kod diye bir şey vardır ve bunu yazmak istemezsiniz.
Bunların bir kısmını derslerde gösterdim, ancak anlamlı değişken adları kullanmak gibi şeyler
çok önemlidir.
Ya da döngüleri gereğinden fazla kullandığınız verimsiz bir kod yazıyorsanız veya bir if deyimi kullanıyorsanız
ya da bunu yapmanız gerekmiyorsa.
Bu tür şeylerin tümü düşük kaliteli kod oluşturur.
Eğer 100 farklı şey yapan bir fonksiyonunuz varsa ve birbiriyle uyumlu değilse, bir fonksiyonda
5000 satır varsa, kodunuz modüler bir şekilde organize edilmemişse veya fonksiyonlar
arasında çok fazla bağımlılık varsa, tüm bunlar kalitesiz koddur ve bunu yapmamak için çaba göstermelisiniz.
Programınızın organize edildiği teknikleri kullanmak istersiniz.
Bakımı kolaydır, son derece uyumludur, düşük bağlantıya sahiptir ve anlamlı değişken adları kullanırsınız.
Çok, çok önemli.
Yine bu da çok önemli çünkü bakım aşaması çok ama çok pahalı.
Kalitesiz kod yazarsanız, bakımını yapmak çok daha zor hale gelir.
Hataları izole etmek ve yeni özellikler eklemek daha zordur.
Bu yüzden kodunuzu yazarken iyi ve yüksek kaliteli teknikler kullanın.
Birim testleri.
Birim testleri hataları önlemeye büyük ölçüde yardımcı olur.
Birim testleri derlendiğinde genellikle otomatik olarak çalıştırılır ve regresyonu önlemeye yardımcı olabilir.
Bu en önemli faktörlerden biridir.
Regresyon, yeni kod yazdığınızda ve daha önce çalışan bir şeye bir hata eklediğinizde ortaya çıkar.
Eski kodu kırdın.
Bunu yapmak istemezsin.
Bir yazılım çalışıyorsa ve daha sonra yaptığınız yeni bir şey onu bozduysa, hemen haberdar olmak istersiniz
ve birim testleri bunu yapmaya yardımcı olabilir çünkü birim testleri o eski kod üzerinde çalışacak ve Hey, bu çalışıyordu,
şimdi başarısız oluyor diyecektir.
Ayrıca, yeni koddaki hataları teslim edilmeden önce bulabilir, çünkü yine, derledikten sonra çalışırlar ve size hemen
bir şeylerin yanlış olduğunu söyleyecektir.
Gerçekten çok popüler hale gelen test güdümlü geliştirme diye bir kavram var.
Bu, önce testlerinizi yazdığınız ve ardından kodunuzu geliştirdiğiniz yerdir.
Buradaki amaç, ilk testinizi yazdığınızda testinizin başarısız olması ve ardından geçmesini sağlayacak
kodu yazmanızdır.
TDD'nin pek çok avantajı var ve bu bir tür tersine düşünme biçimi.
Normalde insanlar kod yazarken önce kodu yazarlar ve ardından testi yazarlar.
Ancak TDD ile aslında size farklı bir düşünme şekli sunar, böylece gerçekten küçük parçalar halinde çalışırsınız
ve çok uyumlu kod yazma eğiliminde olursunuz ve kodunuz yoktur, çok fazla bağımlılığınız yoktur
çünkü tahmin edin ne olur?
Kodu test edebiliyorsanız, kodun çok fazla bağımlılığı olmadığı anlamına gelir.
Birim testiniz gerçekten çok büyükse ve tüm bu farklı şeyleri taklit ediyorsanız, bu genellikle
kodunuzun başka şeylere çok ama çok bağımlı olduğunun büyük bir göstergesidir.
TDD'yi kullanarak, sizi bağımlılıkları olmayan çok gevşek bir şekilde bağlanmış kod yazmaya zorlar ve
işlevlerinizin çok tutarlı olmasını sağlar.
TDD'nin pek çok avantajı vardır.
Ayrıca iyi bir dokümantasyon sağlamak ve uygun bir planlama yapmak istersiniz.
Sadece koda dalmayın ve uygulamaya başlayın.
Tasarımınızı kağıda yazın.
Sözde kod kullanın.
Doğru.
Kodunuzu planlayın.
Kodunuzu planlarsanız, gereksinimleri anlarsanız ve iyi düşünülmüş bir tasarıma sahip olursanız,
birçok hatayı önleyebilirsiniz.
Kurs boyunca bundan bahsettim, ancak böl ve yönet tipi bir yaklaşıma sahip olmak,
küçük adımlarla çalışmak ve her adımdan sonra sürekli test etmek, 1000 satır kod yazıp sonra tamam, derle
ve test et dememek çok ama çok önemlidir.
Bu iyi bir yaklaşım değil.
Aynı anda çok fazla değişiklik yapmaktan kaçının.
Değişiklikler yaparken, bunları aşamalı olarak uygulayın, bir değişiklik ekleyin, ardından bir sonraki adıma başlamadan
önce iyice test edin.
Bu, her türlü hatayı azaltmaya yardımcı olabilir ve ayrıca sorun setinizi sınırlar.
Yani bir hata varsa, kodun neresinde olduğunu hemen bilirsiniz çünkü az önce derlediniz
ve o satırı veya satır sayısını eklediniz.
Yüksek kalitede kod yazarak hata ayıklamanın, hataları önlemenin önemini bir kez daha vurgulamadan edemeyeceğim.
Bu problem çözme teknikleri size tonlarca zaman kazandıracak ve sizi çok daha iyi bir üst düzey programcı
yapacaktır.
Bu yüzden önümüzdeki birkaç derste, c programlama dilinde gördüğümüz bazı yaygın hatalardan bahsetmek
istiyorum.
Ayrıca, çağrı yığını hakkında da biraz konuşmak istiyorum.
Size menü seçeneklerini ve saatleri nasıl durdurup çalıştırabileceğinizi tanıtan hata ayıklayıcıdan
geçmek istiyorum.
Ayrıca, derleyicileri, derleyici uyarılarını ve hatalarını nasıl yorumlayacağınızı görmeniz için bazı yaygın derleyici hatalarını tanımlamanıza yardımcı
olmak istiyorum.
Derleyicinin bunu söylemesi ne anlama geliyor?
Derleyicinin size bu uyarıyı vermesi ne anlama geliyor?
Teşekkür ederim.