एक सफल क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट के लिए पाँच नियम

अनुवादक से: मैं अब क्रॉस-प्लेटफ़ॉर्म सॉफ़्टवेयर डिज़ाइन पर थोड़ा सा साहित्य एकत्र कर रहा हूँ। यह लघु पाठ सबसे दिलचस्प है जो मैंने अब तक पाया है।

एन्कोडर के लिए Google एक विशिष्ट सुविधा को लागू करने के लिए पर्याप्त है, लेकिन क्या डिजाइन की विशेष आवश्यकताएं हैं? मान लीजिए कि तरीकों में #ifdef ब्रांचिंग किसी प्रोजेक्ट के प्लेटफ़ॉर्म-विशिष्ट भागों को उजागर करने का एकमात्र तरीका है? (क्या पास्ता की अधिकता नहीं है?) क्या कोई उच्च स्तरीय दृष्टिकोण, टेम्पलेट, # एड-ऑन पर "ऐड-ऑन" हैं ? मुझे उम्मीद है कि यह पोस्ट आगे की चर्चा के लिए भोजन का काम करती है।

क्रॉस-प्लेटफॉर्म विकास के अनुभव से, मैंने कुछ सरल सिद्धांत सीखे, जिनका अनुसरण करने से आम जाल से बचने में मदद मिलेगी।

1. MVC की अवधारणा में अपना एप्लिकेशन विकसित करें। शायद यह क्रॉस-प्लेटफॉर्म प्रोजेक्ट की सफलता की मुख्य कुंजी है।
   
2. बहुत शुरुआत से, दो कमांड आपके लिए काम करना चाहिए: विंडोज और मैक के लिए। दोनों समूहों का अनुभव डिजाइन और कार्यान्वयन के शुरुआती चरणों में पहले से ही आवश्यक है, अगर आप गंभीरता से क्रॉस-प्लेटफॉर्म पर केंद्रित हैं। ¹
   
3. VCS में कोड की एक शाखा का उपयोग करें। व्यक्तिगत शाखाएं अक्सर नियंत्रण से बाहर हो जाती हैं और अब सिंक्रनाइज़ नहीं होती हैं। ² एक विशिष्ट मंच के लिए कोड करने के लिए #ifdef का उपयोग करें।
   
4. ANSI मानकों के अनुरूप C / C ++ कोड लिखें; मानक एएनएसआई और एसटीएल पुस्तकालयों का उपयोग करें। कई क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट कई कंपाइलर्स का उपयोग करते हैं, इसलिए कंपाइलर त्रुटियों और चेतावनियों को कम करना महत्वपूर्ण है। इसे उच्च चेतावनी स्तर शामिल करने के लिए एक नियम बनाएं और जांचें कि सभी कोड में कोई चेतावनी नहीं है।
   
5. अपने मैक और पीसी को प्रत्येक डेवलपर की टेबल पर रखें। समय-समय पर, एक स्थिति उत्पन्न होगी जब एक मंच के लिए एक डेवलपर यह देखना चाहता है कि उसके कोड ने दूसरे प्लेटफ़ॉर्म को कैसे प्रभावित किया। यदि डेवलपर के पास किसी अन्य मशीन तक आसान पहुंच नहीं है, तो संभावना है कि उसकी प्रतिबद्धता किसी अन्य प्लेटफ़ॉर्म के बढ़ने पर एप्लिकेशन को तोड़ देगी।
   

नोट

[१] यह महत्वपूर्ण बिंदु उस टीम में छूट गया जहाँ मैंने १ ९९९ में काम किया था। यह परियोजना MVC पर अच्छी तरह से बनाई गई थी। मॉडल एक सी ++ डीएलएल है, प्रस्तुति जेएनआई के माध्यम से स्विंग है, सब कुछ मैक ओएस और विंडोज के लिए कोडवेयर में लिखा गया है। अच्छा लगता है अब तक, है ना? और इसलिए, विंडोज टीम ने परियोजना को पहले बनाया और मैकिंटोश टीम को दिया। फिर यह पता चला कि यह एप्लिकेशन जावा 2 विनिर्देशन में लिखा गया था, जो तब मैक पर समर्थित नहीं था। आगे - और: स्रोत फ़ाइल नाम 31 वर्णों की खोजक सीमा से अधिक हो गया, प्रोजेक्ट फ़ाइलें टूटी # शामिल होने के कारण संकलित नहीं हुईं ... प्रबंधन ने परियोजना को दो शाखाओं में विभाजित करने का निर्णय लिया, जिनमें से प्रत्येक ने अनावश्यक क्रॉस-प्लेटफ़ॉर्म कोड का एक गुच्छा छोड़ दिया। अगर हम मैक डेवलपर्स को शुरू से ही टीम की सलाह देते तो इन नुकसानों से बचा जा सकता था। ^

[२] मैंने एक बार एक परियोजना का नेतृत्व किया, और हमारे प्रबंधन ने पहले मैक संस्करण को लॉन्च करने के लिए कोड को कांटा करने का फैसला किया। हालांकि इस फैसले से कई महीने बच गए, लेकिन दोनों शाखाओं को फिर से मिलाने में एक और साल लग गया। ^

निष्कर्ष (अनुवादक से)

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

हम मैक और लिनक्स पर एमएफसी एप्लिकेशन को फिर से लिखेंगे, और जीयूआई को HTML5 / WebKit में फिर से लिखा जाएगा। यह हमारे लिए पहली ऐसी परियोजना है, मैं अधिकतम संख्या में रेक से बचना चाहूंगा ... कृपया अपना अनुभव साझा करें! मेरे भाग के लिए, परिणामों के अनुसार, मैं हेब्रा को लिखूंगा