Kod sahipliği bir kod kokusu mu?


27

Bu tartışmalı programlama görüşleri başlığında bu cevabı okuduğumdan beri düşündüğüm bir şey :

İşin, kendini işten çıkarmak.

İşvereniniz için bir yazılım yazarken, oluşturduğunuz herhangi bir yazılım, herhangi bir geliştirici tarafından alınabilecek ve minimum çaba ile anlaşılabilecek şekilde yazılmalıdır. İyi tasarlanmış, açık ve tutarlı bir şekilde yazılmış, temiz bir biçimde biçimlendirilmiş, olması gereken yerde belgelendirilmiş, beklendiği gibi günlük olarak inşa edilmiş, depoya kontrol edilmiş ve uygun şekilde sürümlendirilmiştir.

Eğer alırsanız bir otobüs çarptı , işten, ateş, ya da işi çekip, işverenin bir an fark sizi değiştirmek gerekir ve sonraki adam, rolünüz adım kodunuzu almak ve yukarı olmak ve olabilir bir hafta içinde koşuyorlar. O yapamazsa, o zaman sefil başarısız oldun.

İlginç bir şekilde, bu amacın benim işverenim için beni daha değerli kıldığını gördüm. Tek kullanımlık olma çabası arttıkça, onlar için daha değerli oluyorum.

Ve bu gibi diğer sorulara, içinde biraz tartışıldı bu bir , ama daha nokta taslaktan görüşmek üzere tekrar gündeme getirmek istediğini " bir kod koku !! " bakış açısı - gerçekten örtülü edilmemiştir hangi Henüz derinlemesine.

On yıldır profesyonel bir geliştiriciyim. Herhangi bir iyi yeni geliştirici tarafından kodun nispeten hızlı bir şekilde alınabilmesi için yeterince iyi yazılmış bir işim oldu, ancak çoğu sektörde, çok yüksek bir sahiplik düzeyi (hem bireysel hem de ekip sahipliği) olduğu anlaşılıyor. norm. Çoğu kod tabanının, yeni bir geliştiricinin bunları alıp hızlı bir şekilde çalışmasını sağlayacak belgelere, sürece ve “açıklığa” sahip olmadığı görülüyor. Her zaman sadece kod tabanını çok iyi bilen ("sahibi") birisinin bildiği, yazılı olmayan küçük numaralar ve kesitler vardır.

Elbette, bununla ilgili bariz sorun şudur: Ya kişi istifa ederse ya da "bir otobüse çarptıysa"? Ya da takım düzeyinde: peki ya tüm ekip ekip öğle yemeğinde dışarı çıktıklarında yiyecek zehirlenmesi geçirirse, ve hepsi ölürse? Ekibi nispeten acısız bir şekilde yeni bir rastgele geliştirici grubuyla değiştirebilecek misiniz? - Geçmiş işlerimin çoğunda, bunun olduğunu hayal bile edemiyorum. Sistemler o kadar çok hileyle ve hack ile doluydu ki, “ bilmek zorundasınız ”, işe aldığınız her yeni ekibin işleri tekrar yürütmek için karlı iş döngüsünden (örneğin, yeni kararlı sürümler) çok daha uzun sürdüğünü belirtti. Kısacası, ürün terk edilmek zorunda kalırsa şaşırmam.

Açıkçası, bir kerede bütün bir takımı kaybetmek çok nadir olurdu. Fakat bunda daha ince ve kötü bir şey olduğunu düşünüyorum - bu konuyu daha önce tartıştığımı görmediğim için bu konuyu başlatmayı düşünmemi sağlayan nokta budur. Temel olarak: Kod sahipliğine yüksek bir ihtiyaç duymanın teknik borcun bir göstergesi olduğunu düşünüyorum . Süreç eksikliği, iletişim, iyi tasarım, sistemde “bilmeniz gereken” birçok küçük hile ve saldırı varsa, bu genellikle sistemin giderek daha derin ve daha derin bir teknik borç alması anlamına gelir.

Ancak mesele şu ki - kod sahipliği genellikle bir projeye ve şirkete bir tür "sadakat", işiniz için "sorumluluk almanın" olumlu bir şekli olarak sunulur - bu nedenle doğrudan kınamaya alışmadık. Ancak aynı zamanda, denklemin teknik borç tarafı genellikle kod tabanının giderek daha az açık olması ve birlikte çalışmanın zorlaştığı anlamına gelir. Özellikle insanlar ilerledikçe ve yeni geliştiricilerin yerini alması gerektiğinde, teknik borç (bakım) maliyeti artmaya başlar.

Bu nedenle, bir anlamda, kod sahibi olma ihtiyacının yüksek düzeyde açıkça bir iş kokusu olarak görülmesi (popüler programcının imgeleminde), mesleğimiz için iyi bir şey olacağını düşünüyorum. Çalışmalarında “sorumluluk almak ve gurur duymak” olarak görülmek yerine, “kendini işe almak ve teknik borçlarla yapay iş güvenliği yaratmak” olarak görülmeli.

