उत्पादकता को मापने के लिए एसएलओसी के वैध उपयोग ज्ञात हैं?


55

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

उन्होंने मीट्रिक के बारे में आपत्तियों को यह कहते हुए खारिज कर दिया कि एक ही कंपनी के भीतर, समान संस्कृति के साथ, व्यवसाय की रेखा और पर्याप्त डेटा के साथ, अंतर (अद्वितीय स्थितियों और व्यक्तियों की क्षमताओं के लिए) पर्याप्त मिश्रण करते हैं ताकि SLOC मीट्रिक उत्पादकता की तुलना करने के लिए उपयोगी हो। उपकरण और भाषाएँ।

जबकि मुझे नहीं लगता कि यह दावा कठोर सांख्यिकीय विश्लेषण द्वारा समर्थित है, क्या उद्योग में कुछ सबूत हैं जो इस सोच की रेखा का समर्थन करेंगे?


25
उत्पादकता गलत शब्द है। उस अवधि को समय की अवधि में पूरा किए गए कार्य की मात्रा के रूप में परिभाषित किया गया है, जो उत्पादित कोड के लिए असंबंधित है।
फ्रैंक हिलमैन

25
एक बुद्धिमान व्यक्ति ने कहा कि हमें कोड की पंक्तियों को "निर्मित" नहीं बल्कि "खर्च" के रूप में समझना चाहिए; भौतिक इंजीनियरिंग में जब हम BOM के भागों की गिनती और लंबाई पर विचार करते हैं, तो छोटा बेहतर होता है।
pjc50

23
विभिन्न भाषाओं की तुलना (भले ही स्थिर या गतिशील हो) "एक ही कंपनी के भीतर, समान संस्कृति के साथ, व्यवसाय की रेखा" की धारणा को हरा देती है: भाषाओं में अंतर SLOC तुलनाओं को अर्थहीन बनाते हैं।
लूटना

4
यह विधि त्रैमासिक त्रुटिपूर्ण है। एक ही कंपनी में एक ही विकास के माहौल का उपयोग करने वाले दो अलग-अलग डेवलपर्स अक्सर एक ही सुविधा सेट को लागू करने के लिए बहुत अलग एसएलओसी का उत्पादन करेंगे।
17 की 26

8
उत्पादकता को मापने के लिए एसएलओसी का उपयोग करना उतनी ही समझदारी है, जितना कि जब आपको ईंधन की दक्षता के बारे में ध्यान रखना चाहिए, तो दूरी को मापने के लिए उत्सर्जित प्रदूषण का उपयोग करना चाहिए। जिन तरीकों से यह सही है, वे अभी भी गलत हैं। इसका उपयोग करें
१०:१२ पर candied_orange

जवाबों:


66

वरिष्ठ वास्तुकार का तर्क दो चीजों का मतलब हो सकता है।

  1. इसका मतलब यह हो सकता है कि कंपनी में एक औसत डेवलपर गतिशील भाषाओं का उपयोग करते समय स्थिर भाषाओं का उपयोग करते हुए कोड की अधिक पंक्तियों का उत्पादन करता है। उदाहरण के लिए, यदि पंद्रह डेवलपर्स छह महीने के लिए जावा के साथ काम करते हैं, तो वे 100 KLOC लिखेंगे, और यदि वही पंद्रह डेवलपर्स छह महीने के लिए पायथन के साथ काम करते हैं, तो वे केवल 50 KLOC लिखेंगे।

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

  2. उनका यह भी मतलब हो सकता है कि कंपनी में एक औसत डेवलपर गतिशील भाषाओं का उपयोग करते समय स्थिर भाषाओं का उपयोग करते हुए कोड की कम पंक्तियों का उत्पादन करता है: पंद्रह डेवलपर्स छह महीने में जावा में 100 KLOC, या पायथन में 200 KLOC लिखेंगे।

    हालांकि कोड की कम लाइनें आमतौर पर बेहतर होती हैं (लिखने के लिए, पढ़ने और बनाए रखने के लिए कम कोड), यह अभी भी स्पष्ट नहीं है कि पायथन लोगों की तुलना में जावा डेवलपर्स ने कितनी विशेषताएं पैदा कीं। हो सकता है कि उन्होंने पायथन डेवलपर्स की तुलना में कोड की आधी पंक्तियां लिखी हों, लेकिन आधी संख्या में विशेषताएं भी उत्पन्न की हों?

