क्या सॉफ्टवेयर उद्योग में खराब प्रोग्रामिंग प्रथाएं विशिष्ट हैं? [बन्द है]

Question

मैंने अभी एक महीने पहले एक सॉफ्टवेयर डेवलपर के रूप में अपनी पहली नौकरी शुरू की थी। मैंने OOP, SOLID , DRY , YAGNI, डिज़ाइन पैटर्न, SRP , आदि के बारे में जो कुछ भी सीखा है , उसे खिड़की से बाहर फेंक दिया जा सकता है।

वे C # .NET वेबफॉर्म का उपयोग करते हैं और कोड के भीतर लगभग सब कुछ बहुत ही बाहरी कक्षाओं के साथ करते हैं, निश्चित रूप से वस्तुओं को नहीं कहा जाता है। वे कस्टम नियंत्रण का उपयोग करते हैं और उनका पुन: उपयोग करते हैं। एंटिटी फ्रेमवर्क द्वारा उपयोग की जाने वाली एकमात्र वस्तुओं के बारे में है । वे प्रत्येक ग्राहक के लिए कोड Behinds का पुन: उपयोग करते हैं। उनके पास ऐसी विधियाँ हैं जो सभी प्रकार के सामानों को करने वाली 400 रेखाएँ हैं नए क्लाइंट के लिए वे aspx और aspx.cs लेते हैं और क्लाइंट कोड को निकालते हैं और नए क्लाइंट-विशिष्ट कोड को जोड़ना शुरू करते हैं।

उनका पहला बहाना यह होगा कि अतिरिक्त रखरखाव और अधिक कोड अधिक रखरखाव है। यह खुद सहित तीन डेवलपर्स की एक छोटी सी दुकान है। एक डेवलपर के पास 30 से अधिक वर्षों का अनुभव है और दूसरे के पास 20+ वर्ष का अनुभव है। एक गेम डेवलपर हुआ करता था और दूसरा हमेशा C और C ++ में काम करता था।

सॉफ्टवेयर उद्योग के भीतर यह कितना सामान्य है? मैं यह कैसे सुनिश्चित कर सकता हूं कि मैं ओओपी और संबंधित सिद्धांतों के शीर्ष पर रहूं? मैं अपने खाली समय में अभ्यास करता हूं, और मुझे ऐसा लगता है कि मुझे वास्तव में OOP में बेहतर होने के लिए अधिक अनुभवी डेवलपर के तहत काम करने की आवश्यकता है।

Comments

मैंने चैट में शीर्षक पर एक चर्चा खोली है: chat.stackexchange.com/transcript/message/40126879#40126879 कृपया मुझसे जुड़ें।

— dcorking

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— वर्ल्ड इंजीनियर

Answer 1

1. आपने अपने प्रश्न में जिन सिद्धांतों का हवाला दिया है, वे सिर्फ ... सिद्धांत हैं। वे जनादेश, कानून या आदेश नहीं हैं।
2. जबकि जो लोग इन सिद्धांतों के साथ आए हैं वे बहुत चालाक हैं, वे पूर्ण अधिकारी नहीं हैं। वे सिर्फ अपनी अंतर्दृष्टि और मार्गदर्शन प्रदान करने वाले लोग हैं ।
3. प्रोग्राम करने का कोई "सही" तरीका नहीं है। यह इस तथ्य से जाहिर होता है कि "स्वीकृत" तरीके से हम इसे बदल चुके हैं, और समय के साथ मौलिक रूप से बदलते रहते हैं।
4. एक उत्पाद को शिपिंग करना अक्सर "सही" तरीके से करने पर पूर्वता ले सकता है। यह एक ऐसी प्रचलित प्रथा है जिसका एक नाम है: तकनीकी ऋण।

5. कुछ सॉफ्टवेयर आर्किटेक्चर आम उपयोग में नहीं हैं। सर्वोत्तम प्रथाएं मॉड्यूल के शिथिल-युग्मित संग्रह की ओर बड़े, अखंड अनुप्रयोगों से दूर विकसित हो रही हैं ।

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

