कौन सी विशिष्ट प्रथाओं को "सॉफ्टवेयर इंजीनियरिंग" के बजाय "सॉफ्टवेयर शिल्प कौशल" कहा जा सकता है? [बन्द है]

Question

हालांकि नहीं एक नए विचार वहाँ पिछले कुछ वर्षों (विशेष रूप से अक्सर सिफारिश की पुस्तक स्वच्छ कोड का पूरा शीर्षक है से अधिक सॉफ्टवेयर शिल्प कौशल में रुचि में एक बड़ी वृद्धि की गई है लगता है : चंचल की एक पुस्तिका स्वच्छ कोड सॉफ्टवेयर शिल्प कौशल )।

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

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

एक सॉफ्टवेयर शिल्पकार ऐसा क्या कर सकता है जो एक सॉफ्टवेयर इंजीनियर (संभवतः एक बुरा) कर सकता है?

Comments

सादृश्य फिट नहीं लगता है। सॉफ्टवेयर शिल्प कौशल और सॉफ्टवेयर इंजीनियरिंग दोनों का एक ही लक्ष्य (और निहित स्वार्थ) है जो सॉफ्टवेयर की दीर्घकालिक उपयोगिता में सुधार करता है।

— rwong

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

— बेन ब्रोका

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

— gbjbaanb

यह सिर्फ अपने आप को देने के लिए एक बहुत ही सुंदर शीर्षक की तरह लगता है।

— michaelsnowden

Answer 1

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

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

थोड़ा सा जोश पसीने को तोड़े बिना इन सब को ढक लेता है।

Comments

मुझे लगता है कि अंतिम एक विशेष रूप से महत्वपूर्ण है

— लोविस

Answer 2

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

जैसा कि मेरे एक प्रोफेसर ने एक बार कहा था (पैराफ़्रास्ड): "एक सॉफ़्टवेयर इंजीनियर के रूप में, सॉफ़्टवेयर वितरित करना केवल आपका काम नहीं है। सॉफ़्टवेयर को वितरित करना आपका काम है जो आपके ग्राहकों को खुश करता है।"

एक सॉफ्टवेयर शिल्पकार ऐसा क्या कर सकता है जो एक सॉफ्टवेयर इंजीनियर (संभवतः एक बुरा) कर सकता है?

कुछ नहीं - एक इंजीनियर एक शिल्पकार है ... लेकिन अधिक। शिल्प कौशल पर इंजीनियरिंग का निर्माण होता है।

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

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

Comments

और आपके पास निश्चित रूप से अपने अनुभवों का समर्थन करने के लिए एक शिक्षा है - खुशी है कि आपने "औपचारिक" नहीं कहा।

— treecoder

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

— थॉमस ओवेन्स

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

— थॉमस ओवेन्स

मैं असहमत हूं, एक इंजीनियर जरूरी नहीं कि एक शिल्पकार हो।

— निकोल

@ संदर्भ द्वारा परिभाषा, इंजीनियरिंग एक शिल्प है। शिल्प की परिभाषा: "एक कला, व्यापार, या व्यवसाय विशेष कौशल, विशेष रूप से मैनुअल कौशल की आवश्यकता होती है"। इंजीनियरिंग एक व्यवसाय है जिसमें विशेष कौशल की आवश्यकता होती है, इसलिए यह एक शिल्प है। हालांकि, यह वैज्ञानिक सिद्धांत (अन्य चीजों के बीच) का अनुप्रयोग भी है, जो इसे और अधिक बनाते हैं।

— थॉमस ओवेन्स

Answer 3

सॉफ्टवेयर शिल्प कौशल आंदोलन "पारंपरिक" सॉफ्टवेयर इंजीनियरिंग की विफलताओं और असंतोषजनक परिणामों की प्रतिक्रिया में शुरू किया गया था (कुछ डेवलपर्स की लापरवाही के साथ) आज हमारे पेशे के प्रति हितधारकों और उपयोगकर्ताओं से अविश्वास पैदा होता है।

इसका लक्ष्य दो गुना है: प्रोग्रामर में विश्वास बहाल करना, और ऐसा करने के लिए, सॉफ्टवेयर की गुणवत्ता और डेवलपर कौशल का बार उठाना।

स्व शिल्प कौशल तकनीकी प्रथाओं को बढ़ावा देता है जैसे:

• ठोस डिजाइन सिद्धांतों
• डिजाइन पैटर्न्स
• टीडीडी ("डबल एंट्री अकाउंटिंग" रूपक)
• ...

और टीम / संगठनात्मक प्रथाओं:

• जोड़ा प्रोग्राम तैयार करना
• सलाह
• कोड कटास
• Dojos / कोड पीछे हट जाता है
• ...

तो मैं कहूंगा कि 2 के बीच का अंतर स्पष्ट है: सॉफ्टवेयर शिल्प कौशल 40+ वर्षों के अस्तित्व में समस्याओं के एक बड़े हिस्से को संबोधित करने की कोशिश करता है, जो आज हमारे अनुशासन को असफल बना देता है और असफलताओं के इतिहास से अपंग हो जाता है।

Comments

मैं असहमत हूं - सॉफ्टवेयर इंजीनियरिंग विफल होने का कारण यह है कि इसमें इंजीनियर नहीं थे, केवल कारीगर इंजीनियर होने का नाटक कर रहे थे। नासा ने कारीगरों का उपयोग करके चंद्रमा पर अंतरिक्ष यान नहीं भेजा!

— gbjbaanb

