"Eski kod efsanedir!"
[CSDN editörünün notu] Yazılım endüstrisinde yeterince uzun kaldığınız sürece, kaçınılmaz olarak çetrefilli bir sorunla karşılaşacaksınız: eski kod tabanını onarın. Eski kod, birçok programcının gözünde "büyük bir sorundur", öyleyse neden bu kadar "tartışılıyor"? Bu makale, eski kodun nedenlerini ve çözümlerini yazmak için bir masal referansını kullanır - "Biz eski kod değiliz ... biz efsaneleriz."
Yazar | Michael Stahnke
Çevirmen | Crescent Moon, sorumlu editör | Guo Rui
Üretildi | CSDN (ID: CSDNnews)
Aşağıdaki çeviridir:
Göze çarpmayan küçük bir köşede, belirsiz küçük bir kod var.
Eski kod olarak adlandırılmaktan ve insanlar tarafından köşede bırakılmaktan bıktı. Sonuçta, hala bir parça iş mantığından sorumlu. Bununla birlikte, tüm işlemleri gerçekleştirmesine, çok değer sağlamasına ve birçok kullanıcıya yardımcı olmasına rağmen, kaçınılmaz olarak alay edilmektedir.
Küçük kod üzücü. "Ben bu işin bel kemiğiyim!" Diye bağırdı ama çığlığını kimse duymadı. İnsanlar onu görmezden gelmek, hatta onunla etkileşim kurmak istemiyor. Küçük kodlar genellikle çok sert takma adlar kullanan kişiler tarafından duyulur. Daha geçen hafta, birisi küçük kodu değiştirme emri aldı, ancak o kişi Kelimeler küçük kodu derinden incitti.
Bir takım lideri, "Küçük koda dokunmak istemiyorum. Bu çok çirkin ve şu anki uygulamamıza uymuyor. Küçük koda her dokunduğumda kötü şansım oluyor." Dedi.
Küçük Kod köşede üzgün oturdu ve ağladı, ama gözyaşları yoktu. Daha sonra küçük kod neşelendirmeye karar verdi, marka tanıtımına ihtiyacı olduğunu hissetti. Böylece diğer kodlarla konuşmaya başladı. Küçük kodlar ve diğer kodlar iyi arkadaşlar olmasa da, her zaman onu çağırırlar.
"Merhaba, Bay Microservices, insanlar neden sizi bu kadar çok seviyor?"
"Oh, merhaba," diye cevapladı mikro hizmet, küçük koda hızlıca bir göz atarak. Açıkçası, sohbeti mümkün olan en kısa sürede bitirmek istiyor. "Belki de amacımız tanımlanması kolay olduğu için test kapsamım var ve kolayca dağıtmak."
"Ah," dedi küçük kod, "işinizden kim sorumlu?"
"Tüm ekip. Yazmaktan, yeniden düzenlemekten ve beni Kubernetes'e dağıtmaktan, ardından güncelleme ve otomatik olarak ölçeklendirmekten sorumlular."
"Vay canına, kulağa ilginç geliyor. Kubernetes nedir?" Dedi küçük kod, "Prodüksiyon için uygun musunuz?"
"Üretim mi?" Mikro hizmet, "Bu nedir?"
"Ah, hayır." Küçük kod cevapladı.
"En iyi" kodla konuştuğunun farkına varır - kod teknik olarak mükemmeldir ancak kullanıcıya yardımcı olmaz. Küçük kodumuz bunun gibi birçok geri bildirim aldı. Birçok yeni sistemin yeni fikirleri vardır, ancak küçük kodun sorumluluğu işi yürütmektir. Eskiden öyleydi, şimdi ve gelecekte olacak.
Bir dizi isabetle karşılaştıktan sonra, küçük kod çeşitli yollar düşündü ve başka bir kod tabanıyla etkileşime girmeye çalıştı.
"Merhaba. İnsanların neden benden hoşlanmadığını biliyor musunuz?"
Kod tabanı çok büyük ve günlerdir traş edilmemiş. Biraz utanmış görünüyor ama genel olarak çok zeki görünüyor.
Utanan kod hafifçe şöyle dedi: "Elbette kimse sizi sevmiyor, çünkü eski kodsunuz."
Küçük kod, "Beni şahsen utandırmaya gerek yok" dedi.
"Hayır, hayır. Eski kod, işi yürütmekten sorumlu olduğunuz anlamına gelir. Çok büyük bir etkiniz var. Her türlü sorumluluğunuz var ... Ama aynı zamanda, sizinle mutlu bir şekilde çalışma zamanının da bunları takip ettiği anlamına gelir. İnsanlar birlikte uzaklaştı. İnsanlar yeni modelleri, uygulamaları ve araçları benimsedi. Şimdi ben de aynı durumdayım. "
"Gerçekten mi?" Küçük Kod üzgün bir şekilde sordu.
"Elbette, eski kod asla aşağılayıcı bir terim değildir. Eski kod, bu kodların uzun süre geçerli olduğu, uzun süre çok çalıştıkları ve fırtınadan sağ çıktıkları anlamına gelir. Sizin ve benim gibi kodun sorumluluğu çalıştırmaktır İş dünyasında, görevleri yerine getirmeye devam ediyoruz. Liderler tarihi efsaneler olmak istiyor ve kod tabanı aynı. "
"Ancak bu mikro hizmetler her zaman herkesin onlardan hoşlandığından bahsediyor. Benim dijital terk edilmiş bir çocuk olduğumu söylüyorlar."
"Bunu sadece sizi kıskandıkları için söylüyorlar. Bu hizmetlerden kaç tanesi görülebilir? Siz veya ben olmadan, kaç kişi işini gerçekten tamamlayabilir? Tabii ki, bu aslında onların işiydi, ancak genellikle insanlar bunu doğru yapamazlar. Soyut kod. Bu hizmetler sonunda bizi çağıran arayüz haline gelecektir. Eski kod olmamıza rağmen, değer sağladığımız için önemli değil. Diğer kod tabanları işlem ve gecikmeler ister, ancak sağlıklıyız. "
"Öyleyse neden bizi yönetecek özel bir ekip yok?"
"İnsanlar mühendislik ekiplerini yeniden düzenlemeyi severler. Bunlar etki alanlarına, mikro hizmetlere veya alt sistemlere bölünecekler. Çoğu zaman, insanların organizasyon yapısı ayrılmadan önce zaten varız. Her zaman belirsizliğin küçük köşesinde olacağız ve unutulacağız. Ama hangi takımda olurlarsa olsunlar bizi görecek bazı dikkatli insanlar var. "Bu çok akıllı kod dedi.
"Eh. İyi çalıştığımız için, insanlar başka şeylerle meşgul ve bizi unutuyor, değil mi?"
"Bunu söyleyemem. İnsanlar varlığımızı biliyor. Katkımızı biliyorlar. Sadece yeni bir şekilde çalışmak istiyorlar. Bazen yeni teknolojilere ve araçlara yatırım yapıyorlar. Sık sık hangi ürünlerin üretime gireceğini merak ediyorum. Unutmayın, üretim öz değerimizi gösterdiğimiz yerdir. "
Little Code mutlu bir şekilde "Her zaman prodüksiyondayım ..." dedi, "Teşekkürler."
"Rica ederim."
Küçük kod aniden durdu, döndü ve gülümsedi ve şöyle dedi:
"Biz eski kod değiliz ... biz efsaneyiz. " "Bu bizim ruhumuz. Değer veriyoruz ve bu dünyaya gelmemiz bizim için değerlidir. Bununla gurur duyuyoruz."
Yukarıdakiler bir peri masalıdır, ancak bu hikayede gösterilen sorun çok gerçektir. Lütfen, yazılımın neden yöneticiyi kaybettiğini ve kimsenin sevmediği, üzgün ve yalnızlık duyduğu küçük kodların üretilmesini nasıl önleyeceğimizi görelim.
Yazılım sahipliği eksikliğinden kaynaklanan sorunlar
Kod tabanının bir kısmının açık bir sahibi olmadığı zaman, sorunlar ortaya çıkacaktır. Bir soruna neden olmasa bile er ya da geç çökecektir.
Aşağıdaki işaretler, kodun sahiplik sorunları olduğunu gösterir:
-
Sistemde yönetilmeyen bileşenler var mı?
-
Kod tabanında yeni çalışanlara tanıtmanız bile gerekmeyen bir yer var mı?
-
Kodun veya sistemin bazı bölümleri, eski günlerin uzmanlarının ve kahramanlarının kabile bilgilerinden mi geliyor?
Yukarıdakilerden birine denk gelirseniz, eski kodla ilgili bir sorununuz olması muhtemeldir ... uh ... efsanevi kod.
Kodu gönderdikten sonra, kod başkalarına verilirse, buna sahiplik denmez, daha çok süresi dolmuş bir kiralama gibidir. İşlev, alt sistem veya uygulama piyasaya sürüldüğünde, bakımından kim sorumludur? Bu görevleri operasyon ekibine veya diğer şanssız ekiplere mi gönderiyorsunuz? Bu, kod tabanını korumanın en iyi yolu değildir, çünkü neredeyse hiç etki alanı bilgisine sahip değildirler ve altyapının istikrarını koruyamazlar veya yükseltme ve iyileştirmeler yapamazlar.
Kod sahipliği ne zaman gereklidir?
Üretimdeki tüm kodun birileri tarafından bakımı mı gerekiyor?
Genellikle sektörümüzde, SRE (Site Güvenilirliği Mühendisliği, web sitesi güvenilirliği yönetimi) ekibinin görevi, tüm hasarlı şeylerden sorumlu olmaktır. Yazılımın açık bir sahibi olmadığında, SRE sığınağına girmesi gerekir.Zamanla, SRE ekibi bir dizi dijital enkaz biriktirir.Ayrıca, sistem politikalarının çalıştığından emin olmaları gerekir. Ancak bu, SRE için çok haksızlık, biraz da yeteneklerini boşa harcıyor. Peki işler bu noktaya nasıl gelişti?
Genellikle, bir geliştirme ekibinin performansını ölçmenin göstergesi, yeni özelliklerin sunulma veya geliştirme hızıdır. Ancak, gerçek performans ölçümleri bu bakış açılarından gelmez ve aynı zamanda çalışabilirlik, izlenebilirlik ve kütüphaneyi güncel tutma için ödüllendirileceklerdir ... Temelde bunlar işlev değildir. Geliştirme ekibi bakım sorumluluğunu görmezden geldiğinden, bu sorumluluk genellikle sonunda operasyon ekibine düşer. Operasyon ekibinin performans göstergeleri istikrar ve güvenilirliktir. Sistemi korumak için Newtonun üçüncü hukuk sistemi yönetim yöntemini kullanabilirler, yani "Sisteme dokunmadığınız sürece normal şekilde çalışmaya devam edecektir." Bu durumun ancak bir süre korunabileceğini biliyoruz, ancak ondan önce, Operasyon ekibi bunu yapacak.
Sahiplik neden belirsiz?
Bir yazılım parçasının mülkiyetini kaybetmenin veya belirsiz bir sahipliğin dört ana nedeni vardır:
-
Kodu yazan kişi gitti;
-
Eskiden bir sahip vardı, ancak ekibin yeniden düzenlenmesi nedeniyle sahiplik devredildi veya kayboldu;
-
Eski yazılım terk edildi, ancak yeni yazılım onu tamamen değiştiremedi;
-
Başından beri net bir sahiplik modeli yoktu.
Kulağa basit gelen bir cümle var, ama yine de vurgulamak istiyorum: kodu yazdıktan sonra arkanı dönüp gidemezsin - ama insanlar bunu her zaman yapar.
Fonksiyonel testler tamamlandıktan sonra ekip kaçınılmaz olarak değişecek ve kendilerini yeni projelere adamaları gerekecek. Yerleşik yazılım üretime alındı ve birçok kişi bu özellikleri kullanıyor ve bunlara güveniyor. Bu insanlar yazılımın çalışmaya devam etmesini ister ve çoğu zaman birinin yazılımı geliştirmesini isterler. Bununla birlikte, çoğu durumda, bir ürün veya işlev bir kez kullanılmaya başlandığında geride kalacaktır.
Bu, uygulanabilir ürün geliştirmeyi en aza indirmenin kaçınılmaz sonucu olabilir: ürünleri hızlı teslim etmek ve hızlı geri bildirim almak. Ancak sorun şu ki, bu modelin genellikle eksik olduğunu görüyoruz Değerli verileri topladıktan ve geri bildirim döngüsünü tamamladıktan sonra, modelin planı sona erdi. Ancak insanların genellikle gözden kaçırdığı bir şey de, geribildirim almak için kullanılan yazılım ne olacak? Bunun olmasını önlemek için baştan eksiksiz adımlar atmalıyız.
Yazılımın sürekli sürdürülebilirliğini planlamak, yazılım oluşturmanın sorumluluğunun bir parçasıdır. Kod yazmak ve teslim etmek bir başarı duygusudur, ancak işiniz kodu yazdıktan sonra burada bitmez. Asıl iş, kodu sürekli olarak korumak ve güncellemektir.
Kalıcı işletim maliyetleri ile karşılaştırıldığında, yazılımın ilk geliştirme maliyetleri neredeyse göz ardı edilebilir.
İnsanları yazılımın sahipliğini almaya nasıl teşvik edilir?
Ya da bir kod sahibini kaybederse ne yapmalısınız?
Birçok kuruluş, ayrı kod projelerine sahiplik atamak için Spotifyın guild veya Valvenin kabineleri gibi Overlayed Matrix Modelini kullanır. Denedik ama dürüst olmak gerekirse bu yaklaşımın etkili olduğunu düşünmüyorum. Özünde lonca çalışması ana işiniz değildir. Bu nedenle, loncadaki performansınız performans değerlendirmesine yansıtılamaz. Bu nedenle, bu yöntem gerçekten sahiplik sorununu çözmez. Ve bu yöntem sorumlulukları zayıflatacaktır.
Aşağıdakiler, uygulanabilir olduğunu düşündüğüm bazı yollar:
-
Bazı şirketler, ekibin bakım için sorumluluk almasına izin verir. Ekibinizin planlama ve ödemeden sorumlu olduğunu varsayalım. Şu anda izole bir proje zaten çevrimiçidir. Planlama ve ödeme ile hiçbir ilgisi olmasa da ekibinizin sorumluluğu olacaktır. Bu yöntem loncadan daha etkilidir çünkü takımın üstlendiği iş performans değerlendirmesine dahil edilmiştir. Ancak bazı insanlar bu yöntemi sevmiyor çünkü biraz kafa karıştırıcı ve görevin sorumluluklarının ekibin temel alanıyla ilgisi yok. İnsanlar mükemmel dünyayı severler ama biz mükemmel bir dünyada yaşamıyoruz. Bir üretim ortamında çalışan herhangi bir kod, birinin bakımından doğrudan sorumlu olmasına ihtiyaç duyar, sahibi ideal olmasa bile, hiç yoktan iyidir.
-
Diğer bir strateji, kod tabanında erken ortak uygulamalar oluşturmaktır. Bir geliştirici aynı anda birden fazla benzer kod tabanını düşünürse, bu kod tabanlarında çalışırken düşünme maliyeti kaçınılmaz olarak azalacaktır. Bu ortamda, test etme, oluşturma, dağıtma ve güncelleme işlemleri aynı şekilde çalışır.Bir kod tabanını koruyan herkes devreye girebilir ve başka bir kod tabanını koruyabilir. Kullanılan dil veya etki alanı modeli farklı olsa da, aynı araçları kullanabilirsiniz. Geliştiriciler soyutlama yoluyla test çalıştırmaya odaklanabilir, aynı şekilde derleyebilir, aynı şekilde test edebilir ve aynı şekilde dağıtabilirsiniz.
Sonuçta, kod sahipliğini geliştirme konusu, yazılımın tasarlanma ve oluşturulma şekli ile ilgilidir. Özellikle, yazılım tasarlarken, görevlerin atanması, değerlendirilmesi ve izlenmesi dikkate alınmalıdır.Doğru yazılım yazmaktan daha yüksek bir seviyenin amacı, yazılımın normal çalışıp çalışmadığını doğrulayabilmektir. Tasarım yaparken problemleri teşhis etmeyi düşünmek istiyorsanız, geliştiricinin niyetlerini önceden anlamalısınız. Normalde, operasyonel bir görev almadıkları sürece böyle bir niyetleri yoktur.Bu nedenle, performans değerlendirme maddelerine uygun denetim hedefleri ve hata ayıklama hedefleri ekleyebilirsiniz.
Yazılım sahipliğinin projenin işlevi ile hiçbir ilgisi yoktur. Bu, işletmek, ölçmek ve bakımını yapmak için zaman harcayan insanlarla ilgili bir sorudur. Unutmayın, yazılımda yeni özellikler geliştirmenin maliyeti, uzun yıllar veya uzun dönemlerdeki operasyon, güncelleme ve bakım maliyetlerine kıyasla neredeyse sıfırdır.
Yazılımın sahipliğinin olmaması basit bir sorun değildir, işte önerilerimden bazıları:
-
Bir işi üstlenmeye isteksiz olsanız bile, bu işin ortadan kalkacağı anlamına gelmez. Ekibin yeniden düzenlenmesi yoluyla iyi planlamanız ve bu işi gelecekte iyi yapmak için bakım planları geliştirmeniz gerekir.
-
İşletmeyi yürütmek için kod tabanına yeni çalışanları tanıtın. Yaygın bir sorun, yeni gelenlerin yeni işi devralmalarına izin verilirse, eski sistemin işini üstlenebilecek geliştirici veya mühendislerin oranının azalmasıdır. Bu, kahramanca bir kültür üretecek ve genişlemeye uygun değil.
-
Kod tabanını devralanlar gerçek durumu anlamadılar. Belki iki yıl içinde bu kişi işinizi devralır. Her kararın arkasındaki nedenleri ve kararın içeriğini kaydetmeniz ve kodu gönderirken iyi yorumlar doldurmanız gerekir.
-
Geliştiriciler için "Başarı ve başarısızlık kodu", eski kodu terk etmeye veya sistemin işlevlerini değiştirmeye istekli olduğunuzda artıları ve eksileri tartmanız gerekir. Ancak, sevgili küçük kodumuzu ve yıllar boyunca sağladığı tüm işlevleri, işlemleri, kullanıcıları, fonları ve verimi lütfen asla unutmayın. Küçük kodun biraz sevgiye ihtiyacı var, daha alması gereken uzun bir yolu var.
Orijinal: https: // circleci .com / blog / küçük-eski-kod-olabilecek-bir-yazılım-sahipliği-sahipliği-/
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
SON