तो आप एक "सही" पथ, एक राजसी मार्ग का पालन कैसे करते हैं, ताकि आप जंगल से निकल सकें?

1. शुद्धता के बजाय , उपयुक्तता का अध्ययन करें । सॉफ्टवेयर विकास में कुछ भी करने का "सही" तरीका वह है जो सबसे प्रभावी रूप से आपकी विशिष्ट आवश्यकताओं को पूरा करता है।
2. ट्रेडऑफ का अध्ययन करें। सॉफ्टवेयर विकास में सब कुछ एक व्यापार है। क्या आप अधिक गति या कम मेमोरी उपयोग चाहते हैं? क्या आप कुछ चिकित्सकों के साथ एक बहुत ही अभिव्यंजक प्रोग्रामिंग भाषा चाहते हैं, या कम अभिव्यंजक भाषा जिसे कई डेवलपर्स जानते हैं?

3. अध्ययन कालहीनता। कुछ सिद्धांत समय की कसौटी पर खरे उतरे हैं और हमेशा प्रासंगिक रहेंगे। टाइप सिस्टम सार्वभौमिक हैं। प्रथम श्रेणी के कार्य सार्वभौमिक हैं। डेटा संरचनाएँ सार्वभौमिक हैं।

4. व्यावहारिकता सीखें। व्यावहारिक होना जरूरी है। गणितीय शुद्धता, क्रिस्टल-कैथेड्रल आर्किटेक्चर और हाथीदांत-टॉवर सिद्धांत बेकार हैं यदि आप जहाज नहीं कर सकते हैं।

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

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— यानिस

मैं उन अंतर्दृष्टि को व्यवस्थित रूप से प्राप्त कर सकता हूं जहां मेरे पास कोई मार्गदर्शन नहीं है?

— ओकर

बस समझ में नहीं आता कि सबसे अच्छा अभ्यास क्या है, लेकिन सबसे अच्छा अभ्यास के मूर्त लाभ क्या हैं। आपको उचित व्यवहार को उपयुक्तता से जोड़ने की अनुमति देता है और सबसे अच्छा प्रभाव डालने के लिए अभ्यास को लागू करने में प्रभावशीलता सुनिश्चित करता है। यदि आप केवल यह कहते हैं कि एक सर्वोत्तम अभ्यास "चिंताओं के पृथक्करण" को पूरा करता है, तो आप शायद यह सुनिश्चित नहीं कर सकते कि आप अभ्यास के लाभों को पुनः प्राप्त करने के लिए सही तरीके से टुकड़ा कर रहे हैं।

— एरोनल्स

Answer 2

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

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

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

तो हाँ: आप विश्वविद्यालय में जो सीखते हैं वह वास्तव में इस क्षेत्र में बहुत आम नहीं है।

---

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

Comments

@nocomprende: नो एंटिओन्डो ... क्या आपका मतलब यह है कि आम अधिक सामान्य है, और असाधारण है, दुर्भाग्य से, असाधारण? या कि आम असाधारण रूप से अच्छा नहीं है? सही है।

— पीटर ए। श्नाइडर

"आप विश्वविद्यालय में जो सीखते हैं, वह वास्तव में बहुत सारे क्षेत्र में सामान्य नहीं है" - यह महत्वपूर्ण लगता है ...

— ब्रायन नोब्लुक

मेरा मतलब सिर्फ यह था कि सॉफ्टवेयर क्षेत्र में मानव क्षमता की पूरी श्रृंखला, विशेषज्ञता की पूरी श्रृंखला, कंपनियों के पास तैयारियों की पूरी श्रृंखला, प्रकार की समस्याओं की पूरी श्रृंखला और बाकी दुनिया की तरह लोग हैं। सॉफ्टवेयर अन्य क्षेत्रों की तुलना में इन तरीकों से अलग नहीं है। समस्या किसी भी एसई साइट में रखी जा सकती थी।

