सीएसएस हैक करने के लिए शेम.सीएसएस का इस्तेमाल करें, देव कहते हैं

BSkyB के वरिष्ठ यूआई डेवलपर हैरी रॉबर्ट्स के अनुसार, डेवलपर्स को परियोजनाओं में किसी भी त्वरित-फिक्स 'हैक' सीएसएस को साइलो करने के लिए शेम.सीएसएस नामक एक अवधारणा का उपयोग करना चाहिए।

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

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

.net ने रॉबर्ट्स (HB) से CSS हैकिंग के बारे में बात की और यदि सही तरीके से इस्तेमाल किया जाए तो शेम.

.net: क्या आपको लगता है कि उद्योग में कुछ लोगों की प्रवृत्ति है कि वे साइट को काम करने के लिए (उम्मीद के मुताबिक) शॉर्ट-टर्म हैक्स की आवश्यकता के बारे में अवास्तविक हैं?
मानव संसाधन: ज़्यादा समय। यदि आप किसी ऐसी साइट या उत्पाद पर काम करते हैं जो प्रति वर्ष लाखों पाउंड कमाता है, तो किसी भी बग, टूट-फूट या विचित्रताओं को जल्द से जल्द ठीक करने की आवश्यकता है। आपका उत्पाद स्वामी परवाह नहीं करता है कि आपका सीएसएस सही है या नहीं - वे इस बात की परवाह करते हैं कि साइट ऊपर है और कार्यात्मक है और उस राजस्व पर टिक रही है। अच्छा कोड है महत्वपूर्ण है, और हैक्स आदर्श से बहुत दूर हैं, लेकिन यह सोचना कि आप हमेशा हैक्स को रोक सकते हैं और अल्पकालिक/त्वरित सुधार असंभव है।

.net: तो आप कहेंगे कि वे व्यवसाय के भीतर सिर्फ एक आवश्यक बुराई हैं?
मानव संसाधन: जब कोई ग्राहक आपकी गर्दन नीचे कर रहा है - या एक लाइव साइट पर एक सुविधा टूट गई है - आपको यह सुनिश्चित करने की ज़रूरत है कि आप सही हितधारकों को खुश रख रहे हैं। यदि आप दो मिनट में सतही रूप से तय की जा सकने वाली किसी चीज़ के लिए सही फिक्स लिखने में एक घंटा बिताते हैं, तो मैं कहूंगा कि आप गलत व्यक्ति को खुश रख रहे हैं - यानी स्वयं!

अपने स्वयं के काम में, मैंने पाया है कि हैक्स के लिए 'ज़रूरत' परियोजना के आकार के साथ काफी आनुपातिक रूप से बढ़ती है, लेकिन इसके बारे में अच्छी बात यह है कि बाद में आपके पास उन हैक्स को ठीक करने के लिए समर्पित अधिक प्रोजेक्ट समय होगा।

.net: वह कौन सी जगह है जहां शेम.सीएसएस आता है। उस अवधारणा के साथ, आप विशेष रूप से एक सीएसएस हैक पर क्या विचार करते हैं?
मानव संसाधन: कुछ ऐसा जो अधिक समय देकर बेहतर किया जा सकता था। संदर्भ से बाहर के उदाहरणों के बारे में सोचना मुश्किल है, लेकिन मुझे लगता है कि जब कुछ हैक होता है तो आपको अक्सर पता चल जाएगा। ऐसा कुछ लिखा है जिसे किसी सहकर्मी को समझाने में आपको शर्म आएगी? यह शायद एक हैक है!

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

.net: अपने लेख में, आप दस्तावेज़ीकरण हैक्स का उल्लेख करते हैं, लेकिन क्या कोई तर्क नहीं है कि डेवलपर्स को आम तौर पर हैक्स के बजाय सीएसएस को और अधिक दस्तावेज करना चाहिए?
मानव संसाधन: हाँ! यदि एक चीज है जो सभी डेवलपर्स को और अधिक करनी चाहिए, तो वह है टिप्पणियाँ लिखना। आपको कुछ भी ऐसी टिप्पणी करनी चाहिए जो अकेले कोड से तुरंत स्पष्ट न हो। अपने कोड का दस्तावेजीकरण करें ताकि, यदि आप अपने घर के रास्ते में बस की चपेट में आ जाते हैं, तो आपका सहयोगी अगले दिन कार्यभार संभाल सकता है।

.net: शर्म.सीएसएस को एकीकृत करने के संदर्भ में, आप क्या सुझाव देते हैं?
मानव संसाधन: यदि प्रीप्रोसेसर का उपयोग कर रहे हैं, @आयात शर्म की बात है। [एससीएसएस | कम | आदि] आदर्श रूप से अंत में फ़ाइल करें। (यह हमेशा विशिष्टता और स्रोत-आदेश की समस्याओं का कारण बन सकता है, इसलिए आपका लाभ भिन्न हो सकता है।)

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

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

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

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

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

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

Sharm.css के पीछे का विचार केवल आपके हैक्स को अधिक पारदर्शी, मात्रात्मक और अलग-थलग बनाना है। यह आप पर निर्भर है कि आप उस जानकारी का क्या करते हैं!