पायथन कोडिंग मानक बनाम उत्पादकता


18

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

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

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

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

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

सभी समय सीमा को पूरा करने के लिए दबाव बढ़ रहा है।

मेरा मानना ​​है कि एक बुनियादी मुद्दा यह है कि प्रमुख देव और एक अन्य कोर देव ने अन्य डेवलपर्स पर भरोसा करने से इनकार कर दिया है ताकि वे अपना काम कर सकें। लेकिन उससे कैसे निपटें? हम अपना काम नहीं कर सकते क्योंकि हम सब कुछ लिखने में बहुत व्यस्त हैं।

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


4
याद रखें कि कोडिंग मानकों का उद्देश्य दीर्घकालिक उत्पादकता को बढ़ाना है। यह अल्पकालिक उत्पादकता की लागत पर आता है यदि अस्तित्व परियोजना लंबे समय तक किसी भी मानक का पालन नहीं कर रही थी।
Arseni Mourzenko

1
कोडिंग मानकों के अनुसार अपने कोड को स्वचालित रूप से ग्रहण करने के लिए बस ग्रहण और पाइदेव को प्रोग्राम करें। यह कुछ संवाद बॉक्स भरने की बात है।
user16764

1
@DemianBrecht - सहयोगी रूप कोडिंग मानकों जो परिभाषित और सभी कोडर द्वारा सहमत हुए हैं लेखक हैं एक अच्छी बात है और कर सकते हैं लंबे समय तक उत्पादकता में सुधार। आधिकारिक कोडिंग मानक, जो टीम से बिना खरीद- फरोख्त के ऊपर से लगाया गया है, समय की भारी बर्बादी है और परियोजना को गतिरोध या प्रतिगमन करने के लिए बर्बाद कर सकते हैं, जैसा कि तथाकथित लीड डेवलपर द्वारा परीक्षण को फेंकने से छूट दी गई है क्योंकि कोड फिर से नए मानक उन परीक्षणों में विफल रहे। ईमानदारी से WTF?
मार्क बूथ

1
@MarkBooth: आप हर किसी को खुश नहीं कर सकते। मैं सहमत हूं कि यदि यह केवल ऊपर से लगाया गया है तो अन्य सदस्यों से खरीदना मुश्किल है, लेकिन यह अभी भी "समय की भारी बर्बादी" नहीं है। मानकों को लागू करने में, कोड अधिक सुसंगत होना चाहिए और इसलिए आप पूरे प्रोजेक्ट में कोड में कम विविधता में भाग लेंगे, जिससे पठनीयता बढ़ जाती है। लेकिन हाँ .. मानकों के कारण परीक्षण फेंकने से मुझे विश्वास हो जाएगा कि हुड के नीचे बड़ी समस्याएं थीं।
डेमियन ब्रेख्त

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

जवाबों:


27

कोडिंग मानक समस्या नहीं हैं। समस्या यह है कि प्रबंधन यह पता नहीं लगा सकता है कि समस्या क्या है। यह "कुछ करो ... कुछ भी करो!" मोड। आप एक तर्कसंगत समाधान की तलाश कर रहे हैं, लेकिन यह एक तर्कहीन समस्या है। सबसे अच्छा आप कर सकते हैं:

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

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

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

7

किसी को यह तय करने की आवश्यकता है कि मानकों को पूरा करने के लिए शिपिंग या सुस्त पालन वास्तविक प्राथमिकता है। मुझे पता है कि मेरी प्राथमिकता क्या होगी; अगर यह यूनिट और स्वीकृति परीक्षण से गुजर रहा है, तो मैं कहता हूं कि जहाज। एक बार जब यह जहाज जाता है, तो कंपनी यह तय कर सकती है कि तकनीकी ऋण को ठीक करने के लिए समय और पैसा खर्च करना है या नहीं।

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


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

4

क्या मैं मानकों के कोडिंग के लिए उनके पालन पर सवाल उठाना गलत हूं?

यह समूह पर निर्भर करता है। निजी तौर पर , मुझे लगता है कि हर चीज पर सवाल उठाया जाना चाहिए। कुछ लोग सवाल उठाते हैं कि वे एक अफेयर हैं; कि मुझे उन पर भरोसा नहीं है।