"सुरक्षा प्रासंगिक सॉफ़्टवेयर अच्छी तरह से वेट किए गए टूल पर निर्भर करता है (हम वर्तमान में 1990 के दशक से एक मान्य C ++ कंपाइलर का उपयोग कर रहे हैं)" मेरे लिए बहुत अच्छा लगता है!

— होवरकॉच

@ पीटरए.साइडराइडर यह एक मूर्खतापूर्ण मजाक था कि यह वास्तव में आपके टूल को कैसे काट रहा है। ;)

— होवरकच

Answer 3

वे C # .Net वेबफ़ॉर्म का उपयोग करते हैं और कोड के भीतर लगभग सब कुछ बहुत कम बाहरी कक्षाओं के साथ करते हैं

वहीं तुम्हारा स्पष्टीकरण है। यदि आप जागरूक नहीं हैं, तो आउट-ऑफ-द-बॉक्स वेब फॉर्म कोड OOP, SOLID, DRY, YAGNI, डिज़ाइन पैटर्न, SRP , आदि के ध्रुवीय विपरीत हैं। कुछ साल पहले Microsoft के आधिकारिक उदाहरण भी। आज आपको पंगु बना देगा।

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

और यह .NET वेब फॉर्म स्पेस, btw में काफी आम है।

Comments

टेक स्टैक को संबोधित करते हुए अच्छा लगा

— जसनोरीओर्डन

कौन चेक-इन या चेक बॉक्स को अनचेक करता है, यह पता लगाने के लिए कि क्या होता है, यह पता लगाने के लिए 20 वर्गों को एक-दूसरे के साथ बुलाते हुए देखना चाहिए। केवल पागल लोग, या जो लोग सोचते हैं कि कॉलेज के प्रोफेसर भगवान हैं।

— developerwjk

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

— BgrWorker

हाँ ये सच है। आपका दृश्य कितने एमबी था? अजीब तरह से, मुझे लगता है कि यूआई में व्यावसायिक तर्क को प्रोत्साहित करने के लिए सर्वर-साइड नियंत्रणों का उपयोग किया जाता है। फिर भी प्रोग्रामर की बहुत गलती थी, जो कि asp.net कार्गो-पंथ प्रोग्रामिंग बकवास के साथ आसानी से जा रहा था। इस प्रकार: इतनी सारी घटनाएँ जो व्यावसायिक वस्तुओं को सही स्थिति में नहीं ला सकती हैं। बस। UI युग्मन के कारण ऑब्जेक्ट एक दूसरे को कॉल नहीं कर सकते हैं। तब: ओह, देखो मो! हम "डिस्कनेक्ट" काम कर सकते हैं! nyuck, nyuck, nyuck वास्तविक डेटा वॉल्यूम ने आपके ऐप को एक डेटाबेस इंजन होने का दिखावा करने वाले asp.net वर्गों के रूप में पीसने वाले पड़ाव में लाया। लेकिन हम बाहर पहनने से कनेक्शन बचा रहे थे!

— राडारोब

यह सब शेख़ी सच है ... दिल से सच्चा सच। मैंने देखा है कि इस पोस्ट में WebForms अनुप्रयोगों के बारे में बहुत कुछ बताया गया है, जिससे मुझे ऐसा लगता है कि ये अनुप्रयोग कुछ PHP स्क्रिप्ट्स की तुलना में थोड़ा बेहतर हैं, जो एक हाई स्कूली द्वारा एनर्जी ड्रिंक पर एक साथ फेंकी गई हैं - और इसे एंटरप्राइज़ सॉफ़्टवेयर माना जाता था!

— ग्रेग बरगार्ड

Answer 4

सॉफ्टवेयर उद्योग के भीतर यह कितना सामान्य है?

बहुत ही आम। प्लम्बर के रूप में समान समानता के बारे में आपकी प्लंबिंग को नष्ट करना, कबाड़ पहुंचाने वाला कारपेंटर या खराब फिटिंग वाला सूट बनाना। यानी, यह सब इंसान है।

