Birden fazla projede aynı kod parçaları nasıl korunur [kapalı]


9

Birden fazla Android projesinde çalışan bağımsız bir geliştiriciyim. Farklı projelerde aynı işlevselliği sürdürmekte sorun yaşıyorum. Örneğin, üç uygulamam aynı 2 sınıfı kullanıyor; farklı projeler oldukları için, bu sınıflarda bir değişiklik yapmam gerektiğinde, bunu üç kez yapmam gerekiyor. Bu tür ortak bir sorunun basit bir çözümü var mı?


Bu nasıl gerçek bir soru değil ??
Andre Figueiredo

Yanıtlar:


15

Paylaşılan kodu bir kütüphaneye ayırın ve kütüphaneyi projelere dahil edin.

Bir Android geliştiricisi olarak, muhtemelen Java kullanıyorsunuzdur. Maven veya Ivy gibi bir bağımlılık yönetim aracı kullanmayı düşünün .

Bir yan etkisi, bunun modülerliği uygulayarak endişelerin ayrılmasını sağlamaya yardımcı olmasıdır . Maliyet, ayırmak için biraz çalışma gerektirebilir; fayda daha iyi gelecekteki sürdürülebilirliktir. Ayrıca, karar verirseniz, kütüphaneyi uygulamalarınızdan ayrı olarak (ticari veya açık kaynak olarak) serbest bırakabilirsiniz.


2
Bağımlılık yönetimi için +1. Tüm popüler diller için iyi seçenekler olmalıdır.
Adrian Schneider

11

Sürüm kontrolü. Git. Git Alt Modülleri.

Git veya mercurial gibi bir dvcs kullanarak projelerinizi sürüm kontrolü altına alın. Paylaşılan kodu git'deki bir alt modüle yerleştirin. Alt modülü ihtiyacı olan projelerde kullanın. Alt modülü güncellediğinizde, değişiklikleri tek bir komutla diğer projelere çekebilirsiniz.


1
-1: Bu gerçekten sorunun cevabının gizlenmesinde belirli bir ürünün "evanjelik tanıtımı" dır. Başlangıçta bu cevaba oy verdim, ancak soruyu tekrar okuduğumda, cevabın aslında farklı bir soruya doğru cevap olduğuna karar verdim.
mattnz

1
-1 de. Bunun paylaşılan bir kütüphaneden daha iyi olduğu konusunda kafam karıştı. Bu
git'i

5
Git, sadece kullanılacak bir araçtır. Kullanıyorum, memnunum. Kullanabilir veya kullanmayı reddedebilirsiniz. Gerçek şu ki, sorunu çözüyor. Sorunun SADECE çözümü olduğunu iddia etmiyorum.
Hakan Deryal

1
Bu, çalışan bir yaklaşımı açıklar: bir kütüphanenin çıkarılması, OP'nin zaman kısıtlamaları altında mümkün olan veya mümkün olmayan bazı çalışmalar ister;
Francesco

2
+1 Bağlantı için teşekkürler! Paylaşılan bileşen etkin geliştirme aşamasındaysa, bu çözümün (IMHO) paylaşılan kütüphane çözümüne kıyasla belirgin faydaları vardır.
JanDotNet

5

Kimse henüz iki ucu keskin kılıçtan bahsetmedi, bu yüzden 2 sent ekleyeceğim. Birden fazla projeniz varsa ve hepsi iyi programlama uygulamalarına / ilkelerine (örneğin KURU) göre yeniden kullanılabilir bazı kodları paylaşıyorsa, kodu tek bir global yere yerleştirmeli ve herkes tarafından paylaşılabilecek şekilde yapılandırmalısınız. herhangi bir değişiklik yapmadan projeleriniz. Başka bir deyişle, arayüzleri genel ve herkese uyacak kadar yaygın olacak şekilde tanımlayın.

Bunu yapmak için birkaç seçenek vardır: 1) Başkalarının dayandığı bir temel proje oluşturun. Bu proje, diğer projelerin tükettiği bir ikili dağıtım oluşturabilir. 2) Kuruluşunuzda açık kaynaklı bir model çekin. Ortak kod kendi kod dalı olmak ve diğer projelerin kod herhangi bir çevrimiçi OSS kaynak kodu alacağınız şekilde çekmek var.

Şimdi kılıç burada devreye giriyor ...

Kodu diğer projelerin / insanların bağımlı olduğu ortak bir yere yerleştirmek oldukça pahalı hale gelebilir. Diyelim ki bir parça kodunuz var ve buna bağlı 4 proje daha var. A projesini kullanan müşterilerinizden biri bir hata bulur ve bir düzeltme yapmanız gerekir. Düzeltmeyi acele ettiniz ve o müşteri mutlu. Ancak diğer 3 projenin de bağlı olduğu bazı kodları değiştirdiniz. Kenar koşullarının getirilmediğinden emin olmak için hepsini yeniden test ettiniz mi?

Ortak kod da çok daha dikkatli bir şekilde hazırlanmalı ve modül arayüzleri çok daha iyi tasarlanmalıdır, çünkü bu kod bir değil 4 istemciyi barındırmalıdır ve bunların her biri bu kodu çok küçük bir farkla kullanabilir.

Projeleriniz farklı sürüm döngülerinde ise, ortak kodu yönetme konusunda daha da dikkatli olmanız gerekir. Ortak kodda değişiklik yapamazsınız çünkü C projesi için nihai görüntüyü kesmekten 3 gün uzaktaysanız, B projesi yeni bir işleve ihtiyaç duyar.