दोनों ही मामलों में, LOC एक मूल्यवान मीट्रिक नहीं है, क्योंकि समान सुविधा अलग-अलग भाषाओं में कोड की समान मात्रा में अनुवाद नहीं करेगी । कुछ भाषाओं में अधिक क्रिया होती है; दूसरों-अधिक कॉम्पैक्ट। जबकि कुछ मामलों में, कॉम्पैक्टनेस मूल्यवान है, इसके लिए कोई सामान्य नियम नहीं है। एक चरम उदाहरण ब्रेनफैक भाषा होगी जिसमें अत्यधिक कॉम्पैक्टनेस है, लेकिन जो इसकी पठनीयता के लिए लोकप्रिय नहीं है। समान भाषाओं की तुलना करना मुश्किल हो सकता है: उदाहरण के लिए, जब यह घुंघराले ब्रेसिज़ की बात आती है, तो जावा K & R शैली का अनुसरण करता है, जबकि C # में, आधिकारिक स्टाइल का पालन करते समय, ज्यादातर मामलों में प्रारंभिक घुंघराले ब्रेस अपनी लाइन में होते हैं, जो कृत्रिम की ओर जाता है। C # के लिए LOCs की वृद्धि। और क्या होता है जब कोई एक प्रक्रियात्मक भाषा की तुलना एक वस्तु-उन्मुख एक या एक कार्यात्मक भाषा के साथ करता है?

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

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


8
हाँ। केवल मीट्रिक मैं भरोसा करता हूं कि प्रति यूनिट समय पर पूरा किए गए टिकटों की संख्या (विशेषताएं, बग, अनुसंधान आदि) हैं। यह टीम द्वारा अलग-अलग होता है (अलग-अलग टीम अलग-अलग ग्रैन्युलैरिटी के साथ टिकटों को तोड़ती है) लेकिन एक ही टीम या टीमों के समूह के भीतर टिकट आकार को काफी सटीक बनाने के लिए एक संस्कृति सामने आएगी (जब तक आप उस संस्कृति के बाहर से उनकी तुलना नहीं करते)
स्लीवतमैन

10
यह बात मुझे अधिक पसंद है: "कभी भी केवल एक मीट्रिक पर भरोसा न करें"
चोकोक्रोक

30
@slebetman मुझे आपके टिकट बनाने वाले व्यक्ति की सटीकता / निरंतरता से जलन होती है, लेकिन मुझे "2 शब्दों को ठीक करें" से लेकर "फीचर X जोड़ें" जैसे मुद्दों को हल करना होगा। टिकटों का मीट्रिक LOC की तुलना में मेरे लिए कम उपयोगी है। कम से कम 20 एलओसी द्वारा क्लास कोड कम करने से मुझे किए गए काम का अंदाजा हो जाता है। 5 टिकटों को हल करना एक घंटे का काम हो सकता है, लेकिन साथ ही एक सप्ताह भी हो सकता है।
आर। श्मिट्ज़

3
@ R.Schmitz यह मेरी कंपनी में एक ही है, लेकिन प्रत्येक टिकट में एक आकार भी जुड़ा होता है, इसलिए टिकट आकार पर काम करना होगा।
निको बर्न्स

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

26

उत्पादकता और SLOC के बारे में

SLOC के साथ समस्या