ऐसा होने का एक अच्छा कारण है: वे लोग जो वास्तव में प्रशिक्षित नहीं हैं (या उत्साही नहीं हैं) दबाव में कुछ लागू करने के लिए।

यह उन लोगों की समस्या नहीं है, मुख्य रूप से, लेकिन आमतौर पर उस कंपनी में सॉफ्टवेयर विकास के आसपास की संरचनाएं। उदाहरण के लिए, एक कंपनी के पास इंटर्नों का एक समूह हो सकता है जो अपने आंतरिक सॉफ़्टवेयर को विकसित करता है; यहां तक ​​कि अगर वे इंटर्न उज्ज्वल और जानकार हैं, तो वे केवल कुछ हफ्तों या महीनों के लिए वहां रहेंगे, और स्वामित्व अक्सर स्विच करेंगे।

या कुछ व्यक्ति जो डोमेन में महान हैं, लेकिन एक प्रोग्रामर नहीं, कुछ VBA आदि एप्लिकेशन को एक साथ हैक कर सकते हैं क्योंकि यह शुरुआत में काफी आसान लगता है।

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

मैं यह कैसे सुनिश्चित कर सकता हूं कि मैं ओओपी और संबंधित सिद्धांतों के शीर्ष पर रहूं? मैं अपने खाली समय में अभ्यास करता हूं और मुझे ऐसा लगता है कि मुझे वास्तव में OOP में बेहतर होने के लिए अधिक अनुभवी डेवलपर के तहत काम करने की आवश्यकता है।

दो संभावित उत्तर हैं:

• या तो: अपने बॉस के साथ इस पर चर्चा करें और सुनिश्चित करें कि आप स्वच्छ परियोजनाओं में शामिल हों। यदि संभव न हो, तो नया बॉस खोजें।
• या: इसके लिए खुद जिम्मेदारी लें। इसका मतलब है कि यह अपने दम पर कर रहा है - अपने खाली समय में, या यदि आप कंपनी में कर सकते हैं, लेकिन खुद से प्रेरित (संभावनाहीन)।

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

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

यही कारण है कि नेतृत्व डेवलपर जो आप प्रशिक्षण है है काफी संभावना बिल्कुल इस तरह से है कि सामान सीखा ...

Comments

तो, केवल अच्छी तरह से योग्य, पूरी तरह से प्रशिक्षित और उत्साही लोगों को किराए पर लें ... अच्छी तरह से, कुछ भी। हम ऐसा क्यों नहीं कर रहे हैं? यह सवाल है: कैसे अच्छी तरह से योग्य नहीं, अच्छी तरह से प्रशिक्षित और अठारह लोग नहीं रहना चाहिए? चार्ल्स डिकेंस ने उस एक के उत्तर की सूचना दी: यदि बहुत अच्छा नहीं है।

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

— AnoE

मैं बस से कर्ट Vonnegut के सवाल के बारे में सोच रखने के भगवान तुम्हें आशीर्वाद मिस्टर गुलाब जल : "नरक में क्या लोग हैं के लिए ?"

@nocomprende, अगर मैं एक "गैर-प्रशिक्षित व्यक्ति" के बारे में बात करता हूं तो मैं यह नहीं कह रहा हूं कि लोग बेवकूफ हैं, मैं कह रहा हूं कि किसी भी कारण से एक व्यक्ति ने एक काम किया जो उस नौकरी के लिए अच्छी तरह से प्रशिक्षित नहीं था। गलती उसके प्रबंधक के साथ हो सकती है ताकि उसे गलत काम दिया जा सके; या परिस्थिति के साथ (यानी एक सह-कार्यकर्ता बीमार हो रहा है), या जो भी असंख्य कारण आप कल्पना कर सकते हैं। यह सुझाव देने के साथ कुछ भी नहीं है कि हमें केवल महान लोगों को काम पर रखना चाहिए। अगर मुझे अपने घर में प्लंबिंग को ठीक करना है, तो आपको पूरा यकीन हो सकता है कि मैं एक गड़बड़ कर दूंगा, हालाँकि मैं जो कुछ भी कर सकता हूँ, मैं उससे महान हूँ।

