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