C # डेवलपर प्रति माह कोड की कितनी लाइनों का उत्पादन कर सकता है? [बन्द है]


21

मेरे कार्यस्थल पर एक कार्यकारी ने मुझसे और मेरे डेवलपर्स के समूह से सवाल पूछा:

C # डेवलपर प्रति माह कोड की कितनी पंक्तियों का उत्पादन कर सकता है?

एक पुरानी प्रणाली को C # में पोर्ट किया जाना था और वह इस उपाय को परियोजना की योजना के हिस्से के रूप में पसंद करेगा।

कुछ (स्पष्ट रूप से विश्वसनीय) स्रोत से उनके पास "10 एसएलओसी / माह " का जवाब था, लेकिन वह इससे खुश नहीं थे।

समूह ने सहमति व्यक्त की कि यह निर्दिष्ट करना लगभग असंभव था क्योंकि यह परिस्थितियों की लंबी सूची पर निर्भर करेगा। लेकिन हम बता सकते हैं कि अगर हम उसे बेहतर तरीके से जवाब देने के साथ नहीं आए तो वह आदमी नहीं छोड़ेगा (या हम में बहुत निराश होगा)। इसलिए उन्होंने "10 एसएलओसी / दिन " के कई गुना बेहतर जवाब दिए।

क्या इस सवाल का जवाब दिया जा सकता है? (अपमान या कुछ विश्लेषण के साथ भी)


7
क्या उन लाइनों को किसी भी गुणवत्ता को एम्बेड करने की आवश्यकता है? > _>
हन्नीबल लेक्चरर

4
क्या यह कंप्यूटर जनरेटेड कोड हो सकता है? यदि हां, मुझे पूरा यकीन है कि मैं सही हार्डवेयर को देखते हुए, ज़ेटा पावर प्रीफ़िक्स (10 ^ 21) को लाइनों में ले सकता हूं। यह कुछ भी नहीं, तुम बुरा मत मानना ​​...
ग्रैंडमास्टरबी

6
विश्वसनीय स्रोत: पौराणिक मानव महीना
मार्टिन

2
अगर एक लकड़हारा लकड़ी काट सकता है तो एक लकड़हारा चक कितनी लकड़ी काट सकता है? मुझे विश्वास नहीं हो रहा है कि यह सवाल अभी भी पूछा जा रहा है! क्या है, यह 1975 है? बहुत बेहतर सवाल हैं, जैसे, "इस वर्ष विकास टीम ने कितने सिस्टम को सफलतापूर्वक तैनात किया है?" या "पहले की तुलना में वर्तमान प्रणाली का उपयोग करके प्रति माह कितने घंटे बचाए गए हैं?" सवाल मूल्य का होना चाहिए, एक अप्रासंगिक मीट्रिक की मात्रा नहीं।
मार्क फ्रीडमैन

3
प्रश्न का उत्तर नहीं दिया जाना चाहिए क्योंकि यह "अधिक बेहतर है" या "अधिक कोड का अर्थ है अधिक गुणवत्ता" जैसी गलत धारणाओं पर आधारित है।
थॉमसएक्स

जवाबों:


84

अपने कार्यकारी से पूछें कि उसके वकील कितने अनुबंध प्रति माह लिख सकते हैं। तब (उम्मीद है) उसे एहसास होगा कि एक पृष्ठ के अनुबंध को लिखने और खामियों और विरोधाभासों के बिना 300-पृष्ठ अनुबंध लिखने के बीच एक बड़ा अंतर है। या एक नया अनुबंध लिखने और मौजूदा एक को बदलने के बीच। या एक नया अनुबंध लिखने और एक अलग भाषा में अनुवाद करने के बीच। या एक अलग कानून व्यवस्था के लिए। हो सकता है कि वह इस बात से भी सहमत हो कि "समय की प्रति इकाई अनुबंध के पृष्ठ" वकील उत्पादकता के लिए एक बहुत अच्छा उपाय नहीं है।

लेकिन आपको अपने असली सवाल का कुछ जवाब देने के लिए: मेरे अनुभव में, एक नई परियोजना के लिए प्रति दिन कुछ सौ SLOC और डेवलपर असामान्य नहीं हैं। लेकिन जैसे ही पहले कीड़े दिखाई देंगे, यह संख्या तेजी से गिर जाएगी।


18
वह संख्या इतनी तेजी से गिर सकती है जितना कि ऋणात्मक में जाने के लिए ...
हंस के '26