एसएलओसी मीट्रिक के साथ समस्या यह है कि यह कोड की मात्रा के एक अनुमान को मापता है, जिसे ध्यान में रखे बिना:

  • कोड की गुणवत्ता (यानी क्या होगा यदि प्रत्येक 100 SLOC के लिए आपको बग के कारण एक और 90 SLOC जोड़ना होगा, लेकिन यह कि आपको पता नहीं है कि आपका कोड किस समय वितरित किया गया है?)
  • लक्ष्य कोड के साथ पहुंच गए (यानी 10K SLOC सभी अपेक्षित उपयोग के मामलों या उपयोगकर्ता कहानियों को संभालती है? या केवल एक छोटे उपसमूह को?)
  • कोड की स्थिरता (यानी आपको उभरती आवश्यकताओं की उम्मीद करने के लिए कोड को समायोजित करने के लिए 1% या 50% अधिक कोड जोड़ना होगा?)।

अन्यथा कहा गया है, बहुत से कॉपी-पेस्ट किए गए भागों के साथ त्रुटि रहित अनपेक्षित स्पेगेटी कोड के उत्पादन को सावधानीपूर्वक इंजीनियर पुन: प्रयोज्य कोड की तुलना में अधिक उत्पादक माना जाएगा।

तो SLOC निश्चित रूप से उत्पादकता को मापने का सबसे अच्छा तरीका नहीं है।

हम किस उत्पादकता पर विचार कर रहे हैं?

उत्पादकता को एक प्रक्रिया के लिए मापा जाता है। इसलिए SLOC अकेले कोडिंग प्रक्रिया के लिए पूरी तरह से वैध संकेतक हो सकता है।

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

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

सॉफ्टवेयर डिलिवरेबल्स कैसे मापें?

कई दृष्टिकोण मौजूद हैं:

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

स्थिर बनाम गतिशील टाइपिंग की उत्पादकता के बारे में

मुझे यह स्वीकार करना होगा कि मैं व्यक्तिगत रूप से वैधानिक रूप से टाइप की जाने वाली भाषाओं का प्रशंसक हूं, क्योंकि अपने भीतर के स्वयं को मैं जानता हूं कि यह अधिक विश्वसनीय है (कोडिंग के वर्षों ने मुझे यह साबित कर दिया है)।

अतः एक बात जो मैं सुनिश्चित करता हूं वह यह है कि स्टेटिक टाइप की गई भाषाओं की तुलना में स्टेटिकली टाइप की गई भाषा संकलन के समय (उदाहरण के लिए टाइपो, बेमेल टाइप) में बहुत अधिक त्रुटियों / बग्स को रोकने में सक्षम है। लेकिन सभी निष्पक्षता में, मैं इसे उच्च उत्पादकता के रूप में अपमानजनक रूप से सामान्य बनाने की हिम्मत नहीं करूंगा।

क्या आपका आर्किटेक्ट सही है?

शायद शायद नहीं।

लेकिन उनकी दलीलें मान्य नहीं लगती हैं: सांख्यिकीय रूप से टाइप की गई भाषा का उत्पादकता लाभ उन त्रुटियों की एक महत्वपूर्ण संख्या से आता है, जो संकलक द्वारा पकड़ी जाती हैं।

नतीजतन यह गतिशील रूप से टाइप की गई भाषाओं के लिए आवश्यक rework को देखे बिना अकेले SLOC को देखकर इस "उच्च" उत्पादकता लाभ का पता लगाना संभव नहीं है। इसलिए उनकी तुलना निष्पक्ष नहीं हो सकती।

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

उस दावे का समर्थन करने के लिए कोई अध्ययन?

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


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

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

8
@ConorMancone कोड लिखने के लिए किसी को भुगतान नहीं किया जाता है। उन्हें समाधान बनाने के लिए भुगतान किया जाता है। एक सादृश्य बढ़ई को मापता होगा कि वह कितने नाखूनों और बोर्डों का उपयोग करता है। एक मसखरा जो बोर्डों को छोटा करता है और अधिक नाखून काटता है जो वह घर चलाता है वह इस मीट्रिक द्वारा मास्टर बढ़ई की तुलना में अधिक उत्पादक होगा।
जिमीजैम

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