Ortak kütüphanenin doğru çözüm olmadığını söylemiyorum. DRY'nin güçlü bir destekçisiyim ve daha önce ortak kod oluşturup destekledim ve yapmaya devam ediyorum. Sadece kodu ortak hale getirmenin kendi masrafları olacağını söylemek istedim.

Bu kodu yeniden kullanan tek kişi sizseniz, bu o kadar da kötü değil. Bir mühendis ekibiniz varsa ve ortak kodu kullanmaya başlarlarsa, masraflar daha da artar. Başkaları da dahil ise, ortak bir kütüphaneye kod yerleştirmenin "tam" olduğunu düşündüğünüz bir noktaya gelmesi için 3 kat daha fazla zaman almasını bekleyin. A) her türlü kenar koşuluna ve geçersiz kullanıma karşı korumak için kütüphaneyi daha sağlam hale getirmeniz, b) diğerlerinin kütüphaneyi kullanabilmesi için dokümantasyon sağlamak ve c) diğer kişilerin kütüphaneyi kullandığınız şekilde hata ayıklamalarına yardımcı olmak beklemediniz ve belgeleriniz özel kullanım durumlarını kapsamıyordu.

Sunduğum birkaç öneri:

  1. Otomatik birim testleri kapsamında ortak kodun bulunması uzun bir yol kat edebilir ve bir değişiklik yaptığınızda, sadece başka bir projeyi kırmadığınızı aklınızdan çıkarmayın.
  2. Ben sadece ortak kod içine çok istikrarlı bir işlevsellik yerleştirir. Geçen yıl zamanlayıcı yönetimi yapmak için bir sınıf yazdıysanız ve 9 ay içinde değiştirmediyseniz ve şimdi zamanlayıcılara ihtiyaç duyan 3 projeniz daha varsa, bunun iyi bir aday olduğundan emin olun. Ama geçen hafta bir şey yazdıysanız, iyi ... o kadar çok seçeneğiniz yok (ve muhtemelen bir sonraki adamdan daha fazla kopyalama / yapıştırma kodundan nefret ediyorum) ama bunu iki kez yaygınlaştırmayı düşünürdüm.
  3. Bir kod parçası önemsizse, ancak birkaç yerde kullandıysanız, mermiyi ısırmak, DRY'yi yalnız bırakmak ve birden fazla kopyanın yaşamasına izin vermek daha iyi olabilir.
  4. Bazen ortak kodu ortak bir konuma koymak ve herkesin referans almasını sağlamak işe yarar. Ancak daha ziyade ortak kodu, sürümler, çıkış tarihleri ​​ve her şeyle serbest bırakılabilir olarak kabul edin. Bu şekilde proje C, "Ortak kütüphane v1.3 kullanıyorum" diyebilir ve eğer proje D yeni işlevsellik gerektiriyorsa, v1.3'ü yalnız bırakırsınız, v1.4'ü serbest bırakırsınız ve C projesi etkilenmez. Unutmayın, sadece ortak bir yere kontrol etmek yerine ortak kodu kendi ürünü olarak ele almak çok daha pahalıdır.

1

Bu ideal bir çözümdür ve çalışmak için biraz çaba harcayabilir.

KURU ilkesi, tek bir yetkili gerçeğin kaynağı olması gerektiğini belirtir. Bu , tüm program mantığı için çoğaltma olmadan tek bir kaynak havuzunun kullanılmasını gerektirir; belgelerin paylaşılmasını ve yeniden kullanılmasını teşvik etmek için düzenlenmiş dosyalar.

Dağıtılmış, çok ekipli bir ortamda iletişimin pragmatik gereksinimleri, her proje veya işbirliği için bir tane olmak üzere, birden fazla bağımsız depo olması gerektiğini düşündürmektedir.

Bu probleme kaçınılmaz olana başvurarak yaklaşacağım: her iki yaklaşımı da aynı anda almanız gerekecek ve yaklaşımların çelişkili olduğu gerçeğini düzeltmek için kodlama ve otomasyon kullanacağız.

:-)

Birleştirilmiş havuz tek yetkili kaynağınız olacaktır. Her proje için derleme işlemi, o proje tarafından kullanılan tüm dosyaları (ve yalnızca bu dosyaları) bir ara konuma kopyalar, ardından o ara konumdan derler. (Tüm dosyalar yerine deltaları taşımak için Unison veya benzeri bir araç kullanılabilir).

Bu ara konumlar, ikincil, türetilmiş veya akışaşağı depolar kümesi için yerel çalışma kopyaları olarak kullanılabilir. Yetkili depodaki işlem sonrası kanca komut dosyaları, tüm ara konumları güncelleştirir ve her biri için değişip değişmediğini kontrol eder ve bir değişiklik algılanırsa ilgili ikincil depoya da aynı işlemi yapar.

Bu şekilde, çoklu ikincil havuzlar tek yetkili kaynak havuzuyla senkronize halde tutulur ve oluşturma işlemi, ikincil havuzların, yapının başarılı olması için gerekli olan (muhtemelen paylaşılan) tüm belgeleri ve diğer dosyaları içermesini sağlar. Son olarak ve en önemlisi, geliştirme ve oluşturma işlemi, dosyaların tek bir yerde ve yalnızca tek bir yerde düzenlenmesini ve tüm kopyaların tutarlı ve güncel tutulmasını sağlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.