Az Önünüze Yeni Gelen Eski C++ Kod Tabanı: Şimdi Ne Yapmalı?

Mevcut bir C++ kod tabanını devraldıysanız ne yapmalısınız?

• Yeni bir işe başladıktan, ekip değiştirdikten ya da deneyimli bir ekip arkadaşı ayrıldıktan sonra, karmaşık ve kendine özgü yapıya sahip büyük bir C++ kod tabanından sorumlu olabilirsiniz.
• Hataları düzeltmek ve yeni özellikler eklemek gerekir, ancak kod tabanını görmezden gelemez ya da çöpe atamazsınız. Bu, maaşınızı ödeyenler için önemliyse sizin için de önemlidir.

İlk adım: Kodu yerelde çalıştırmak

• Kod ve build sistemi üzerinde mümkün olan en az değişikliği yaparak sistemi yerelde çalıştırın. Henüz büyük çaplı refaktörlere girişmeyin.

Gereksiz şeyleri kaldırmak

• Şirketin ya da açık kaynak projesinin duyurduğu ve sattığı işlevleri sunmak için kesinlikle gerekli olmayan her şeyi kaldırın.

Projeyi 21. yüzyıla taşımak

• CI (sürekli entegrasyon), linter, fuzzing, otomatik formatlama gibi araçları ekleyin.

Kodu kademeli olarak iyileştirmek

• Koda küçük ve aşamalı değişiklikler yapın. Bunu tekrar tekrar uygulayarak projeyi güvenlik, geliştirici deneyimi, doğruluk ve performans açısından kabul edilebilir bir duruma getirin.

Bellek güvenli bir dille kısmi yeniden yazımı değerlendirmek

• Mümkünse, kodun bir kısmını bellek güvenli bir dille yeniden yazmayı değerlendirin.

Desteklenen platformları belirtmek

• README dosyasında resmi olarak desteklenen <mimari>-<işletim sistemi> çiftlerini belirtin. Örneğin x86_64-linux veya aarch64-darwin gibi.

Makinede build'i çalıştırmak

• Tüm desteklenen platformlarda güvenilir ve tutarlı biçimde build alındığından emin olun.

Makinede testleri geçirtmek

• Test yoksa, kodu değiştirmeden önce test yazın; testler geçtikten sonra değişikliklere geri dönün.

README'de uygulamanın nasıl build edileceğini ve test edileceğini açıklamak

• Build ve test komutlarını, uzman olmayan kişilerin de kolayca takip edebileceği kadar basit hale getirin.

Build ve test hızını artırmak için kolay kazanımları bulmak

• Build sistemini değiştirmeden build ve test süresini kısaltabilecek basit yöntemler arayın.

Gereksiz kodu kaldırmak

• Derleyici uyarılarını ve linter'ı kullanarak kullanılmayan kodu bulun ve kaldırın.

Linter

• Linter kurallarına aşırı takılmadan birkaç temel kural ekleyin ve bunu geliştirme döngüsüne entegre edin.

Kod biçimlendirme

• Uygun bir zamanda tüm kod tabanına toplu olarak bir kod stili uygulayın ve yapılandırmayı commit edin.

Sanitizer'lar

• Sanitizer'ları kullanarak gerçek hataları ve bellek sızıntılarını tespit edin ve düzeltin.

CI pipeline eklemek

• Kurduğunuz tüm iyi uygulamaları (linter, kod biçimlendirme, testler vb.) otomatikleştirin ve her değişiklik için üretim ortamında kullanılacak binary'leri üretin.

Kodu kademeli olarak iyileştirmek

• Güvenlik, doğruluk ve performans gibi somut hedeflere odaklanın; clean code gibi öznel ölçütlerden uzak durun.

Bellek güvenli bir dille yeniden yazım?

• Bu hâlâ devam eden bir tartışma alanıdır ve birçok dikkat edilmesi gereken nokta vardır. Yalnızca açık bir gerekçe olduğunda yapın.

Sonuç

• Karmaşık bir eski C++ kod tabanından çıkış için somut ve adım adım bir plan sunar.

Ek: Bağımlılık yönetimi