2
वर्षों पहले, कम से कम एक प्रोग्रामिंग शॉप में कुछ लोगों ने लॉजिक डायग्राम लिखे और अन्य लोगों ने उन लॉजिक डायग्राम को कंपाइलेबल कोड में बदल दिया। संक्षेप में कि दुकान के संकलक में मानव पूर्वप्रक्रमक थे। उन मानव पूर्वजों में से किसी एक की उत्पादकता को मापने के लिए एसएलओसी / माह का उपयोग करना उचित होगा; असेंबली में लाइन असेंबली कर्मी कितने छेद में स्थापित कर सकते हैं, इसके अनुरूप है, जहां इंजीनियरों ने कहा था कि उन्हें जाना चाहिए। इंजीनियर जब 15 को 100 स्क्रू निर्दिष्ट करता है तो नौकरी की आवश्यकता होती है फर्म की उत्पादकता कम होती है। (इसी तरह अगर वे 5 पेंच निर्दिष्ट करते हैं!)
डेविड के

7

यहां आपके वरिष्ठ वास्तुकार के लिए एक जवाबी कार्रवाई है: मान लीजिए कि मैं तीन कक्षाओं का एक पदानुक्रम लिखना चाहता हूं, जिनमें से दो तीसरे से प्राप्त होते हैं, कुछ आभासी कार्यों को लागू करते हैं जो आधार वर्ग को परिभाषित करता है।

अगर मैं C ++ में इन तीनों वर्गों को लिखता हूं, तो यह बहुत सीधा है। मैं कक्षाओं की घोषणा करता हूं, सही स्थानों पर आभासी का उपयोग करता हूं, और किया जा सकता है।

यदि मैं C में इन तीन वर्गों को लिखता हूं, तो मुझे काफी कोड जोड़ने की आवश्यकता होगी: मुझे structv- तालिकाओं के लिए s को परिभाषित करने की आवश्यकता है, मुझे आधार वर्ग में एक v- तालिका सूचक जोड़ने की आवश्यकता है, मुझे जोड़ने की आवश्यकता है कंस्ट्रक्टरों के लिए कोड वास्तव में वी-टेबल पॉइंटर्स सेट करने के लिए, मुझे कंस्ट्रक्टर्स को कोड जोड़ने की आवश्यकता है वास्तव में बेस क्लास कंस्ट्रक्टर को कॉल करने के लिए, मुझे एक कंस्ट्रक्टर को कॉल करने से पहले मेमोरी आवंटन को स्पष्ट रूप से निष्पादित करने के लिए कोड जोड़ना होगा (जो कि C ++ newएक ही चरण में करता है ), इसी तरह, मुझे बाद की free()कॉल से विनाश को अलग करने की आवश्यकता है , और इसी तरह, और आगे।

मुद्दा यह है कि, ये सभी अतिरिक्त चीजें बहुत नासमझ हैं। मैं उन्हें बहुत जल्दी कर सकता हूं। इसलिए, C C संस्करण को लिखने के लिए मुझे C ++ संस्करण लिखने की आवश्यकता नहीं है। फिर भी, मैंने C ++ कोड की तुलना में C कोड की कई और लाइनें बनाई हैं। इतना तो, कि मैं एसएलओसी के संदर्भ में सी में अधिक उत्पादक प्रतीत होता हूं।

किसी भी भाषा को कुछ मात्रा में बॉयलरप्लेट कोड की आवश्यकता होती है, वह ऐसी भाषा की तुलना में SLOCs के संदर्भ में अधिक उत्पादक दिखाई देगी, जिसे बॉयलरप्लेट कोड की समान मात्रा की आवश्यकता नहीं है।

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


1
मुझे आपका आखिरी वाक्य पसंद है।
पीटर - मोनिका

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

6

मैं विरोधाभासी हो जाऊंगा।

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

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

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

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

एक अपवाद

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

जाहिर है, उपरोक्त सब कुछ मेरे अपने व्यक्तिगत अनुभव पर आधारित है। आपका लाभ भिन्न हो सकता है, और जाहिर है कि मैं अल्पमत में हूं। असहमति महसूस करते हैं। हालांकि सारांश में:

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


