कामोत्तेजक प्रोग्रामिंग

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

• रिक्त स्थान के खिलाफ टैब। कितना होगा दांव?
• ब्रेसिज़ स्टाइल
• कैमलकेस, मिक्सकैस, अंडरस्कोर
• परिवर्तनीय नामकरण सम्मेलनों, विशेष रूप से हंगेरियन संकेतन
• फ़ंक्शंस 50 या 100 लाइनों से अधिक नहीं हो सकते हैं, या फ़ंक्शन एक से अधिक स्क्रीन नहीं हो सकते हैं
• कभी भी GOTO, eval, ऑपरेटर ओवरलोडिंग, सिंगललेट्स, और किसी अन्य भाषा की विशेषताओं का उपयोग न करें जिसे बुराई माना जाता है।
• फ़ंक्शंस में केवल एक निकास बिंदु होता है।
• कोई वैश्विक चर नहीं
• ओओपी केवल, कार्यात्मक प्रोग्रामिंग केवल
• डिजाइन पैटर्न
• TDD (परीक्षण के माध्यम से विकास)
• गैन्ट चार्ट, एजाइल, स्क्रैम, एक्सट्रीम प्रोग्रामिंग, यूजर स्टोरीज़
• SQL संग्रहीत कार्यविधियों का उपयोग न करें या SQL संग्रहीत कार्यविधियों पर सभी तर्क लागू करें
• SQL बनाम NoSQL
• PHP टैग लिखने के लिए कभी भी संक्षिप्त रूप का उपयोग न करें
• सभी वेब इंटरफेस रेस्टफुल होना चाहिए
• HTML कोड को W3C सत्यापन पास करना होगा
• सख्त एक्सएचटीएमएल

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

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

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

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

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