यह एक सही उपमा नहीं है। एक अनुवादक के एक अंग्रेजी पाठ के कितने पृष्ठ वह एक सप्ताह में जर्मन में अनुवाद कर सकता है, यह पूछना पूरी तरह से ठीक है। और वे एक एप्लिकेशन को एक भाषा / प्लेटफ़ॉर्म से दूसरे में पोर्ट कर रहे हैं, अनुवाद के लिए थोड़े समान हैं।
एसके-लॉजिक

4
@ SK-Logic क्या है? एक आकस्मिक वार्तालाप का अनुवाद करने का प्रयास करें, फिर एक लंबे कानूनी दस्तावेज़ का अनुवाद करने का प्रयास करें।
ब्लैकिस

@ एसके-तर्क - अनुवादित स्रोत दस्तावेज़ में प्रत्येक पंक्ति आमतौर पर लक्ष्य दस्तावेज़ में एक पंक्ति में मैप की जाएगी - यह एक बहुत रैखिक मैपिंग है। जब सॉफ्टवेयर की बात आती है, तो यह संभावना नहीं है कि दो प्रोग्रामिंग भाषा संरचना और क्षमता में समान हैं जो समान होने की उम्मीद करने में सक्षम हैं। संभवतः ऐसे कई क्षेत्र होंगे जहाँ बचत की जा सकती है, और कुछ क्षेत्र, जहाँ आपके पास लिखने के लिए तुलनात्मक रूप से अधिक कोड होंगे।
cjmUK

1
@ क्रिस्तोफ्रोवोस्ट, एक 1-टू -1 अनुवाद आम तौर पर एक लंबी और दर्दनाक रिफैक्टिंग प्रक्रिया के लिए एक प्रारंभिक बिंदु है। लेकिन पहले कुछ काम कर लेना जरूरी है। और मुझे मिले सभी अनुवाद परियोजनाओं में, मुख्य प्रेरणा मूल टूलचैन (जैसे, पीएल / आई से सी ++) की उम्र बढ़ने और इसके भविष्य में आत्मविश्वास की कमी थी। इस तरह की परियोजनाओं में स्वच्छ और मुहावरेदार कोड कभी सर्वोच्च प्राथमिकता नहीं थी।
एसके-लॉजिक

33

C # डेवलपर प्रति माह कोड की कितनी पंक्तियों का उत्पादन कर सकता है?

यदि वे अच्छे हैं, शून्य से कम है।


5
+1: जब विरासत कोड को बनाए रखते हैं, तो हम एक नकारात्मक-LOC चेक-इन (कार्यक्षमता को बनाए रखते या सुधारते समय) के लिए प्रयास करते हैं। मेरे एक सहकर्मी ने एक चेक-इन में कोड की 2,500+ लाइनें निकालने में कामयाबी हासिल की। उस रिफैक्टरिंग ने उसे लगभग एक सप्ताह का समय दिया, लेकिन कुल मिलाकर औसतन अभी भी -300 से अधिक लाइनें प्रति दिन थीं। :-)
पीटर के।

कोड की कम पंक्तियों द्वारा माप करना केवल उतना ही व्यर्थ है जितना कि एक ही जाल में गिरता है - कोड की पंक्तियों की संख्या कोड की लाइनों के अलावा किसी भी अन्य चीज का एक वैध माप है। मुझे किसी भी दिन अपठनीय, बग-रिग्ड स्पेगेटी की 10,000 लाइनों पर अच्छे कोड की 40,000 लाइनें दें ।
मैक्सिमस मिनिमस

1
निश्चित ही यह व्यर्थ है @ म्ह। यह जीभ-इन-गाल उत्तर का अधिक है
क्वेंटिन-स्टारिन

21

दूसरा रास्ता चलाओ ... अब।

एलओसी सबसे खराब मैट्रिक्स में से एक है जिसका आप उपयोग कर सकते हैं।

बुरे डेवलपर्स संभावित रूप से अच्छे डेवलपर्स की तुलना में एक दिन में अधिक एलओसी लिख सकते हैं, लेकिन बकवास कोड को मंथन कर सकते हैं।

कोड की जटिलता के आधार पर, स्वचालन प्रक्रियाओं द्वारा पोर्टिंग की जा सकती है जिसके परिणामस्वरूप बड़े हजार + एलओसी एक दिन में बदल जाते हैं, जबकि अधिक कठिन खंड जहां भाषा के निर्माण में बेतहाशा भिन्न कोड होते हैं उन्हें प्रति दिन 100LoC पर पोर्ट किया जाता है।

