8 प्रोग्रामिंग नुकसान

इस लेख में उन प्रोग्रामिंग ट्रैप को शामिल किया गया है जो मैं अपने आप में गिर गया हूं, लगातार गिरता जा रहा हूं और शायद कभी रुकेगा नहीं, साथ ही साथ जिन लोगों में मुझे अपने साथी मिले।

हालांकि, मेरा मानना ​​है कि यदि आप जानते हैं कि आप किस जाल में गिर सकते हैं और उनसे कैसे बाहर निकल सकते हैं तो उन्हें टाला जा सकता है। शायद यह विश्वास एक और जाल है।

संक्षिप्त परिचय

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

प्रोग्रामिंग में, आप भी फंस सकते हैं। लेकिन अगर हम गड्ढे को एक सादृश्य के रूप में लेते हैं, तो यह 50 मीटर गहरा होगा और ऊपर से एक भारी स्टील प्लेट के साथ कवर किया जाएगा।

आप क्या सोचते हैं, आप कब तक ऐसे गड्ढे में रहेंगे?

सबसे अधिक संभावना है जब तक कोई आपको वहां नहीं पाता है!

लेकिन यह इतनी बड़ी समस्या नहीं है, आप हर प्रोग्रामिंग ट्रैप से बाहर निकल सकते हैं और लगभग कोई बाहरी प्रयास नहीं है - आपको बस तीन चीजों को जानने की जरूरत है: आप किस ट्रैप में हैं, आप वहां कैसे पहुंचे और "गुप्त दरवाजा" किस तरह से बाहर है।

प्रोग्रामिंग ट्रैप्स में एक आश्चर्यजनक बात है - लगभग हर ट्रैप दो विपरीत छोरों में से एक के लिए एक प्रतिबद्धता है, और ट्रैप से बाहर निकलने का मतलब है उनके बीच कुशलता से संतुलन बनाना।

हम कह सकते हैं कि जाल से बचने के लिए एक संकीर्ण मार्ग चल रहा है, जहां बाईं तरफ समस्याएं हैं, और दाईं ओर उन्हें हल करने के तरीके हैं, जिन्हें बेतुकी बात पर लाया जाता है।

ठीक है, कोई भी वैसे भी परिचय नहीं पढ़ता है, इसलिए चलो!

---

ट्रैप # 1: अनुकूलन

जैसा कि नॉट ने लिखा है, समयपूर्व अनुकूलन सभी बुराई की जड़ है। बहुत से लोग इस नियम को जानते हैं, कुछ इसका पालन नहीं करते हैं, कुछ इसे पूर्णता तक बढ़ाते हैं, लेकिन कुछ लोग जानते हैं कि बेल्टेड ऑप्टिमाइज़ेशन और भी बदतर है!

अनुकूलन पर बहुत अधिक ध्यान केंद्रित करें

ओलंपिक के रूप में अक्सर इस प्रकार के प्रोग्रामर पाप करते हैं। प्रभावी एल्गोरिदम या प्रोसेसर की आंतरिक संरचना का ज्ञान उन्हें लगता है कि कोड यथासंभव कुशल होना चाहिए।

व्यवहार में, अनुकूलन में बहुत अधिक समय लगता है, कोड पूरी तरह से असमर्थित, गैर-एक्स्टेंसिबल और त्रुटि-प्रतिरोधी हो जाता है।

संकेत हैं कि आप फंस गए हैं

• तेज / संसाधन-कम कोड को तुरंत लिखने का प्रयास
• कोड से बाहर सब कुछ निचोड़ने की इच्छा, अन्य संकेतकों की गिरावट के लिए
विश्वास है कि O (n) के बजाय O (n) {2}) या बिटवाइड शिफ्ट के साथ 2 से गुणा करने के सभी कार्यों को बदलने से कैंडी को प्रोग्राम से बाहर कर दिया जाएगा

अनुकूलन बहुत कम ध्यान केंद्रित करता है

मेरी अभी भी अधूरी परियोजनाओं में से एक समाप्त हो रही है। समय से पहले अनुकूलन की त्रुटि से बचने की कोशिश करते हुए, अनुकूलन को अंत तक भुला दिया गया - अंतिम (तबादला, यदि पूरी तरह से ईमानदार होने के लिए) मंच पर स्थानांतरित कर दिया गया।

अब, जब आधे से अधिक तैयार हो गया है, मुझे एहसास हुआ - एक जाल से बचने की कोशिश कर रहा है, मैं इसके विपरीत गिर गया!

