गिना जा रहा है आप कोड आप एक साल

Question

मैं वास्तविक आंकड़े और अनुभवों की तलाश में हूँ में लिखने का आकलन से बचा सकता है कि कितना समय, यह भी आत्मगत ले कृपया नहीं:

जबकि कुछ और की तलाश में, मैं happened on an interesting statement, जो आंशिक रूप से पढ़ने इस प्रकार है:

[...] राष्ट्रीय औसत 9,000 प्रति व्यक्ति प्रति वर्ष कोड की लाइनें है [...]

। 210

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

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

Answer 1

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

मैं यह भी ध्यान दूंगा कि कुछ काफी परिष्कृत मॉडल हैं जिनके पास पर्याप्त अनुसंधान हुआ है और यहां तक ​​कि वास्तविक परियोजनाओं के खिलाफ भी मापा गया है ताकि वे कम से कम कुछ विचार प्राप्त कर सकें कि उनके परिणाम वास्तविकता से संबंधित हैं।उदाहरण के लिए, COCOMO II मॉडल आम तौर पर समय प्रति इकाई कोड की लाइनों का उपयोग करने से बेहतर परिणाम देगा। कम से कम एक free online implementation है (संपादित करें: इसे देखकर, यह अब या तो LoC या फ़ंक्शन पॉइंट आधारित मॉडलिंग की अनुमति देता है)। SoftStar और Function Point Modeler जैसे टूल भी हैं जो कि कॉकॉमो-जैसे मॉडल को फ़ंक्शन पॉइंट्स के साथ जोड़ते हैं ताकि वे निष्पक्ष ठोस परिणाम होने के लिए (कम से कम मेरे लिए) दिखाई दे सकें।

Answer 2

18000 दिन में लगभग 36 लाइनों के कोड का औसत होगा।

दिन में केवल 36 लाइनों के कोड के साथ, समस्या क्या है? समस्या डीबगिंग और आपके कोड को फिर से लिखना है।

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

जहां आप समय बचा सकते हैं, इस बारे में अधिक सावधान रहना है कि आप कैसे कोड करते हैं। क्यूए के माध्यम से अपनी परियोजना को थोड़ा तेज़ी से प्राप्त करें - अधिक स्पष्ट, टाइपएफ़ भाषा और कोड में कोड अधिक स्पष्ट रूप से प्राप्त करें।

जहां भी संभव हो, अपना कोड डेटा संचालित और पूरी तरह से फैक्टर कर रहा है, हालांकि यह आपके द्वारा भेजे जाने वाले एलओसी को कम कर देगा, इससे हर किसी के जीवन को आसान बना दिया जाएगा और परियोजना तेजी से बढ़ जाएगी।

स्वचालित कोड इनपुट कभी न करें - यदि आप कर सकते हैं, तो आप इसे गलत कर रहे हैं!

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

Answer 3

यह Mythical Man Month में मेट्रिक के प्रकार के बारे में बात की गई है। मैन-डेज़/महीनों/वर्षों में परियोजनाओं का आकलन करना, या उत्पादकता मेट्रिक के रूप में कोड की गिनती लाइनिंग रिपोर्टिंग में गलतता की गारंटी देता है।

Answer 4

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

जितना अधिक एसएलओसी नंबर कुछ भी लायक है, यह केवल इसी तरह की परियोजनाओं में काम कर रहे एक ही विकास दल के भीतर है।

Answer 5

मेरा मानना ​​है कि एलओसी की दर परियोजना में technical debt पर निर्भर करती है।

मेरे पास एक प्रोजेक्ट (एसक्यूएल) है जो 27 केएलओसी (समर्थन के लिए 4K अधिक) है। 7 महीने से अधिक इस कोड पर काम करते हुए, मैंने परियोजना के लिए 3 के नेट न्यू लॉक को जोड़ा, लगभग 14 केएलओसी केवल फेंकने के परीक्षण के लिए लिखा गया (विसंगतियों को अलग करने के लिए परीक्षण, यूनिट परीक्षण नहीं)।

आप मापने के तरीके के आधार पर, मैं 2 9 केएलओसी/वर्ष ((3 के + 14 के)/7 महीने * 12 महीने) लिखता हूं लेकिन केवल 5 केएलओसी/वर्ष (3 के/7 महीने * 12 महीने) का उत्पादन करता हूं।

ऋण (27 केएलओसी) को ऋण के रूप में देखते हुए, हमारे पास कोड है जो प्रति वर्ष फेंकने वाले कोड में 7% (2 केएलओसी) उत्पन्न करता है, या प्रति वर्ष 88% (24 केएलओसीसी) उत्पन्न करता है।

मान लीजिए कि मैं एक संपूर्ण 2 9 केएलओसी/वर्ष को चालू करना जारी रख सकता हूं, और मानते हुए कि कोड को बनाए रखने की लागत 88%/सालाना है, मेरी निजी परियोजना सीमा कोड की 33 के रेखाएं हैं। इसके अलावा, मैं अपने तकनीकी समय पर ब्याज का भुगतान करने, फेंकने वाले कोड लिखने और नेट शून्य एलओसी का उत्पादन करने में अपना पूरा समय व्यतीत करूंगा।

भाग्यशाली है कि अंतिम 3KLOC एक रिफैक्टरिंग था, जो मेरी ब्याज दर को कम करना चाहिए।