व्यक्तिगत अनुभव का टुकड़ा: विकास, पुल अनुरोध, कमिट, सॉफ्टवेयर कौशल

हाय, हब्बर! इस लेख में, मैं सॉफ्टवेयर के विकास के बारे में अपनी राय साझा करूंगा। मैं सूचना प्रौद्योगिकी में इतने लंबे समय से पहले नहीं था, लेकिन मैंने विकास के प्रति एक मजबूत रवैया विकसित किया है, जिसमें काम के लिए आवश्यकताओं के स्पष्टीकरण के नाम शामिल हैं।

डिज़ाइन

सजातीय परिवर्तन

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

कार्य कार्यान्वयन

एक कृपाण के साथ समस्या को हल न करें, जल्दी में महत्वपूर्ण निर्णय न करें, भले ही ऐसा लगता है कि आपका दृष्टिकोण सही है। इन दिशानिर्देशों का पालन करें:

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

अनुरोधों को खींचो

नाम

शीर्षक में परिवर्तन थीसिस का वर्णन होना चाहिए - संक्षिप्त और संक्षिप्त हो। हेडर डिजाइन नियमों का पालन करें:

• बड़े अक्षर से शुरू करें
• अंत में एक बिंदु के बिना
• एक अनिवार्य मूड है।

Ticket-295: Add base cat interface and British cat realization 

विवरण

पुल अनुरोध के इस खंड को एक ऐसी भाषा में सही ढंग से लिखा जाना चाहिए जो गैर-तकनीकी विशेषज्ञ के लिए समझ में आता है, जिसे सिमेंटिक लोड द्वारा विभाजित किया गया है, और परिवर्तनों का खुलासा इस प्रकार किया गया है:

• कई वाक्यों में परिणाम,
• परिवर्तनों से पहले क्या था
• उन्हें क्यों और कैसे करना पड़ा,
• आपने वास्तव में क्या किया
• आपने इसे कैसे कार्यान्वित किया

 The base cats interface was created to provide the common cats functionality and attributes. Also the realization of the British cats was created as the individual one. Our business-analytics have provided for product owner that they want to interact with cats on out platform too, not only with docs. So developers got the tasks to design and implement basic implementation of the cats interface to describe the common patterns of the interaction with it by user. Also the goal was to create one demo cat called British cats (British Shorthair) with its great noses. 

सूचना

अंत में, पुल अनुरोध में शामिल विषयों के लिंक छोड़ दें। यदि किसी अन्य डेवलपर को परिवर्तनों को बेहतर ढंग से समझने की आवश्यकता है, तो वह वहां देख सकेगा। इसके अलावा कुछ नियम:

• संक्षेप में वर्णन करें कि सहायता कहाँ निर्देशित है
• यदि संभव हो - पूर्ण लिंक फेंकें,
• यदि नहीं, तो git.io और bit.ly के साथ छोटा करें,
• एक सूची बनाओ।

 References: • British cats — https://en.wikipedia.org/wiki/British_Shorthair • Cats anatomy — https://en.wikipedia.org/wiki/Cat_anatomy 

प्रतिबद्ध

मर्ज कमेट

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

 $ git log --oneline 4336d35 Create cats interface 7bc2ba9 Implement Persian cat realization 5f330fd Add Persian cat documentation ... 

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

 $ git log --oneline d2ccf1a Ticket-299: Prevent cats graph be stopped unexpectedly (#301) 82a921a Ticket-295: Add base cat interface and british cat realization (#293) ... 

परिणामस्वरूप, डिफ़ॉल्ट शाखा परिवर्तनों के विस्तृत वर्णन के साथ भर जाती है।

 Ticket-299: Prevent cats graph be stopped unexpectedly There was a situation when cats graph is stopped unexpectedly without any verbose information and traceback. The socket connection between two web-servers (back-end and front-end) was successfully debugged and founded the socket library async latent behavior. Implemented: — Create handler for async socket connection as sync. The consumer doesnt specify a condition for ending the while loop and stream, so the application checker in Daphne cleans up the task if the protocol disconnects and the app doesnt handle it. So `channel_layer` is wrapped to `async_to_sync`. — Fix low latency between pushing the cats graph data and its output on the user interface. There was a high coupling between interface class that proxy via a few client to the realization. The separated cats graph message class was created. References: • Socket channel layers — https://channels.docs.io/channel_layers.html • Daphne handle_reply() — https://git.io/fgVzK Issue: #56 

मर्ज करने के दौरान इन दिशानिर्देशों का पालन करें:

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

नरम कौशल

लिखित संचार

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

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

उत्तरदायित्व

आप एक पेशेवर के रूप में विकसित होते हैं न केवल जब आप नए अनुभव और ज्ञान प्राप्त करते हैं, बल्कि यदि:

• समस्याओं को हल करते समय, विशेषज्ञों के साथ परामर्श करें;
• आपके काम को बेहतर किया जा सकता है - सुधार;
• आप एक सहयोगी के रूप में एक बेहतर काम कर सकते हैं - उसे इसके बारे में बताएं;
• आप कुछ नहीं जानते - इसे स्वीकार करें और मदद के लिए पूछें;
• प्रक्रियाओं में सुधार करें, नई चीजें लाएं और समस्याओं की अनदेखी न करें।

प्रकाशित करने के लिए समय निकालने के लिए धन्यवाद। निजी संदेशों या टिप्पणियों में प्रतिक्रिया छोड़ें, मुझे चर्चा करने में खुशी होगी।