किसी ऐसे व्यक्ति की मदद करना जो कभी नहीं होगा और कभी भी एक पेशेवर प्रोग्रामर नहीं होगा जो कोड लिखेगा जो उपयोग करने और व्याख्या करने के लिए अधिक सुपाठ्य और प्रयोग करने योग्य होगा [बंद]


20

मैं एल्विस हूं, आइंस्टीन बनना सीखने की बहुत कोशिश कर रहा हूं। मैं मोर्टार के लिए काम करता हूं।

इस पागल बेवकूफ के बारे में क्या बात है?!?! (आपको केवल पहले कुछ पैराग्राफ पढ़ने की जरूरत है)

यदि आप उस लिंक को पढ़ने का मन नहीं करते हैं, तो मूल रूप से, मैं एक पेशेवर प्रोग्रामर हूं, और मेरा बॉस है (यह बहुत सटीक है):

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

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

क्या किसी ऐसे व्यक्ति की मदद करने के लिए कुछ अन्य रणनीतियाँ हैं जो एक पेशेवर प्रोग्रामर नहीं हैं, कभी भी एक पेशेवर प्रोग्रामर लिखने वाला कोड आगे नहीं बढ़ेगा जो मेरे लिए उपयोग करने और व्याख्या करने के लिए अधिक सुपाठ्य और प्रयोग करने योग्य हो?


3
वर्कप्लेस के लिए एक अच्छा प्रश्न प्रतीत होता है ।stackexchange.com को वहां छिपाया जाना चाहिए, लेकिन मुझे यकीन नहीं है कि यह प्रश्न अपने वर्तमान रूप में अच्छी तरह से प्राप्त होगा।
बार्ट वैन इनगेन शेनॉ

2
@BartvanIngenSchenau मैंने इसे वहां पोस्ट करने पर विचार किया लेकिन मैंने यहां चुना क्योंकि मुद्दे बहुत विशिष्ट प्रोग्रामिंग हैं। मैं इसे (मदद से) विकास के तरीके और प्रक्रियाओं और सॉफ्टवेयर इंजीनियरिंग प्रबंधन के लिए मानता हूं । मैं सामान्य कार्यस्थल के मुद्दों, कार्यालय की राजनीति के बारे में नहीं पूछ रहा हूं, मैं पूछ रहा हूं कि "ऐसे व्यक्ति के साथ काम करने के लिए मैं कौन सी सॉफ्टवेयर विकास रणनीतियों का उपयोग कर सकता हूं"।
डुर्रोन 597

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

6
सवाल यह है कि क्या आप इस स्थिति में अधीनस्थ होने पर कुछ भी कर सकते हैं?
फिलिप

4
मुझे यहां हल करने के लिए कोई समस्या नहीं दिख रही है। काम की गुणवत्ता कम होने के कारण क्या आपको कंपनी के अन्य लोगों से समस्याएँ हो रही हैं? क्या आप रखरखाव की लागत की वजह से महत्वपूर्ण समय-सीमाएं याद कर रहे हैं, या क्या सॉफ़्टवेयर लगातार आपके साथ दुर्व्यवहार कर रहा है और आपके उपयोगकर्ताओं द्वारा परेशान किया जा रहा है? यदि उपरोक्त में से कोई भी नहीं है, तो मुझे लगता है कि आप और आपके मालिक जो कम गुणवत्ता वाले काम कर रहे हैं, वही ठीक वैसा ही है जैसा कि व्यवसाय चाहता है और उसकी जरूरत है, और वास्तव में कोई समस्या नहीं है कि आप एक अलग नौकरी चाहते हैं। जो बिंदु पर आप ही तय कर सकते हैं कि बहुत आप एक अलग काम करना चाहता है, अगर यह जोखिम के लायक
जिमी हौफा

जवाबों:


8

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

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

जहां आप यहां से जाते हैं, काफी हद तक विश्वास की डिग्री पर निर्भर करता है कि "वैज्ञानिक" आपके काम को समझने की क्षमता में है। यदि उन्हें विश्वास है कि आप उनके कोड को समझ सकते हैं और जब आप चीजों को संशोधित करते हैं, तो यह नहीं होगा, तो आमतौर पर कोई समस्या नहीं होती है। वे आपकी विशेषज्ञता पर भरोसा करेंगे।

हालाँकि, यदि वैज्ञानिक नहीं चाहते कि आप उनके कोड को बदल दें, तो इस बात की बहुत अधिक संभावना है कि आपने अभी तक उनका विश्वास अर्जित नहीं किया है। यदि ऐसा है तो वैज्ञानिक को ठीक करने पर ध्यान देने के बजाय, आपको अपने आप को "ठीक करने" पर ध्यान देना चाहिए। इससे मेरा मतलब है कि उनका आत्मविश्वास हासिल करने की दिशा में कदम उठाना। संभवतः ऐसा करने का सबसे आसान तरीका इस प्रकार है:

आपकी परीक्षण प्रक्रिया के भाग के रूप में:

  1. एल्गोरिदम को समझना आसान बनाने के लिए शुरू करें (जैसे आरेख, पीडीएल, गणित संकेतन)
  2. एल्गोरिदम को समझना सीखें।
  3. किनारे के मामलों की पहचान करना सुनिश्चित करें।
  4. वैज्ञानिक से पूछें कि क्या आपका सरलीकृत "वैकल्पिक" प्रतिनिधित्व सही है
  5. और सबसे महत्वपूर्ण समस्याओं की पहचान की जो आपको मिली; और "अभियोगात्मक" लगने के बिना "मैं एल्गोरिथ्म देख रहा था और XYZ ऐसा करने वाला है या ऐसा करने वाला है?" इस गोली से बेहतर उनका आत्मविश्वास कुछ भी नहीं हासिल करेगा।

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

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

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


19

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

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

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

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

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


2
मुझे यह करना प्रिय होगा। समस्या यह है कि, यदि हम प्रत्येक सप्ताह 40 सप्ताह तक काम करते हैं, तो यह श्रम के विभाजन को 20 और 60 की तरह बदल देगा, और उसे अपने बाकी समय के साथ बहुत कम करना होगा। अधिक कर्मचारियों के लिए हमारी आवश्यकता (ताकि उसे प्रोग्राम न करना पड़े) कुछ ऐसा है जो हम दोनों चाहते हैं, लेकिन इस समय वित्तीय मुद्दे हैं।
डुर्रोन 597

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

2
@ Durron597: ऐसा लगता है कि वह एक मोटे सबूत की अवधारणा को हैक करता है और फिर आपको इसे अच्छा और पॉलिश और उत्पादन-तैयार करने के लिए प्राप्त करता है।
FrustratedWithFormsDesigner

4
@ durron597 यदि वह डोमेन विशेषज्ञ है जो शुद्धता को सत्यापित करने में सक्षम है, तो क्या वह इकाई परीक्षण लिखने के विचार के लिए खुला होगा जो पूरी तरह से सब कुछ निर्दिष्ट करेगा? मूल रूप से उसके बजाय कार्यक्षमता को प्रोटोटाइप करने के लिए, आप लोग टीडीडी का एक रूप करेंगे जहां वह यह सुनिश्चित करने के लिए परीक्षण लिखता है कि सब कुछ सही है और आप वास्तविक कार्यान्वयन करते हैं?
एवीकाटोस

4
@ durron597 (टिप्पणियों में से एक द्वारा गढ़ी गई एक जंगली हरे रंग के बाद :) क्या आप एक (एन ई) डीएसएल लिखने में सक्षम होंगे जो उसे अधिक तार्किक रूप से अपने तर्क को व्यक्त करने में सक्षम करेगा जिससे आपको अपने हिस्से पर फिर से लिखने की आवश्यकता नहीं होगी। ?
पौल

3

आप अपने आप से पूछते हैं: यहां आपका अंतिम लक्ष्य क्या है? 1. अपने मालिक की मदद करने के लिए? 2. कंपनी की मदद करने के लिए? 3. खुद की मदद करने के लिए? और इससे पहले कि आप "उपरोक्त सभी" का उत्तर दें, धीमा करें। आपका पहला कार्य अपने प्राथमिक उद्देश्य को स्पष्ट रूप से परिभाषित करना है, क्योंकि उत्तर इस पर निर्भर करता है।