उसे SLOC पर विकिपीडिया पृष्ठ पढ़ने के लिए भेजें । अगर यह इस तरह के एक गरीब मीट्रिक क्यों है के कुछ अच्छे और सरल उदाहरण देता है।


1
MxGrath: SLOC केवल प्रगति को मापने के लिए खराब है, लेकिन यह समग्र जटिलता, esp को मापने के लिए अक्सर उपयोग करने योग्य है। चूंकि, लेस हैटन ने बताया, "मैककेबे साइक्लोमैटिक कॉम्प्लेक्सिटी में कोड की लाइनों के समान भविष्यवाणी क्षमता है।"
स्तंभकार

18

सही उत्तर: नहीं ...

इस कार्यकारी को शिक्षित किया जाना चाहिए, कि SLOC विश्लेषण प्रगति के लिए एक वैध मैट्रिक्स नहीं है

मैला जवाब: कोई भी संख्या आप बना सकते हैं।

बस उसे कुछ नंबर दें, आप और आपकी टीम आसानी से उस नंबर को बना सकते हैं। (जब तक लाइन, खाली लाइनें, टिप्पणियां आदि आदि डालकर, बस इस आदमी को अपनी काल्पनिक दुनिया में रहने के लिए अनुमति देने के लिए, और अभी तक एक और टीम का शिकार करना और दुखद प्रबलित चक्र को जारी रखना है जो एक कहानी को thedailywtf बनाता है।

अच्छा नहीं है, लेकिन सक्षम है।


मुझे यह कहना होगा कि टिप्पणी कोड की उपयोगिता बढ़ा सकती है , हालांकि।
नाइट्रोडिस्ट

2
@ निट्रोडिस्ट वास्तव में अच्छी टिप्पणियां हैं, जिन टिप्पणियों का मैं उल्लेख कर रहा हूं, वे केवल कार्यकारी को खुश करने के लिए उपयोग किए जाते हैं। जो पूरी तरह से बेकार होगा ...
Zekta Chan

10

पहली नज़र से यह सवाल बिल्कुल बेवकूफी भरा लग रहा है, और यहाँ हर कोई बेवकूफ सी # एलओसी का हिस्सा है। लेकिन एक महत्वपूर्ण बारीकियों है - यह एक पोर्टिंग प्रदर्शन के बारे में एक सवाल है । इस प्रश्न को पूछने का सही तरीका यह है कि स्रोत परियोजना की कोड की कितनी पंक्तियां (एक को पोर्ट किया जा रहा है) किसी दी गई इकाई के भीतर संभाल सकती है। यह पूरी तरह से उचित प्रश्न है, क्योंकि कोड की कुल संख्या ज्ञात है, और यह बिल्कुल काम की राशि है। और इस qeestone का जवाब देने का सही तरीका थोड़ा ऐतिहासिक डेटा इकट्ठा करना है - प्रत्येक डेवलपर्स के लिए काम, कहना, एक सप्ताह और माप प्रदर्शन।


1
यह काम की सटीक मात्रा का संकेत कैसे किया जाता है? यदि आपको कोड की 1000 लाइनों को पोर्ट करने की आवश्यकता है, तो उपलब्ध लाइब्रेरी / मौजूदा कार्यक्षमता आदि के लिए कोड की 50 लाइनों को पोर्ट करना संभव हो सकता है। और यह कोड की मौजूदा 100 लाइनों को पोर्ट करने के लिए 50 लाइनें भी ले सकता है। पूरी तरह से कोड पर निर्भर करता है।
मार्क फ्रीडमैन

मैंने कहा कि एलओसी का एक स्रोत संख्या एक उचित मीट्रिक है, आउटपुट नहीं।
एसके-तर्क

2
मैं असहमत हूं। यदि कोड के खंड मूल में मौजूद हैं जो पोर्ट में कोई मतलब नहीं रखते हैं, तो उन्हें कभी भी 'पोर्टेड' नहीं माना जाता है और इसलिए, कभी भी गिना नहीं जाता है। ओटीओएच, मूल के लिए एक विशेषता और समर्थन सेट बनाने से प्रगति-से-पूर्ण होने के अधिक सार्थक संकेत मिल सकते हैं। सीधे शब्दों में कहें, प्रगति मीट्रिक केवल उस प्रयास के लायक है जिसे कोई व्यक्ति इसे बनाने और बनाए रखने के लिए तैयार है।
मम्मी

1
@ मम्मी, जिन प्रभावों के बारे में आप बात कर रहे हैं, वे केवल उतार-चढ़ाव हैं, उन्हें एक सांख्यिकीय आधार पर पर्याप्त बड़ा होना चाहिए।
एसके-तर्क

7

मेरे पास केवल एक ही बात है:

"कोड की तर्ज पर प्रोग्रामिंग प्रगति को मापना वजन द्वारा विमान निर्माण प्रगति को मापने जैसा है।"

-- बिल गेट्स

उसके बाद, आप तर्क दे सकते हैं कि बिल गेट्स को पता नहीं था कि सफल सॉफ्टवेयर कैसे बनाया जाता है;)

