एक टीम को एक ऐसा बिलिंग मॉड्यूल विरासत में मिलता है जिसे कोई भी पूरी तरह से नहीं समझता। इसमें मौजूदा कार्यप्रणाली की सुरक्षा के लिए कोई परीक्षण नहीं हैं। इसे "ठीक करने" के लिए एक स्प्रिंट प्रस्तावित किया गया है, और योजना कोर को एक नई संरचना में फिर से लिखने की है। कोई भी यह नहीं बता सकता कि उन्हें कैसे पता चलेगा कि नया संस्करण अभी भी ग्राहकों से सही शुल्क ले रहा है।
यह एक उदाहरण मात्र है, कोई दस्तावेजी घटना नहीं। यह उस कमी को दर्शाता है जिसे रिफैक्टरिंग प्रशिक्षण परियोजना को दूर करना होता है: ऐसे इंजीनियर जो यह तो देख सकते हैं कि कोड अव्यवस्थित है, लेकिन अभी तक एक सीमित सुधार की योजना नहीं बना सकते और यह प्रदर्शित नहीं कर सकते कि व्यवहार को बरकरार रखा गया है।
यह मार्गदर्शिका इंजीनियरिंग एनेबलमेंट लीड्स और इंजीनियरिंग मैनेजर्स के लिए है। इसमें प्रदर्शन संबंधी समस्या का वर्णन करना, कमियों का पता लगाना, तैयारी और अभ्यास डिजाइन करना, किसी केस स्टडी पर काम करना और यह आकलन करना शामिल है कि क्या कौशल वास्तविक कार्य में लागू होता है। यह प्रशिक्षण डिजाइन के बारे में है। आपके प्रोग्राम में कोड, परीक्षण और नियम आपके अपने स्टैक पर वरिष्ठ इंजीनियरों द्वारा मान्य किए जाने चाहिए।
रिफैक्टरिंग प्रशिक्षण परियोजना क्या है?
रिफैक्टरिंग प्रशिक्षण परियोजना, पुराने कोड पर किया जाने वाला एक व्यवस्थित कार्य है, जिसका उद्देश्य क्षमता निर्माण के साथ-साथ कोड में सुधार करना भी है। शिक्षार्थी एक छोटा, सीमित परिवर्तन निर्धारित करते हैं, परीक्षणों के माध्यम से मौजूदा कार्यप्रणाली को सुरक्षित रखते हैं, छोटे-छोटे चरणों में डिज़ाइन में सुधार करते हैं और यह साबित करते हैं कि कुछ भी खराब नहीं हुआ है। कोड बेहतर होता जाता है, और इससे भी महत्वपूर्ण बात यह है कि इंजीनियर वास्तविक तकनीकी कमियों को दूर करने के लिए आवश्यक निर्णय लेने का अभ्यास करते हैं।
त्वरित तथ्य
| सवाल | संक्षिप्त जवाब |
|---|---|
| कार्य क्या है? | सीमित दायरे में मौजूद पुराने कोड में सुधार की योजना बनाएं और उसका सत्यापन करें। |
| आपका स्कोर क्या है? | जोखिम विश्लेषण, और इस बात के प्रमाण कि मौजूदा व्यवहार संरक्षित रहा। |
| क्या व्यापक पुनर्लेखन एक अच्छा प्रशिक्षण प्रोजेक्ट है? | आमतौर पर नहीं। यह अभ्यास किए जा रहे कौशल को छुपा देता है और संरक्षित व्यवहार को प्रदर्शित करना कठिन बना देता है। |
| क्या रिफैक्टरिंग पैटर्न पर आधारित एक प्रश्नोत्तरी पर्याप्त है? | नहीं। यह पूर्वापेक्षाओं की पुष्टि करता है, लेकिन यह नहीं कि कोई इंजीनियर किसी बदलाव की योजना बना सकता है और उसे मान्य कर सकता है या नहीं। |
| सामग्री का सत्यापन कौन करता है? | एक इंजीनियरिंग मैनेजर और एक वरिष्ठ इंजीनियर जो कोडबेस से परिचित हो। |
| प्रशिक्षण से क्या ठीक नहीं हो सकता? | परीक्षण के लिए आवश्यक उपकरणों की कमी, दबाव कम होना, स्वामित्व का स्पष्ट न होना और रखरखाव कार्य के लिए समय का अभाव। |
| आपको कैसे पता चला कि यह काम कर गया? | एक नया, अनदेखे लेगेसी-कोड केस, जिसका मूल्यांकन सहमत मानदंडों के आधार पर किया जाएगा, और वास्तविक कार्य पर अनुवर्ती कार्रवाई की जाएगी। |
1. प्रदर्शन संबंधी समस्या का वर्णन करें।
कार्य से शुरुआत करें: सीमित दायरे में पुराने कोड में सुधार की योजना बनाएं और उसका सत्यापन करें। "सीमित" शब्द महत्वपूर्ण है। शिक्षार्थी ऐसा बदलाव चुनता है जो पूरा करने के लिए पर्याप्त छोटा हो, और यह बता सके कि कौन सा बदलाव दायरे में है और कौन सा नहीं।
शब्दों के बारे में सटीक होना सहायक होता है। मार्टिन फाउलर रीफैक्टरिंग को मौजूदा कोड बेस के डिज़ाइन को बेहतर बनाने की एक नियंत्रित तकनीक के रूप में वर्णित करते हैं , जो छोटे, व्यवहार-संरक्षणकारी परिवर्तनों से बनी होती है। "व्यवहार-संरक्षणकारी" वाक्यांश ही रीफैक्टरिंग को रीराइट से अलग करता है, और प्रशिक्षण में इसी बात को स्पष्ट रूप से समझाना आवश्यक है। तकनीकी ऋण रूपक को वार्ड कनिंघम ने गढ़ा था , और फाउलर की चर्चा एक उपयोगी अनुस्मारक है कि ऋण जानबूझकर और विवेकपूर्ण तरीके से लिया जा सकता है, इसलिए हर अव्यवस्थित मॉड्यूल एक गलती नहीं है जिसे ठीक किया जाना चाहिए।
माइकल फेदर्स की लेगेसी कोड पर लिखी किताब भी व्यवहारिक दृष्टिकोण अपनाती है। इसके प्रकाशक के विवरण में कहा गया है कि यह डेवलपर्स को ऐसे टेस्ट लिखना सिखाती है जो यह सुनिश्चित करते हैं कि वे अनजाने में एप्लिकेशन में कोई बदलाव न करें , और मौजूदा सॉफ़्टवेयर को पूरी तरह से दोबारा लिखे बिना ही उसे नियंत्रण में ला सकें।
प्रदर्शन विवरण को एक वाक्य में लिखें और किसी इंजीनियरिंग मैनेजर से इसकी जाँच करवाएँ: “एक पुराने मॉड्यूल और एक परिभाषित लक्ष्य को देखते हुए, इंजीनियर एक सीमित परिवर्तन का प्रस्ताव करता है, वर्तमान व्यवहार को सुनिश्चित करने वाले परीक्षण जोड़ता है, छोटे-छोटे चरणों में परिवर्तन करता है और दिखाता है कि व्यवहार संरक्षित है।”
2. सीखने और संदर्भ संबंधी कमियों का निदान करें
कुछ भी बनाने से पहले, आवश्यक कार्य की तुलना अपनी वर्तमान गतिविधियों से करें और उसका मूल्यांकन करें। तीन प्रश्न आमतौर पर प्रशिक्षण की कमी को किसी अन्य समस्या से अलग करते हैं:
- क्या वर्तमान कार्यप्रणाली में वास्तविक कार्य का उपयोग किया जाता है? यदि प्रशिक्षण में स्लाइड के माध्यम से रिफैक्टरिंग पैटर्न को समझाया जाता है, लेकिन कोई भी अप्रमाणित कोड में बदलाव नहीं करता है, तो किसी ने भी सुरक्षात्मक व्यवहार का अभ्यास नहीं किया है। यदि मूल्यांकन कोड स्मेल पर आधारित बहुविकल्पीय परीक्षा है, तो यह स्मरण क्षमता को मापता है।
- संज्ञानात्मक आवश्यकता क्या है? ब्लूम के संशोधित वर्गीकरण में, किसी परिवर्तन की सुरक्षा का आकलन करना विश्लेषण और मूल्यांकन स्तरों पर आता है, और योजना एवं परीक्षणों का निर्माण सृजन स्तर पर पहुँचता है। इन स्तरों के अनुरूप गतिविधियों का मिलान हमारी मार्गदर्शिका में शामिल है। ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना.
- क्या कौशल के अलावा कोई और चीज बाधा बन रही है? कर्मचारियों, उपकरणों और प्रक्रियाओं की जाँच करें। यदि निर्माण में एक घंटा लगता है, तो कोई भी नियमित रूप से परीक्षण नहीं करेगा। यदि रखरखाव कार्य कभी निर्धारित नहीं किया जाता है, तो इंजीनियर केवल गुप्त रूप से ही सुधार करेंगे। प्रशिक्षण से परे कारणों की जानकारी उन लोगों को दें जो उन्हें ठीक कर सकते हैं।
3. उद्देश्यपूर्ण तैयारी और अभ्यास की योजना बनाएं
एक बार जब आपको पता चल जाए कि प्रशिक्षण से किन कमियों को दूर किया जा सकता है, तो प्रत्येक चरण को एक अलग कार्य सौंप दें।
तैयारी। एक संक्षिप्त नैदानिक परीक्षण के साथ पूर्वापेक्षाओं की जाँच करें: आपका परीक्षण ढांचा कैसे काम करता है, लक्षण वर्णन परीक्षण क्या है, और आपकी टीम समीक्षा और विलय कैसे करती है। इस चरण में स्व-गति से अध्ययन करना उपयुक्त है। एक पुनरावलोकन जाँच केवल पूर्वापेक्षाओं की पुष्टि करती है।
अभ्यास करें। स्पष्ट रूपरेखा वाले व्यवस्थित रिफैक्टरिंग प्रोजेक्ट्स का उपयोग करें। एक छोटे, सुरक्षित नमूने से शुरुआत करें, फिर अपने कोडबेस के एक वास्तविक लेकिन सीमित हिस्से पर आगे बढ़ें। गिल्डेड रोज़ काटा पहले चरण के लिए एक प्रसिद्ध शुरुआती बिंदु है। एमिली बाचे द्वारा बनाए गए इसके README में कोड में बदलाव करने से पहले टेस्ट लिखने की सलाह दी गई है और इस अभ्यास को छोटे-छोटे कदम उठाने, बार-बार टेस्ट चलाने और धीरे-धीरे डिज़ाइन में सुधार करने के अभ्यास के रूप में प्रस्तुत किया गया है। प्रत्येक प्रोजेक्ट के लिए एक उपयुक्त क्रम यह है: लक्ष्य और सीमा निर्धारित करें, ऐसे टेस्ट लिखें जो वर्तमान में कोड क्या करता है उसे दर्शाते हों, एक समय में एक ही चीज़ बदलें, हर चरण के बाद टेस्ट चलाएं और आपने जो सीखा उसे लिख लें।
प्रतिक्रिया। प्रतिक्रिया को निर्णयों से जोड़ें, न कि कुल स्कोर से। "आपने छूट का तर्क तो निकाल लिया, लेकिन आपके परीक्षण केवल सही परिणाम तक ही सीमित थे, इसलिए आप राउंडिंग में हुए बदलाव को नहीं देख पाए होंगे" कहना "5 में से 3" कहने से कहीं अधिक उपयोगी है।
लाइव इंस्ट्रक्टर इनपुट या एसिंक्रोनस रिव्यू? लाइव इनपुट तब सबसे ज़्यादा फ़ायदेमंद होता है जब कोई विकल्प अस्पष्ट हो, जैसे कि रुककर छूटा हुआ टेस्ट जोड़ना है या जारी रखना है। एसिंक्रोनस रिव्यू तब पर्याप्त होता है जब शिक्षार्थी अपनी योजना और टेस्ट की तुलना किसी विशेषज्ञ द्वारा तैयार किए गए संस्करण से करते हैं। कई टीमें दोनों तरीकों का इस्तेमाल करती हैं: पहले स्व-गति से तैयारी, फिर कठिन मामलों पर एक निर्देशित सत्र।
4. एक वास्तविक उदाहरण के माध्यम से काम करें
उदाहरण के तौर पर। इंजीनियरिंग मैनेजर को उपयोग करने से पहले मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।
मामला यह है कि एक पुराना फ़ंक्शन छूट, कर और शिपिंग नियम सहित ऑर्डर का कुल योग गणना करता है। इसमें कोई परीक्षण नहीं है। एक टीम पूरे बिलिंग मॉड्यूल को पुनर्गठित करने का प्रस्ताव देती है ताकि इसे "अधिक सरल" बनाया जा सके।
कार्य। शिक्षार्थी यह बताता है कि वह क्या करेगा, वह कौन से साक्ष्य एकत्र करेगा, और उसे और किस प्रकार की जानकारी या सहायता की आवश्यकता है।
पहला प्रयास। “मैं मॉड्यूल को तीन सेवाओं में विभाजित करूँगा और लॉजिक को स्थानांतरित करूँगा, फिर स्टेजिंग में संख्याओं की जाँच करूँगा।” शिक्षार्थी ने एक बड़ा बदलाव और बाद में मैन्युअल जाँच का विकल्प चुना है। यह पता लगाने का कोई तरीका नहीं है कि पुराने और नए संस्करण विशिष्ट मामलों में सहमत हैं या नहीं।
प्रतिक्रिया और पुनः प्रयास। समीक्षक पूछता है कि खाली टोकरी, कुल राशि को ऋणात्मक बनाने वाली छूट और राउंडिंग के मामले में यह फ़ंक्शन आज क्या करता है। पुनः प्रयास में शिक्षार्थी से कहा जाता है कि वह दायरे को एक व्यवहार तक सीमित करे और बताए कि वह कैसे साबित करेगा कि उसमें कोई बदलाव नहीं हुआ है।
एक और बेहतर प्रयास। “मैं फिलहाल मॉड्यूल संरचना को अपरिवर्तित छोड़ दूंगा। मैं परीक्षण के तौर पर कुछ इनपुट के लिए, जिनमें अपवाद भी शामिल हैं, ऑर्डर टोटल फ़ंक्शन द्वारा आज प्राप्त होने वाले मानों को रिकॉर्ड करूंगा। फिर मैं डिस्काउंट गणना को एक अलग फ़ंक्शन में निकालूंगा, उस एक चरण के बाद परीक्षण चलाऊंगा और रुक जाऊंगा। मैं यह नोट करूंगा कि शिपिंग नियम में कुछ ऐसा व्यवहार है जिसे मैं समझ नहीं पा रहा हूं और इसे छूने से पहले किसी सहकर्मी से पूछ लूंगा।” ध्यान दें कि यह उत्तर परिवर्तन को सीमित करता है, व्यवहार को पहले सुरक्षित रखता है और अज्ञात को नाम देता है।
प्रत्येक प्रतिक्रिया उचित है या अपूर्ण? प्रत्येक का मूल्यांकन स्वीकृत मानदंडों के आधार पर करें, न कि समीक्षक की पसंद के आधार पर। पहला प्रयास दीर्घकालिक दृष्टि से एक समझदारी भरा कदम हो सकता है, लेकिन योजना के रूप में अपूर्ण है, क्योंकि इसमें संरक्षित व्यवहार का कोई प्रमाण नहीं है। बेहतर प्रयास छोटा, जाँच योग्य और अनिश्चितता के प्रति ईमानदार होता है।
5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं
क्षमता का प्रमाण किसी नए लेगेसी-कोड केस पर प्रदर्शन है जिसे शिक्षार्थी ने पहले कभी नहीं देखा है। जोखिम विश्लेषण और व्यवहार के संरक्षण के प्रमाण को अंक दें। एक सरल मूल्यांकन मानदंड प्रत्येक मापदंड के लिए 0 से 2 के पैमाने का उपयोग करता है:
| कसौटी | प्रत्यक्ष साक्ष्य |
|---|---|
| कार्य निष्पादन | सीमित दायरे में मौजूद पुराने कोड में सुधार की योजना बनाता है और उसे मान्य करता है, तथा इस कार्रवाई और इसके पीछे के साक्ष्य को रिकॉर्ड करता है। |
| विचार | यह बाधाओं, विकल्पों और अनिश्चितता की व्याख्या करता है, और जोखिमों और इस बात के सबूतों की जांच करता है कि व्यवहार संरक्षित रहा। |
| सीमाएँ | स्वीकृत प्रक्रियाओं का पालन करता है, और जानकारी या अधिकार अपर्याप्त होने पर सहायता मांगता है। |
मुख्य बिंदु: 0 का अर्थ है अनुपस्थित या असमर्थित, 1 का अर्थ है प्रासंगिक कमियों के साथ आंशिक, और 2 का अर्थ है पूर्ण और सहमत मानदंडों के अनुसार उचित। गंभीर त्रुटियों को अलग से परिभाषित करें, जैसे कि बिना किसी परीक्षण के व्यवहार में परिवर्तन, ताकि समग्र स्कोर ऐसी त्रुटि को छिपा न सके। यह मूल्यांकन मानदंड एक प्रस्ताव है, मान्य मानक नहीं: इसे इंजीनियरिंग प्रबंधक के साथ अनुकूलित करें और इसका प्रायोगिक परीक्षण करें। उपयोगी प्रतिक्रिया के साथ इंटरैक्टिव अभ्यास को डिज़ाइन करने के लिए हमारी मार्गदर्शिका बताती है कि निर्णयों से संबंधित प्रतिक्रिया कैसे लिखें।
स्थानांतरण की योजना सोच-समझकर बनाएं। अभ्यास के बाद, प्रत्येक इंजीनियर को एक छोटा, वास्तविक कार्य सौंपें जिसे वे समीक्षक के साथ मिलकर हल कर सकें, या हाल ही में किए गए किसी ऐसे बदलाव पर संक्षिप्त समीक्षा करें जिससे कोई समस्या उत्पन्न हुई हो। कार्यशाला के तुरंत बाद नहीं, बल्कि वास्तविक कार्य का उचित अनुभव प्राप्त करने के बाद स्थानांतरण की जांच करें।
जहां इंटरैक्टिव डिलीवरी मददगार होती है
इंटरैक्टिव फॉर्मेट तब मददगार होते हैं जब समूह के सामने आने से पहले सभी को अपनी सहमति देनी होती है। लाइव सेशन में, फैसिलिटेटर एक छोटा सा पुराना कोड दिखा सकता है, प्रत्येक इंजीनियर से पूछ सकता है कि वे पहला बदलाव क्या करेंगे और उसे सुरक्षित कैसे साबित करेंगे, और फिर चर्चा से पहले स्प्रेडशीट दिखा सकता है। तैयारी के लिए इसी प्रक्रिया को सेल्फ-पेस्ड मोड में भी चलाया जा सकता है। AhaSlides इंटरैक्टिव लर्निंग और लाइव व सेल्फ-पेस्ड डिलीवरी के बीच स्विच करने की सुविधा देता है। यह एक प्रेजेंटेशन और लर्निंग टूल है, कोड चलाने या उसका विश्लेषण करने की जगह नहीं, इसलिए रिफैक्टरिंग को अपने खुद के वातावरण में चलाएं। किसी भी विशिष्ट ऑथरिंग, फीडबैक या रिपोर्टिंग फंक्शन की जांच अपने वर्कफ़्लो के अनुसार करें जिस पर आप निर्भर रहने की योजना बना रहे हैं। फॉर्मेट चुनने के बारे में मार्गदर्शन के लिए, हमारा लेख देखें कि एडैप्टिव, इंटरैक्टिव और लाइव लर्निंग का उपयोग कब करना चाहिए ।
जो परिवर्तन हुआ उसे मापें
पहले से ही तय कर लें कि किन बातों से यह साबित होगा कि इंजीनियर कार्य को पूरा कर सकते हैं। जोखिम विश्लेषण की गुणवत्ता और एक अनदेखे मामले में संरक्षित व्यवहार के साक्ष्य की तुलना एक आधारभूत मानक से करें। यह निर्धारित करें कि इसमें कौन-कौन शामिल हैं, आधार क्या है और समय क्या है। यदि परिणाम बेहतर होते हैं, तो प्रशिक्षण का श्रेय देने से पहले यह जांच लें कि उसी अवधि में और क्या-क्या परिवर्तन हुए हैं, जैसे कि नए परीक्षण उपकरण, तेज़ निर्माण या स्वामित्व में परिवर्तन।
वे बाधाएं जो बनी रह सकती हैं
- रखरखाव कार्य का समय। यदि कर्ज के काम की कभी योजना नहीं बनाई जाती है, तो भी प्रशिक्षित इंजीनियरों के पास अपने कौशल का उपयोग करने के लिए कोई जगह नहीं होगी।
- परीक्षण उपकरण। उपयोगी परीक्षण उपकरण या त्वरित निर्माण के बिना, छोटे-छोटे कदम उठाना और बार-बार जांच करना मुश्किल होता है।
- मामले का विवरण। एक पुराने मामले से कुछ प्रकार के जोखिम स्पष्ट होते हैं। स्कोर किसी इंजीनियर के सामान्य निर्णय को नहीं दर्शाता है।
- यह तय करना कि कब रिफैक्टरिंग नहीं करनी है। कुछ कोड को वैसे ही छोड़ देना, बदल देना या हटा देना बेहतर होता है, और इस निर्णय में कौशल से कहीं अधिक चीजें शामिल होती हैं।
- स्थानांतरण। किसी काटा में प्रदर्शन, डिलीवरी के दबाव में उत्पादन मॉड्यूल में प्रदर्शन के समान नहीं होता है।
इन समस्याओं के बारे में प्रायोजकों को पहले ही बता दें और अलग-अलग समाधानों की योजना बनाएं। प्रशिक्षण से इंजीनियर की योजना बनाने और उसे साबित करने की क्षमता में सुधार होता है। इससे समय या उपकरण उपलब्ध नहीं होते।
ज़्यादातर पूछे जाने वाले सवाल
रिफैक्टरिंग प्रशिक्षण परियोजना क्या है?
यह पुराने कोड पर किया जाने वाला एक संरचित अभ्यास है, जिसमें इंजीनियर एक छोटे से बदलाव की योजना बनाते हैं, परीक्षणों के माध्यम से मौजूदा व्यवहार की सुरक्षा करते हैं, डिजाइन को छोटे-छोटे चरणों में बदलते हैं और यह दिखाते हैं कि कुछ भी खराब नहीं हुआ है।
क्या तकनीकी ऋण के बारे में जानने के लिए पूरी तरह से पुनर्लेखन करना एक अच्छा तरीका है?
आमतौर पर नहीं। पुनर्लेखन बड़ा होता है, सत्यापन करना कठिन होता है और इससे वह कौशल छिप जाता है जिसे आप विकसित करना चाहते हैं। सीमित परिवर्तन और वर्तमान व्यवहार को दर्शाने वाले परीक्षण, इसके पीछे के तर्क को स्पष्ट करते हैं।
आप यह आकलन कैसे करते हैं कि इंजीनियर सुरक्षित रूप से रिफैक्टरिंग कर सकते हैं या नहीं?
एक नया लेगेसी-कोड केस दें और जोखिम विश्लेषण तथा व्यवहार के संरक्षण के प्रमाण को सहमत मानदंडों के आधार पर स्कोर करें। रिफैक्टरिंग पैटर्न पर आधारित एक प्रश्नोत्तरी केवल पूर्वापेक्षाओं की पुष्टि करती है।
क्या आपको प्रशिक्षण के लिए सैंपल कोडबेस की आवश्यकता है?
आपको अभ्यास करने के लिए एक सुरक्षित स्थान की आवश्यकता है। कई टीमें सार्वजनिक अभ्यास से शुरुआत करती हैं और फिर अपने स्वयं के कोड के एक सीमित भाग पर आगे बढ़ती हैं। आपके इंजीनियरिंग मैनेजर को यह पुष्टि करनी चाहिए कि कोड उपयुक्त है।
कहा से शुरुवात करे
अपने कोडबेस में मौजूद किसी एक छोटे, बार-बार होने वाले पुराने बदलाव को चुनें। उसका परफॉर्मेंस स्टेटमेंट लिखें, किसी इंजीनियरिंग मैनेजर से उस केस और टेस्ट्स को वैलिडेट करवाएं जिनसे मौजूदा व्यवहार बरकरार रहे, और 0 से 2 के स्केल पर तीन मानदंडों वाला एक रूब्रिक और गंभीर त्रुटियों की एक सूची तैयार करें। इसे लागू करने से पहले एक छोटे समूह के साथ इसका पायलट परीक्षण करें।
यह देखने के लिए कि कैसे रिफैक्टरिंग निर्णय अभ्यास आपकी अपनी टीम के साथ लाइव चलाया जा सकता है, और बाद में स्व-गति से पुन: उपयोग किया जा सकता है, AhaSlides देखें।
