2010-05-09 8 views
7

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

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

(प्रश्न/चीजें है जिसके लिए मैं सुझाव चाहते हैं इटैलिक में कर रहे हैं)

1] Cygwin स्थापित करें, और प्राप्त यह विंडोज के साथ अच्छी तरह से काम करने के लिए तो मैं Git या किसी ऐसे ही संस्करण नियंत्रण प्रणाली का उपयोग कर सकते (है वहाँ एक डीवीसीएस जो सीधे विंडोज सीएलआई से काम कर सकता है, तो मैं सिग्विन चरण को छोड़ सकता हूं?)।

2] Emacs सेट करें सी, अजगर, और MATLAB फाइलों के साथ काम करने के लिए, तो मैं संपादित करें और (जैसे कि, Emacs)

एक भी संपादक से एक ही बार में सभी तीन संकलन कर सकते हैं (मैं बहुत नहीं कर रहा हूँ Emacs मेनू से परिचित है, लेकिन क्या कुछ भाषाओं के लिए कंपाइलर के लिए पथ सेट करने का कोई तरीका है? मुझे पता है कि मैं इसे Google कर सकता हूं, लेकिन एमएक्स दस्तावेज अब तक पढ़ने के लिए बहुत कठिन साबित हुआ है, इसलिए अगर मैं इसकी सराहना करता हूं तो मैं इसकी सराहना करता हूं किसी ने मुझे सरल भाषा में बताया)

3] प्रत्येक दिन या आधे दिन के अंत में कोड में जांचना शुरू करें ताकि मेरे कोड (दो प्रश्न) की प्रगति का उचित मार्ग बनाए रखा जा सके,

  • क्या आप सीधे emacs से फ़ाइलों को चेकआउट कर सकते हैं?

  • क्या लैबव्यू फ़ाइलों को गिट की तरह एक डीवीसीएस में चेकआउट करने का कोई तरीका है?

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

उत्तर

3

1) दोनों गिट और मर्कुरियल विंडोज के तहत काम करेंगे - सिग्विन की कोई ज़रूरत नहीं - एक पर्यावरण मैं जितना संभव हो उससे बचूंगा।

2) यह न देखें कि आपको क्यों लगता है कि आपको emacs का उपयोग करना है।

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

+2

+1 "यह न देखें कि आपको क्यों लगता है कि आपको emacs का उपयोग करना है।" –

+0

@ax यह वास्तव में मेरा मुख्य बिंदु नहीं था। निश्चित रूप से, अगर लोग emacs का उपयोग करना चाहते हैं, तो उन्हें - एक और उबाऊ ज्वाला युद्ध शुरू करने में शून्य रुचि या इरादा होना चाहिए। –

+0

मुझे पता है, मैं सहमत हूं, और मैं न तो उबाऊ लौ युद्ध शुरू करना चाहता हूं। सिर्फ इस विचार में + 1 'है कि emacs के बगल में अन्य संपादक हैं। –

2

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

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

2) रातोंरात निर्माण प्रक्रिया को प्राप्त करें। या कम से कम कुछ स्वचालित प्रक्रिया जो आपके कोड को हर बार कोड जांचते समय पुनर्निर्माण करती है। क्या यह उस बिल्ड पर आपके सभी परीक्षण चलाएं।

2

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

वैज्ञानिक वातावरण जहां बहुत से लोग केवल तेजी से स्नातक होने के या उनके वित्त पोषण को मंजूरी दे दी प्रस्तावों हो रही के बारे में परवाह कोडिंग के एक हिट-एन-रन चरवाहे शैली nuture लगते हैं। यदि आप लोगों को गुणवत्ता और पुनरुत्पादन के बारे में सोच सकते हैं तो आप पहले ही जीत चुके हैं।

