Etiket arşivi: reverse engineering

Hal 100:Kucağına düşen 3ncü parti ürün üzerinde bug/fix yapıp sevinir ve ardından yeni taleplerle karşılaşır.

Özellikle sahada kullanılan ürünleri olan firmaların olmassa olmaz ihtiyaçlarından birisi teknik destektir. Var olan ürünlere yapılacak yeni eklemeler veya güncellemeler haricinde, müşterilerden gelen geri bildirimler doğrultusunda acil olarak halledilmesi gereken vakalar da vardır. Bunlar her ne kadar bazı profesyonel firmalar tarafından seviyelendirilip uygun birimlere yönlendiriliyor olsa da hayat bu kadar toz pembe değildir. Doğruyu söylemek gerekirse olası pek çok vaka vardır. Bu vakalardan belki de en kötüsü bir servis sağlayıcıdan alınmış olan ürünler ile ilgilidir. 

  • Ürüne olan teknik destek, sahibi olan firma tarafından kesilmiş olabilir,
  • Ürünün sahibi teknik destek için yüksek miktarda fatura kesiyor olabilir(Vendor Lock-In anti pattern’ inin oluşma nedenidir),
  • Ürün sahibi firma kapanmış olabilir,
  • Ürün eskidir ve aslında üzerinde çalışmış geliştiriciler sahibi olan firmada artık yoktur
  • Ürünün teknik dokümantasyonu olmayabilir vb

Eğer söz konusu ürün, onu kullanan firma tarafından kolay kolay terk edilemiyorsa durum vahimdir. Ürün yeteri kadar ayrık yapıda tutulmamışsa sistemden kopartmak ve yerine başka bir alternatifi koymak her zaman güçtür. Durum böyle olunca birisinin o ürün üzerinde değişiklik yapması şarttır.

Üçüncü parti bir ürünün üzerinden değişiklik yapmak risklidir. Ancak bazı sebeplerden ötürü servis sağlayıcından habersiz olarak değişiklik yapılması çok daha risklidir.

Çünkü servis sağlayıcının yeni bir sürüm çıkartması halinde, yapılmış olan güncellemelerin bu versiyona da aktarılması gerekir. Bu, Dead End adı verilen anti-pattern’ in yolunu açar.

Eğer yukarıda sayılan sebeplerden ötürü 3ncü parti ürün üzerinde değişiklik yapılması kaçınılmazsa elden bir şey gelmez ve bir geliştiricinin bu konuya eğilmesi gerekir. Ürünün çeşidine, isteğin aciliyetine göre başına verilecek adamın kaliteli bir kumaşa sahip olması gerekebilir. Çünkü 3ncü parti ürün tam bir kod çöplüğüne benzeyebilir.

Ürünün hızla analiz edilmesi, çabucak keşfedilmesi, büyük resmin hemen fark edilmesi, içeride kullanılmış mimari kalıp veya prensiplerin anlaşılması, müdahale edilmesi gereken en uygun yerin bulunması gerekir. Bir anlamda geliştiricinin tersine mühendisliğin farkında olması ve kullanması icap edebilir.

SOA gibi üst düzey mimariler içeren, farklı platformlarda koşan ürünlerin bir arada konuştuğu sistemlerde, çıktıları kiritik olan 3ncü parti ürünler kullanılmakta olabilir.

Bu ürünlerin sistemden kolayca kopartılamadığı, üstüne bir de teknik destek alınamadığı ve bazı kanuni kurallar yüzünde acil değişikliklerin yapılması gerektiği durumlar karşısında yetkin geliştiricilerin bir mucize yapması beklenir.

Bu mucizeleri yapan geliştiriciler gerçekten de vardır.

Anahtar Kelimeler (Bunlara Bir Bakalım)

  • Dead End Anti Pattern
  • Lavaflow Anti Pattern
  • Vendor Lock-In Anti Pattern
  • Tersine Mühendislik (Reverse Engineering)

Hal 37:Dev bir Solution’ın neresinden Debug etmeye başlanması gerektiğinde ki kararsızlık durumudur.

Malesef işler her zaman geliştiricinin istediği şekilde gitmez. Bazılarımız hayatının çok az bir döneminde sıfırdan bir projeye başlama şansı yakalar. Özellikle çok uzun soluklu projelerde ve yıllara varan geliştirme süreçlerinde ise projenin sonunu göremeyen çok olur.

Dolayısıyla geliştiricinin sıklıkla karşılaşacağı durumlardan birisi zaten geliştirilmiş olan bir ürün üzerinden gelen yeni isteklerin karşılanmasıdır. Bu bazen can sıkıcı hata yakalama ve düzeltme işlerini de beraberinde getirir. Söz konusu ürün oldukça eski olabilir ve tek bir geliştiricinin üstüne yapışabilir. Artık geliştiricinin yatıp kalkıp uğraştığı sadece bu sıkıcı iştir.

37

@coderizbiz

Bu tip ürünlerde asıl sorun bazen de kalabalık ve karmaşık proje topluluklarıdır. .Net’çe düşünürsek Solution içerisinde n sayıda proje olabilir(30un üstünde proje içeren Solution’ ları görmüş birisi olarak söylüyorum) Eğer doküman da eksikse “vay halime” diyebilirsiniz ama demeyin. Doküman olabilir ancak var olan doküman güncel olmayabilir. İşte bu hale düşen geliştirici çoğunlukla Solution’ un neresinden, hangi projesinden başlayacağını ilk etapta kestiremez.

Yapılması gereken basittir; Solution’ u Collapse All ile ufaltmak ve büyük resme daha geniş bir açıdan bakıp parçalar arasındaki ilişkiyi kavramaya çalışmak.

Bir nevi tersine mühendislik gibi görünen bu işler arttıkça geliştiricinin tecrübesel yetkinliği artsa da yıpranma olasılığı yükselecektir.

Anahtar Konular(Bunlara Bir Bakalım)

  • Tersine Mühendislik(Reverse Engineering)
  • Visual Studio Solutions Collapse All
  • Bug-Fix
  • Debugging