Bir Denetim Klasiği: “Kodu Yazan Canlıya Taşıyamaz”

Kurumsal bir firma için kod yazan pek çok kişinin karşısına bu nokta çıkmıştır: Geliştirmeyi yapan kişi ayrı, yapılan geliştirmeleri canlıya atan kişi ayrı olmalıdır.

Bilhassa SAP ABAP ortamında bu durumla defalarca karşılaştım. Bu noktanın geçerli olmadığı kanaatinde olduğum ve her seferinde tekrar tekrar anlatmak durumunda kaldığım için, fikirlerimi bu yazıda dile getirmek istedim.

ABAP’çı Neden Request Atabilmeli?

Hırsıza kilit yok! Eğer programcının art niyetle zararlı bir program yazıp kimsenin ruhu duymadan canlıya atmasını önlemek istiyorsanız, size kötü bir haberim var: Programcı niyeti bozduysa, zararlı kodu masum gözüken bir programın içine de saklayabilir. Request’leri başka birinin taşıyor olması bunu değiştirmez. Hatta yapılan geliştirmeleri taşımadan önce teknik denetimden de geçirseniz, yine de dikkat çekmeyecek yerlere bu tarz bir kod saklanabilir. O yüzden, güvenilir geliştiricilerle çalışmaya bakın.

Şeffaflık mümkün! SAP’de kimin ne zaman nereye hangi Request’i attığı zaten şeffaf bir şekilde saklanmaktadır. Canlı sistemde TPALOG tablosuna bir göz atarsanız, bu günlüklere kolayca erişebilirsiniz. Bakılabilecek başka yerler de var tabii. Programcıları yavaşlatmak yerine günlük bir Request taşıma raporu çekip kimin ne taşıdığını takip etmek daha iyi bir fikir olabilir.

Taşıyan, geliştirmeleri tanımalı! Aynı anda hangi geliştirmelerin sürdüğünü ve bu ABAP nesnelerinin tarihçesini bilmeyen biri Request attığında, bilgili bir gözün bazı detayları yakalayıp hataları oluşmadan önlemesinden mahrum kalmış olursunuz. ABAP’çının taşımadan önce “Aaa, bu User Exit’e bir başka ihtiyaç için de kod yazmıştık, hemen taşımayalım” diyebilmesi değerlidir. Veya bir diğer Request’te kalmış Data Element’leri tespit edip, taşınacak Request’lere dahil edebilir.

Teknik bilgi lazım! Request taşımak, teknik bilgi gerektiren bir iştir. Bilhassa kapsamlı geliştirmelerde; ABAP’çı sıklıkla Request’leri ve nesneleri inceleyip, nelerin canlıya gitmesi / gitmemesi gerektiği konusunda insiyatif kullanmaktadır. Request Release / Import edilirken ortaya çıkabilen bazı uyarı / hata mesajlarının çözülebilmesi yine ABAP bilgisi gerektirebilmektedir. ABAP bilmeyen ve geliştirmelerin detaylarından habersiz üçüncü bir kişi Request atmaya kalktığında, farkında olmadan hatalı işlemler yapabilmektedir.

Hata çözümü yavaşlar Bazen Request atarken bir hata olur ve hızlıca ToC atmak / kod yıldızlayıp tekrar atmak / vb gerekir. Request taşıma işini bir başkasına verdiğinizde, bu tarz manevraları hızlı yapabilme şansınız azalıyor. Canlıda yanlış / hatalı çalışmaya başlayan bir kodun olumsuz etkisi daha geniş bir alana yayılmış oluyor.

Geliştirme yavaşlar! Bazen sadece test / canlı sistemde ortaya çıkan bir hata ile karşılaşıyoruz ve hızlı bir şekilde kod yaz → taşı → test et ⮐ döngüsüne girmemiz gerekiyor. Request taşımamız üçüncü bir kişiyi masasında bulabilmemize bağlı olduğunda, bu iş çok yavaşlayıp uzayabiliyor ve canlıdaki bir hata bu süre zarfında daha büyük zarara yol açmış olabiliyor.

Sonuç

Özetle; programcı niyeti bozduysa zaten yapacak bir şey yok. O yüzden, ABAP’çılardan Request taşıma yetkisini alıp işleri boş yere yavaşlatmak yerine, güvendiğiniz kişilerle çalışın ve günlük raporlama yapın.

Advertisement