कैसे समझा जाए कि डिजाइन के विकल्प अच्छे क्यों हैं? [बन्द है]


26

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

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

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


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

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

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

2
@DanielB मुझे लगता है मैं वास्तव में अतीत में डिजाइन विकल्पों के लिए अपने दूसरे तर्क का उपयोग किया है, और "हालांकि KISS यही नहीं है" प्रतिक्रिया के साथ पूरा किया गया लगता है कि परेशानी है,। सभी डेवलपर यह नहीं पहचानते हैं कि आपके द्वारा बताई गई बातें और भी अच्छी क्यों हैं।
जिमी होफा

1
पढ़ने की सिफारिश की: मैं $ $ {किसी} में {} कुछ कैसे की व्याख्या कैसे करते? - कुटकी समय की शुरुआत के बाद से
rwong

जवाबों:


41

यह सीधे आपके प्रश्न का उत्तर नहीं दे सकता है, लेकिन यह आपको एक दिलचस्प दिशा में ले जा सकता है।

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

आपके CEO के लिए समय-समय पर बाज़ार की कुंजी हो सकती है, आपके प्रबंधक के लिए यह अधिक पूर्वानुमान योग्य कार्यक्रम हो सकता है, आपके प्रोग्रामिंग सहयोगियों के लिए यह तेज़ कोडिंग (या आसान परीक्षण / प्रलेखन / डिबगिंग / जो भी हो) हो सकता है, और आपकी कंपनी के ग्राहकों के लिए हो सकता है हो सकता है ... ?

बिक्री स्वचालित रूप से नहीं होती है - आपको दूसरे व्यक्ति के दृष्टिकोण को समझने के लिए एक ठोस प्रयास करना होगा , और फिर यह पता लगाना होगा कि अपने विचारों को उनके हैप्पी प्लेस ™ में कैसे मैप किया जाए। एक बार जब वे जानते हैं कि वे इस नई चीज से व्यक्तिगत रूप से कैसे लाभान्वित होंगे, तो वे अक्सर पूछते हैं, "इसकी लागत कितनी होगी और हम इसे कितनी जल्दी कर सकते हैं?" एक बार जब आप उन जादूई शब्दों को सुन लेते हैं जिन्हें आप जानते हैं कि आपने अपनी बिक्री को अच्छी तरह से किया है।


5

मेरे पास वास्तव में आपके प्रश्न का हल नहीं है, लेकिन कुछ समय पहले मैंने बिल्कुल उसी दुविधा का सामना किया है और वास्तव में इसी प्रश्न का उत्तर ढूंढ रहा हूं।

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

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

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

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

  1. आप रैंक खींचने की कोशिश कर सकते हैं (मैंने अपने बॉस के पास जाकर रैंक मांगा क्योंकि मैं इन मृत-अंत के तर्कों से बहुत थक गया था)
  2. आप का समर्थन करने के लिए टीम के बहुमत के लिए पैरवी करने की कोशिश कर सकते हैं।
  3. यदि परियोजना खर्च कर सकती है (यानी उत्पादकता में बहुत अधिक नुकसान नहीं), तो आपकी राय में क्या बुरा फैसला है, दूसरे व्यक्ति को तर्क को जीतने दें। दो चीजों में से एक होगा:
    • कुछ मामलों में (उम्मीद से बहुत छोटा हिस्सा), आपका अंतर्ज्ञान गलत होगा और आप कुछ सीखेंगे। आपके लिए अच्छा हैं।
    • ज्यादातर मामलों में (फिर से ... उम्मीद है), आप और जो व्यक्ति "खराब" डिज़ाइन की वकालत कर रहे थे, उन्हें एहसास होगा कि यह क्यों बुरा है; सब के बाद हमेशा 20/20 hindsight है। उम्मीद है, यह उस व्यक्ति को एक सबक होगा जो संभवतः आपको पता है कि आप किस बारे में बात कर रहे हैं और अगली बार वे दो बार उनके मामले पर बहस करेंगे।

4

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

यदि यह विरासत पर रचना की तरह कुछ है, तो आपको शायद यह कहना होगा कि वर्तमान में शायद 90% डेवलपर्स का मानना ​​है कि सबसे अच्छा अभ्यास (एक जंगली अनुमान, इस तथ्य पर आधारित है कि 100% डेवलपर्स लगभग कुछ भी नहीं पर सहमत हैं), और आप सहमत हैं और क्यों में जाने के लिए खुश होंगे।

मैं उतना ही ईमानदार रहने की कोशिश करता हूं जितना कि विवादास्पद हो सकता है, और डेवलपर्स कितने प्रतिशत मुझसे सहमत होंगे।

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

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

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


शायद। मैं शायद उन टीमों के लिए उपयोग किया जाता हूं जहां मेरे पास खरगोश छेद नहीं था। सामान्य ज्ञान का एक साधारण संदर्भ पर्याप्त था। या केवल डिजाइन पर बेचे जाने के लिए आवश्यक सुराग ... आवश्यक भाग पर अच्छा बिंदु; हालांकि इससे पीटर की बिक्री मुश्किल हो जाती है:]
तेलस्टिन

@Telastyn - मुझे लगता है कि "उत्तर के साथ काम करने के लिए बेहतर शिक्षित लोगों को पाने के लिए जगह है" जवाब :)
psr

3

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

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

आपकी कंपनी में दूसरों के नजरिए के आधार पर, परिवर्तन जल्दी से आ सकता है, या हो सकता है कि यह चाचा के माध्यम से तैरने की कोशिश कर रहा हो। कुछ प्रबंधक पूरी तरह से अचल हैं जब तक कि उनके सामने ठोस आंकड़े / सबूत नहीं हैं, जहां अन्य नवीनतम सोच के साथ रखने के लिए काफी उत्सुक हैं।

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


0

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

आपको यह मामला बनाने में सक्षम होना चाहिए कि किसी भी डिजाइन में सुधार या तो होगा

  • कंपनी के लिए पैसा बचाओ
  • कंपनी के लिए पैसा बनाते हैं

उदाहरण के लिए, एकल-जिम्मेदारी सिद्धांत का पालन करने के लिए क्या मामला है? यदि प्रत्येक वर्ग की एक ही ज़िम्मेदारी है, तो बगों का पता लगाना और उन्हें ठीक करना बहुत आसान हो जाता है, और इससे सुविधाओं और सुधारों को जोड़ना आसान हो जाता है। कम समय बग को ठीक करने और सुविधाओं को जोड़ने = पैसे की बचत।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.