Efsanevi adam geliştirici günü başına aylık 10 satır - büyük projelere ne kadar yakın? [kapalı]

Herkes her zaman "Mythical Man Month" dan itibaren "geliştirici başına günde 10 satır" ı yenebileceğini söylüyor ve bir projeye başlarken, genellikle bir günde birkaç yüz satır alabiliyorum.

Ancak önceki işverenimde, tüm geliştiriciler çok zekiydi, ancak bu büyük bir projeydi, bir milyon satırdan fazla kod içeriyordu, çok zahmetli sertifika gereksinimleri ve diğer milyonlarca satırlık projelerle arayüz oluşturuyordu. Bir noktada, bir merak egzersizi olarak, grubumdaki nakliye ürünündeki kod satırlarını çizdim (geliştirdiğimiz araçları saymadım) ve kesinlikle, artımlı olarak, geliştirici başına günde yaklaşık 12 satır net ekleme geldi. Değişiklikleri, test kodunu veya geliştiricilerin her gün gerçek proje kodu üzerinde çalışmadığı gerçeğini saymamak.

Diğer insanlar nasıl? Ve ne tür gereksinimlerle karşılaşıyorsunuz (bunun bir faktör olduğunu düşünüyorum)?

Eklenen hat sayısının büyük ölçüde projenin durumuna bağlı olduğunu düşünüyorum, yeni bir projeye ekleme oranı, bir başlangıç ​​projesinden çok daha yüksek olacaktır.

İş ikisi arasında farklıdır - büyük bir projede genellikle zamanın çoğunu parçalar arasındaki ilişkileri bulmak için ve sadece küçük bir kısmını gerçekten değiştirmek / eklemek için harcarsınız. oysa yeni bir projede - çoğunlukla yazarsınız ... yeterince büyüyene ve oran düşene kadar.

Mevcut projelerimden birinde, bazı modüllerde, kod tabanına eksi satır sayımına katkıda bulunduğum için gurur duyuyorum. Hangi kod alanlarının gereksiz karmaşıklığa sahip olduğunu ve daha temiz ve daha net bir tasarımla basitleştirilebileceğini belirlemek yararlı bir beceridir.

Elbette bazı problemler doğası gereği karmaşıktır ve karmaşık çözümler gerektirir, ancak çoğu büyük projede kötü tanımlanmış veya değişen gereksinimleri olan alanlar, hat başına daha fazla sayıda sorunla aşırı karmaşık çözümlere sahip olma eğilimindedir.

Çözülecek bir problem verildiğinde, satır sayısını azaltan çözümü daha çok tercih ederim. Tabii ki, küçük bir projenin başlangıcında günde ondan fazla kod satırı üretebilirim, ancak yazdığım kod miktarını düşünmüyorum, sadece ne işe yaradığını ve ne kadar iyi yaptığını. Günde on satır geçmeyi kesinlikle hedeflemem veya bunu bir başarı olarak görmem.

Bu alıntıyı beğendim:

Kod satırlarını saymak istiyorsak, bunları "üretilen satırlar" olarak değil, "harcanan satırlar" olarak görmeliyiz. - Edsger Dijkstra

Bazen kod eklemekten çok kaldırarak katkıda bulunuyorsunuz

Bu metriği kullanmayı bırakmalısınız, çoğunlukla anlamsızdır. Uyum, birleştirme ve karmaşıklık, kod satırlarından daha önemli ölçütlerdir.

Diğer insanlar nasıl?

Şirketimizdeki tek tam zamanlı geliştiriciyim ve son 7 yılda 500.000 satır OCaml ve F # kodu yazdım, bu da günde yaklaşık 200 satır koda eşittir. Ancak, bu kodun büyük çoğunluğu, her biri birkaç yüz satır uzunluğunda yüzlerce ayrı projeden oluşan eğitici örneklerdir. Ayrıca, OCaml ve F # arasında çok sayıda kopyalama vardır. 50kLOC'den daha büyük herhangi bir şirket içi kod tabanına sahip değiliz.