अब, एक स्वीकार्य स्तर तक प्रदर्शन में सुधार करने के लिए, आपको केवल प्रोफाइलर को एक-दो बार नहीं चलाना होगा और फ़ंक्शन में अलग-अलग एल्गोरिदम को ठीक करना होगा, आपको पहले से लिखे गए कोड के कम से कम एक तिहाई को फिर से लिखना होगा!

इस जाल को कहा जाता है - बेलगाम अनुकूलन, यदि आप अग्रिम में अनुकूलन की संभावना के लिए प्रदान नहीं करते हैं, तो इस तथ्य के लिए तैयार रहें कि आपके सुंदर और समझने योग्य कोड का एक महत्वपूर्ण हिस्सा बाहर फेंकना होगा!

संकेत हैं कि आप फंस गए हैं

• ईमानदारी से विश्वास है कि किसी भी अनुकूलन समय से पहले है
• परियोजना के अंतिम भाग में देरी का अनुकूलन
• भविष्य के अनुकूलन के लिए कुछ छोटे वास्तु समाधान प्रदान करने में विफलता

निकास

• कोड को अभी से ऑप्टिमाइज़ करने की कोशिश न करें - भविष्य के अनुकूलन के अवसर बनाएँ
• बिना किसी कारण के अनुकूलन में देरी न करें
• नियम 20/80: कोड के उन 20% पर अपना समय व्यतीत करें जो 80% परिणाम देगा (हाँ, प्रोफाइलर का उपयोग करें)

---

ट्रैप # 2: अमूर्तता

प्रोग्रामिंग में अमूर्तता शायद सबसे अच्छी बात है। सबसे पहले, बाइनरी कोड थे, फिर प्रोसेसर निर्देशों के mnemonics, फिर अनिवार्य प्रोग्रामिंग - राज्य और संचालन (स्टेटमेंट), फिर संरचनात्मक, प्रक्रियात्मक, मॉड्यूलर, ऑब्जेक्ट-उन्मुख, कार्यात्मक प्रोग्रामिंग।

कल्पना करें कि लूप को व्यवस्थित करने के लिए आपको अभी भी गोटो का उपयोग करने की आवश्यकता है।

कल्पना करें कि आपको अभी भी वही फ़ंक्शन उत्पन्न करने की आवश्यकता है जो केवल डेटा के प्रकार (डायनामिक टाइपिंग और टेम्प्लेट / जेनरिक का लाभ लेने के बजाय) में भिन्न हो।

कल्पना करें कि आप केवल संग्रह नहीं ले सकते हैं और उसका आकार बदल सकते हैं - आपको एक नया मेमोरी आवंटित करने की आवश्यकता है, वहां पुराने संग्रह को कॉपी करें, एक नया तत्व जोड़ें, अप्रयुक्त मेमोरी को मुक्त करें।

अत्यधिक जटिलता

फिर से, हम एक ऐसे जाल से शुरू करते हैं, जहाँ दुनिया की हर चीज़ को अमूर्त करने का प्रयास किया जाता है।

20 वर्गों को ढेर करें, 12 अलग-अलग पैटर्न का उपयोग करें, एक और डीएसएल को पार्स करने के लिए अपने डीएसएल को लागू करें, एक और टेट्रिस बनाने के लिए चक्रीय रेखांकन की कल्पना के लिए एक क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क बनाएं - यह "एब्सट्रैक्शन के चैंपियन" के बारे में है।

संकेत हैं कि आप फंस गए हैं

• बुनियादी कार्यक्षमता को लागू करने से पहले एक सार्वभौमिक रूपरेखा लिखना, इसके अलावा, इसका उपयोग लिखित कोड के 30% के बल पर किया जाएगा
• किसी भी समस्या से बाहर निकलने का सबसे अच्छा तरीका यह है कि किसी तरह के पैटर्न का इस्तेमाल किया जाए
• सबसे सामान्यीकृत लेखन, दुनिया में सब कुछ स्वीकार करना और किसी विशेष के बजाय किसी फ़ंक्शन के इनपुट मूल्यों के लिए सही परिणाम देना, भले ही इसकी कार्यक्षमता का उपयोग कभी नहीं किया जाएगा।

अनंत का सरलीकरण

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

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

संकेत हैं कि आप फंस गए हैं

इस आइटम के लिए, सामान्य विशेषताओं को चुनना मुश्किल है - यह सब भाषा, कार्य और अन्य कारकों के एक समूह पर निर्भर करता है, लेकिन:

• अमूर्तता को अनदेखा करना जो कोड को बेहतर ढंग से सुधार सकता है (उदाहरण के लिए, C ++ में पुनरावृत्तियाँ, हास्केल में मठवासी (मेरा मतलब है कि मैं अपने मठ को लिखने से इनकार कर रहा हूं, जहां यह समझ में आता है), पायथन में जनरेटर, जावा में इंटरफेस, आदि)
• जब एक नई प्रोग्रामिंग भाषा पर स्विच करना - उसके अमूर्त अध्ययन का खंडन करना, क्योंकि यह उनके बिना एक अच्छा जीवन था (फिर से, एक उदाहरण - जब C से C ++ में स्विच करना - पुनरावृत्तियों को सीखने से इनकार करना, जब एक अनिवार्य भाषा से Haskell पर स्विच करना - मना करना सीखने के मठों से)
• यह विश्वास कि भाषा की वे विशेषताएं जो आप वास्तव में उपयोग नहीं करते हैं, वे बहुत ही शानदार हैं (सी ++ प्रोग्रामर पर लागू नहीं होती हैं; मजाक बेशक है, लेकिन जैसा कि हर मजाक में जाना जाता है ...)

निकास

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

---

ट्रैप # 3: पूर्णतावाद

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

उत्कृष्टता के लिए प्रयत्नशील

मेरे सामने इस विषय पर सब कुछ चबाया गया था, हालांकि, मैं लगातार रहना चाहता हूं, इसलिए मैं हड्डियों द्वारा इस जाल का विश्लेषण भी करूंगा।

संकेत हैं कि आप फंस गए हैं

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

अराजकता का रास्ता

पिछली सूची से यह स्पष्ट है कि पूर्णतावाद एक खतरनाक जाल है, क्या इसे पूरी तरह से छोड़ दिया जा सकता है?

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

इसलिए, उत्कृष्टता के अपने पीछा की एक पूरी अस्वीकृति आपको पूरी तरह से विपरीत जाल में चलाएगी।

संकेत हैं कि आप फंस गए हैं

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

निकास

हमेशा कहीं बीच में:

• स्वीकार करें कि कोड की सुंदरता और परिणाम की उपलब्धि महत्वपूर्ण है, कभी-कभी दूसरा और भी महत्वपूर्ण होता है
• एक अंतिम उपाय के रूप में खरोंच से पुनर्लेखन पर विचार करें, लेकिन स्वीकार करें कि यह आवश्यक हो सकता है।
• अपने आप को अधिकतम समय दें जो आप रिफैक्टरिंग पर खर्च कर सकते हैं। यह पूरे काम के समय का 20, 50, यहां तक ​​कि 80% भी हो सकता है, मुख्य बात यह है कि इसे कभी भी अधिक न करें, ताकि अटक न जाए
• जब आपको कोई दोष पता चलता है, तो विचार करें कि क्या यह पर्याप्त है कि इसे ठीक करने में समय व्यतीत हो।
• 20/80 नियम का उपयोग करें - सबसे पहले उन 20% कार्यों को करने का प्रयास करें जो 80% परिणाम लाएगा

मुझे उम्मीद है कि ये टिप्स हब्रोस्क लोगों के लिए पूर्णतावाद जाल से बाहर निकलने में मदद करेंगे। उन सभी को इस बीमारी से निपटने के कड़वे अनुभव के माध्यम से समझा गया था और शाब्दिक रूप से उस समय के लिए पीड़ित था जब मैं प्रोग्रामिंग कर रहा था।

---

ट्रैप # 4: प्रौद्योगिकी और उपकरण

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

हालांकि, कभी-कभी उनका उपयोग या तो अक्सर या बहुत कम ही किया जाता है। पहले मामले के साथ फिर से शुरू करते हैं।

आलस

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

एक साथ बढ़ावा देना, क्यूटी और सक्रिय रूप से एसटीएल का उपयोग करना जब हैलो वर्ल्ड लिखना एक अच्छा विचार नहीं है, लेकिन कभी-कभी इसी तरह की चीजें होती हैं और यह एक और जाल है।

संकेत हैं कि आप फंस गए हैं

• मेर्सन बवंडर की खातिर 30+ मेगाबाइट की एक लाइब्रेरी को जोड़ना
• विश्वास करें कि आपकी ज़रूरत की हर चीज़ पहले ही लिखी जा चुकी है
• यह स्वीकार नहीं करना कि एक बाइक बेहतर हो सकती है
• आईडीई में ऑटो-पूरा किए बिना कोड लिखने और लाइनों की अक्षमता
• उपकरण का सक्रिय उपयोग, उनके काम के सिद्धांतों को समझे बिना। उदाहरण के लिए, GUI दृश्य संपादन टूल (जैसे Qt Creator, CodeGear Rad Studio, MS Visual Studio) का लगातार उपयोग और, एक ही समय में, उनके डिवाइस का पता लगाने की कोशिश करने से इनकार करना