• C++ dünyasında bağımlılık yönetimi tutarlı değildir ve çoğu zaman sistem paket yöneticileri kullanılır. Ancak bu iyi bir fikir değildir.
• Yazarın bağımlılık yönetimi konusundaki görüşü, git submodule ve kaynak koddan derleme yaklaşımını kullanmaktır.

GN⁺ görüşü

• Bu yazı, C++ kod tabanını devralmış giriş seviyesi yazılım mühendisleri için faydalı, adım adım bir rehber sunuyor.
• Eski kodla uğraşmak birçok geliştirici için yaygın bir zorluktur ve bu yazı böyle durumlar için pratik tavsiyeler veriyor.
• Kod tabanını iyileştirme sürecinde testlerin önemini vurgulaması, iyi yazılım geliştirme pratiklerini yansıtıyor.
• Yazarın bağımlılık yönetimi konusundaki görüşü tartışmalıdır; gerçek projelerde Conan veya vcpkg gibi modern paket yöneticilerinin başarıyla kullanıldığı birçok örnek de vardır.
• Teknoloji seçerken projenin özellikleri ve ekibin yetkinlik seviyesi dikkate alınmalıdır; bu yazı böyle kararlar vermek için iyi bir başlangıç noktası olabilir.

[GN⁺]

Hacker News görüşleri

• Bazı Hacker News yorumlarında, bir C++ projesini devraldığınızda izlenebilecek tavsiyeler sunuluyor:

  • Yeniden üretilebilir build: Docker gibi araçlarla build ortamını sarmalayarak araçları ve bağımlılıkları açık ve yeniden üretilebilir hale getirmeniz öneriliyor.
  • -Wall seçeneğiyle temiz build almak: Uyarıları gidererek koddaki sorunları düzeltin; nadiren de olsa, uyarıyı anladıktan sonra görmezden gelmek de mümkün olabilir.
  • İlk testler için Valgrind gibi araçlarla okuma/yazma hatalarını incelemeniz öneriliyor.
  • Refactoring’i başlangıçta yerel kapsamda tutmanız ve genel yapıyı anlamadan büyük çaplı yeniden tasarımlardan kaçınmanız tavsiye ediliyor.

• Diğer yorumlarda ise önce CI, linting, auto-formatting gibi araçların devreye alınmasının önemli olduğu savunuluyor:

  • Koddan gereksiz kısımları kaldırmadan önce programın nasıl çalıştığını anlamak gerekir; statik analiz araçları da programın hangi noktalarında çalışma gerektiğine dair içgörü sağlayabilir.

• Bir kullanıcı, yeni bir ekibe veya şirkete geçmeyi öneriyor.

• Kod anlama araçları ve tekniklerinin önemine değinen yorumlar da var:

  • Kod tabanını indeksleyen araçları kullanmak, UML sequence diagram çizmek ve sanki başkasına öğretiyormuş gibi not almak önemli görülüyor.

• Bir yorum, projeyi modernize etmek için CI, linters, fuzzing, auto-formatting gibi araçları eklemeye yönelik tavsiyeler sunuyor:

  • CI sayesinde projenin başka ortamlarda da build edilebilmesi sağlanabilir; derleyici uyarıları ve statik analiz araçlarıyla kod sorunları tespit edilebilir.
  • Kodun önemli bölümleri için unit test kurarak kodun doğru işi yaptığını doğrulayın.
  • Otomatik biçimlendirme daha düşük öncelikli görülüyor; orijinal bakımcının stiline uyulması öneriliyor.

• Başka bir yorum ise bazı bölümleri bellek güvenli bir dille yeniden yazma tavsiyesini eleştiriyor:

  • Bunun için gereken ek kaynakları bulmak zor olabilir, C++ dışında ek bir dil bilgisi gerektirir ve test sürecini daha karmaşık hale getirebilir.

• Git submodule ve kaynak koddan derleme yaklaşımının paket yöneticilerinden daha üstün olduğunu savunan yorumlar da var:

  • vcpkg gibi araçları denemeden bu eleştirileri getirmelerinin tuhaf olduğu belirtiliyor.

Bu yorumlar, bir C++ projesini devraldığınızda uygulanabilecek farklı yaklaşımlar ve tavsiyeler sunuyor; proje yönetimi, kodu anlama, refactoring ve modernizasyon stratejileri konusunda çeşitli görüşleri yansıtıyor.