Testin (düşünce deneyi) temelde olması gerektiğini düşünüyorum: Ya kişi (ya da gerçekten de tüm takım) yarın Dünya'nın yüzünden kaybolursa. Bu projenin muazzam - muhtemelen ölümcül - bir sakıncası olur mu, yoksa yeni insanlar getirebilir miyiz, onları doccoları okumalarını ve dosyaları yardım etmelerini ve kodla birkaç gün boyunca oynamalarını sağlayabilir miyiz? birkaç hafta içinde iş (ve bir ay ya da öylesine bir tam verimlilik geri)?


3
Sorun nedir? Ayrıca, "kod kokusu" nedir?
CamelBlues

2
@CamelBlues: " Kod kokusu , bir programın kaynak kodunda muhtemelen daha derin bir sorun olduğunu gösteren herhangi bir belirtidir." (Wikipedia) Bu sitedeki kod kokularıyla ilgili pek çok soru için bu aramaya bakın .
Carson63000

4
Kod mülkiyeti değil mi bir sonuç kodunun değil kod sahipliği kokuyor bir olan kod koku? Bunun da dahil olmak üzere diğer sorularla aynı soru olduğunu düşünüyorum: programmers.stackexchange.com/questions/48697/…
Rei Miyasaka

1
Benim için "sorumluluk alma / sahiplik"! = "Kod sahipliği" için, son zamanlarda bir yöneticiyle kod sahipliğinin biraz kötü olduğu ve insanların sorumluluktan vazgeçmesine izin verme ile aynı olmadığı konusunda bir tartışma yaptım. Bu yönetici kodunun mülkiyeti, sorumlu olmakla aynı şeyi ifade ediyordu.
Thomas James,

1
Evet, bu Q'nun neyi tanımladığı gibi demek için hiçbir zaman kod sahibi olmadım. Bana sahip olmak, korkunç otobüs olayından sonra beni değiştiren adamın kodumu okuyabileceği anlamına geliyor, çünkü kendi kişisel bebeğimmiş gibi gurur duydum.
Erik,

Yanıtlar:


32

Kod sahipliği arasında bir fark yaratmamız gerektiğini düşünüyorum:

  • sorumluluk açısından,
  • Kod stili / kesmek vb. bakış açısından.

İlki teşvik edilmelidir. Düşük kaliteli kod ve hatalardan kimse sorumlu değilse, kötü şeyler olacaktır . Bu, kendi kodunuzla ilgili hatanın size her seferinde atanması gerektiği anlamına gelmez: kod doğru yazılırsa, herhangi biri hatayı kodun herhangi bir bölümünde düzeltebilir. Ancak yaptığınız hatalar hakkında herhangi bir geri bildiriminiz yoksa, aynı hataları tekrar tekrar üreteceksiniz .

Kod sahipliği hem yöneticilere hem de geliştiricilere, özellikle geliştiricilere çok yardımcı olabilir. Projede çalışan üç geliştiriciyken üründeki hataların% 80'inin kodumda olduğunu ve bu hataların% 75'inin SQL Injection ile ilgili olduğunu bilirsem, bir dahaki sefere kod yazarken daha dikkatli olurdum ve Veritabanı sorgularını doğru yazmak için fazladan çaba gösterin.


İkincisi (kod stilinden / bilgisayar kodundan kod sahipliği vb.) Çoğunlukla kötü bir şeydir. Ürüne ne getiriyor? Ürünün kalitesini artırmaz, ancak kaynak kodunun tek biçimliliğini azaltır ve son zamanlarda bakımını zorlaştırır .

Birçok büyük projede, insanlar aynı kod parçasında çalışarak yaşam boyu kalmazlar. Ve burada, geliştiricinin otobüse çarpması gibi korkunç şeylerden bahsetmiyorum bile: Bu durumda kod sahipliğinin ilk mesele olduğunu sanmıyorum. Ancak pek çok küçük düşünce var: insanlar gelişimden yönetime veya başka işlere geçiyorlar, başka projeler seçiyorlar, başka şeyler üzerinde çalışıyorlar veya başka bir dil kullanmaya başlıyorlar (eğer bir projede birkaç dil kullanılıyorsa), vb.

Bir projenin bir kodunun parçası başka bir projede de kullanılabilir ve bu diğer projede çalışan geliştirici, kodun eski yazarına tavsiye vermeden kodun bazı kısımlarını yeni ihtiyaçlara uyacak şekilde değiştirmek ister.

Kod kokusu mu? Kod kokusuyla ne demek istediğine bağlı. Benim için her şey projenin genel tutarlılığı ve doğru yönetim ile ilgili . İyi bir projede

  • kod stili yönergeleri daha sonra kodu daha kolay anlamaya yardımcı olmak için uygulanır,
  • daha deneyimli geliştiriciler KISS ilkesini ihlal etmiyor, bu nedenle daha sonra daha az deneyimli olan meslektaşlar tarafından kaynak kodun anlaşılmasına yardımcı oluyorlar.

Sonuç olarak, kod sahipliğinin sürüm kontrolü aracılığıyla izlenmesi gerekir, ancak bir takım kodun sizin veya bir başkası tarafından bir takımda yazıldığını söyleyemezsiniz .


9

Öncelikle “kod sahipliğinin” ne olduğunu tanımlamamız gerekir.


Bir kod parçası (parçası) geliştirilmekte olan erken bir süreçte olduğunda, genellikle bir veya iki kişiyi "sahip" olarak belirtmek gerekir, çünkü:

  • Başlangıçta açık bir spesifikasyon ya da gereklilik yoktur ve geliştiricilerin kendi başlarına bilgi toplamaları gerekir. Bu bulguların toplanması ve belgelendirilmesi arasında bir zaman aralığı vardır.
  • Kod parçası etkin olarak değiştirilirken çakışan düzenlemelerden kaçının.
  • "Sahip (ler)", özellik geliştirmenin ilerlemesini rapor edebilecek kişi (ler) dir.

Normalde her görev için tek bir sahip var. Çift sahipler Çift programlama ile mümkündür. Dar bir şekilde belirlenmiş “kod sahipliği” olmadan yapması pratik olmaz.

Not:
MainMa en @ bakınız yanıt gelişimi sırasında diğer sorunlardan sorumlu değildir. Bu durumlarda, "kod sahipliği", daha büyük sorunların bir belirtisidir, yani: en düşük mimarlık seçimi, kodlama stili tutarsızlığı ve genellikle kod kalitesinin olmaması.


Bir parça kod tabanına yazıldığında ve kabul edildiğinde ("tamamlandı"), daha genel "kod sahipliği" sorusu belirir.

  • Bu kod parçası / işlevselliğin bu bölümü hakkındaki tüm soruları cevaplayabilecek uzman kim?
  • Bu bilgi gereksinim belgesi, birim testleri, kabul testleri, değişiklik kayıtları, proje wiki vb. Gibi maddi eserlerde yakalandı mı?

Her zaman etki alanı bilgisinin (müşterilerin gereksinimlerinin tam anlaşılması, ark sistemleriyle uyumluluk sorunları vb.) Yazılı şartnamelere biçimlendirilmesi zor olan bir kısım olacaktır. Bu nedenle, bir felaket olayı gerçekleştiğinde, bir miktar etki alanı bilgisi kaybı beklenmelidir.

Alan bilgisinin kaybıyla birlikte, sistemin ayrıntılarını açıklayabilecek uzman cevaplayıcıları da kaybedeceksiniz. Bu açıdan, uzmanın kaybı evrensel olarak kötü bir şeydir. Bilgi daha önce alınmış olmalıydı.

Bu, "uzmanların" varlığının kötü olduğu anlamına gelmez: Uzmanları yazılı bilgilerin bir "önbelleği" olarak kabul edin. Uzmanlar genellikle soruları cevaplamaktan ve yazılı bilgiyi bulmaktan ve özetlemekten daha hızlı cevap verebilirler.


Ancak, bazen "kod sahipliği", dışarıdan kişilerin kodu değiştirmesini önlemek için bir projenin aktif geliştiricileri tarafından oluşturulan engelleri ifade eder.

  • Bu kod parçasında kim değişiklik yapabilir?
    • Bariz hataları düzeltmek için?
    • Kodu diğer bazı gereklilikleri yerine getirmek için?
    • Kodu tamamen zevkinize göre yeniden yazmak için?

İyi engeller ve kötü engeller var:

  • İyi engeller
    • Etki alanı bilgisi - gereklilikleri ve mimari / kodlama stilini ne kadar iyi anlıyorsunuz?
    • Programlama ve tasarım becerisi - projenin tasarımını ve kod kalitesini iyileştirme becerisine sahip misiniz?
  • Kötü engeller
    • Orijinal geliştirici ekibindeydiniz, bu nedenle değişiklik yapmanıza izin verilmiyor.
    • Sadece hata düzeltmeleri kabul edilir. Özellik geliştirmeleri kabul edilmez.

Bu durumda, başka bir projenin kaynak kodunu düzenleme ayrıcalığı kod sahipliğine dayanmamalı, ancak değere dayalı olmalıdır.


Son olarak, @Ghamham Lee'nin cevabı departmanlaşmanın neden olduğu bilgi ve mimarlığın parçalanmasına işaret ediyor.

Bu durumda, "kod sahipliği" bölümlenmenin belirtilerinden biridir. İkinci belirti ise "diğer takımın projelerine ilgi göstermemesi". Bir kuruluş olarak, yöneticilerin ekipler ve departmanlar arasında bilgi aktarımı ve işbirliğini teşvik etmek için adımlar atması gerekecektir.


7

Daha sinsice, bazı şirketler (birinde çalıştım) yönetim yapılarını işlevsel ekipler etrafında düzenlerler: Windows istemci geliştiricilerini yönetirsiniz, kurucu ekibi yönetir, arka uç geliştiricileri vb. Yönetir. Bu sadece tanımladığınız güçlü kod sahipliğine yol açmakla kalmaz, aynı zamanda işlerin nasıl yürüdüğünü de gösterir. Yazılım mimarisini politik bir çatışmaya dönüştürür.

Bu bir sorun mu? Mimarinin-veya-alt-hale gelmesi durumunda. Örneğin, kurulumcunun daha iyi çalışacağını veya müşterinin sadece bir kullanım durumuysa gelişmesi için daha ucuz olacağını söylemek imkansızdır, çünkü bu bir ekip ve yöneticisinin kontrolünü elinden alır. İşlevsel modüller arasındaki bölünmeler, mühendislik departmanının çalışma şekli ile ilgili gerçekler haline geldi ve bu gerçekleri değiştirmek için büyük bir moral bozuyor.

[Yukarıdaki tartışmayı açıklığa kavuşturmadığı takdirde BTW, sorunuza cevabım evet. Kod mülkiyeti bir kod kokusudur, çünkü iyi fikirleri olan zeki insanları, hatta kod üzerinde çalışmanız gerektiğinde mevcut olan insanları bile durdurabilir. Açıkçası, kaprisli değişiklikleri durdurmak için kontrollere sahip olmak iyi bir şeydir, ancak bir hatayı nasıl düzeltebileceğini görebilecek ve bunu yapacak vakti olan bir mühendisiniz varsa, bu mühendisi bloke etmemelisiniz çünkü bir başkası buggy kodunu yazmıştır. ]


6

Sorunuzu biraz farklı bir bakış açısıyla ele alarak, kod sahipliği bir kod kokusu DEĞİLDİR. Bunun yerine bir yönetim ve kaynak kokusu .

Bir kod kokusunun ne anlama geldiğini düşünün. Kodunuza baktığınızda, yazılımın kodunda ve / veya tasarımında bir şeylerin doğru olmadığını söyleyen bir metafordur, ancak sorun, parmağınızı neye koyacağınız kadar açık olmayabilir. Kesin sorun olabilir ama ne olursa olsun muhtemelen iyi bir fikrin var. Evinizde, eğer bir şey kötü kokarsa, sorunun kaynağını bulana kadar burnunuzu takip edersiniz ve sonra bu konuda bir şeyler yaparsınız. Aynı şekilde, eğer kodda bir problem varsa, daha az problem çıkana veya bazılarının söyleyebileceği gibi güzel veya iyi hazırlanmış hale gelinceye kadar onu araştırıp değiştirirsiniz .

Öte yandan kod sahipliği ciddi bir sorun olabilir. Gözetim eksikliği ve kod sahibi ayrılırsa, kod ve çözdüğü belirli sorunlar hakkındaki bilgilerin artık şirket için geçerli olmayacağı riskini ortaya koymaktadır. Bunun gerçek kodun kendisi ile ilgisi yok. Temel olarak, risklerimizin bir sonucu olarak, verilerimizi yedeklememize yol açar ve aynı şekilde görev sahipliği veya şirketin diğer alanlarındaki belge sahipliği için de aynı şekilde uygulanır.

Diğer işletme sorunlarını koku olarak tanımlamanın iyi olduğunu düşünüyorum , ancak kesinlikle sadece bir koku olduğu için, özellikle de kodla ilgili olduğu anlamına gelmez .


1

Gelecekte kodunuzun üzerinde çalışacağını kabul ederek, Kod Sahipliğini yazdığınız kod için kişisel sorumluluk olarak tanımladım . Böyle şeyler düşünürseniz, bilgisayar korsanlığı yazma olasılığınız düşük olacaktır, çünkü a) bu modüldeki hatalar size geri izlenebilir ve b) ekip üyelerinin gelecekte kodu değiştirmek için zor zamanları olabilir .

Birkaç ay önce bunun üzerine bir blog yazısı yazdım , burada kod sahibi olmadan, tanımladığım gibi bir kod temeli sık sık Commons Trajedisine düşüyor .

Kod sahipliği tanımınıza göre, yalnızca yazarın çalışabileceği bir koda sahip olmanın kötü olduğunu kabul ediyorum.


Daha çok "kodlu" veya "kodlu" (la bebek) "gibi görünüyor. Cevabınızdaki her şeye katılıyorum.
Mawg
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.