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