नोट: SLOC कोड-बेस जटिलता का एक बहुत अच्छा उपाय है!


5
I 
can
write
large
numbers
of
lines
of
code
per
month.

शब्दों की संख्या के लिए आनुपातिक, वास्तव में।

आप मेरी बात देखिए?


1
अधिकांश उपकरण जो लोक आँकड़े उत्पन्न करते हैं, वे आपको तार्किक LOCs प्रदान करते हैं - अर्थात "कोड स्टेटमेंट" "एडिटर लाइन्स" नहीं। तो आपके जवाब से 1 LLOC का स्कोर प्राप्त होगा। वे कोड और कोड जटिलता के लिए टिप्पणियों के अनुपात जैसे उपयोगी मीट्रिक भी उत्पन्न करते हैं, इसलिए वे पूरी तरह से बेकार नहीं हैं।
gbjbaanb

1
@gbjbaanb यह सिर्फ एक और तरह का बेकार है। घोषणात्मक भाषाओं में कथन नहीं होते हैं या इसलिए, "कथन रेखाएँ" होती हैं। अच्छा कोड टिप्पणियों के बजाय समझदार नामों के साथ स्व-दस्तावेजीकरण हो सकता है। अन्य कोड अधिक रेखीय रूप से लिखे गए हैं जहां "लाइनों" की कोई सार्थक अवधारणा नहीं है, उदाहरण के लिए गणितज्ञ नोटबुक।
जॉन हैरोप

4

इस पर मेरा थोड़ा अलग रुख हो सकता है, लेकिन मुझे लगता है कि मैं समझ सकता हूं कि कार्यकारी इस जानकारी की तलाश में थे कि क्या वे वर्तमान में प्रोजेक्ट प्लानिंग कर रहे हैं। चूँकि यह अनुमान लगाना कठिन है कि किसी परियोजना को कितना समय लगने वाला है, जो उपयोग की जाने वाली विधियों में से एक है (देखें: सॉफ़्टवेयर अनुमान: ब्लैक आर्ट को डीमिस्टिफ़ाइ करना ) यह अनुमान लगाना है कि संख्या की संख्या के आधार पर परियोजना को कितना समय लगेगा इसी तरह की परियोजनाओं में एसएलओसी और अब डेवलपर्स औसतन उत्पादन कर सकते हैं। व्यवहार में यह ऐतिहासिक रिकॉर्ड का उपयोग करने के लिए किया जाता है जो समूह के समान या समान डेवलपर्स के साथ समान परियोजनाओं के लिए हाथ में है।

हालांकि, यह कुछ भी नहीं है कि ये अनुमान केवल मूल परियोजना योजना के लिए हैं और वास्तव में परियोजना पर डेवलपर्स की गति निर्धारित करने का इरादा नहीं है क्योंकि दिन-प्रतिदिन चीजें बदल जाती हैं। इस प्रकार, जो आप एसएलओसी का उपयोग अनुमान उपकरण के रूप में करते हैं, उसमें से अधिकांश यह है कि वे लंबे समय से अच्छे हैं यदि आपके पास पहले से ही ज्ञान का अच्छा शरीर है, लेकिन दिन के उपयोग के लिए घटिया है।


4

आमतौर पर आपके बॉस को बेवकूफ कहना एक बुरा विचार है, इसलिए मेरे सुझाव मैट्रिक्स को समझने और चर्चा करने से शुरू होते हैं, बजाय उन्हें खारिज करने के।

