Bir projeyi büyük yapan nedir? [kapalı]

Sadece meraktan küçük, orta ve büyük ölçekli bir proje arasındaki fark nedir? Kod satırlarıyla mı yoksa karmaşıklıkla mı ölçülür?

Bir takas sistemi kuruyorum ve şimdiye kadar giriş / kayıt için yaklaşık 1000 kod satırı var. Çok fazla LOC olmasına rağmen, büyük bir proje olarak görmeyeceğim, çünkü bu benim ilk projem olmasına rağmen o kadar da karmaşık değil. Nasıl ölçülür?

Karmaşıklık.

Karmaşıklık arttıkça, projedeki her şeyi öğrenmek zorlaşır.

Kabaca bazı şeyleri nasıl kabul edeceğimi - bunun az ya da çok keyfi olduğunu aklınızda bulundurun. Projenin karmaşıklığı, kaynak kod satırı, özellik sayısı / işletme değeri vb. Gibi diğer faktörlerin bir birleşiminde "boyutu" Çok küçük bir ürün çok miktarda değer sağlayabilir, vb.

• 2m + sloc büyük projeye büyük. Bunlar genellikle o kadar karmaşıktır ki, eğer birileri tüm sistemde 'akıcıysa'; Bunun yerine sorumluluk, kodun yapısı boyunca modüle edilme eğilimindedir. Bu projeler genellikle çok büyük bir iş değeri sunar ve kritik görev olabilir. Aynı zamanda bazen teknik borçların ve diğer eski kaygıların ağır bir şekilde zorlanması altındadır.

• 100k - 2m'lik sloc orta ölçekli bir projedir. Bu benim orta noktam: proje, uzmanlık bilgisi gerektirecek kadar karmaşık ve muhtemelen bir dereceye kadar teknik borç tahakkuk ediyor; muhtemelen bir dereceye kadar işletme değeri de sağlıyor.

• 10k - 100k küçük bir projedir, ancak uzman değerlendirmesi isteyecek kadar karmaşık olmak için çok küçük değildir; Açık kaynak iseniz, güvendiğiniz kişilerin taahhütlerinizi gözden geçirmelerini sağlayın.

• 10 bin sloc'tan küçük şeyler gerçekten çok küçük. Bu hiçbir şekilde hiçbir değer sağlayamayacağı anlamına gelmez ve çok ilginç birçok projenin çok küçük bir etkisi vardır (örneğin, kaynağı ~ 2 kb (!) Olan Camping). Uzman olmayanlar, genellikle etki alanı hakkında çok fazla şey bilmeden, değer kaygılarını giderebilir - hataları giderebilir ve özellikler ekleyebilir.

Bir projenin büyüklüğü sürdürülemezlik derecesi ile ölçülür.

Birkaç şekilde tahmin edilebilecek karmaşıklık:

1. Bütçe. 10.000.000 $ + bütçesi olan bir proje, muhtemelen 10.000 $ 'ın altındaki projelerden oldukça farklıdır. Bu, işgücü, yazılım, donanım ve proje yaparken ortaya çıkan diğer maliyetleri içerebilir.
2. Projeyi tamamlamak için çalışma saatleri. Milyon saat mi sürecek başka bir şey mi olacak? Bu, bazı projelerin yıllar alabileceği zaman çizelgesi faktörü olarak da görülebilir, bir haftadan az sürebilecek olan diğerlerine göre büyüktü. Personel saatini iki katına çıkararak, personelin iki katına çıkacağını düşündüğü gibi kişi saatlerinin yanıltıcı olabileceğine dikkat edin, böylece proje üzerinde iki kat fazla çalışma var, sonra program aklıma nadiren işe yarıyor.
3. Projenin inşa ettiği şeyi kullanan donanım, diğer sistemler ve insanlar. Eğer 101 sisteme bir şey bağlıysa, yalnız kalması ve başka hiçbir şeye bağlanmaması durumunda daha karmaşık olması muhtemeldir.

Gereksinimler, bunu ölçmenin güzel bir yolu gibi görünse de, genellikle Şelalesi olmayan bir metodoloji varsayarak bir proje yapılırken bulunacak daha fazla gereksinim vardır.

Bir proje büyüklüğü muhtemelen, gereksinimlerin daha da azaltılamadığı sistem gereksinimlerine göre ölçülür.

Tabii ki, daha fazla gereksinim çoğunlukla daha fazla karmaşıklık anlamına gelir, ancak her zaman böyle değildir.

Bir projenin büyüklüğünü, tüm projeyi tek bir büyük resim olarak görmenin ne kadar zor olduğunu ölçebilirim. Örneğin, üzerinde çalıştığım bir makine öğrenme problemi için keşif / prototipleme kod tabanına sahibim. Sadece 5k kod satırı, ancak büyük bir proje gibi geliyor. Tahmin edilemeyen şekillerde etkileşimde bulunan tonlarca yapılandırma seçeneği vardır. Tüm bu karmaşıklığı yönetmek için kod tabanında bir yer tarafından bilinen bir tasarım modelini hemen hemen bulabilirsiniz. Tasarım çoğu zaman düşüktür, çünkü olay evrim yoluyla çok büyümüştür ve olması gerektiği gibi yeniden yansıtılmamaktadır. Bu kod temeli üzerinde çalışan tek kişi benim ama yine de işlerin nasıl yürüdüğüne şaşırdım.