@gbjbaanb मुझे लगता है कि यह बिल्कुल विपरीत है - हमारे पास इंजीनियर थे, और इसीलिए उन्होंने एक पारंपरिक इंजीनियरिंग मॉडल और अन्य उद्योगों के सॉफ्टवेयर पर मानसिकता से निपटने की कोशिश की, लेकिन यह काम नहीं किया।

— गुरिल्ला 31

स्पेसक्राफ्ट अमूर्त सामान से नहीं बने होते हैं जिन्हें फिर से तैयार किया जा सकता है, फिर से इंजीनियर और फिर से तैयार किया जा सकता है। वे जो कानून मानते हैं, वे काफी हद तक सॉफ्टवेयर प्रोग्राम से भिन्न होते हैं।

— गुरिल्ला ३

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

— gbjbaanb

कृपया सॉफ्टवेयर के संदर्भ में "इंजीनियर की मानसिकता" को परिभाषित करें।

— गुरिल्ला 31

Answer 4

Http://manifesto.softwarecraftsmanship.org/ द्वारा जाने पर मैं निम्नलिखित जानकारी प्राप्त करूंगा।

एक शिल्पकार "इंजीनियर" की पारंपरिक धारणाओं से अलग है क्योंकि

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

Comments

ईमानदारी से, उन सभी बुलेट पॉइंट्स में एक अच्छे इंजीनियर का वर्णन है। खास तौर पर 1, 2, और 4

— थॉमस ओवेन्स

@ThomasOwens और बुरे इंजीनियर के बारे में क्या? क्या वह एक शिल्पकार भी है? या अच्छा बनाम बुरा शिल्पकार?

— युफोरिक

@ उत्साही मुझे नहीं लगता कि आप एक अच्छे कारीगर होने के बिना एक अच्छे इंजीनियर हो सकते हैं। यह एक मंचन जैसा है। "अच्छा इंजीनियर" हासिल करने से पहले आपको "अच्छे शिल्पकार" प्राप्त करने होंगे। हालांकि, आप एक अच्छे कारीगर हो सकते हैं और एक अच्छे इंजीनियर नहीं हो सकते।

— थॉमस ओवेन्स

Answer 5

अंकल बॉब ने किसी तरह यह संकेत दिया कि प्रोग्रामिंग एक बहुत ही युवा अनुशासन है जिसमें अभी तक कानूनों या नियमों का एक स्थिर निकाय नहीं है जिसे शासन द्वारा मान्यता प्राप्त है (या यह फ्रेडरिक ब्रूक्स था?)। मैं यहाँ एक क्रियात्मक उद्धरण नहीं बना रहा हूँ।

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

एक प्रोग्रामर एक छोटी गाड़ी कार्यक्रम बनाता है या अक्षमता के कारण एक परियोजना को विफल कर देता है और वह प्रोग्रामिंग जारी रखने के लिए स्वतंत्र है।

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

Answer 6

पैटर्न के लिए Refactoring।

यही है, कुछ ऐसी चीज़ों का निर्माण करें जो 90% सॉफ़्टवेयर आवश्यकताओं को पूरा करती हैं, फिर पूरे प्रोजेक्ट को कुछ साफ, सुरुचिपूर्ण डिज़ाइन में रिफैक्ट करें।

आम तौर पर, सॉफ़्टवेयर इंजीनियरिंग आपको ऐसा करने से रोकती है, क्योंकि 90% आवश्यकताओं को संतुष्ट करने का मतलब है कि सॉफ्टवेयर का ग्राहक के लिए पर्याप्त व्यावसायिक मूल्य है कि इसे किसी भी महत्वपूर्ण तरीके से संशोधित नहीं किया जाना चाहिए (उच्च प्राथमिकता वाले बगफिक्स को छोड़कर)।

सॉफ़्टवेयर इंजीनियरिंग आपको इस बिंदु पर सॉफ़्टवेयर को स्थिर करने की सलाह देगा ।

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

स्पाइक समाधान।

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

जो भी कारण हो, डिप्रेसेशन ।

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

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

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

Answer 7

मैं कहूंगा कि 100% कोड को कवर करने वाली इकाई परीक्षण एक अच्छा होगा। जैसा कि अतिरिक्त सामान को छीनने की अनुमति देता है।

मैं कभी-कभी सॉफ्टवेयर विकास की तुलना मूर्तिकला से करता हूं। यह वह नहीं है जो आप जोड़ते हैं, यह वह है जो आप दूर ले जाते हैं।

जाहिर है आप इसे बहुत दूर ले जा सकते हैं। कोई नहीं एक छोटा चमकदार कंकड़ कहने के लिए एक अच्छा मूर्तिकला है: एस

Comments

हम यहाँ कितनी चमकदार बात कर रहे हैं? :-)

— क्रिस

ज्यादातर समय मैं इससे सहमत हूं - लेकिन मुझे यकीन नहीं है कि सख्त 100% हमेशा सार्थक होता है - जैसे गेटर्स / सेटर जहां उनके पास कोई तर्क नहीं है। यूनिट कोड के बिना जनरेट किया गया कोड आमतौर पर बेहतर होता है (हालाँकि एकीकरण परीक्षण उचित हो सकता है)

— फिनक

@FNNk - मैं सहमत हूँ। मैंने हाल ही में डॉटकॉवर का उपयोग किया है और यह कहता है कि यदि दूसरे परीक्षण में इसका उपयोग किया जाता है तो एक गेटटर / सेटर कवर किया जाता है। इसलिए, मुझे वास्तव में प्रत्येक गेटर और सेटर के लिए एक परीक्षण विधि का मतलब नहीं था

— एंटनी स्कॉट