🙋🏻 🧚🏼 👩🏿‍🔧 रिफैक्टिंग का अभ्यास। स्पष्ट कार्य ↘️ 🏘️ 🚘

एक दिन, हमारी टीम ने पाया कि यह काफी सरल एसक्यूएल क्वेरी निष्पादित करते समय सिस्टम प्रदर्शन को काफी खराब कर देती है:

select count(*) n from products where category_id = ?

बेशक, सवाल यह था कि इसे कैसे अनुकूलित किया जाए।

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

आज हम एक बहुत ही सरल रीफैक्टरिंग विधि के बारे में बात करेंगे, जिसने इस विशेष मामले में सिस्टम प्रदर्शन में काफी वृद्धि की है।

यह क्वेरी पुराने कोड में थी जो SQLConsts वर्ग में, अन्य अन्य एसक्यूएल प्रश्नों के बीच, कुछ वर्षों से नहीं चढ़ रही थी:

 public class SQLConsts { public static final String PRODUCTS_SQL = "select count(*) n from products where category_id = ?"; ...

और यह एक अन्य वर्ग में इस्तेमाल किया गया था

 public class CategoryRepository { ... private boolean isCategoryVisible(int categoryID) { ResultSet resultSet = executeQuery(SQLConsts.PRODUCTS_SQL, categoryID); int n = resultSet.getIntegerFieldByName("n"); return n > 0; } ...

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

यह स्पष्ट महाकाव्य कैसे दिखाई दिया? गिट-लॉग के विश्लेषण से पता चला कि शुरू में isCategoryV अदृश्य विधि में एक अधिक जटिल तर्क था जो इसकी गणना में लाइनों की संख्या का उपयोग करता था। लेकिन तब उन्होंने जटिल तर्क से इनकार कर दिया, और केवल n > 0

बने रहे। जाहिरा तौर पर, प्रोग्रामर जिन्होंने इन बदलावों को किया है, उनके पास बस एक सवाल नहीं था कि वास्तव में n

क्या है, और उन्होंने SQL क्वेरी को स्वयं नहीं देखा, खासकर जब से यह पूरी तरह से अलग फ़ाइल में था।

अब जब कोड के ये दो टुकड़े एक-दूसरे के बगल में हैं, तो अनुकूलन स्पष्ट हो जाता है। नतीजतन, isCategoryVoice विधि को फिर से लिखा गया: select count(*)

एक निर्माण से बदल दिया गया where exists

, जिसने बड़े डेटा संस्करणों पर एक ठोस प्रदर्शन को बढ़ावा दिया; और SQLConsts वर्ग बाद में निपटाया गया था।

 public class CategoryRepository { ... private boolean isCategoryVisible(int categoryID) { ResultSet resultSet = executeQuery( "select null from dual where exists (select null from products where category_id = ?)", categoryID ); return !resultSet.isEmpty(); } ...

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

हमारे मामले में, डेटा (SQL क्वेरी) को एक वर्ग में संग्रहीत किया गया था - SQLConsts, और फ़ंक्शन isCategoryV अदृश्य है, जो इस डेटा का उपयोग करता है - दूसरे में: CategoryRepository में। फाउलर ऐसे कार्यों को ईर्ष्या कहते हैं, क्योंकि वे उस वर्ग में नहीं, जिसमें वे स्थित हैं, लेकिन कुछ अन्य में अधिक रुचि रखते हैं। और सबसे अधिक बार ईर्ष्या डेटा होती है, जैसा कि हमारे मामले में है: isCategoryVouble envies एक और SQLConsts वर्ग SQL क्वेरी को संग्रहीत करता है जिसे इस वर्ग की आवश्यकता नहीं होती है, लेकिन जो isCategoryV अदृश्य है, उसकी आवश्यकता होती है।

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

क्रियात्मक ईर्ष्या

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

इसलिए, शायद हमें पूरे ईर्ष्या के बारे में बात करनी चाहिए श्रेणीबद्ध श्रेणी, क्योंकि वास्तव में इस वर्ग के सभी तरीकों में SQLConsts से डेटा का उपयोग किया गया था, और SQLConsts ने स्वयं इन डेटा का उपयोग नहीं किया था।

अधिक विस्तार से इस प्रश्न के बारे में मेरी दृष्टि यहाँ है:

habrahabr.ru/post/220883/#comment_7547819

पुनश्च

लेकिन क्या होगा यदि चर n

उदाहरण के लिए, productCount

, और productCount

स्थिरांक PRODUCT_COUNT_IN_CATEGORY

? फिर productCount > 0

डेवलपर को यह सोचने के लिए प्रेरित करेगा कि उसे अनुरोध में मात्रा की गणना करने की आवश्यकता है या नहीं।

इसलिए, दूसरा नियम: चर, स्थिरांक, विधियों और कक्षाओं को स्पष्ट नाम दें । शायद यह नियम पहले के शासन से भी अधिक महत्वपूर्ण है।

अद्यतन

जो लोग पसंद नहीं करते उनके लिए एक छोटा शैक्षिक कार्यक्रम exists

।

exists

ऑपरेटर true

लौटेगा यदि उपकुंजी से कम से कम एक रिकॉर्ड category_id = को संतुष्ट करता है?

इस प्रकार, DBMS सबक्वेरी से सभी पंक्तियों का चयन नहीं करेगा: यह पहला रिकॉर्ड खोजने के लिए पर्याप्त है जो स्थिति को संतुष्ट करता है।

इसलिए, ये दो विकल्प समान रूप से प्रभावी होंगे:

 select null from dual where exists (select null from products where category_id = ?)

 select null from products where category_id = ? and rownum = 1

* Oracle में rownum = 1

MySQL में limit 1

के समान है।

लेकिन where NOT exists

वास्तव में where NOT exists

सभी उपयुक्त अभिलेखों की गणना की जाती है। लेकिन यह ध्यान दिया जाना चाहिए कि इस मामले में rownum = 1

का उपयोग करना संभव नहीं होगा।

अद्यतन २

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

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

रिफैक्टिंग का अभ्यास। स्पष्ट कार्य

क्रियात्मक ईर्ष्या

पुनश्च

अद्यतन

अद्यतन २

More articles: