प्रोग्रामर की बुरी आदतें

* दूसरे दिन मुझे प्रोग्रामर की बुरी आदतों के बारे में एक दिलचस्प बात पता चली। हो सकता है कि यह कुछ स्पष्ट बातों के लिए हो, लेकिन अक्सर आप उन पर ध्यान नहीं देते हैं।

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

अप्रयुक्त कोड को फेंक दें

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

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

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

आपके पास पुराने कोड को संग्रहीत करने के लिए एक संस्करण नियंत्रण प्रणाली है, इसे हटाने से डरो मत! अभी करो!

सामान्य रूप से सामान्य करना

कई प्रोग्रामर कोड लिखने की कोशिश करते हैं जो आपको खिलाने वाली हर चीज को संसाधित करने में सक्षम होंगे, और हर प्रोजेक्ट में इस दृष्टिकोण को लागू करना शुरू करेंगे। मैंने सार कोड लिखने के बारे में पर्याप्त समझने के लिए कई घटकों, चौखटे, अपने स्वयं के 3 डी गेम इंजन का निर्माण किया है। 90% अनुप्रयोगों के लिए, यह दृष्टिकोण आवश्यक नहीं है।

हम सोचते हैं कि हम भविष्य में अपने कोड का उपयोग करेंगे, इसलिए हम इसे यथासंभव सामान्यीकृत और सारगर्भित बनाने का प्रयास कर रहे हैं। आप अपने घटक विकसित कर रहे हैं? यह सुनिश्चित करने के बारे में कि यह 10 स्थितियों को कैसे संभालती है, भले ही हमें वर्तमान एप्लिकेशन में केवल 2 की आवश्यकता हो?

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

हम OOP पर तय किए गए हैं

मैं नोट करना चाहता हूं: मैं ओओपी का बहुत बड़ा प्रशंसक हूं, मुझे इस दृष्टिकोण से प्यार है , क्योंकि इसे समझना और बनाए रखना आसान है।

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

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

"मैं इसे बेहतर महसूस कर सकता हूं।"

हममें से प्रत्येक के पास एक बहुत बड़ा अहंकार है। हमें लगता है कि हम कुछ भी लिख सकते हैं और शायद किसी और से बेहतर। इसलिए, अपने अहंकार को घर पर छोड़ दो!

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

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

- (void)dealloc { [A release]; [B release]; [A dealloc]; [B dealloc]; A = nil; B = nil; [self release]; [super dealloc]; } 

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

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

और अगर आपको विश्वास नहीं है कि आप बुरा कोड लिख सकते हैं, तो बस कुछ प्रोजेक्ट खोलें जो आपने कुछ साल पहले लिखे थे। मुझे यकीन है कि यह कोड आपको BAD प्रतीत होगा।

हम सहायक उपकरण से डरते हैं (कम कोड लिखें)

लोग बदलाव का विरोध करते हैं। हमारी आदतें हैं जो हम मानते हैं कि वे सही हैं और आराम क्षेत्र से बाहर निकलने और कुछ नया करने के लिए कुछ प्रयासों की आवश्यकता है।

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

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

और अंत में, आप जितना कम कोड लिखेंगे, आपको उतने कम कीड़े पकड़ने होंगे ।

निष्कर्ष

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