Öte yandan, hobi projelerimden birinin kodunun 3-4x kadarı var ve yine de çok daha küçük geliyor çünkü temelde birbirlerine dik dik bir matematiksel işlev kütüphanesi. Her şey karmaşık yollarla etkileşime girmez ve her bir işlevi yalıtımlı olarak anlamak güzeldir. Büyük resmi, olduğu kadar görmek kolaydır, çünkü görecek pek bir şey yoktur.

İsteğe bağlı cevap: Projenin ne kadar büyük olduğu, etkinlik kaynaklı ve SOA ile baştan başlamasını dilediğiniz kadar. Ya da sistemin yazarları Evan'ın "DDD: Yazılımın Kalitesindeki Karmaşıklık ile Mücadele" kitabını okudular;

Compexity ve Kapsam

Karmaşıklık ve Kapsam Bir projenin gerçekte ne kadar büyük olduğunu belirleyen şeyin olduğuna inanıyorum. Ancak, bir projenin boyutunu da etkileyebilecek çeşitli maddi olmayan varlıklar vardır.

Gereksinimler

Karşılaştığım en büyük düşüş şartların olmamasıydı. Özel durumumda satış müdürü gereksinimleri belirliyordu. Odak noktası satışa çıktı ... satışı almalı. Müşterinin istediği aklında, o kadar karmaşık görünmüyordu, çünkü benzer bir şey yaptık. Belirsiz şartlar düşük işlere ve aşırı beklentilere yol açar.

CCMU eksikliği

CCMU benim " Coo Ca Moo " dediğim şeydir (Karşılıklı Anlaşmayı Tamamla). Müşterinizle birlikte bir CCMU'nuz olması gerekir.

Eğer zayıf bir CCMU ile küçük bir projeniz varsa, o zaman projeyi 2,3,4 ya da daha fazla kez yaparak kapatabilirsiniz. Böylece, 20 saatlik basit bir iş, stresli personel ve çok memnun olmayan bir müşteriyle 60 saatlik bir projeye dönüşüyor.

Kapsam Sürünme

Bu düşündüğünüzden daha sık olur. Müşteri, zaten A, B & C yaptığınız için D veya F eklemek bile zor olmayacağına karar verir. Bu davranış kontrol edilmezse küçük bir projeyi orta ölçekli bir projeye dönüştürebilir. Ve satış yöneticisinin işi nasıl sattığına bağlı olarak, bu kapsamdaki sürünme beklentileri müşteriye "ÜCRETSİZ" görünebilir .

Tuhaf, bu cevapların çoğunu okuyarak bir projenin boyutunu çok farklı görüyorum. Belki de büyük bir şirkette çalışıyorum, ancak bir projenin büyüklüğünü, müşterilerinin görünebilirliği / arzu edilebilirliğinin bir ölçüsü olarak görme eğilimindeyim (çalışma alanınıza bağlı olarak bunlar iş arkadaşları veya gerçek ödeme yapan müşteriler olabilir).

Karmaşıklık doğru cevaptır, ancak nasıl tahmin edilir?

Faktörler:

1. Uzatma noktaları sayısı
2. Modüller katmanları sayıları (fonksiyonlar, sınıflar, sınıf sistemleri, kütüphaneler, paylaşılan kütüphaneler, uygulamalar, ağ uygulamaları vb.)
3. Bağımlılık sayısı (platformlar dahil)
4. Aralıklar arası sayıma sahiptir.
5. Gerekli kod dışı kaynaklar (grafikler / sanatlar, sürüş komut dosyaları - seviye tasarım komut dosyaları gibi - ve uygulamanın bir sürümünü tamamlamak için gereken diğer kaynaklar dahil).

Bunlardan ne kadar fazlaysanız, proje de o kadar karmaşık olur.

LOC olan ölçümlerin bir sürü için herkesin bildiği gibi yanlış, ama ben gerçekten ölçmek için doğru bir yol olmadığını şey ölçmek için çalışıyoruz düşünüyorum. Belki de bir alternatif döngüsel karmaşıklık olabilir .

Sonuçta, bir projenin "büyüklüğünün" ölçülmesinin zor olduğunu düşünüyorum. Neredeyse bir köpeğin büyük olup olmadığına nasıl karar verdiğinizi sormak gibidir. Bunu ölçmek için sadece birçok yol var (kütle, hacim vb.), Ama ben şahsen çok yararlı bulmuyorum. Gerçek şu ki, kriterlerimin muhtemelen "Karanlık bir sokakta görürsem bu köpeğe kaçma ihtimalim ne kadar olur" gibi bir şey olacak.

Ve kayıt için, genellikle 1k kod satırını çok fazla düşünmezdim. Oldukça büyük miktarda bir kod olurdu, ama olayların büyük bölümünde bu kadar olmazdı . Tabii ki, diline bağlı olduğunu düşünüyorum. Örneğin, 1k kod satırı, Py gibi bir dilden C gibi bir dilde çok daha az koddur.