यदि आप लक्ष्य है:

  1. अपने बॉस की मदद करें? हार मान लेना। वह इसके लिए पूछ रहा प्रतीत नहीं होता है। आपने कहा, "वह जानता है कि उसका कोड खराब है, लेकिन यह वही करता है जो उसे चाहिए।" खैर, चर्चा का अंत। जब तक और जब तक आपका बॉस मौजूदा स्थिति से असंतुष्ट नहीं होता, तब तक वह बदलने वाला नहीं है, और वह आपकी मदद करने के आपके प्रयासों पर नाराजगी जताएगा। यदि भविष्य में किसी बिंदु पर वह यथास्थिति के "दर्द को महसूस करता है", तो उम्मीद है कि आपने खुद को एक भरोसेमंद संरक्षक के रूप में स्थापित किया होगा और उसे पता होगा कि मदद के लिए कहां आना है।

  2. आपकी कंपनी की मदद? क्या वर्तमान स्थिति नीचे की रेखा को धमकी दे रही है? जोखिम में हैं समय सीमा? क्या ऊपरी प्रबंधन अपनी गर्मी बढ़ा रहा है? यदि नहीं, तो इसे छोड़ दें। (यह अनिवार्य रूप से बिंदु है कि जिमी हॉफ़ा ने आपकी मूल पोस्ट के लिए अपनी टिप्पणी में बनाया है।) यदि, हालांकि, वर्तमान स्थिति वास्तव में आपके विभाग / कंपनी के लिए अस्वीकार्य जोखिम का प्रतिनिधित्व करती है, तो प्रक्रिया का एक परिवर्तन क्रम में है। उस मामले में मेरा सुझाव है कि आप अलग बैठें और एक अलग रूपरेखा तैयार करेंश्रम विभाजन। यहाँ पर यह बताना महत्वपूर्ण है कि जब आप अपने बॉस के कोड को रिफैक्ट करने में समय बिताते हैं तो बेहतर होगा कि आप नया कोड लिखकर खर्च करें। आप कहते हैं कि आपके पास यह सब लिखने का समय नहीं है, लेकिन यह वह नहीं है जो मैं सुझा रहा हूं। आपको यह पता लगाने की आवश्यकता है कि अपनी संबंधित शक्तियों को अधिकतम कैसे करें। एक मोर्टार के रूप में उसके बारे में सोचना बंद करें, और उसे बेहतर डोमेन ज्ञान के साथ एक जूनियर डेवलपर के रूप में सोचें। यह उद्योग में काम करने की एक बहुत ही सामान्य व्यवस्था है, और आपको यह सीखना होगा कि आप इसमें कैसे कामयाब होते हैं। उदाहरण के लिए, सुनिश्चित करें कि वह जानता है कि आप जानते हैं कि उसकी विशेषज्ञता कितनी आवश्यक है (इस कदम को अक्सर दोहराएं), और फिरविनम्रतापूर्वक निम्नलिखित रणनीति (या कुछ इसी तरह) को बाजार के लिए अपने ज्ञान को प्राप्त करने के लिए एक तेज पथ के रूप में सुझाव दें: (ए) "फुर्तीली" स्प्रिंट में काम को तोड़ दें, (बी) ओवर-फ्रंट (प्रत्येक स्प्रिंट में) को परिभाषित करने में भारी सहयोग करें -सभी आवश्यकताओं और वास्तुकला। (c) उसे बंद करने दें और सभी एल्गोरिदम संबंधी निर्णयों को पूरा करने के लिए प्रोटोटाइप का निर्माण करें, जबकि आप उस बुनियादी ढांचे का निर्माण करते हैं जिस पर आपने पिछले चरण में सहमति व्यक्त की थी। (d) अपने एल्गोरिदम को अपनी संरचना में लागू करें जबकि वह इसे सत्यापित करने के लिए परीक्षण बनाता है। (e) अपने V & V को एक साथ सहकर्मी-प्रोग्रामिंग वातावरण में आचरण करें। (उदाहरण के लिए, "यह परीक्षण विफल रहा; क्यों; एल्गोरिथम तर्क त्रुटि या कोडिंग गलती?"

  3. अपनी सहायता कीजिये? यहां ईमानदार बनो। यदि आप जो कुछ भी कर रहे हैं वह शिकायत कर रहा है कि आप अपनी नौकरी का आनंद नहीं लेते हैं, तो मेरा सुझाव है कि आपको ऊपर # 2 के बारे में सोचने में अधिक समय बिताने की आवश्यकता है। यदि आप कंपनी के बारे में परवाह नहीं करते हैं और आप अपनी नौकरी का आनंद नहीं लेते हैं, तो अपना रिज्यूमे वितरित करना शुरू करें। यदि आप अपनी कंपनी की परवाह करते हैं, लेकिन अपनी नौकरी का आनंद नहीं लेते हैं, तो # 2 पर ध्यान केंद्रित करके बीओटीएच खातों पर मदद करनी चाहिए। लेकिन उस मामले में, यह केवल "जीत-जीत" है अगर यह हर किसी के लिए स्पष्ट है कि आपका जुनून वास्तव में टीम की मदद करने की इच्छा से उपजा है, और न केवल आपके असाइनमेंट में आत्म-केंद्रित निराशा से।


1
बहुत बढ़िया जवाब। यह निश्चित रूप से # 2 है, और आपका क्या करना है इसका विवरण पिछले कुछ दिनों में हमने चर्चा की है। हम निश्चित रूप से पर्याप्त संवाद नहीं करते हैं।
ड्यूर्रोन 597

मैंने सिर्फ 3 अंक में एक अंतिम वाक्य जोड़ा है। शायद सबसे महत्वपूर्ण है। अपनी पोस्ट को फिर से पढ़ें और ईमानदारी से अपने आप से पूछें कि क्या आप दूसरों के सामने आ रहे हैं।
किमीकोट

2

मुझे यकीन नहीं है कि मैं इस चर्चा में कुछ जोड़ूंगा, लेकिन इसी तरह के परिदृश्यों में काम किया है जहां एक एक्सेस उल्लंघन लाइन के साथ ShowMessage('Hello');या इसी तरह से टकरा रहा है, केवल यह पता लगाने के लिए कि एक ही लाइन में अधिक कोड है, स्क्रीन से बाहर सही,

मेरा मानना ​​है कि आपके पास दो मूल विकल्प हैं:

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

"एक पुस्तकालय / रूपरेखा बनाएँ" मैं कोशिश कर रहा हूं कि जब भी मुझे खाली समय मिले, लेकिन समस्या यह है कि परियोजना "तत्काल अल्पावधि चिंताओं" के लिए दूर हो रही है
ड्यूर्रोन 597

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

एक पुस्तकालय का निर्माण छोटे कार्यक्रमों के सरल संग्रह के साथ शुरू होना चाहिए जो आपने पहले से ही लिखा है, उसके एक कार्यक्रम के बाद।
डगएम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.