क्या ओओपी कोडिंग प्रथाओं के लिए आप हमेशा समय लेते हैं?

Question

मैं छोटी समयसीमा पर बहुत सारी परियोजनाएं करता हूं और बहुत से कोडों का उपयोग कभी नहीं किया जाएगा, इसलिए कोनों को काटने के लिए हमेशा दबाव/प्रलोभन होता है। एक नियम जो मैं हमेशा चिपक जाता हूं वह encapsulation/ढीला युग्मन है, इसलिए मेरे पास एक विशाल भगवान वर्ग की बजाय बहुत से छोटे वर्ग हैं। लेकिन मुझे कभी और समझौता क्यों नहीं करना चाहिए?

अद्यतन - महान प्रतिक्रिया के लिए धन्यवाद। बहुत से लोगों ने यूनिट परीक्षण का सुझाव दिया है, लेकिन मुझे नहीं लगता कि यह वास्तव में यूआई कोडिंग के प्रकार के लिए उपयुक्त है। उपयोगिता/उपयोगकर्ता स्वीकृति परीक्षण बहुत महत्वपूर्ण लगता है। दोहराने के लिए, मैं असंभव समय सीमा परियोजनाओं के लिए कोडिंग मानकों के बार न्यूनतम के बारे में बात कर रहा हूं।

Answer 1

नहीं OOP, लेकिन एक अभ्यास है कि दोनों में छोटी और लंबी रन सूखी है में मदद करता है, अपने आप को दोहराएँ न करें। कॉपी/पेस्ट विरासत का उपयोग न करें।

Answer 2

परिवर्तनीय सार्वजनिक चर (संरचना-जैसी) के साथ कोई सार्वजनिक वर्ग नहीं है।

इससे पहले कि आप इसे जानते हों, आप अपने सार्वजनिक कोड पर इस सार्वजनिक चर को संदर्भित करते हैं, और जिस दिन आप यह निर्णय लेते हैं कि यह क्षेत्र एक गणना है और इसमें कुछ तर्क होना चाहिए ... refactoring गन्दा हो जाता है।

यदि वह दिन आपकी रिलीज़ की तारीख से पहले है, तो यह गड़बड़ हो जाता है।

Answer 3

ओओपी अभ्यास नहीं, लेकिन सामान्य ज्ञान ;-)।

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

आप समय वापस आने के लिए नहीं था, तो आप हमेशा टिप्पणी तो आप जानते हैं, क्यों समाधान पल में चुना गया था की है।

Answer 4

ईकाई परीक्षण - आप रात में सोने में मदद करता है :-)

Answer 5

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

Answer 6

उपयोग स्रोत नियंत्रण।

कोई फर्क नहीं पड़ता कितना समय (सेकंड ..) स्थापित करने के लिए, यह हमेशा अपने जीवन आसान हो जाएगा ले जाता है! (अभी भी यह ओओपी संबंधित नहीं है)।

Answer 7

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

Answer 8

लोगों (यहां तक ​​कि अपने भविष्य के आत्म हो सकता है) पढ़ सकते हैं और कुछ बिंदु पर कोड को समझना होगा, जो के बारे में सोचो।

Answer 9

ओओपी पर लागू होने वाले कोडिंग के लिए जितना अधिक ओओपी प्रथाओं, उतना ही ओओपी प्रथाओं की तरह नहीं।

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

शायद अनगिनत अन्य "कंधे" हैं, लेकिन अगर मुझे अपना शीर्ष तीन चुनना पड़ा, तो यह सूची होगी। टिप्पणी करने के लिए

जवाब में

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

Answer 10

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

Answer 11

अन्य सभी को वैसे ही जैसे सुझाव दिया है इन सिफारिशों OOP के लिए विशिष्ट नहीं कर रहे हैं:

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

हैक आमतौर पर घुलनशील और सहज ज्ञान युक्त होते हैं, इसलिए कुछ अच्छी टिप्पणी आवश्यक है।

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

सादर,

Docta

Answer 12

[डालने बॉयलरप्लेट नहीं-OOP विशिष्ट चेतावनी यहाँ] चिंताओं, इकाई परीक्षण, और भावना से

• पृथक्करण कि अगर कुछ बहुत जटिल है ऐसा शायद इसलिए है अभी तक काफी संकल्पना नहीं है।

• यूएमएल स्केचिंग: इसने कई बार बर्बाद प्रयासों को स्पष्ट और बचाया है। चित्र महान हैं वे नहीं हैं? :)

• वास्तव में इस बारे में सोच रहा है और यह है। यह सही पहली बार प्राप्त करना इतना महत्वपूर्ण है।

Answer 13

कोई फर्क नहीं पड़ता कि कोई कंपनी कितनी तेज़ी से चाहती है, मैं हमेशा अपनी योग्यता के लिए कोड लिखने की कोशिश करता हूं।

मुझे नहीं लगता कि यह अब और अधिक समय लेता है और आमतौर पर शॉर्ट टर्म में भी बहुत समय बचाता है।

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

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

कोडिंग स्वयं बहुत तेज़ और आसान है, डीबगिंग बकवास किसी ने लिखा था जब वे "दबाव में" थे, हर समय क्या होता है!

Answer 14

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

Answer 15

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

उम्मीद है कि आप इसे पहले से ही करते हैं और मैं गाना बजानेवालों के लिए प्रचार कर रहा हूं।

Answer 16

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

Answer 17

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

1. उपयोग स्रोत नियंत्रण और वास्तव में टिप्पणी के लिए प्रतिबद्ध लिखें:

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

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

मुझे पता है कि इनमें से अधिकतर का उल्लेख पहले से ही किया जा चुका है, लेकिन चूंकि यह एक विषयपरक मामला है, इसलिए मैं अपनी रैंकिंग जोड़ना चाहता था।

Answer 18

कुछ दिन/सप्ताह पहले आपके द्वारा लिखे गए कोड पर वापस जाएं और अपने कोड की समीक्षा करने में 20 मिनट व्यतीत करें। समय बीतने के साथ, आप यह निर्धारित करने में सक्षम होंगे कि भविष्य में रखरखाव के प्रयासों के लिए आपका "ऑफ-द-कफ" कोड व्यवस्थित है या नहीं। जब आप वहां हों, तो अवसरों का पुन: उपयोग और नाम बदलने की तलाश करें।

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

Answer 19

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

इस तरह के वर्ग बनाए रखने के लिए तनावपूर्ण हैं क्योंकि आप कभी भी सुनिश्चित नहीं हैं कि आपका "फिक्स" क्या टूट जाएगा।