क्या मैं उपयोगी पाया:

  • हमेशा छोटे उप कि आप आसानी से परीक्षण कर सकते हैं में अपने कोड को तोड़ने के लिए प्रयास करें। प्रत्येक चेक-इन पर अपने परीक्षण चलाएं। आप अपने "एप्लिकेशन" को इकट्ठा करने के लिए गिट के सबमिड्यूल का उपयोग कर सकते हैं।
  • एक से अधिक लोगों astyle तरह रिपोजिटरी उपयोग कुछ सतत प्रारूपण के लिए (शायद कम अजगर कोड के लिए एक मुद्दा) के लिए प्रतिबद्ध कर सकते हैं।
  • तरह gitweb/cgit/... ताकि लोगों को कोड के tarballs प्राप्त कर सकते हैं और यह विचार है कि स्रोत नियंत्रण उपयोगी है आदत हो कुछ सेट करें।
  • अपने समूह/समुदाय में coding buddy ढूंढने का प्रयास करें। कोड समीक्षा एक ऐसे माहौल में करना बहुत कठिन है जहां लोग "बस इसे पूरा करते हैं" के लिए प्रवण होते हैं, अक्सर बोर्ड पर अच्छी शैली/सामान्य ज्ञान फेंकते हैं।
0

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

मैं तुम्हें एक छोटे से स्रोत नियंत्रण के लिए बनाम ग्राहकों स्रोत नियंत्रण की मेजबानी के बारे में उलझन हो सकता है लगता है। के लिए सीवीएस, SVN, Git और दूसरों खिड़कियों के लिए लगभग सर्वत्र उपलब्ध है। होस्टिंग कई वेब होस्टिंग कंपनियों से उपलब्ध है ग्राहकों। ऐसा हो सकता है एक अच्छा विकल्प, क्योंकि यह आपको प्रभावी रूप से ~ 100 $/वर्ष के लिए अपने कोडबेस का ऑफसाइट बैकअप भी देगा। वैकल्पिक रूप से आप सर्वर को कम अंत पीसी पर लोड कर सकते हैं और इसे कहीं कोठरी में रख सकते हैं, हालांकि बिजली की लागत शायद जितना आप होस्टिंग के लिए भुगतान करेंगे।

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

+0

अफसोस की बात है, "बनाता है"! = "अच्छा है"। कुछ गुणवत्ता के लिए आप कम से कम एक छोटा परीक्षण सूट चाहते हैं। ये अभी भी अक्षम कोड या क्रैपी एपीआई डिज़ाइन नहीं पकड़ सकते हैं - इनके लिए आपको सहकर्मी समीक्षा की आवश्यकता है (और यह प्राप्त करने का सबसे कठिन हिस्सा है)। –

+0

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

+0

@ ड्रैंचन: स्रोत नियंत्रण बैकअप का एक प्रकार हो सकता है। जब भी कुछ काम करता है प्रतिबद्धता। फिर आप बाद में वापस जा सकते हैं जैसे कि आप लैब बुक एंट्री से पुराना माप स्थापित करने में सक्षम होना चाहिए। –

0

क्या लैबव्यू फ़ाइलों को गिट की तरह एक डीवीसीएस में चेकआउट करने का कोई तरीका है?

कोई कारण नहीं है कि LabVIEW फ़ाइलें DVCS में क्यों नहीं हो सकती हैं, मैं Mercurial का उपयोग कर रहा हूं। हालांकि चूंकि लैबव्यू फाइलों को बाइनरी फाइलों के रूप में माना जाता है, इसलिए आपके रेपो का आकार तेजी से बढ़ेगा।

बॉक्स LabVIEW केवल प्रदान करता है 3-way merges में से एक few tweaks साथ, दो संशोधनों के बीच एक अंतर समारोह आप LV-diff की जरूरत का उपयोग करने के उपकरण है कि केवल फाइलों का स्थान बदलने का समर्थन करने के (जैसे। डुप्लिकेट फ़ाइल नाम)।

इसके अलावा आपकी अनदेखी सूची में * .lvlps और * .aliases जोड़ना महत्वपूर्ण है, इन फ़ाइलों के पास किसी अन्य कंप्यूटर पर उपयोगी अर्थ नहीं है।

संबंधित मुद्दे

 संबंधित मुद्दे