कुछ लोग जिन्हें वास्तव में बेवकूफ नहीं माना जाता है, उन्होंने मैट्रिक्स का उपयोग किया है जो कोड की लाइनों पर आधारित थे। फ्रेड ब्रूक्स, बैरी बोहम, कैपर्स जोन्स, वॉट्स हम्फ्रीज, माइकल फगन और स्टीव मैककोनेल सभी ने उनका इस्तेमाल किया। आपने शायद उनका उपयोग किया है, भले ही किसी सहकर्मी से कहने के लिए, यह भगवान मॉड्यूल 4000 लाइनें हैं, इसे छोटे वर्गों में विभाजित करने की आवश्यकता है।

इस प्रश्न से संबंधित एक स्रोत से विशिष्ट डेटा है जिसका हममें से कई लोग सम्मान करते हैं।

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

मुझे संदेह है कि प्रोग्रामर प्रति घंटे कोड की लाइन का सबसे अच्छा उपयोग यह दिखाने के लिए है कि परियोजना के जीवन पर, यह मूल्य बहुत अधिक शुरू हो जाएगा, लेकिन जैसा कि दोष पाए जाते हैं और तय किए जाते हैं, समस्याओं को हल करने के लिए कोड की नई लाइनें जोड़ी जाएंगी मूल अनुमानों का हिस्सा नहीं थे, और नकल को खत्म करने और दक्षता में सुधार करने के लिए हटाए गए कोड की लाइनें दिखाती हैं कि एलओसी / घंटा उत्पादकता के अलावा अन्य चीजों को इंगित करता है।

  • जब कोड तेजी से लिखा जाता है, मैला होता है, फूला हुआ होता है, और बिना किसी प्रयास के रिफैक्टरिंग होता है, तो स्पष्ट दक्षता अपने उच्चतम स्तर पर होगी। यहां नैतिक यह होगा कि आप जो मापते हैं उसके लिए आपको सावधान रहना चाहिए।
  • किसी विशेष डेवलपर के लिए, यदि वे इस सप्ताह उच्च मात्रा में कोड जोड़ रहे हैं या छू रहे हैं, तो अगले सप्ताह कोड की समीक्षा, परीक्षण, डिबग, और rework के संदर्भ में भुगतान करने के लिए एक तकनीकी ऋण हो सकता है।
  • कुछ डेवलपर्स दूसरों की तुलना में आउटपुट के अधिक सुसंगत दर पर काम करेंगे। यह पाया जा सकता है कि वे अच्छी उपयोगकर्ता कहानियां प्राप्त करने में सबसे अधिक समय बिताते हैं, बहुत जल्दी घूमते हैं और संबंधित इकाई परीक्षण करते हैं और फिर बारी-बारी से कोड बनाते हैं जो केवल उपयोगकर्ता कहानियों पर केंद्रित होता है। यहाँ ले जाना यह है कि विधायी डेवलपर्स के पास शायद जल्दी बारी होगी, कॉम्पैक्ट कोड लिखेंगे, और कम rework होगा क्योंकि वे कोड को शुरू करने से पहले समस्या और समाधान को अच्छी तरह से समझते हैं। यह उचित लगता है कि वे कम कोड करेंगे क्योंकि वे कोड के बाद ही सोचते हैं कि वे पहले और बाद में इसके बजाय।
  • जब कोड को उसके दोष घनत्व के लिए मूल्यांकन किया जाता है, तो यह वर्दी से कम पाया जाएगा। कुछ कोड अधिकांश परेशानी और दोषों के लिए जिम्मेदार होंगे। यह पुनर्लेखन के लिए एक उम्मीदवार होगा। जब ऐसा होता है, तो यह सबसे महंगा कोड बन जाएगा क्योंकि इसके द्वारा उच्च स्तर की पुनरावृत्ति होती है। इसमें कोड काउंट (जोड़े गए, हटाए गए, संशोधित किए गए,) की उच्चतम सकल लाइनें होंगी, जैसा कि CVS या SVN जैसे उपकरण से रिपोर्ट किया जा सकता है, लेकिन प्रति घंटे कोड की सबसे कम शुद्ध लाइनें निवेशित होती हैं। यह अंत में सबसे जटिल समस्या या सबसे जटिल समाधान को लागू करने वाले कोड का संयोजन हो सकता है।

भले ही कोड की लाइनों में प्रोग्रामर उत्पादकता पर बहस कैसे निकले, आप पाएंगे कि आपको अधिक मैन पॉवर की आवश्यकता है जो आप खर्च कर सकते हैं और सिस्टम कभी भी समय पर पूरा नहीं होगा। आप वास्तविक उपकरण मैट्रिक्स नहीं हैं। वे बेहतर कार्यप्रणाली का उपयोग करते हैं, सबसे अच्छा डेवलपर्स जिसे आप किराए पर ले सकते हैं या प्रशिक्षित कर सकते हैं, और गुंजाइश और जोखिम का नियंत्रण (संभवत: फुर्तीली विधियों के साथ)।