4
एक अन्य अपवाद भी है: बग शिकार। विशेष रूप से गंदा कीड़े के लिए बग शिकार में एक लंबा समय लग सकता है, लेकिन आमतौर पर कोड परिवर्तन की एक पंक्ति होती है।
नाथन मेरिल

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

हम अपनी कंपनी में gitprime ( gitprime.com ) का उपयोग करते हैं , और एक प्रबंधक और इंजीनियर दोनों के रूप में, मुझे लगता है कि यह दुनिया की सबसे अच्छी बात है। फिर से, यह हमारे लिए केवल तस्वीर का हिस्सा है, लेकिन वास्तविक समस्या होने से पहले इंजीनियरों के साथ संभावित समस्याओं की पहचान करने में यह बेहद मददगार रहा है। पारदर्शिता भयानक है, और वे जो कुछ भी करते हैं वह अंततः SLoC के लिए उबलता है। मूल्य और अंतर्दृष्टि की मात्रा को देखते हुए, मैं एसएलओसी को आउट-ऑफ-हैंड खारिज करने की कुछ इंजीनियरों की प्रवृत्ति के बारे में हमेशा बहुत संदिग्ध हूं। किसी का भी उनकी राय में स्वागत है, लेकिन यह निश्चित रूप से काम करता है
कॉनर मैनकोन

सवाल यह पूछ रहा है कि क्या एलओसी का उपयोग टूल और भाषाओं की तुलना करने के लिए किया जा सकता है, वरिष्ठ डेवलपर के संदर्भ में यह कहते हुए कि यह "स्थिर" भाषाओं में उच्च उत्पादकता दिखाता है। आप एक अलग प्रश्न का उत्तर दे रहे हैं - एलओसी का उपयोग डेवलपर्स की तुलना करने के लिए किया जा सकता है, लेकिन आप अभी भी सहमत हैं कि इसका उपयोग भाषाओं की तुलना करने के लिए नहीं किया जा सकता है क्योंकि एक दिए गए डेवलपर टूल / भाषा की परवाह किए बिना एलओसी की समान संख्या लिखते हैं? आप कहते हैं कि आप अन्य उत्तरों के विपरीत यहाँ हैं, लेकिन ऐसा लगता है कि आप समझौते में हैं?
TessellatingHeckler

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

6

हालांकि मैं बैंडबाजे पर कूद रहा हूं। मुझे लगता है कि प्रोग्रामर के व्यवहार पर प्रभाव को उजागर करने की आवश्यकता है।

उत्पादक के लिए एक उपाय के रूप में एसएलओसी का उपयोग करने से प्रोग्रामर मनोबल पर विषाक्त प्रभाव पड़ता है। आपकी टीम / कंपनी में किसी भी इंजीनियर को यह पता चलता है कि वे SLOC पर मापे जाते हैं।

  1. वे समान कार्य करने के लिए बहुत लंबा कोड लिखना शुरू करते हैं
  2. वे अपने कोड की गुणवत्ता के बारे में कम परवाह करेंगे
  3. वे अन्य चीजें करना बंद कर देंगे जो आपकी टीम की मदद करती हैं (भर्ती, डिबगिंग, जूनियर्स की मदद करना)
  4. वे अपने काम और संभावित छुट्टी से नफरत करेंगे

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


