स्प्रिंग प्लेटफॉर्म के साथ काम करते समय 10 सबसे आम त्रुटियां। भाग 1

सभी को नमस्कार। आज हम लेख के पहले भाग को साझा करते हैं, जिसका अनुवाद विशेष रूप से पाठ्यक्रम के छात्रों के लिए तैयार किया गया था "डेवलपर ऑन द स्प्रिंग फ्रेमवर्क" । चलो शुरू हो जाओ!

---

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

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

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

कॉमन मिस्टेक # 1: लो-लेवल प्रोग्रामिंग जाना

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

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

@Getter @Setter @NoArgsConstructor public class Bean implements Serializable { int firstBeanProperty; String secondBeanProperty; } 

जैसा कि आप पहले ही समझ चुके होंगे, उपरोक्त कोड निम्न रूप में परिवर्तित हो गया है:

 public class Bean implements Serializable { private int firstBeanProperty; private String secondBeanProperty; public int getFirstBeanProperty() { return this.firstBeanProperty; } public String getSecondBeanProperty() { return this.secondBeanProperty; } public void setFirstBeanProperty(int firstBeanProperty) { this.firstBeanProperty = firstBeanProperty; } public void setSecondBeanProperty(String secondBeanProperty) { this.secondBeanProperty = secondBeanProperty; } public Bean() { } } 

ध्यान दें कि यदि आप अपने एकीकृत विकास के माहौल में लोम्बोक का उपयोग करना चाहते हैं तो आपको सबसे उपयुक्त प्लग-इन स्थापित करना होगा। IntelliJ IDEA के लिए इस प्लग-इन का संस्करण यहां पाया जा सकता है ।

सामान्य गलती संख्या 2. आंतरिक संरचनाओं की "लीक"

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

 @Entity @NoArgsConstructor @Getter public class TopTalentEntity { @Id @GeneratedValue private Integer id; @Column private String name; public TopTalentEntity(String name) { this.name = name; } } 

मान लें कि एक समापन बिंदु है जिसे किसी TopTalentEntity ऑब्जेक्ट के डेटा तक पहुंचने की आवश्यकता है। TopTalentEntity उदाहरणों को वापस करने के लिए एक आकर्षक विचार लगता है, लेकिन एक अधिक लचीला समाधान एक नया वर्ग बनाना होगा जो API समापन बिंदु के लिए TopTalentEntity डेटा का प्रतिनिधित्व करता है:

 @AllArgsConstructor @NoArgsConstructor @Getter public class TopTalentData { private String name; } 

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

सामान्य गलती संख्या 3. ऐसे फ़ंक्शंस जो कोड में वितरित करना बेहतर होगा

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

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

 @RestController public class TopTalentController { private final TopTalentRepository topTalentRepository; @RequestMapping("/toptal/get") public List<TopTalentData> getTopTalent() { return topTalentRepository.findAll() .stream() .map(this::entityToData) .collect(Collectors.toList()); } private TopTalentData entityToData(TopTalentEntity topTalentEntity) { return new TopTalentData(topTalentEntity.getName()); } } 

पहली नज़र में, ऐसा लगता है कि इस कोड के टुकड़े में कोई स्पष्ट त्रुटियां नहीं हैं। यह TopTalentData ऑब्जेक्ट्स की एक सूची प्रदान करता है, जो TopTalentEntity वर्ग के उदाहरणों से लिया गया है। लेकिन यदि आप कोड को अधिक बारीकी से देखते हैं, तो हम देखेंगे कि वास्तव में TopTalentController यहां कई क्रियाएं करता है, अर्थात्, यह एक विशिष्ट समापन बिंदु के साथ अनुरोधों को सहसंबंधित करता है, रिपॉजिटरी से डेटा को पुनर्प्राप्त करता है और TopTalentRepository रिपॉजिटरी से प्राप्त वस्तुओं को एक अलग प्रारूप में परिवर्तित करता है। एक क्लीनर समाधान को इन कार्यों को अलग-अलग वर्गों में अलग करना चाहिए। उदाहरण के लिए, यह इस तरह दिख सकता है:

 @RestController @RequestMapping("/toptal") @AllArgsConstructor public class TopTalentController { private final TopTalentService topTalentService; @RequestMapping("/get") public List<TopTalentData> getTopTalent() { return topTalentService.getTopTalent(); } } @AllArgsConstructor @Service public class TopTalentService { private final TopTalentRepository topTalentRepository; private final TopTalentEntityConverter topTalentEntityConverter; public List<TopTalentData> getTopTalent() { return topTalentRepository.findAll() .stream() .map(topTalentEntityConverter::toResponse) .collect(Collectors.toList()); } } @Component public class TopTalentEntityConverter { public TopTalentData toResponse(TopTalentEntity topTalentEntity) { return new TopTalentData(topTalentEntity.getName()); } } 

इस पदानुक्रम का एक अतिरिक्त लाभ यह है कि यह हमें यह समझने की अनुमति देता है कि कोई फ़ंक्शन क्लास के नाम को देखकर कहाँ स्थित है। इसके बाद, परीक्षण के दौरान, हम आसानी से सरोगेट कोड के साथ इनमें से किसी भी वर्ग के कोड को बदल सकते हैं, यदि आवश्यकता होती है।

सामान्य गलती संख्या 4. यूनिफ़ॉर्म कोड और खराब त्रुटि हैंडलिंग

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

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

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

 @Value public class ErrorResponse { private Integer errorCode; private String errorMessage; } 

इसके समान एक प्रारूप अक्सर सबसे लोकप्रिय एपीआई में पाया जाता है और, एक नियम के रूप में, महान काम करता है क्योंकि इसे आसानी से और व्यवस्थित रूप से प्रलेखित किया जा सकता है। आप इस प्रारूप के अपवाद को विधि में @ExceptionHandler एनोटेशन जोड़कर (एनोटेशन के उदाहरण के लिए, "सामान्य गलती # 6" अनुभाग देखें) में परिवर्तित कर सकते हैं।

सामान्य गलती संख्या 5. मल्टीथ्रेडिंग के साथ गलत काम

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

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

वैश्विक राज्यों के उपयोग से बचें

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

उत्परिवर्तित वस्तुओं से बचें

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

महत्वपूर्ण डेटा लॉग करें

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

तैयार धागा कार्यान्वयन का उपयोग करें

जब आपको अपने थ्रेड स्पॉन करने की आवश्यकता होती है (उदाहरण के लिए, विभिन्न सेवाओं के लिए अतुल्यकालिक अनुरोध बनाने के लिए), तो अपना खुद का बनाने के बजाय तैयार किए गए सुरक्षित थ्रेड कार्यान्वयन का उपयोग करें। ज्यादातर मामलों में, आप थ्रेड बनाने के लिए ExecutorService एब्स्ट्रक्शन और Java 8 के लिए शानदार फंक्शनल एब्सट्रैक्टफुलटेबल का उपयोग कर सकते हैं। स्प्रिंग प्लेटफॉर्म आपको DeferredResult क्लास का उपयोग करके अतुल्यकालिक अनुरोधों को संभालने की भी अनुमति देता है।

पहले भाग का अंत।
दूसरा भाग पढ़ें