Kendi yazılımımızı geliştirmeye ve sürdürmeye ek olarak, son 7 yılda sektördeki birçok müşteriye de danışmanlık yaptım. İçin ilk istemci , ben günde kod 20 satır 3 ay içinde OCaml 2.000 satırları yazdım. Bir sonraki müşteri için , dördümüz 6 ayda milyonlarca satır C / C ++ / Python / Java / OCaml kodunun yanı sıra geliştirici başına günde 2.000 satır kod üreten bir derleyici yazdık. Başka bir müşteri için, 6 ayda 50kLOC C ++ 'ı 6kLOC of F # ile değiştirdim, bu da günde -352 satır koddur. İçin henüz başka bir istemci , ben günde kod 0 hatları böylece aynı boyutta olacaktır F # OCaml arasında 15kLOC yeniden ediyorum.

İçin mevcut istemci , ben günde kod -6000 satır olacak (ısmarlama derleyici yazarak) 1 yıl içinde F # ~ 160kLOC ile C ++ ve Mathematica kod 1.600.000 satırları yerini alacak. Bu, bugüne kadarki en başarılı projem olacak ve müşterimizin devam eden maliyetlerinde yılda milyonlarca dolar tasarruf edecek. Bence herkes günde -6.000 satır kod yazmayı hedeflemelidir.

"The Mythical Man-Month" nüshasına gerçekten bakmadan (bunu okuyan herkesin hazır bir kopyası olmalı), Brooks'un üretkenliğe yazılı satırlarla baktığı bir bölüm vardı. Ona göre ilginç olan nokta, günlük yazılan gerçek satır sayısı değil, montajcı ve PL / I'de kabaca aynı görünmesi gerçeğiydi (sanırım bu kullanılan üst düzey dildi).

Brooks, bir çeşit keyfi bir üretkenlik rakamını atmak üzere değildi, ancak gerçek projeler üzerindeki verilerden çalışıyordu ve hatırlayabildiğim kadarıyla, bunların ortalama 12 satır / gün olabilirdi.

Üretkenliğin değişmesinin beklenebileceğine işaret etti. Derleyicilerin uygulama programlarından üç kat, işletim sistemlerinin derleyicilerden üç kat daha zor olduğunu söyledi. (Üçün çarpanlarını kategorileri ayırmak için kullanmayı seviyor gibi görünüyor.)

Programcı üretkenliği arasındaki bireysel farklılıkları takdir edip etmediğini bilmiyorum (her ne kadar büyüklük sırasına göre bir argümanda yedi farklık bir faktör olduğunu varsaymasına rağmen), ama bildiğimiz gibi üstün üretkenlik sadece daha fazla yazmaktan ibaret değil kod, aynı zamanda işi yapmak için doğru kodu yazma.

Bir de çevre sorunu var. Brooks, geliştiricileri neyin daha hızlı veya daha yavaş yapacağı konusunda biraz spekülasyon yaptı. Pek çok insan gibi, o da mevcut heveslerin (zaman paylaşımlı sistemler kullanarak etkileşimli hata ayıklama) eski yöntemlerden daha iyi olup olmadığını sorguladı (tüm makineyi kullanarak iki saatlik bir çekim için dikkatli bir şekilde önceden planlama).