The take away here is that methodical developers will probably have quick turn around, will write compact code, and have low rework.सहमत नहीं हैं। यह या तो कम reword या त्वरित बदलाव है। ठीक है, तीसरे विकल्प को जला दिया जाता है और डेवलपर के कैरियर को छोड़ देता है।
नियोलिस्क

3

उसके साथ काम करने के लिए बेहतर मेट्रिक दें

के बजाय एलओसी , समझाने यह है उपयोग करने के लिए सबसे खराब मीट्रिक। फिर उसे एक विकल्प दें:

कार्य की संख्या / विशेषताएं प्रति फीचर / समारोह अनुरोध -> Noff / RFF

आपको प्रति सप्ताह अनुरोधों की मात्रा को पूरा करने के लिए NOFF / RFF के शीर्ष पर एक भार / सामान्यीकरण जोड़ने की आवश्यकता हो सकती है।

:) स्पष्ट रूप से ऊपर बना है, लेकिन कुछ भी, SLOC से बेहतर है ...


3

मैं आपको बता सकता हूं कि एक बड़ी परियोजना के लिए ठेकेदारों के एक लोड ने एक वर्ष में 15000 एलओसी (प्रत्येक) लिखा था। यह एक अविश्वसनीय रूप से मोटा जवाब है, लेकिन यह हमारे लिए उपयोगी था क्योंकि हमारे पास 400,000 मौजूदा C ++ LoC है और हम यह पता लगा सकते हैं कि इसे C # में परिवर्तित करने से हमें पूरा करने में लगभग 26 मानव-वर्ष लगेंगे। दे या ले।

इसलिए अब हम परिमाण के मोटे क्रम को जानते हैं, हम इसके लिए बेहतर योजना बना सकते हैं - 20 देव प्राप्त करना और उन सभी के लिए एक साल के काम का अनुमान लगाना सही होगा। मतगणना से पहले, हमारे पास कोई सुराग नहीं था कि प्रवास करने में कितना समय लगेगा।

तो आपके लिए मेरी सलाह यह है कि आप एक विशिष्ट मात्रा में लिखे गए सभी कोड की जांच करें (मैं काम करने के लिए एक नई परियोजना के लिए भाग्यशाली था), फिर उस पर कई कोड मीट्रिक टूल में से एक चलाएं। संख्या को समय से विभाजित करें और आप उसे सटीक उत्तर दे सकते हैं - आप प्रति दिन कितना एलओसी लिखते हैं। हमारे लिए, वह प्रति दिन 90 LOC पर निकला था! मुझे लगता है कि हमने उस परियोजना पर बहुत सारी बैठकें और प्रलेखन किए हैं, लेकिन फिर मुझे लगता है कि हम अगले एक बैठक में बहुत सारी बैठकें और प्रलेखन करेंगे ...


2

सही के बारे में लगता है।

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

यदि आप डिबगिंग, डॉक्यूमेंटेशन, प्लानिंग आदि को ध्यान में रखते हैं, तो यह औसत प्रति दिन लगभग 10 लाइनों का कोड होता है। वास्तव में मैं उच्च पक्ष (यानी एक बहुत ही उत्पादक देव) पर एक दिन में 10 लाइनें लगाऊंगा।

भले ही आप एक ही दिन में सौ लाइनों की एक जोड़ी का मंथन कर सकते हैं (यह टिकाऊ नहीं है)। यह गुणवत्ता कोड नहीं हो सकता है जब तक कि आपने तब सभी इकाई परीक्षण को दस्तावेज में जोड़ दिया हो और निश्चित रूप से आपकी इकाई परीक्षण त्रुटियों को दिखाने के बाद कोड को डिबग कर दिया हो। आखिरकार, आप 10 पर वापस आ गए हैं।


1

मेरा अनुमान है, C # जैसी भाषा के साथ काम करने वाले डेवलपर को लगभग 10K LoCs / दिन लिखने / उत्पन्न करने में सक्षम होना चाहिए। मुझे लगता है, मैं ऐसा कर सकता था। मैं बस कभी नहीं होगा।

