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   tercih ediyorum: UML dizi diyagramlarını  Onlarla biraz deneyimim var.  Anlambilim   değildir, UML'yi bilen kişiler arasında bir noktaya kadar paylaşılır. geçici  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); } //... }    , son erişim zamanının güncellenmesini tetikleyen   dosyasını okur. DefaultRecordStore Record  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   gidiyor: PlantUML'ye  Bir   ve   sunar web uygulaması Docker konteyneri  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   yayınlandı A Java Geek'te

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Make resilience your competitive advantage

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

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps