मैं सिम्फनी पर अपना पहला प्रोजेक्ट कैसे देखना चाहूंगा

पिछले डेढ़ साल से, मैं वेब एप्लिकेशन विकसित करने के लिए सिम्फनी 2 का उपयोग कर रहा हूं। इस समय के दौरान, मैंने तीन बार एक नई परियोजना शुरू की, तीन और परियोजनाओं में विरासत कोड पर काम किया, और ढांचे के ज्ञान के लिए लगभग 15 परीक्षण कार्यों की समीक्षा भी की।

यह संभवत: डेढ़ साल पहले वापस जाने और अपनी पहली परियोजना शुरू करने से पहले खुद को कुछ सलाह देने के लिए बहुत अच्छा होगा। काश, यह असंभव है। लेकिन शायद मेरी सलाह अन्य नौसिखिया सिम्फनी डेवलपर्स के लिए काम आ सकती है?

कोड शैली और नामकरण सम्मेलनों का पालन करें

मैं हजारवीं बार कोड शैली के महत्व के बारे में बात नहीं करूंगा, लेकिन अधिकांश शुरुआती डेवलपर्स इसका अनुपालन नहीं करते हैं।

सौभाग्य से, इस समस्या को ठीक करना आसान है। आधुनिक आईडीई स्वचालित रूप से चयनित नियमों के अनुसार कोड को प्रारूपित कर सकते हैं। मैं वर्तमान में PHPStorm का उपयोग कर रहा हूं। सिम्फनी के लिए पूर्वनिर्धारित सेटिंग्स हैं, और उपयोग के बयान के स्वत: परिवर्धन, और कई और अच्छे।

अगर हम कोडिंग मानकों के बारे में बात करते हैं, तो हम Fabien Potencier से PHP CS फिक्सर का उल्लेख नहीं कर सकते हैं। PHP CS फिक्सर थोड़ी देर के बाद आपका अवश्य ही टूल बन जाएगा।

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

वसा नियंत्रक मत बनाओ

मोटी बेवकूफ बदसूरत नियंत्रक (TTUK), दूसरी सबसे लोकप्रिय त्रुटि जो एक नौसिखिया डेवलपर के कोड में होती है। मोटे नियंत्रकों के बारे में बहुत कुछ लिखा गया है। संक्षेप में, नियंत्रक सामान्य मामले में पुन: प्रयोज्य सॉफ्टवेयर मॉड्यूल नहीं हैं। इसलिए, व्यावसायिक तर्क को यहां न रखें। नियंत्रकों में तर्क DRY सिद्धांत का उल्लंघन करता है और कॉपी-पेस्ट को भड़काता है। कहीं भी, मॉडल के लिए व्यावसायिक तर्क को लेयर लेयर पर ले जाएं। एक नया वर्ग, सेवा, विधि बनाने के लिए स्वतंत्र महसूस करें, टीटूकी करने के लिए स्वतंत्र महसूस करें।

कंटेनर पर निर्भर सेवाएं न करें

सबसे अच्छा, यह भूल जाते हैं कि ऐसा अवसर बिल्कुल मौजूद है। जिस क्षण आप कंटेनर-निर्भर सेवा बनाते हैं, आप यह नियंत्रित करने के लिए संघर्ष करेंगे कि इसमें क्या हो रहा है। और अगर आप पूरे कंटेनर को सेवा में लागू करना चाहते हैं, सिर्फ इसलिए कि यह निर्भरता से "सूज" जाता है, तो सबसे अधिक संभावना है कि आपको वास्तुकला के साथ समस्या है। सेवा में कंटेनर आपको एकल जिम्मेदारी सिद्धांत का उल्लंघन करने के लिए उकसाएगा और किसी भी तरह से सही डिजाइन के निर्माण में योगदान नहीं करेगा। कंटेनर जागरूक सेवाओं का परीक्षण करना कठिन होगा। और अगर आप इस तरह के वर्ग के आधार पर एक पदानुक्रम शुरू करते हैं, तो यह भी रिफलेक्टर करना मुश्किल होगा।

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

कोड को यथासंभव सरल लिखें

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

दूसरे, सार्वजनिक वर्ग एपीआई को यथासंभव सरल बनाएं। दूसरे शब्दों में, आपको कक्षा के सार्वजनिक तरीके नहीं बनाने चाहिए, जिनका आप अभी उपयोग नहीं करेंगे।

तीसरा, वे विधियाँ और गुण बनाएँ, जो डिफ़ॉल्ट रूप से एक सार्वजनिक वर्ग एपीआई निजी नहीं हैं। यदि आप किसी विधि या संपत्ति को ओवरलैप करने के लिए आवश्यक हो जाते हैं, तो आप हमेशा दायरा बदल सकते हैं। लेकिन जब कोई अन्य प्रोग्रामर आपके कोड को पढ़ता है, तो वह एक सौ प्रतिशत सुनिश्चित होगा कि इस पद्धति का उपयोग कहीं और नहीं किया गया है।

चौथा, अब लागू न करें कि कल क्या उपयोग किया जाएगा। अभ्यास से पता चलता है कि यह भूतिया कल कभी नहीं आ सकता है। हां, आप कभी यह नहीं कह पाएंगे कि परियोजना की आवश्यकताएं कैसे बदलेंगी। तो अब परियोजना को जटिल क्यों करें? आपको अतिरिक्त काम करने की आवश्यकता क्यों है?

ठीक है, और पांचवीं, एक छोटी सी सुविधा के लिए, परियोजना में पूरे बंडलों को शामिल न करें। उदाहरण के लिए, नियंत्रक में से एक में JSON को वापस करने के लिए आपको FOSRestBundle की आवश्यकता नहीं है।

टिप्पणियों का दुरुपयोग न करें

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

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

समझें कि सिद्धांत कैसे काम करता है।

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

ट्विग की सभी विशेषताओं का उपयोग करें

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

अपवादों का बुद्धिमानी से उपयोग करें

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

विन्यास को भारी मत बनाओ

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

अपनी परियोजना निर्भरता को अधिक बार अपडेट करें

यदि संभव हो तो बंडलों के स्थिर संस्करणों का उपयोग करें। यदि नहीं, तो जितनी बार संभव हो अपनी निर्भरता को अपडेट करें। प्रकट होते ही त्रुटियों को ठीक किया जाता है। जब आप बहुत सारे अपडेट एकत्र करते हैं, तो सभी असंगति समस्याओं को समाप्त करना अधिक कठिन होगा।

परीक्षण लिखिए

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

PHPUnit में इकाई परीक्षण लिखें। कम से कम सबसे जटिल और सबसे महत्वपूर्ण तरीकों के लिए। कोड से पहले परीक्षण लिखें, इससे आप बेहतर डिजाइन बना पाएंगे। इकाई परीक्षणों से लाभ कोड में बग्स और प्रतिगमन की अनुपस्थिति में होगा।

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

कुछ लिंक:

• सिम्फनी कोड स्टाइल
  
• टूटी हुई विंडोज का सिद्धांत
  
• मूल लेख "एम एम इन एमवीसी: व्हाई मॉडल्स मिसअंडरस्टूड एंड अनपैग्रेटेड" पडरैड ब्रैडी द्वारा और हैब्रीज़र वॉनडिर द्वारा लेख का एक अच्छा अनुवाद । यदि आप विकिपीडिया को मानते हैं, तो यह पहली बार इस लेख में है कि वसा नियंत्रकों का उल्लेख किया गया है।
  
• डीआई के "उचित" उपयोग पर अच्छा लेख
  
• सिद्धांत के "अधिकार" पर वीडियो का उपयोग करें