वास्तव में ... कोई भी मेट्रिक जो किसी को निरर्थक कोड हटाने से रोकता है ("आपने इस सप्ताह एक नकारात्मक SLoC मीट्रिक लिया है!" गलत है, सादा गलत!
एंड्रयू

1

यह आमतौर पर उत्पादकता को मापने का एक वैध तरीका नहीं माना जाता है। छोटे कोड आमतौर पर बड़े कोड से बेहतर होते हैं, इसलिए अधिक उत्पादक डेवलपर आमतौर पर कम कोड का उत्पादन करता है। उत्पादकता डीबगिंग में अपना सबसे बड़ा हिट लेती है; कुशल डेवलपर्स डिबगिंग में बहुत कम समय लगाते हैं।

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


1
यदि हम व्यक्तिगत डेवलपर्स की उत्पादकता की तुलना कर रहे हैं तो यह एक मान्य बिंदु हो सकता है। सवाल हालांकि भाषाओं के बीच तुलना के बारे में है, इसलिए संदर्भ बहुत अलग है। उदाहरण के लिए, इसका मतलब यह है कि छोटे कोड बेहतर या बड़े कोड से बदतर नहीं हैं; Ruby में लिखे कोड के साथ Brainfuck में लिखे गए LOC कोड की तुलना करें, कहें तो रूबी।
आर्सेनी मूरज़ेंको

1
@ArseniMourzenko ब्रेनफॉक जैसे चुटकुलों के अलावा, अच्छी तरह से डिज़ाइन की गई भाषाओं की तुलना वास्तव में एक कार्य को हल करने के लिए आवश्यक कोड की मात्रा के आधार पर की जाती है। आमतौर पर ऐसी तुलना को अभिव्यक्ति कहा जाता है। यह सच है, हालांकि, मैं एक ही भाषा में LOC के बारे में बात कर रहा था, न कि भाषाओं में। उत्पादकता को आम तौर पर परिभाषित किया जाता है कि किसी कार्य को करने में कितना समय लगता है; यह प्रोग्रामिंग के लिए विशिष्ट नहीं है।
फ्रैंक हिलमैन

0

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

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

सभी गंभीरता में, टीमों / भाषाओं की उत्पादकता की तुलना करना निरर्थक है क्योंकि बहुत सारे अतिरिक्त कारक हैं जो टीम की उत्पादकता को प्रभावित करते हैं आप इससे सार्थक निष्कर्ष नहीं निकाल सकते हैं।

मैंने एक ऐसी परियोजना पर काम किया, जहां बुनियादी ढांचा बहुत नाजुक था और उपकरण पुराने थे। इस परियोजना का निर्माण जावा पर एक सिंगल पेज ऐप के साथ किया गया था, जिस पर थप्पड़ मारा गया, लेकिन बिना किसी स्पष्ट लाभ के पोर्टलेट कंटेनर में होस्ट किया गया। साधारण परिवर्तनों को करने में लगने वाला समय हास्यास्पद रूप से लंबा था। यदि आप उस विशेष परियोजना पर अपने सभी निष्कर्षों को आधार बनाने के लिए थे, तो आप यह निष्कर्ष निकाल सकते हैं कि जावा खराब था, या एकल पृष्ठ एप्स खराब थे। न ही सच हैं। जिस सिस्टम को बदसूरत प्रोजेक्ट को बदलना चाहिए था, वह C # और WebForms पर बनाया गया था। जब हमने ग्राहकों की ज़रूरतों को संभालने के लिए मौजूदा एप्लिकेशन का विस्तार करने के लिए व्यावसायिक मामला बनाया, तो हमारी उत्पादकता आसमान छू गई। इसका मतलब है कि एक कसकर युग्मित WebForms ऐप बेहतर है? आप केवल इस विशेष मामले के लिए ही निष्कर्ष निकाल सकते हैंऔर यह दुनिया में बड़े पैमाने पर विस्तार नहीं करता है। और यह केवल समझ में आता है क्योंकि विस्तार करने के लिए पर्याप्त परिपक्वता के साथ एक मौजूदा आवेदन था।

यहां तक ​​कि ट्रैकिंग सिस्टम में वस्तुओं को हल करने की दरों की तुलना इस अर्थ में की जाती है कि आप एक दूसरे के खिलाफ प्रोजेक्ट इन्फ्रास्ट्रक्चर की तुलना कर रहे हैं। उपयोग किए जाने वाले पुस्तकालय और ढांचे या तो गति बढ़ा सकते हैं या प्रगति को धीमा कर सकते हैं। आप दूर करने के लिए बहुत कम जड़ता के साथ स्टार्ट अप चरण में हो सकते हैं, जहां आप जिस प्रोजेक्ट से "बेहतर हैं" एक रखरखाव चरण में हैं, जहां नए टिकटों की संख्या अपेक्षाकृत कम है। यह कभी चीजों की तुलना करने का मामला नहीं है।

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