ayrıca hiçbir bilgisayar mühendisi direkt olarak stabilizasyonuyla ilgilenmez. kodlarını okur. kod okumadan stabilizasyon testi yapan torpille mezun olmuştur.
satır satır kodların işleyişini, kullanılan kütüphaneleri ve başka alternatifleri varken hatta kendi yazma imkanları varken neden o kütüphaneleri kullandıklarını analiz edersin. sonra sıra gelir stabil mi değil mi tartışmalarına.
bakarsın kodlarda performans düşürücü bir şey var mı. bakarsın kodlar nasıl yazılmış. gereksiz kod kullanımı var mı. debug loglarına bakarsın. o debug loglarından 10 tane kitap çıkar basılsalar. ama okumak mecburiyetindesin. mühendissin. format atmakla olmuyor. her debug logu ayrı bir hata barındırmaktadır. ve bu hatalar aynı zamanda stabil olma konusuyla direkt alakalıdır. unittest dediğimiz olaya ve o testlerin olaylarına dalmadım bile. bu dediklerim unittest olmadan yapılacaklardı.
ayrıca okunacak kodlardansa 2 cilt meydan larousse çıkar. sırf bu yüzden kod okumaktan vazgeçiyorsa gitsin tekstil atölyesi açsın.
zorunlu ekleme://
adam log okumanın bir makine ile yapıldığını düşünmüş. log okuma dediğimiz şey debug etme olayından sonra ortaya cikan datalarin birikimi ve sonra degerlendirilmesidir. aslinda test muhendisleri bu alanda calismalidirlar. teknik detaydan sonra muhendise bildirmelidir. muhendisin anlayacagi sekilde yaparsin bunu. neyse debug edersin ve logları da bilgisayara ya da private ip'deki bir svn'e kaydedersin.
compiler ve ona has debuggerlar vardır. kimisi emacs, kimisi vim, kimisi de nano kullanır ve bunlara gelişkin plug-inler eklerler. bunlardan birisi de debug etme ve debug resultları svn'e pull etme özelliği barındıran eklentilerdir.
log okumak sandığınız kadar zor şey değil. sadece neyi okuyacağını bilecek bilginin olması gerekir.
türkiyede bu yok. üniversitelerde pascal denilen dil öğretiliyor tabii ki olmaz. bilgisayar mühendisi hocana sen ders verirsen tabii ki olmaz.
son olarak unix kodlanırken debug log okuyan makine mi vardı?