Buna göre, bulduğu herhangi bir gerçek üretkenlik sayısını işe yaramaz olarak görmezden gelirim; Kitabın süregelen değeri, insanların öğrenmemekte ısrar ettikleri ilkelerde ve daha genel derslerde yatmaktadır. (Hey, eğer herkes onları öğrenmiş olsaydı, kitap yalnızca tarihsel açıdan ilgi çekici olurdu, tıpkı Freud'un bilinçaltı akıl gibi bir şeyin var olduğuna dair argümanlarının tümü gibi.)

Günde birkaç yüz satır kod almak kolaydır. Ancak günde birkaç yüz kaliteli kod satırı almaya çalışın ve bu o kadar kolay değil. Hata ayıklama ve günde çok az veya hiç yeni satır bulunmayan günler ile devam ederseniz, ortalama oldukça hızlı düşecektir. Zor sorunları gidermek için haftalar harcadım ve yanıt 1 veya 2 satır koddu.

Fiziksel kod satırlarından bahsetmenin oldukça anlamsız olduğunun farkına varmak çok daha iyi olacaktır. Fiziksel Kod Satırlarının (LoC) sayısı, kodlama stiline o kadar bağlıdır ki, bir geliştiriciden diğerine bir büyüklük sırasına göre değişebilir.

.NET dünyasında LoC'yi saymanın uygun bir yolu vardır. Sıra noktası . Sıra noktası, bir hata ayıklama birimidir, bir kırılma noktası belirlenirken koyu kırmızı ile vurgulanan kod kısmıdır. Sıra noktası ile mantıksal LoC'den bahsedebiliriz ve bu ölçü çeşitli .NET dilleri arasında karşılaştırılabilir. Mantıksal LoC kod ölçüsü, VisualStudio kod ölçüsü, NDepend veya NCover dahil çoğu .NET aracı tarafından desteklenir.

Örneğin, burada 8 LoC yöntemi verilmiştir (başlangıç ​​ve bitiş parantezleri sıra noktaları hesaba katılmaz):

LoC üretimi uzun vadede sayılmalıdır. Bazı günler 200 LoC'den fazla tükürürsünüz, bazı günler ise tek bir LoC bile eklemeyerek bir hatayı düzeltmek için 8 saat harcarsınız. Bazı günler ölü kodu temizlersiniz ve LoC'yi kaldırırsınız, bazı günler tüm zamanınızı mevcut kodu yeniden düzenlemek ve toplama yeni bir LoC eklememek için harcarsınız.

Kişisel olarak, kendi üretkenlik puanımda yalnızca aşağıdaki durumlarda tek bir LoC sayıyorum:

1. Birim testleri kapsamındadır
2. bir tür kod sözleşmesi ile ilişkilidir (mümkünse, tüm LoC elbette sözleşmelerle kontrol edilemez).

Bu durumda, .NET geliştiricileri için NDepend aracını kodlayan son 5 yıldaki kişisel puanım , kod kalitesinden hiçbir şekilde ödün vermeden günde ortalama 80 fiziksel LoC'dir . Ritim devam ediyor ve yakın zamanda azaldığını görmüyorum. Sonuç olarak, NDepend şu anda yaklaşık 115K fiziksel LoC ağırlığında olan bir C # kod tabanıdır.

LoC'yi saymaktan nefret edenler için (çoğunu buradaki yorumlarda görmüştüm), bir kez yeterince kalibre edildikten sonra LoC saymanın mükemmel bir tahmin aracı olduğunu onaylıyorum . Özel geliştirme bağlamımda elde edilen düzinelerce özelliği kodlayıp ölçtükten sonra, LoC'deki herhangi bir TODO özelliğinin boyutunu ve onu üretime teslim etmem için ne kadar zaman alacağını tam olarak tahmin edebileceğim noktaya ulaştım.

Gümüş kurşun diye bir şey yoktur.

Bunun gibi tek bir ölçü kendi başına işe yaramaz.

Örneğin, kendi sınıf kitaplığım var. Şu anda aşağıdaki istatistikler doğrudur:

Toplam satırlar: 252.682
Kod satırları: 127.323
Yorumlar: 99.538
Boş satırlar: 25.821

Hiç yorum yazmadığımı, yani 127.323 satır kod yazdığımı varsayalım. Oranınızla, o kod kitaplığını yazmam 10610 gün sürer. Bu 29 yıl.

Kesinlikle 29 yılımı bu kodu yazmakla harcamadım, çünkü hepsi C # ve C # o kadar uzun süredir ortalarda yok.

Şimdi, kodun o kadar da iyi olmadığını iddia edebilirsiniz, çünkü açıkçası günde 12 satır metriğinizi aşmış olmalıyım ve evet, bunu kabul edeceğim, ancak zaman çizelgesini aşağı indirirsem 1.0 piyasaya sürüldüğünde (ve aslında 2.0 yayımlanana kadar yapmaya başlamadım), yani 2002-02-13, yaklaşık 2600 gün, ortalama günde 48 satır kod.

Tüm bu kod satırları iyi mi? Heck hayır. Ama günde 12 satır koda kadar mı?

Heck hayır.

Her şey bağlıdır.

Günde binlerce satır sırasına göre kod çalkalayan birinci sınıf bir programcıya ve günde yüzlerce satır sırasına göre kod çalkalayan orta düzey bir programcıya sahip olabilirsiniz ve kalite aynıdır.

Ve evet, böcekler olacak.

İstediğiniz toplam, bakiyedir. Kodun karmaşıklığına karşı, bulunan hataların sayısına karşı kod miktarı değişti, bu hataları düzeltmenin zorluğu.

Steve McConnell, "Yazılım Tahmini" kitabında ilginç bir istatistik veriyor (s62 Tablo 5.2) Proje türleri (Aviyonik, İş, Telco, vb.) Ve proje boyutu 10 kLOC, 100 kLOC, 250 kLOC arasında ayrım yapıyor. Numaralar her kombinasyon için LOC / StaffMonth'da verilmiştir. EG Aviyonik: 200, 50, 40 Intranet Sistemleri (Dahili): 4000, 800, 600 Gömülü Sistemler: 300, 70, 60

Bunun anlamı: ör. Avionic 250-kLOC projesi için 40 (LOC / Ay) / 22 (Gün / Ay) == <2LOC / gün!

Sanırım bu , bir projenin gerçek geliştirme aşamasının toplam proje süresinin% 20-30'u kadar az olabileceği şelale geliştirme günlerinden geliyor . Toplam kod satırlarını alın ve tüm proje süresine bölün ve günde yaklaşık 10 satır elde edersiniz. Yalnızca kodlama dönemine bölerseniz, insanların alıntı yaptıklarına yaklaşırsınız.

Kod tabanımız yaklaşık 150 adam yıllık bir çaba için yaklaşık 2.2 MLoC'dir. Bu , projenin tüm ömrü boyunca geliştirici başına günde yaklaşık 75 satır c ++ veya c # yapar .

Bence proje boyutu ve dahil olan geliştirici sayısı bunda büyük faktörler. Kariyerim boyunca bunun çok üstündeyim ama bunca zaman yalnız çalıştım, bu yüzden diğer programcılarla çalışmanın bir zararı yok.

İyi planlama, iyi tasarım ve iyi programcılar. Tüm bunları birlikte yaşarsınız ve bir satır yazmak için 30 dakikanızı ayırmazsınız. Evet, tüm projeler durmanızı ve planlamanızı, düşünmenizi, tartışmanızı, test etmenizi ve hata ayıklamanızı gerektirir ancak günde iki satırda her şirketin tetrisin çalışması için bir orduya ihtiyacı olacaktır ...

Sonuç olarak, eğer benim için saatte 2 sıra çalışıyor olsaydın, bana bir sürü kahve getirip ayaklarıma masaj yapsan iyi olur ki kovulmasın.

Bu çok yıllık yönetici-şekerleme parçasının, her şey C'de yazılmış bir sistem uygulaması olduğunda icat edildiğinden şüpheleniliyor, çünkü başka hiçbir şey olmasa sihirli sayı, uygulamanın diline, ölçeğine ve doğasına bağlı olarak büyüklük sıralarına göre değişecekti. Ve sonra yorumları ve nitelikleri azaltmanız gerekir. Ve nihayetinde, yazılan kod satırlarının sayısı kimin umurunda? 10K hatlara ulaştığınızda bitirmeniz mi gerekiyor? 100K? Çok keyfi.

Bu faydasız.