— एओई

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

Answer 5

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

इन अनुभवी लोगों की असफलताओं को कभी ठीक नहीं किया जाता है: इसके बजाय, उनका एकमात्र काम काम करना है। नतीजतन, अधिक से अधिक गलत व्यवहार कोड में जमा होते हैं।

आखिरकार कुछ स्मार्ट गधा कहते हैं कि सबसे अच्छा "समाधान" एक उभरती हुई तकनीक में बदलना है जो एक नया अनुप्रयोग बनाते हुए क्लीनर और अधिक मुख्य कोड उत्पन्न करेगा। मानो तकनीक खुद ही ऐसा कर सकती है।

फिर से, अनुभवहीन प्रोग्रामर को उस नई तकनीक में काम करने के लिए रखा जाता है, कोई भी कोड की समीक्षा नहीं करता है और सर्कल फिर से बंद हो जाता है .... और हमेशा के लिए ....

Comments

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

— Jan Hudec

तथ्य यह भी है कि सॉफ्टवेयर उद्योग अभी भी बढ़ रहा है, इसलिए अपेक्षाकृत कम अनुभव वाले लोग अधिक हैं। और यह कि कई कंपनियों के पास कोई अनुभवी लोग नहीं हैं, क्योंकि वे नए और बहुत सस्ते हैं एक अनुभवी को किराए पर लेने के लिए, कॉलेज से ताज़े ग्रीनहॉर्न का एक गुच्छा सोचेंगे-वे नहीं करेंगे।

— Jan Hudec

@ जैनधुके मैं दूनो यार, मुझे ऐसा लगता है कि मुझे कॉलेज में एक युवा के बजाय 20+ साल के अनुभव वाले लोगों के मूल पोस्टर के बारे में बात करने का अनुभव है

— मिकी माउस

@ मायकीहाउस, सच है, ऐसे कई लोग हैं, जिनके पास 20 साल का अनुभव नहीं है, बल्कि 20 साल का 1 साल का अनुभव है। और वे वास्तव में बड़ी मुसीबत बन गए।

— जन हुदेक

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

— राडारबॉब

Answer 6

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

आप कभी-कभी ऐसे प्रोग्रामर देखेंगे जिन्हें शार्टकट्स और एंटी-पैटर्न्स का उपयोग करके समय के लिए दबाया जाता है, जिन्हें गुणवत्ता समाधानों की तुलना में कम बॉयलर-प्लेट की आवश्यकता होती है।

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

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

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

Comments

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

— user369450

मैं आपके पहले पैराग्राफ से असहमत हूं। अपने कोड का दस्तावेजीकरण (उदाहरण के लिए टिप्पणियों के साथ) कम से कम उतना ही महत्वपूर्ण है जितना कि जब आप कॉलेज में थे। अंतर यह है कि कोई भी पेशेवर टिप्पणी नहीं करेगा कि एक लाइन क्या कर रही है - वे WHY को क्यों दस्तावेज करेंगे। क्या हो रहा है स्रोत कोड से पढ़ा जा सकता है। अक्सर कई मिनटों से लेकर घंटों की सोच का नतीजा क्यों होता है।

— आराहो

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

— BgrWorker

वह फिर कैसे जाता है? कोड एक बार लिखा जाता है और कई बार पढ़ा जाता है। टिप्पणी लिखें और आप लंबे समय में समय की बचत करेंगे । @BgrWorker व्यक्ति पर निर्भर करता है, मुझे लगता है। मैं नियमित रूप से एल्गोरिदम लिखता हूं और मुझे लगता है कि वे टिप्पणी के लायक हैं (सबसे हाल ही में एक प्रतीकात्मक गणित पार्सर होने के नाते ... निश्चित रूप से टिप्पणियों की जरूरत है)

— 7:27 पर person27

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

— bikeman868

Answer 7

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

Comments

विफलता आमतौर पर एक विकल्प भी नहीं है।

Answer 8

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

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

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

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