क्या किसी और ने भी ऐसी ही स्थिति का अनुभव किया है और कैसे उन्होंने सफलतापूर्वक इससे निपटा है?

मैंने पूछा कि ये मानक उत्पादकता में कैसे सुधार करते हैं। मैंने उस समय को मापा जब मैंने मानकों के साथ खराब होने के लिए खर्च किया था बनाम 'सामान किया जाना'। अंत में, जो शक्तियाँ मानकों के साथ चिपके रहने का निर्णय लिया जाता है। होता है। मैंने उनके बारे में सामान्य से अधिक जोर से शिकायत की जब वे मेरे सामान नहीं होने का कारण थे, लेकिन अन्यथा अपना काम पूरा करने पर ध्यान केंद्रित करते थे। लगातार चीजों के बारे में लड़ना उत्पादकता के लिए अच्छा नहीं है ...

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


3

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

यदि यह वास्तव में परियोजना के अंत में रखा गया था, तो यह आपकी लीड (IMHO) द्वारा की गई गलती है।

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

अंत में, उसके अनुरोधों और मानकों का अनुपालन करते हुए, आप उसे लापता डेडलाइन के लिए एक आसान बलि का बकरा प्रदान नहीं करते हैं।

साथ ही, मैं कोडिंग मानकों का एक बहुत बड़ा समर्थक हूं (विशेषकर एक टीम का आकार बढ़ता है), लेकिन जब यह समझ में आता है तो उन्हें लागू किया जाना चाहिए।


1

आपका प्रश्न था '' क्या मैं कोडिंग मानकों के पालन के बारे में सवाल करना गलत हूँ? ''। http://c0x.coding-guidelines.com/Introduction.pdf (C प्रोग्रामिंग भाषा के लिए) में कोडिंग दिशानिर्देशों के मूल्य पर कुछ संदर्भित अध्ययन हैं। पेज 9 पर शुरू होने वाले सेक्शन 9 को देखें।

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

मैं किसी दूसरे व्यक्ति से कहूंगा कि 'दीर्घकालिक उत्पादकता' के लिए मानकों को लागू किया गया है - कोड की स्थिरता जैसे मुद्दे। हो सकता है कि कुछ घटना घटित हुई जो भ्रम और गलत व्याख्या के कारण परियोजना को वापस गंभीर रूप से स्थापित कर दे।

ऐसा लगता है कि दोनों पक्षों में बहुत अधिक भावना है - तर्कपूर्ण चर्चा करने के लिए प्रयास करें।


1

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

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

अपने सामान्य लक्ष्य को पूरा करने के तरीकों का पता लगाने की दिशा में चर्चा को नग्न करने की कोशिश करें; काम करने और बनाए रखने योग्य सॉफ्टवेयर को तुरंत वितरित करना।

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

यदि यह काम करता है, तो आप उसे और अधिक मनमाने नियमों को हटाने की कोशिश कर सकते हैं जो कुछ टूल के साथ ऑटोफ़ॉर्मेट नहीं हो सकते।


-2

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

हो सकता है, एक बात, हो सकता है कि लीड / मर्ज करने से पहले सभी कोड की जांच की जाए / जो भी सुनिश्चित करें कि यह मानक का अनुपालन करता है, क्योंकि जाहिर है कि मौजूदा टूल-चेन स्वचालित रूप से इसे जांचने में असमर्थ है।


-3

सॉफ्टवेयर जो भोजन के वितरण को गति देकर आपात स्थितियों में जान बचाने में मदद कर सकता है

मैं अच्छे कोडिंग मानकों में विश्वास करता हूं, लेकिन मैं यह भी मानता हूं कि इससे जीवन बचता है को ज्यादा महत्वपूर्ण है।

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

अच्छी खबर: आपके पास परीक्षण हैं। टेस्ट आपको कार्यक्षमता को तोड़ने के बिना अपने कोडिंग मानकों का पालन करने में मदद करेंगे, लेकिन यह शिपिंग के बाद होना चाहिए , पहले नहीं।


1
शिपिंग के बाद क्या होना चाहिए? कार्यक्षमता को तोड़ने के बिना कोडिंग मानकों का अनुपालन? परीक्षण कर रहे हैं?
Martijn Pieters

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