एक कदम पीछे कैसे ले जाएं और ताजा आंखों से कोड को देखें? [बन्द है]

Question

मैंने पिछले वर्ष एक अमीर-ग्राहक एप्लिकेशन (35,000+ एलओसी, जो इसके लायक है) विकसित करने वाली टीम के रूप में बिताया है। यह वर्तमान में स्थिर और उत्पादन में है। हालांकि, मुझे पता है कि परियोजना की शुरुआत में मेरे कौशल कठोर थे, इसलिए संदेह के बिना कोड में प्रमुख मुद्दे हैं। इस बिंदु पर, अधिकांश मुद्दे वास्तुकला, संरचना और अंतःक्रियाओं में हैं - आसान समस्याएं, यहां तक ​​कि वास्तुकला / डिजाइन की समस्याएं, पहले से ही मातम कर चुकी हैं।

दुर्भाग्य से, मैंने इस परियोजना के साथ इतना समय बिताया है कि मैं इसके बाहर एक कठिन समय सोच रहा हूं - डिजाइन में खामियों को गहराई से दफन या निहित देखने के लिए इसे एक नए दृष्टिकोण से देख रहा हूं।

मैं अपने सिर के बाहर और अपने कोड के बाहर कैसे कदम रख सकता हूं ताकि मैं एक नया रूप पा सकूं और इसे बेहतर बना सकूं?

Comments

भविष्य में, कृपया क्रॉसपोस्ट न करें । यदि आपने गलत StackExchange साइट पर पोस्ट करके कोई गलती की है, तो माइग्रेशन के लिए फ़्लैग करें और बताएं कि आपको यह कहां लगता है और एक मॉडरेटर आपके लिए प्रश्न को माइग्रेट करेगा।

— maple_shaft

ठीक। कर दूँगा! :) एक युगल लोगों ने बंद किया था, हिलना नहीं था, इसलिए मैंने पूरा प्रश्न हटा दिया और इसे यहां लाया।

— बेनकॉल

हाँ! - लोगों ने 'क्लोज' बटन पर क्लिक किया था, 'फ्लैग' बटन पर नहीं (कम से कम, मुझे लगता है कि ऐसा ही हुआ)। अब से मैं इसे स्वयं फहराऊंगा और हालांकि प्रवास की प्रतीक्षा करूंगा।

— BenCole

youtube.com/watch?v=AtWjYTWGu6I

— थॉमस Eding

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

— डंक

Answer 1

इस तक पहुंचने के तरीके:

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

यदि आपके पास विशिष्ट उदाहरण हैं जिन्हें आप संबोधित करना चाहते हैं, तो शायद उन्हें यहां पोस्ट करें।

Comments

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

— GlenPeterson

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

— जिमी हॉफ

सम्मेलन में जाओ यहाँ, IMO जोड़ा जाना चाहिए। नीचे मेरा विस्तृत जवाब दें।

— मैके

विभिन्न प्रोजेक्ट के लिए +1। आप दिन-प्रतिदिन क्या करते हैं, इसके दायरे से बाहर पूरी तरह से कोशिश करें। आपको कुछ समानताएँ मिलेंगी और साथ ही एक ताज़ा वास्तुशिल्प चुनौती भी मिलेगी।

— 1

Answer 2

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

Answer 3

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

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

उपयोगकर्ता शिकायत करना शुरू कर देंगे। बस जब आपको लगता है कि सब कुछ महान है ...

Answer 4

एक छोटी याददाश्त मदद करती है। मुझे "बेवकूफ" के बारे में शिकायत करने के लिए जाना जाता है जो एक हफ्ते पहले कुछ बदल गया था, केवल स्रोत नियंत्रण से खोजने के लिए यह मैं था।

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

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

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

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

Comments

"बेवकूफ" टिप्पणी की ईमानदारी के लिए +10। :)

— जेनिफर एस

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

— डैनियल प्राइडेन

Answer 5

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

Comments

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

— लीफ कार्लसन

Answer 6