workaholism

क्या इसका मतलब यह है कि मैं सभी को सभी उपकरणों और पुस्तकालयों के उपयोग को छोड़ने का आग्रह करता हूं, नैनो में अपनी बाइक के साथ नंगे कोड लिखने का आग्रह करता हूं (या इससे भी बदतर - पेपिरस पर)?

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

संकेत हैं कि आप फंस गए हैं

• बिना किसी अच्छे कारण के अधिक से अधिक साइकिल का नियमित लेखन।
• विश्वास करें कि भाषा की क्षमता और मानक पुस्तकालय हर चीज के लिए पर्याप्त होना चाहिए
• यह विश्वास कि स्वतः पूर्णता (उदात्त पाठ में नहीं, बल्कि IDE की तरह) स्केलेरकोटिक्स के लिए है
• अपनी खुद की लाइब्रेरी लिखना, भले ही राक्षसी हो, लेकिन मौजूदा एनालॉग्स की कार्यक्षमता में भी करीब नहीं है
• ऐसे डिबगर्स और प्रोफाइलर्स के लिए स्टेटमेंट की जरूरत होती है, जो यह नहीं समझते कि उनका अपना कोड कैसे काम करता है

निकास

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

---

ट्रैप # 5: द गोल्डन हैमर

हमारे ट्रैप चार्ट में एक और बिंदु स्वर्ण हथौड़ा है।

गोल्डन हैमर एक बुरी आदत है। कई समस्याओं को हल करने के बाद एक विधि ने काम किया है, एक फंस व्यक्ति इस पद्धति का उपयोग करना शुरू कर देता है जहाँ भी संभव हो!

कई समान शब्द हैं - रामबाण, जादू की गोली, चांदी की गोली, यानी। एक विधि जो हमेशा 100% मामलों में, किसी भी कार्य को करती है। इस विषय में एक और कहावत है कि खुर्दबीन के साथ नाखूनों में हथौड़ा चलाना।

गोल्डन हैमर काफी सामान्य है, लेकिन अन्य जाल के विपरीत है। कुछ भी एक सुनहरा हथौड़ा हो सकता है, कोई ओओपी के साथ प्यार में पड़ सकता है और हर किसी के लिए कक्षाएं लिख सकता है, किसी को डिजाइन पैटर्न में और केवल कारखानों और एकल से एक कार्यक्रम बना सकता है।

कुछ के लिए, सुनहरा हथौड़ा एक पसंदीदा प्रोग्रामिंग भाषा है, कुछ के लिए, एक पसंदीदा प्रतिमान, कुछ के लिए, एक विकास पद्धति।

मुख्य चीज जो स्वर्ण हथौड़ा को अलग करती है वह हमेशा और हर जगह इसका उपयोग करने का प्रयास है।

संकेत हैं कि आप फंस गए हैं

• सभी कार्यों के लिए एक प्रोग्रामिंग भाषा का उपयोग करना
• विश्वास है कि एक प्रतिमान सभी प्रोग्रामिंग समस्याओं को हल कर सकता है (ज्यादातर वे कहते हैं कि OOP और FP के बारे में)
• सभी परियोजनाओं के लिए उपयोग, एक विकास पद्धति की शर्तों की परवाह किए बिना, उदाहरण के लिए, सभी परियोजनाओं में TDD का विचारहीन उपयोग
• उदाहरण के लिए, अधिकांश कार्यों के लिए भाषा द्वारा प्रदान किए गए उपकरण का उपयोग:
- केवल निरंतर लिंक द्वारा सभी तर्कों को पास करना
- पूरे कार्यक्रम में केवल एक ही प्रकार के संग्रह का उपयोग, एरेज़ (वैक्टर) कहें
- हर जगह गैर-अस्पष्ट वस्तुओं का उपयोग
- समान सिंटैक्स भाषाओं में उपयोग करें (उदा। जावा और C)
एक ही इंडेंटेशन स्टाइल और एंटिटी नामकरण विधि

चांदी की गोली मौजूद नहीं है

मुझे डर है कि यह जाल नियम का एक अपवाद है और एक दूसरे में गिरने के बिना इसे टालना संभव है।

मेरे द्वारा देखे गए पैटर्न के इस अपवाद से एक बार फिर साबित होता है कि सुनहरा हथौड़ा मौजूद नहीं है - जाल को एक दोहरी इकाई के रूप में वर्णन करने की मेरी विधि गलत है, लेकिन मैं इसका इस्तेमाल करने से इनकार करने से डरता नहीं हूं।

