लिंटर के बारे में, कोड की गुणवत्ता, सामान्य और गुणवत्ता प्रबंधन में गुणवत्ता

अपनी इच्छाओं से डरो; वे सच हो सकते हैं।
लोक ज्ञान।

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



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

गुणवत्ता के बारे में एक बहुत सार हिस्सा

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

एक अच्छे उत्पाद के कुछ संकेत होते हैं कि यह उच्च गुणवत्ता का है। विभिन्न उत्पादों के अलग-अलग संकेत होते हैं। उदाहरण के लिए, अच्छे फल स्वादिष्ट लगते हैं, अच्छे लगते हैं, अच्छे लगते हैं।

अब मैं एक अतिशयोक्तिपूर्ण उदाहरण दूंगा, और बाद में मैं सीधे कोड पर जाऊंगा।

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

यदि आप गंभीरता से देखें, तो मूल समस्या पूरी तरह से अलग हो सकती है:

1. हमारे प्रतियोगी समान रूप से उच्च गुणवत्ता वाले फल बेचते हैं, लेकिन उन्होंने हमारे सामने सुगंधित विपणन किया और गंध के साथ आगंतुकों को आकर्षित किया।
2. हमारे फल अच्छे हैं, लेकिन प्रतिस्पर्धी फल वास्तव में हमारे (किस्मों, भंडारण, जो भी हो) से बेहतर हैं
3. हमारे फल सड़े हुए हैं। उन्होंने सिर्फ रोटी खाई और बदबू आ रही थी।
4. पिछले वर्ष के फल, जो प्रदर्शन के मामले में पीछे हैं, सड़े हुए हैं, और हमें उम्मीद है कि हम अभी भी उन्हें बेच सकते हैं। और वे वहां से बदबू आने लगती हैं।
5. प्रतियोगी में अधिक वर्गीकरण है
6. प्रतियोगी ने अधिक खूबसूरती से अपने फलों को बाहर रखा, सामान्य तौर पर, हमारे जैसा ही।
7. यह बेवकूफी से सस्ता है
8. वहां, विक्रेता सुंदर है, और हमारे स्थान पर बाबा मान्या स्थानापन्न करने के लिए आए ...

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

वास्तव में, जब ऐसी समस्या उत्पन्न होती है, तो इसके कारणों का व्यापक विश्लेषण करना आवश्यक होता है और प्रत्येक मामले में एक केस-विशिष्ट निर्णय लेते हैं।

और भी अतिशयोक्तिपूर्ण

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

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

खैर, आप बात करते हैं। अगर किसी चीज में बदबू आती है, तो इत्र मदद नहीं करेगा।

कोड गुणवत्ता के बारे में मामूली सार भाग

अच्छे कोड के गुणों के बीच, हम पाएंगे (महत्व के बिना छंटाई):

• शैली की संगति
• पठनीयता,
• प्रदर्शन,
• तानाना
• वास्तुकला और पैटर्न की पारदर्शिता।

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

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

अब टमाटर के साथ एक सादृश्य आकर्षित करते हैं। हमारे परिपक्व नहीं। एक स्वचालित लिंटर हमें बताएगा: "यहाँ देखो और सही रंग नहीं है।" प्रोग्रामर क्या करेगा? बहुत बार चित्रित। और लिंटर की मेरी आलोचना का यह मुख्य विचार है। अब मैं एक ठोस उदाहरण दूंगा, और फिर एक निष्कर्ष निकालूंगा।

बारीकियों

PixiJS 2 फरवरी, 2018 (एक साल पहले)।

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

एक सी कोड है (16 लाइनें):

float blen(v* p0, v* p1, v* p2) { va,b; ax = p0->x - 2*p1->x + p2->x; ay = p0->y - 2*p1->y + p2->y; bx = 2*p1->x - 2*p0->x; by = 2*p1->y - 2*p0->y; float A = 4*(ax*ax + ay*ay); float B = 4*(ax*bx + ay*by); float C = bx*bx + by*by; float Sabc = 2*sqrt(A+B+C); float A_2 = sqrt(A); float A_32 = 2*A*A_2; float C_2 = 2*sqrt(C); float BA = B/A_2; return ( A_32*Sabc + A_2*B*(Sabc-C_2) + (4*C*AB*B)*log( (2*A_2+BA+Sabc)/(BA+C_2) ) )/(4*A_32); }; 

और निम्नलिखित कोड (जेएस) अनुरोध पूल में भेजा गया था:

 /** * Calculate length of quadratic curve * @see {@link http://www.malczak.linuxpl.com/blog/quadratic-bezier-curve-length/} * for the detailed explanation of math behind this. * * @private * @param {number} fromX - x-coordinate of curve start point * @param {number} fromY - y-coordinate of curve start point * @param {number} cpX - x-coordinate of curve control point * @param {number} cpY - y-coordinate of curve control point * @param {number} toX - x-coordinate of curve end point * @param {number} toY - y-coordinate of curve end point * @return {number} Length of quadratic curve */ _quadraticCurveLength(fromX, fromY, cpX, cpY, toX, toY) { const ax = fromX - ((2.0 * cpX) + toX); const ay = fromY - ((2.0 * cpY) + toY); const bx = 2.0 * ((cpX - 2.0) * fromX); const by = 2.0 * ((cpY - 2.0) * fromY); const a = 4.0 * ((ax * ax) + (ay * ay)); const b = 4.0 * ((ax * bx) + (ay * by)); const c = (bx * bx) + (by * by); const s = 2.0 * Math.sqrt(a + b + c); const a2 = Math.sqrt(a); const a32 = 2.0 * a * a2; const c2 = 2.0 * Math.sqrt(c); const ba = b / a2; return ( (a32 * s) + (a2 * b * (s - c2)) + ( ((4.0 * c * a) - (b * b)) * Math.log(((2.0 * a2) + ba + s) / (ba + c2)) ) ) / (4.0 * a32); } 

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


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

 2*2+2*2 

क्योंकि यह खराब पठनीयता का कारण बन सकता है। किसी ने यह विकल्प बनाया, तो किसी ने इसे परियोजना में शामिल किया, जिसका अर्थ है कि कई लोग इसे उपयोगी पाते हैं।

निष्कर्ष

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

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

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

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