Dec 282012
 

Kısa bir hikaye bu. Mutlu sonla da bitmiyor. Belki limoni, ekşi bir son diyebiliriz.

Hikayemizin kahramanı Yaşar PHP ile yazılmış bir kodun, yapması gereken işi neden tam olarak yapmadığını anlamaya çalışmaktadır. Kapkaranlık terminal penceresinden akıp giden logları satır satır okumakta, her log satırını kod ile karşılaştırıp, programın akışını takip etmektedir. Yaptığı her testte, çalışması gereken kod satırı bir türlü çalışmamakta, PHP inatla o kod satırını es geçmektedir.

Söz konusu kod şuna benziyordu:

....
....
....
// 3. Parti API'den gelen cevabı loga yaz
// 3. Parti API'den gelen cevabı parse et, bu cevaptaki X değerini $x değişkenine Ata
....
....
....
if ($x > 0)
{
    BirSeyYap();
}
else
{
    BaskaBirSeyYap();
}

Logda 3. Partiden gelen cevap yazılıdır ve o logda X’in değeri 2’dir. Ama sanki $x değişkeni hiç bu değeri almıyormuş gibi kod sürekli BaskaBirSeyYap() fonksiyonunu çağırmaktadır. Yaşar en az 10 test yapmıştır, artık gözleri kararmaktadır. En sonunda değiştirmek istemediği kodda, if deyiminin hemen bir satır üstüne Log::writeLog(“X’in değeri bu: $x”); satırını ekler ki logda $x değişkeninin değeri görünsün. Bunun dışında hiçbir değişiklik yapmaz, “yemişim commiti” deyip, kodu Subversion deposuna göndermeden doğrudan production’a alır.

Aynı testi tekrarlar.

3. Parti API daha önceki 10 testte verdiği cevap ile aynı cevabı verir. X değeri 2’dir. Yaşar logları okumaya devam eder ve yeni eklediği log satırını görür. Şöyle yazmaktadır:
X’in değeri bu: 2

ve hemen altında BirSeyYap() fonksiyonun çağrıldığını gösteren log satırını görür. Kod doğru çalışmıştır. Halbuki $x değişkenini loga yazmak haricinde hiçbir değişiklik yapmamıştır. Gözlerini oluşturur. Testi yineler. Sonuç aynıdır. $x 2 değerini alıyordur ve kod doğru çalışıyordur.

Yaşar, “hayır, bu kadar aptalca bir şey olamaz” der ve 3. Parti API’den aldığı önceki cevaplarla, $x’ i loglara yazmasından sonraki cevapları karakter karakter karşılaştırır. Birebir aynıdırlar. Hatta bir Hex editörü ile log dosyasını açıp karşılaştırma yapacak kadar ileri gider. API’ nin döndürdüğü sonuç her durumda aynıdır ve koddaki tek değişiklik $x değişkeninin değerinin loga yazılmasıdır.

Hemen son yaptığı değişikliği geri alır ve kodu production’ a alp tekrar test eder. API aynı cevabı döndürür, $x artık logda görünmemektedir, fakat BirSeyYap() fonksiyonu çalışmaya devam etmektedir. Yaşar ne yaparsa yapsın, aynı durumu tekrar edemez. Halbuki o log satırını yazmadan önce en az 10 kez test etmiş, hepsinde de BaskaBirSeyYap() fonksiyonu çalışmıştır. Log satırını yazınca herşey düzelmiştir. Olayı etrafındakilere anlatır, ama tekrar edemediği için logları göstermesine rağmen kimseyi inandıramaz.

Sonuçta PHP’ ye bol miktarda güzel iltifatlar ederek işine devam eder.

  5 Responses to “Bir Garip PHP Hikayesi”

  1. Bu tip şeylerde, kodda BOM gib harici karakterler olup olmadığını kontrol etmek gerekir. Etmiş miydin?

    • Evet, etmiştim.

    • Daha once BOM’u kontrol ettigimi soyledim ama simdi dusununce emin olamadim. Belki de nedeni buydu.

      Ama isin garibi kodun daha once sorunsuz calisiyor olmasi. Cunku daha once yine bizzat benim tarafimdan test edilmis ve production’a alinmisti. QA testlerinden gecmisti. Aradan birkac ay gectikten sonra yeni bir hata kaydi acildi ve o hataya bakarken gerceklesti tum bunlar.

  2. Aklıma apc veya benzeri bir eklentinin böyle bir probleme yol açabileceği geldi, sen dosya üzerinde değilişiklik yaptığında dosyanın son değiştirilme tarihi değiştiğinden apc o kodu tekrar bytecode olarak derlemiş ve çalışmıştır, daha önce ki çalışmayan kod kısmında kod doğru olmasına rahmen apc bu değişikliği fark etmemiş olabilir. ilk aklıma gelen bu oldu açıkcası.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)