आप एक डेवलपर से क्या चाहते हैं, 10 एलओसी / दिन में अपना काम करवाने के लिए। कम कोड हमेशा बेहतर होता है। मैं अक्सर कई बार कोड का उत्पादन शुरू कर देता हूं और तब तक काट लेता हूं जब तक कि मैं नंगे अधिकतम सरलता तक नहीं पहुंच जाता, इसलिए मेरे पास वास्तव में नकारात्मक LoCs वाले दिन होते हैं।

एक अर्थ में, कोडिंग कविता की तरह है। सवाल यह नहीं है कि एक कवि कितनी पंक्तियों में लिख सकता है, लेकिन एक सॉनेट की 14 पंक्तियों में वह कितना व्यक्त कर सकता है।


5
10K LoC? IMO जो केवल एक जनरेटर द्वारा किया जा सकता है। जहां तक ​​एलओसी को हस्तलिखित करने की बात है, मैं इसके बजाय ऊपरी सीमा को 1 के एलओसी की सीमा में रखना चाहूंगा। और यह एक उत्पादक दिवस होना चाहिए।
user281377

@ स्तनो: यह संभव है। यदि कोई आपसे जितना संभव हो उतना कोड लिखने के लिए कहता है, तो आप ऐसा कर सकते हैं। यह शायद सिर्फ एक मिथक है, लेकिन मैंने सुना है कि प्रोग्रामर कई एलओसी का निर्माण करने के लिए मजबूर करते हैं ताकि मृत या डुप्लिकेट कोड को शामिल किया जा सके, हाथ से लूप और इनलाइनिंग का विस्तार करके (या पहले स्थान पर लूप और सबरूटीन न होने पर) और कई अन्य बेवकूफ बातें। इसके अलावा, बॉयलरप्लेट कोड का अति प्रयोग मदद करता है: D
back2dos

@ back2dos: ठीक है, मैं कोड के बारे में सोच रहा था जो वास्तव में समझ में आता है।
user281377

@ स्तन: अच्छी तरह से निश्चित रूप से कुछ भी नहीं है जो मैं आपको दोषी ठहराऊंगा। मेरी बात यह थी कि मेट्रिक्स, कि कोड के लिए कोई मतलब नहीं है, इसका कोई मतलब नहीं है;)
back2dos

1

अपने प्रबंधक को इसे संभालने दें, या नौकरी की तलाश शुरू करें।

सभी गंभीरता में, आप टिम को खर्च कर सकते हैं, जो कार्य को पूरा करने की दिशा में एक परियोजना की प्रगति को मापने के उचित और अनुचित तरीकों को समझाने में एक निराशाजनक प्रयास हो सकता है। हालांकि सभी वास्तविकता में, इंजीनियरिंग और प्रोजेक्ट मैनेजर किस लिए हैं।

दूसरी ओर में, परिस्थितियों कि कार्यकारी-इन-सवाल ऐसे हैं है अपने इंजीनियरिंग और / या परियोजना प्रबंधक। आपके पास निपटने के लिए बहुत बड़े और अधिक बुनियादी मुद्दे हैं, भले ही वे अभी तक खुद को प्रकट न करें। इस मामले में इस तरह का मुद्दा आने वाली बड़ी समस्याओं के लिए "चेतावनी शॉट" के रूप में काम कर सकता है।


1

अन्य उत्तर सही हैं, यह एक गूंगा प्रश्न है और उत्तर का अर्थ यह नहीं है कि लानत है। यह सब सच है, लेकिन मुझे पता है कि मैंने एक महीने में कोड की कितनी लाइनों का उत्पादन किया।

यह बिना XML-doc के C # कोड की लगभग 3000 लाइनें है। मैं नई कार्यक्षमता लागू कर रहा था और एक महीने या एक महीने और एक सप्ताह में इस राशि के साथ समाप्त हुआ। यह वह सब है जो स्रोत नियंत्रण में समाप्त हो गया है, बहुत सारे कोड लिखे गए और फिर हटाए गए या हटाए गए।

मैं एक C # डेवलपर हूं और मैं इसमें अच्छा बनने की कोशिश कर रहा हूं, लेकिन मैं आपको बता नहीं सकता कि मैं कितना अच्छा हूं। मैंने अच्छा कोड लिखने की कोशिश की और इसे बनाए रखने के लिए बहुत प्रयास किए। मैं इस कोड में केवल एक या दो बार टिप्पणी करता हूं।

