Verimliliği ölçmek için bilinen SLOC kullanımları var mı?

Dinamik ve statik diller konusunda çok kıdemli bir mimarla alışılmadık, kısa bir konuşma yaptım. Şirket verilerinin, statik diller kullanıldığında daha yüksek verimlilik için kanıt olduğunu gösterdiğini söyledi. Not, uzun geçmişi olan büyük bir şirket. Sürprizime (ve diğerleri) şaşırtmak için kullandığı metrik kod satırlarıydı.

Aynı şirkette, benzer kültürde, iş kolunda ve yeterli veride, (bireylerin benzersiz durumları ve yeteneklerine göre) farklılıkların, SLOC metrikinin verimliliğini karşılaştırmak için yararlı olması için yeterince harmanlandığını söyleyen metrikle ilgili itirazlarını çabucak reddetti. Araçlar ve diller

Bu iddianın titiz istatistiksel analizlerle desteklendiğini düşünmemekle birlikte, sektörde bu düşünce biçimini destekleyecek bazı kanıtlar var mı?

Üst düzey mimarın argümanı iki anlama gelebilir.

1. Şirketteki ortalama bir geliştiricinin , statik dilleri kullanırken dinamik dilleri kullanmaktan daha fazla kod satırı ürettiği anlamına gelebilir . Örneğin, on beş geliştirici altı ay boyunca Java ile çalışıyorsa, 100 KLOC yazacak ve aynı onbeş geliştirici Python ile altı ay çalışacaksa, yalnızca 50 KLOC yazacak.

   Burada LOC ile verimlilik arasında bir ilişki yoktur. Java'da Python'da olduğu gibi aynı özelliği oluşturmak dört kat daha fazla kod satırı gerektiriyorsa ne olur? Bu doğruysa, Python kullanmak yukarıdaki KLOC metriklerine göre iki kat verimlilikle sonuçlanacaktır.

2. Ayrıca, şirketteki ortalama bir geliştiricinin, statik dilleri kullanırken dinamik dilleri kullanmaktan daha az sayıda kod satırı ürettiği anlamına gelebilir : onbeş geliştirici, altı ay içinde Java’da 100 KLOC veya Python’da 200 KLOC yazacaktır.

   Daha az kod satırı genellikle daha iyi olsa da (yazmak, okumak ve sürdürmek için daha az kod), Java geliştiricilerinin Python'lara kıyasla ne kadar özellik ürettiği henüz net değil. Belki Python geliştiricilerine kıyasla yarım satır kod yazdılar, ancak özelliklerin yarısını da ürettiler?

Her iki durumda da, LOC değerli bir metrik değildir, çünkü aynı özellik, farklı dillerde aynı miktarda kod satırında çeviri yapmaz . Bazı diller daha ayrıntılı olma eğilimindedir; diğerleri - daha kompakt. Bazı durumlarda, kompaktlık değerli olsa da, bunun için genel bir kural yoktur. Aşırı bir örnek, aşırı kompaktlığa sahip ancak okunabilirliği açısından popüler olmayan Brainfuck dili olabilir. Benzer dilleri bile karşılaştırmak zor olabilir: örneğin, küme parantezleri söz konusu olduğunda, Java K&R stilini takip ederken, C # 'da, açık küme ayracı, yapay bir stil uygulayan resmi stili takip ederken çoğu durumda kendi satırındadır. C # için LOC'lerin artışı. Ve bir prosedürel dili nesne yönelimli bir dille veya işlevsel bir dille karşılaştırdığında ne olur?

Hataya yatkın bir metrik kullanmak yerine, kıdemli mimar birlikte kullanıldığında verimliliği ölçen bir grup metriğe güvenebilir: birlikte geliştirilen özelliklerin sayısı, kod tabanına girilen hataların sayısı ve bu hataları çözmek için harcanan zaman , teknik borcun evrimi vb. Bu karşılaştırma başlangıçta zor olabilir, çünkü ekibin yeni dille olan bilinmeyenliğini hesaba katması gerekir. Takım yeterince aşina olduktan sonra, seçim, çoğunlukla, ekip üyelerinin kendilerinin tercihine bağlı olarak, istikrarlı ölçütlere dayanmalıdır.

LOC vardır bazı dar durumlarda bir değer. Örneğin, projenin büyüklüğü ve projenin bölümleri hakkında bir ipucu verebilir (ve ortalama olarak ölçülmesi daha kolay olmakla birlikte, fonksiyon noktalarıyla korelasyon gösterir) veya daha fazla dikkat edilmesi gereken metot ve sınıfları gösterebilir. onların büyüklüğü. Bununla birlikte, LOC dikkatli kullanılmalıdır, çünkü ilgisiz şeyler arasında bir ilişki olduğunu düşünen kişilerce çok kötüye kullanılır. LOC'lerin en insancıl felaket kullanımı, geçmişte, ayda bir yazılı LOC'lara dayanarak bireysel bir geliştiricinin verimliliğini ölçme girişimi idi.

Verimlilik ve SLOC hakkında

SLOC ile ilgili sorun

SLOC metriği ile ilgili problem, hesaba katılmadan yazılmış kod miktarının yaklaşık bir değerini ölçmesidir :

• Kodun kalitesi (yani, her 100 SLOC için, hatalar nedeniyle başka bir 90 SLOC eklemeniz gerekiyorsa, ancak kodunuzun verildiği anda bilmediğiniz bir durum varsa?)
• kodla ulaşılan hedefler (10K SLOC, beklenen tüm kullanım durumlarını veya kullanıcı hikayelerini mi kullanıyor? yoksa sadece küçük bir altküme mi?)
• Kodun korunabilirliği (diğer bir deyişle, kodu beklenen gelişen gereksinimlere göre ayarlamak için% 1 veya% 50 daha fazla kod eklemeniz gerekecek mi?).

Aksi taktirde, birçoğunun kopyayla yapıştırılan bölümüyle hataya açıklanamayan spagetti kodunun üretilmesi, dikkatlice tasarlanmış yeniden kullanılabilir koddan daha verimli olarak kabul edilecektir.

Bu yüzden SLOC kesin olarak verimliliği ölçmenin en iyi yolu değildir.

Hangi verimliliği düşünüyoruz?

Verimlilik bir işlem için ölçülür. Dolayısıyla SLOC, tek başına kodlama işlemi için mükemmel bir geçerli gösterge olabilir.

Örneğin, zayıf gereklilikleri yanlış anlarsanız, yazılımı üretmek için beş ay geçirirseniz, kullanıcıya gösterirseniz, yanlış olduğunu keşfederseniz ve sıfırdan başlayarak tekrar yazmak için 5 ay daha harcarsanız, SLOC’de aynı üretime sahip olursunuz. / ay, örneğin ilk kez doğru kodu yazan bir ekibin, örneğin sık sık geri bildirim yoluyla yanlış anlamaları azaltan çevik bir süreç kullandıkları için. Bu belirgin eşit verimlilik büyük problemleri gizliyor.

Bu nedenle, yazılım geliştirme verimliliğini ölçmek, gereksinimleri analiz etmek, neyin kodlanacağını tasarlamak, kodlamak, test etmek, hata ayıklamak ve kullanıcı beklentilerinin karşılandığını doğrulamak dahil tüm süreci dikkate almalıdır. Tüm bu faaliyetler çok farklı olduğu için en iyi şey, sadece önemli olan düşünceyi ölçmektir: çalışan yazılım, yani üretilen yazılım kullanıcı için ne anlama geliyor ?

Yazılım çıktılarını nasıl ölçebilirim?

Birkaç yaklaşım var:

• Klasik yazılım mühendisliğinde tipik yaklaşım İşlev Noktaları'dır (FP). İşlev puanları yerine getirilmesi gereken şartlara göre ölçülür (örneğin, form sayısı, her formdaki alan sayısı, vb.). Verimlilik daha sonra zaman başına ve kişi başına FP cinsinden ölçülür. Bazı şirketler, bir geliştiricinin belirli bir dilde belirli bir dilde zaman birimi başına ne kadar işlev noktası üretebileceğini söyleyen verilere de sahiptir. FP ile ilgili sorun, önceden çok ayrıntılı gereksinimler gerektirmesi ve zaman alıcı olmasıdır.
• Daha modern ve pragmatik bir yaklaşım hikaye noktalarıdır (SP). Bunlar, üretilecek kodun karmaşıklığını değerlendirmek için kullanılır ve geliştirme ekiplerinin hızını değerlendirmek için rutin olarak kullanılır. Bununla birlikte, SP tüm detaylar bilinmeden önce yapılan iş için bir tahmin önlemidir. Bu gerçekte ne olduğunun son ölçüsü değil. Bu nedenle, bir verimlilik ölçütü olarak kullanıldığında biraz dikkatli olunmalıdır, çünkü tahmin sürecini geri tepebilir .

Statik ve dinamik yazmanın üretkenliği hakkında

Şahsen statik olarak yazılmış dillerin hayranı olduğumu itiraf etmeliyim, çünkü kendi içimde daha güvenilir olduğunu biliyorum (yıllarca süren kodlama bana bunu kanıtladı).

Kesin olarak aldığım bir şey, statik olarak yazılan dilin, derleme zamanında (örneğin yazım hataları, beklenen türlerde uyumsuzluklar vb.) Statik olarak yazılmayan dillerden çok daha fazla hata / hata önleyebilmesidir. Ancak, tüm tarafsızlıkta, bunu daha yüksek bir verimlilik olarak kötüye kullanmaya cesaret edemem.

Mimarın doğru mu?

Belki, belki değil.

Ancak argümanları geçerli görünmüyor: statik olarak yazılmış dilin üretkenlik kazanımı, derleyici tarafından önceden tespit edilen önemli sayıda hatadan geliyor.

Sonuç olarak, bu "daha yüksek" verimlilik kazancını, dinamik olarak yazılmış diller için gereken yeniden işleme bakmadan yalnızca SLOC'ye bakarak bulmak mümkün değildir. Yani karşılaştırması adil olamaz.

Karşılaştırılabilir koşulların argümanı da geçerli değil. Bazı dinamik olarak yazılmış diller, klasik statik olarak yazılmış dillerden birinde aynısını yapmaktan daha az kod gerektiren bazı yüksek seviye yapılara izin verir. Böylece daha az zamana ihtiyaç duyabilir, daha az kod yazabilir, ancak aynı analizi, test ve ek yükü doğrulayın. Dolayısıyla, verimliliği SLOC tarafından ölçmek, potansiyel verimlilik kazanımlarını azaltacaktır, böylece dinamik olarak yazılmış bir dile karşı bir önyargı yaratacaktır.

Bu iddiayı destekleyen bir çalışma var mı?

Konuyla ilgili birkaç yeni akademik çalışma var. Bazıları statik yazmanın avantajını görmelerine rağmen, genel olarak belirli bir amaçla sınırlıdır (dokümantasyon, kötü belgelenmiş kodun veya API'nin kullanılması vb.). Modern IDE, dinamik yazma ile ilgili riskleri önemli ölçüde azalttığı için akıllıca kelimeler de kullanılır:

• Bir IDE varlığında API kullanımında statik ve dinamik tip sistemlerin ampirik bir karşılaştırması: Eclipse ile Java vs groovy , 2014
• Açık Tip Açıklamaların Verimlilik Etkilerini Düşünmek , 2014, ancak kesin değil
• Belgelenmemiş yazılımın kullanılabilirliği üzerindeki statik tip sistemlerin etkisinin ampirik bir çalışması

İşte kıdemli mimarınız için bir ön örnek: Temel sınıfın tanımladığı bazı sanal fonksiyonları uygulamak için, ikisi üçüncül olan üç sınıflı bir hiyerarşi yazmak istediğimi varsayalım.

Bu üç dersi C ++ 'da yazarsam, bu oldukça açık bir şekilde. Sınıfları ilan ediyorum, doğru yerlerde sanal kullanıyorum ve yapılması gerekiyor.

Eğer bu üç sınıfı C'ye yazarsam, biraz kod eklemem gerekecek: structv-tabloları için s tanımlamam gerekiyor, temel sınıfa bir v-tablo işaretçisi eklemem gerekiyor, eklemek zorundayım aslında v-tablo işaretçilerine ayarlamak için yapıcılara kod, aslında temel sınıf yapıcısını çağırmak için yapıcı kod eklemem gerekiyor, açıkça bir yapıcı çağırmadan önce bellek ayırma işlemini gerçekleştirmek için kod eklemeliyim (hangi C ++ newtek bir adımda? ), aynı şekilde, imhayı sonraki free()çağrıdan ayırmam gerekiyor , vb.

Mesele şu ki, bu ilave şeylerin hepsi oldukça akılsız. Onları çok hızlı yapabilirim. Bu yüzden, C sürümünü yazmam C ++ sürümünü yazmam gerekenden daha uzun sürmeyecek. Yine de, C ++ kodundan çok daha fazla C kodu satırı üretiyorum. Öyle ki, C içinde SLOC'ler açısından daha üretken görünüyorum.

Bir miktar boyler kodunu gerektiren herhangi bir dil, aynı miktarda boyler kodunu gerektirmeyen bir dilden SLOC'ler açısından daha verimli görünecektir.

Gördüğünüz gibi, SLOC argümanı temelde hatalıydı, aslında tam tersi göreceğim: "programcılar statik dillerde daha fazla SLOC üretme eğiliminde" ifadesini alırdım: "statik diller daha fazlasını gerektiriyor Kazan kodunu ve böylece verimliliği düşürün ".

Ben karşıt olacağım.

SLoC'yi işimizde takip ediyoruz (doğrudan personel kararlarında kullanmamıza rağmen) ve insanların çoğu insanın cevaplarında neler söylediğini tartıştık. Aslında, "LoC önemli değil çünkü X teknolojisi bize daha az kodla daha fazla şey yapmamızı sağlıyor" veya "Daha iyi geliştiriciler daha iyi, daha kısa kod yazıyor ve bu yüzden başkalarından daha fazla yazmıyorlar". Tecrübelerime göre (bu şeyleri destekleyecek zor numaralarım olmasa da), bu itirazlar doğru değil. Kendi zamanlarımda, geliştiricilerimiz için kod üretiminin hızı ve kalitesi ile mühendis olarak genel "yeterliklerinin" diğer tüm anlamlı ölçümleriyle karşılaştırıldığında net bir korelasyon gördüm. Yukarıda yapılan tartışma türlerine karşı bazı örnekler vermek için:

1. Evet, bazı diller daha az kodla daha fazlasını yapabilir. Aslında, belirli iş sorunlarımız için gelişimin büyük bölümünü "otomatikleştiren" (sadece arka uç) inşa ettiğimiz bütün bir çerçeveye sahibiz. Tüm bunların sonucu olarak, insanlar daha az kod yazmıyor, sadece kod yazmak için daha fazla zamanımız var. Sonuç olarak, şirketimizde, genel kod yazma oranı teknolojiler arasında oldukça sabittir ve temel olarak mühendisin yeterlilik seviyesine bağlıdır.
2. Daha iyi bir geliştiricinin daha az kod üreteceği fikri, çünkü daha akıllıca yazdıkları için kesinlikle doğru değildir. Evet, daha iyi tasarlanmış bir program daha az kod satırı alabilir. Bununla birlikte, şahsen daha verimli kod yazan "daha iyi" geliştiricilerin, daha küçük bir geliştirici yazmasıyla daha uzun zaman harcayacaklarından daha fazla zaman almadığını öğrendim. Sonuç olarak, daha kıdemli geliştirici kodlama görevlerini daha hızlı yerine getirecek ve aynı yüksek oranda farklı kodlar yazmaya devam edecektir.

Bu son bölüm benim genel özetim BTW. Bulduğum şey, teknoloji yığınına ya da projeye bakılmaksızın, çoğu geliştiricinin faaliyet gösterdikleri tempoda kendi hızlarına sahip olmasıdır. Bir dilin geliştiricilerin kodunu daha etkili hale getiren birçok özelliği varsa, bu iş için büyük bir nimettir, ancak bu sonuç olarak daha az kod yazacakları anlamına gelmez. Bunun yerine, özelliklerin daha hızlı yapılmasını sağlar ve hızlı bir şekilde yeni koda geçer. Yine, nihai sonuç, kodlama oranlarını temel olarak kendi becerilerine ve daha az da teknik yığınlarına bağlı olarak hesaplamalarıdır. Aslında, bu nedenle, genellikle teknoloji yığınının, biletlerin ve özelliklerin geliştirilme hızı üzerinde insanların kodladığı orandan daha fazla bir fark yaratmasını beklerdim.

Bununla birlikte, ne kod yazma oranı ne de bilet kapama oranı mükemmel bir verimlilik ölçütü değildir, bu nedenle doğrudan SLoC temelinde personel kararları almıyoruz. Bunun yerine sürecin bir parçasıdır ve çalışan değerlendirmeleri mümkün olduğunca çok veri noktası kullanılarak yapılır. Mimarın kesinlikle delice olmasa da söyleyebilirim.

Bir istisna

Kabul ettiğim tek istisna, kazan plakası kodunun olasılığı. Bir sınıftan (veya her neyse) diğerine geçip devam ettirmek için bir sürü kopyala ve yapıştır işlemi varsa, o zaman bu açıkça ölçümleri çarpıtır. Bu, sizin için büyük miktarda kod otomatik olarak oluşturabilecek araçlara sahipseniz de geçerlidir. Ancak, bunların kuraldan ziyade istisna olacağını düşünüyorum. Geliştiricileriniz başlamak için kazan plakası kodunu kopyalamak için herhangi bir miktarda zaman harcarsa, yanlış teknoloji setini kullanıyorsunuz demektir. Eğer gerçekten kod yazıyorlarsa, oldukça tekrarlı olsa bile, bunun sadece herhangi bir ölçümü çarpıtmasını beklerim: kod yazarken, çoğu zaman problemi ne kadar hızlı düşünebileceğimize bağlı olduğumuz için ne kadar hızlı yazabileceğimizden. Nispeten tekrarlayan kod yazarken bile,

Açıkçası, yukarıdaki her şey kendi kişisel deneyimime dayanıyor. Kilometreniz değişebilir ve açıkçası azınlıktayım. Katılmıyorum çekinmeyin. Özetle olsa:

Kodlama oranının, sorunlarınızdan sonra herhangi bir şeyden ne kadar hızlı düşünebileceğinize bağlı olduğunu biliyorum. Sonuç olarak, kodlama oranının sadece birkaç olası istisna dışında, teknoloji setlerinde bile iyi bir verimlilik ölçütü olduğunu buldum.

Yine de ben çoğunluğa atlıyorum. Programcıların davranışları üzerindeki etkisinin vurgulanması gerektiğini düşünüyorum.

SLOC'yi üretkenlik ölçüsü olarak kullanmak, programcının morali üzerinde toksik bir etkiye sahiptir. Takımınızdaki / şirketinizdeki herhangi bir mühendisin SLOC'da ölçüldüğünü fark ettiği anda birkaç şey olur:

1. Aynı işlevi yapmak için çok daha uzun kod yazmaya başlarlar.
2. kodlarının kalitesine daha az önem verecekler
3. Takımınıza yardımcı olacak başka şeyler yapmayı bırakacaklar (işe alım, hata ayıklama, gençlere yardım etme)
4. İşlerinden nefret edecekler ve muhtemelen ayrılacaklar

2 farklı şirkette iki kez olduğunu gördüğüm için moral vermenin ne kadar aşındırıcı olduğunu yeterince kuvvetle vurgulayamam. Gördüğü kadar geçerli kullanım durumları ne olursa olsun, kullanımının keşfedilmesi için küçük bir şans olsa bile, ekibiniz / şirketiniz üzerindeki etkisine değmeyeceğini düşünüyorum. Bazı durumlarda, yazılan satır sayısı ile faydalı özelliklerin miktarı arasında bir korelasyon olmasına rağmen, programcılarınızdaki tüm yanlış davranışları teşvik eder ve kalitenin önemli olmadığı mesajını gönderir.

Genel olarak verimliliği ölçmek için geçerli bir yol olarak kabul edilmez. Küçük kod genellikle daha büyük koddan daha iyidir, bu nedenle daha üretken bir geliştirici genellikle daha az kod üretir. Verimlilik hata ayıklamadaki en büyük isabetini alır; verimli geliştiriciler çok az zaman harcıyor.

Statik olarak yazılan diller daha üretkendir (diller arasındaki diğer tüm farklılıkları denetlerseniz), çünkü akıllıca kullanıldığında, hata ayıklama süresini kısaltır, derleme aşamasında hataları gidermek için hataları yakalarlar.

Geliştiriciler için üretkenliği diller arasında karşılaştırmak için kullanabileceğiniz tek ölçü, diller arasındaki kodu karşılaştırmayan bir ölçüdür. Bazı diller ünlü bir şekilde ayrıntılıdır (eski kazanma için COBOL) ve diğerleri bir kod satırında yapabileceğiniz bir şeyi yapmak için birkaç adım gerektirir (montaj vs. hemen hemen her şey). Yalnızca aktif kod satırlarını karşılaştırsanız bile (örneğin, bildirimleri saymaz ve yalnızca bazı eylemleri içeren kodu sayarsanız) sonuçlarınızı çarpıtabilirsiniz.

Değişim oranları için bir tartışma yapabilir. Diğer bir deyişle, aynı zaman diliminde verimlilik eğimini karşılaştırarak kod satırları eklenir. Ancak, bu kod satırlarındaki olumsuz değişiklikleri hesaba katmaz. Örneğin, her yere kopyalayıp yapıştırma kodu olan bir projeyi devralırsınız. Tekrarlanan kod bloklarının sayısını azaltmak için bazı hızlı ve kolay yeniden yapılandırmaları gerçekleştiriyorsunuz - tanım gereği negatif bir eğiminiz var.

Tüm ciddiyette, takımların / dillerin verimliliğini karşılaştırmak anlamsızdır, çünkü bir takımın verimliliğini etkileyen çok fazla ek faktör vardır, bu konuda anlamlı sonuçlar çıkaramazsınız.

Altyapının kırılgan olduğu ve araçların modası geçmiş olduğu bir proje üzerinde çalıştım. Proje, Java üzerine bir Tek Sayfa Uygulamasının üzerine tokatlanarak yapıldı, ancak görünür bir fayda sağlamak için bir portlet konteynerinde barındırıldı. Basit değişiklikler bile yapması gereken zaman gülünçtü. Tüm sonuçlarınızı o projeye dayandıracak olursanız, Java'nın kötü olduğu veya Tek Sayfa Uygulamaları'nın kötü olduğu sonucuna varabilirsiniz. İkisi de doğru değil. Çirkin projenin değiştirmesi gereken sistem C # ve WebForms üzerine kurulmuştu. Müşterilerimizin ihtiyaçlarını karşılamak için mevcut uygulamayı genişletmek için iş vakasını yaptığımızda, üretkenliğimiz hızlandı. Bu, sıkı sıkıya bağlı bir WebForms uygulamasının üstün olduğu anlamına mı geliyor? Bu sonucu yalnızca bu özel dava için yapabilirsiniz.ve genel olarak dünyaya yayılmaz. Ve bu sadece mantıklıdır çünkü uzatmak için yeterli vadeye sahip mevcut bir uygulama vardı.

Sorun takip sistemindeki sorun çözme oranlarının karşılaştırılması bile, tüm proje altyapılarını birbirleriyle karşılaştırmanız anlamında kusurlu. Kullanılan kütüphaneler ve çerçeveler ilerlemeyi hızlandırabilir veya yavaşlatabilir. Üstesinden gelmek için çok az atalet ile başlangıç ​​aşamasında olabilirsiniz; burada "daha iyi" olduğunuz proje, yeni bilet sayısının nispeten düşük olduğu bir bakım aşamasındadır. Asla benzer şeyler karşılaştırmak için bir durum değil.