Alışılmadık Bir Kod Tabanında Nasıl Çalışılır?

Mesleğimizde alışılmadık bir kod tabanı üzerinde çalışmak yaygındır. Bu, ne zaman yeni bir projeye katılsanız, hatta büyük projelerde daha önce dokunulmamış bir kısım üzerinde çalışmaya ihtiyaç duyduğunuzda gerçekleşir.

Bu olay, geliştiricinin bir hatayı düzeltmek zorunda kalmasıyla sınırlı değildir; bu, yeni bir özellik tasarlamak zorunda olan bir çözüm mimarı veya boş zamanlarında bir GitHub sorunu üzerinde çalışan bir Açık Kaynak katılımcısı olabilir. Bu nedenle, başkalarına fayda sağlayabilmek için duruma nasıl yaklaştığımı açıklamak istiyorum.

Örnek Bir Konu

Demek istediğimi açıklamak için, Açık Kaynak projesinde yeni bir özellik talep eden yaygın bir GitHub sorununu kullanacağım.

Hazelcast için çalışırken, hackathon'larda üzerinde çalışmak üzere düzenli olarak "iyi ilk konular" olarak adlandırılan konuları taradım. Böyle bir hackathon'u asla yürütemezdim ama bu konunun dışında. Benim fikrim Açık Kaynak'a katkıda bulunmak isteyen kişilerin kod tabanını tanımalarına yardımcı olmaktı.

O zamanlar şu ilginç konuyu buldum:

GetQuiet işlemi için destek ekleyin http://ehcache.org/apidocs/net/sf/ehcache/Cache.html#getQuiet(java.lang.Object) ?

Buradaki fikir, bir girişe dokunmadan ulaşabilmek, yani girişin son erişilen zaman damgasını güncellememesidir.

Bunun arkasındaki kullanım durumu, bir anahtarın çıkarılmasını değiştirmeden bir anahtarın varlığını izleyebilmektir.

-- Dağıtılmış Harita: getQuiet işlemi için destek ekleyin

Açık Kaynak katılımcısı olarak çalışmaya nasıl yaklaşmalıyım?

Diyagramlama Önemlidir

Belgeleme yeni bir projeye başlamanın ilk adımıdır. Normal bir projede belgeler muhtemelen eksik, eksik veya kısmen (tamamen olmasa da) yanıltıcı olacaktır; Bir hackathon'da ayrıntılı olarak okumak için zaman çok kısa olabilir.

Başarılı Açık Kaynak projeleri genel olarak iyi belgelere sahiptir. Ancak dokümantasyon esas olarak kullanıcılara, nadiren de geliştiricilere yöneliktir. Durum böyle olsa bile belgelerin sorunu çözme ihtimali düşüktür.

Bu nedenle giriş noktam bir diyagram çizmek olacaktır. Bazı araçların kodu tersine çevirebilmesine ve diyagramları otomatik olarak çizebilmesine rağmen bunları bilerek kullanmadığımı unutmayın. Bir diyagramın manuel olarak çizilmesinin, otomatik olarak oluşturulan bir diyagrama göre birçok avantajı vardır:

• Kodun eldeki sorunla ilgili alanlarına odaklanır.

• Çekmeceyi gerçeğin tek kaynağı olan kodu okumaya ve anlamaya zorlar.

• Kodun zihinsel modelini oluşturur.

• Bulgularımızı daha sonra erişilebilmesi için belgeliyor. Ancak, temel kod geliştikçe ve her ikisi de ayrı ayrı ilerledikçe dokümantasyon değerinin zamanla azaldığını unutmayın.

Sorunun kodu için bir diyagram oluşturalım. Öncelikle favori IDE'mizde açmak için repoyu yerel olarak klonlayacağız; gereken tek özellik, bir yöntem çağrısına tıklandığında yönteme yönlendirilmektir.

Diyagramın kendisi için bana eski kafalı diyebilirsiniz, ancak iki nedenden dolayı hala UML dizi diyagramlarını tercih ediyorum:

• Onlarla biraz deneyimim var.

• Anlambilim geçici değildir, UML'yi bilen kişiler arasında bir noktaya kadar paylaşılır.

Daha fazla uzatmadan, işte burada:

Diyagramı çizdikten sonra sorunun nerede olduğunu oldukça hızlı bir şekilde bulabiliriz:

 public abstract class AbstractCacheRecordStore<R extends CacheRecord, CRM extends SampleableCacheRecordMap<Data, R>> implements ICacheRecordStore, EvictionListener<Data, R> { protected long onRecordAccess(Data key, R record, ExpiryPolicy expiryPolicy, long now) { record.setAccessTime(now); // 1 record.incrementAccessHit(); return updateAccessDuration(key, record, expiryPolicy, now); } //... }

1. DefaultRecordStore , son erişim zamanının güncellenmesini tetikleyen Record dosyasını okur.

Sorunun düzeltilmesi bu yazının kapsamı dışındadır. En iyi çözümü geliştirmek için genel tasarıma daha aşina olan kişilerle konuşmayı içerir. Bir hackathonda iyi bir yaklaşım, ilk olarak en az iki alternatif sunmak ve bunların takaslarını belgelemektir.

Takımlama için birçok alternatif mevcuttur. Tercihlerim PlantUML'ye gidiyor:

• Bir web uygulaması ve Docker konteyneri sunar
• SVG veya PNG görüntüleri oluşturur
• Derisi yüzülebilir
• Açık Kaynaktır ve ücretsizdir
• Bakımları düzenli olarak yapılmaktadır

Çözüm

Mevcut bir kod tabanını anlamak, kişinin tam teknik rolüne bakılmaksızın çok önemli bir beceridir. Bir diyagram oluşturmak, dokümantasyonun ek faydasıyla birlikte bu hedefe doğru uzun bir yol kat eder.

UML diyagramlarını seviyorum çünkü onlara aşinayım ve ortak anlamlar sunuyorlar.

Dolayısıyla, eğer bir kod tabanını daha iyi anlamak istiyorsanız, onun kodunu okumaktan daha fazlasına ihtiyacınız vardır; diyagramlar çizmeniz gerekir.

İlk olarak 14 Mayıs 2023'te A Java Geek'te yayınlandı