मुझे नहीं पता कि यह कोड की बहुत अधिक या बहुत कम पंक्तियाँ हैं और मुझे कहना होगा कि मुझे वास्तव में परवाह नहीं है। यह डेटा का एक अर्थहीन टुकड़ा है और इसे किसी भी तरह से एक्सट्रपलेशन के लिए सुरक्षित रूप से उपयोग नहीं किया जा सकता है। लेकिन मुझे यह डेटा पता है इसलिए मैंने साझा करने का फैसला किया।


0

खैर, मुझे हमेशा की तरह इस पार्टी में थोड़ी देर हो गई है, लेकिन यह वास्तव में एक दिलचस्प है। मैंने शुरू में ही सबसे ज्यादा यही सोचा था कि कार्यकारी का सवाल गलत है। हालांकि, मैंने एसके-लॉजिक के उत्तर को पढ़ा और महसूस किया कि यह एक समझदार प्रश्न है जो निरर्थक तरीके से पूछा गया है। या, अलग तरीके से कहें, तो सवाल के पीछे एक वैध समस्या है।

प्रबंधकों को अक्सर एक परियोजना के लिए व्यवहार्यता, वित्त पोषण, स्टाफिंग आदि का निर्धारण करने की कोशिश करनी होती है। यह एक समझदार समस्या है। स्ट्रेटफ़ोर्ड पोर्ट के लिए प्रति दिन कोड प्रति डेवलपर की अनुमानित औसत लाइनों द्वारा विभाजित पोर्ट की लाइनों के आधार पर एक अनुमान सादगी से अपील कर रहा है, लेकिन इस पृष्ठ पर दिए गए सभी कारणों के लिए विफल होने का संकेत दिया गया है।

एक अधिक समझदार दृष्टिकोण होगा: -

  1. ऑन-द-स्पॉट अनुमान के लिए, कोड के साथ सबसे अधिक अनुभव के साथ डेवलपर्स से पूछें कि यह कितना समय लगेगा। यह कई कारणों से गलत है कि मैं यहां नहीं जाऊंगा, लेकिन यह सबसे अच्छा है कि वे शुरुआत में ही कर पाएंगे। कम से कम उन्हें इस बात का अंदाजा होना चाहिए कि क्या अतिरिक्त संसाधनों के साथ भी यह एक हफ्ते या सालों में आसान हो जाएगा। यदि कोई समान आकार के बंदरगाह या काम के टुकड़े किए गए हैं, तो वे इसे एक गाइड के रूप में उपयोग कर सकते हैं।
  2. कुल आकार प्राप्त करने के लिए घटक द्वारा पोर्ट का अनुमान लगाएं। पोर्ट से सीधे जुड़े हुए कार्यों को शामिल करने की आवश्यकता नहीं है, जैसे कि बुनियादी ढाँचा (मशीनें, सिस्टम बनाना, आदि), जाँच करना और सॉफ्टवेयर खरीदना आदि।
  3. पोर्ट के सबसे जोखिम वाले घटकों की पहचान करें और पहले उन लोगों के साथ शुरू करें। ये अनुमान सबसे ज्यादा उड़ाने की संभावना रखते हैं, इसलिए यदि संभव हो तो ऊपर-सामने किया जाना चाहिए ताकि बंदरगाह में देर से आश्चर्य हो।
  4. पोर्ट की अपेक्षित अवधि की लगातार गणना करने के लिए चरण 2 में किए गए आकार के खिलाफ प्रगति का ट्रैक रखें। जैसे-जैसे प्रोजेक्ट आगे बढ़ता है यह और अधिक सटीक होना चाहिए। बेशक, कोड की पंक्तियों की संख्या जो पोर्ट की गई है (मूल कोड आधार में विशेषताएँ जो अब पोर्ट किए गए कोड में हैं) का उपयोग मीट्रिक के रूप में भी किया जा सकता है और वास्तव में यह सुनिश्चित करने के लिए सहायक है कि मूल उत्पाद के बजाय पोर्ट किया जा रहा है वास्तविक पोर्ट से निपटने के दौरान शांत नई कार्यक्षमता का एक गुच्छा जोड़ा जा रहा है।

ये नंगे-हड्डियों के कदम होंगे, निश्चित रूप से इसके आसपास कई अन्य गतिविधियां हैं जो सहायक हैं जैसे पोर्टिंग टूल और प्लगेबल फ्रेमवर्क की जांच करना, प्रोटोटाइप बनाना, यह निर्धारित करना कि वास्तव में पोर्ट किए जाने की आवश्यकता है, परीक्षण उपकरण और बुनियादी ढांचे का पुन: उपयोग करना आदि।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.