मैं इस स्थिति को अच्छी तरह से जानता हूं। जब मैं इस तरह से अटक जाता हूं तो मैं इस परियोजना पर अलग-अलग दृष्टिकोण अपनाने की कोशिश करता हूं।

1.) उपयोगकर्ता / ग्राहक के दृष्टिकोण - प्रतिक्रिया का उपयोग करें

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

2.) अपने कोड का एक कार्यात्मक विश्लेषण करें और इसे कल्पना करें

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

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

3.) गुणवत्ता आश्वासन के लिए आम दृष्टिकोण का उपयोग करें

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

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

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

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

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

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

Answer 7

छोटे सामान पसीना मत करो।

हर कोई बेहतर कोड कर सकता था। हम चीजें तेजी से करते हैं और फिर कुछ हफ़्ते बाद महसूस करते हैं कि यह अधिक कुशलता से किया जा सकता था। मुद्दा यह है कि आपके कोड का 90% संभवत: अच्छा है।

अपने बग लॉग पर देखें और उन दिनचर्या को खोजें जो समस्या पैदा कर सकती हैं। जैसा कि आपको बग मिलते हैं, आप कोड की समीक्षा भी कर सकते हैं और सोच सकते हैं कि कोड को और अधिक कुशल क्या बनाया जा सकता है। अधिकांश समय, आपको एहसास होगा कि बग को ठीक करने से परे, आप ध्यान देने योग्य सुधार नहीं कर पाएंगे, लेकिन कभी-कभी, आपको एहसास होगा कि कुछ करने का एक बेहतर तरीका है।

उपयोगकर्ताओं के साथ बात करें और देखें कि वे कहां मुद्दों पर ध्यान दे रहे हैं, या तो UX या गति के मुद्दे। अपने कोड को बेहतर बनाने के प्रयास के लिए इन समस्याओं को ठीक करें।

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

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

Answer 8

क्या आपने एक कंपनी छोड़ने और खोजने पर विचार किया है जहां आप एक टीम में हो सकते हैं? मुझे बहुत दृढ़ता से लगता है कि अलग-थलग या एक स्थिर टीम में, डेवलपर्स बहुत याद करते हैं जो पेशे को पेश करना है।

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

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

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

Answer 9

"क्या यह एक छोटा मुद्दा है जितना मुझे लगता है कि यह है, या क्या यह दूसरों द्वारा अनुभव की गई समस्या है?"

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

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

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

Answer 10

अन्य उत्तरों के अलावा, मैं एक डेवलपर सम्मेलन में जाने की सलाह दूंगा।

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

अधिमानतः, इसके लिए 3 दिन का समय लें। मैंने पाया है कि अपने काम के लिए आवश्यक मानसिक दूरी पाने के लिए और अपने खुद के बजाय एक बड़े समुदाय (इसलिए बोलने के लिए) की आंखों के माध्यम से इसे देखने के लिए पर्याप्त होना चाहिए।

संयोग से, यह लोगों की टीमों पर भी लागू होता है, क्योंकि ग्रुपथिंक कहीं भी हो सकता है।

अंत में, यदि आपको इसके लिए मंजूरी नहीं मिलती है, तो प्रति वर्ष एक बार कहें, नौकरी बदलें।

Answer 11

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

• कोड को ऐसे कार्यान्वित करें कि जिस चीज की जरूरत है वह सब कुछ विन्यास योग्य और रखरखाव योग्य हो

  री-आर्किटेक्चर और आपकी परियोजना को फिर से लागू करने से निश्चित रूप से बेहतर स्थिरता, प्रदर्शन आदि के साथ ऐप का परिणाम होगा।

Answer 12

मेरा मानना ​​है कि कुछ स्मार्ट लोगों के साथ चिंताओं को 'चारों ओर मारना' मदद करता है। विशिष्ट जानकारी होने की आवश्यकता है। क्या यह 24x7x365 वेबसाइट है? LoB ऐप? यह कहां चल रहा है या होस्ट किया गया है?

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