यह अपने आप को इस जाल से मुक्त करने का सही तरीका है।

निकास

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

---

ट्रैप # 6: क्रॉस-प्लेटफ़ॉर्म

क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन वे हैं जो कई ऑपरेटिंग सिस्टम और / या कई प्लेटफार्मों पर चलते हैं।

और यहां फिर से दो चरम सीमाएं हैं - कुछ डेवलपर्स एक आवेदन लिखने की कोशिश कर रहे हैं ताकि यह सभी संभव ओएस पर काम करे और पीसी और टैबलेट के लिए और स्मार्टफोन के लिए समान रूप से अच्छी तरह से अनुकूल हो।

सबके लिए और सबके लिए

अक्सर लोग क्रॉस-प्लेटफॉर्म की एक अविश्वसनीय डिग्री प्राप्त करना चाहते हैं।

नतीजतन, यह पता चला है कि एप्लिकेशन किसी भी ओएस पर पूरी तरह से सही ढंग से काम नहीं करता है और पीसी और टैबलेट पर और स्मार्टफोन पर इसका उपयोग करना उतना ही असुविधाजनक है!

वे अत्यधिक क्रॉस-प्लेटफॉर्म में फंस गए हैं!

संकेत हैं कि आप फंस गए हैं

• विश्वास है कि आप उन कोड को लिख सकते हैं जो बिना किसी बदलाव के सभी लक्ष्य प्लेटफार्मों पर स्वीकार्य परिणाम तैयार करते हैं
पोर्टिंग में संलग्न होने और कोड के कम से कम हिस्से को बदलने के लिए नहीं चाहते हुए भी कई ऑपरेटिंग सिस्टम और प्लेटफार्मों को कवर करने का प्रयास।
• किसी भी कोड का केवल एक ही प्लेटफ़ॉर्म के लिए इरादा

केवल Win32 है

और इसके विपरीत - कुछ प्रोग्रामर सॉफ्टवेयर लिखते हैं जो केवल ओएस पर चलता है जैसे कि लेखक, इसके अलावा, आपको ठीक उसी माउस, कीबोर्ड और वर्चुअल रियलिटी हेलमेट की आवश्यकता है।

अक्सर इसका कारण सिर्फ यह है कि प्रोग्रामर इस तथ्य के बारे में नहीं सोचता है कि उनके उपयोग के अलावा अन्य ओएस और प्लेटफॉर्म भी हैं।

संकेत हैं कि आप फंस गए हैं

• प्रत्येक लक्ष्य ओएस / मंच के लिए आवेदन कोड के सभी (या अधिकांश) को फिर से लिखना
• जानबूझकर कठिन-से-पोर्ट कोड लिखना जहां इससे बचा जा सकता है
• कस्टम कंपाइलर / दुभाषिया एक्सटेंशन का उपयोग करना

निकास

• ध्यान से लक्ष्य ओएस / प्लेटफार्मों की पहचान करें
• इस तथ्य के लिए तैयार रहें कि कुछ ओएस / प्लेटफार्मों के लिए आपको कोड का हिस्सा बदलना होगा या यहां तक ​​कि खरोंच से एक अलग संस्करण लिखना होगा
• कोड को उद्देश्य से एक मंच पर न बांधें
• यदि यह विकास को मुश्किल बनाता है तो कई प्लेटफार्मों को फैलाने का प्रयास करें

---

ट्रैप # 7: रक्षा

() — , ( ).

— , , , , , null .

, , — . .

,

• ,
• /
• ,
• ,
• ,

, 15 ASSERT' , , , .

— .

,

•
• ,
• MyProjectException 10 ,
• ,
• -

• ,
•
• -
•
• , ,
• , -

---

№8:

, - .

, - , — TODO, HACK, .

, TODO .

,

• TODO HACK
• Code Review , TODO WTF
• , - ( TODO) ( FIX HACK)

, - , ( , “TODO: check argument to null”).

, , , , — .

— TODO HACK , , — .

, , - , — .

, .

,

• TODO ,
• , ,
• ,

• TODO ,
• ,
• ,
• — TODO
• , ,

---

संदर्भ

• AlenaC++:
• Wordpresse:

• Habrahabr:
• Habrahabr: 5
• Habrahabr: , ,
• Habrahabr: : ,
• Habrahabr: ,
• Habrahabr: —
• Habrahabr: : ?
• Habrahabr:

• Wikipedia: KISS
• Wikipedia: YAGNY
• Wikipedia: DRY
• Wikipedia:
• Wikipedia:
• Wikipedia:

एक निष्कर्ष के बजाय

!