ஒவ்வொரு டெவலப்பரிடமும் அந்த ஒரு ஃபோல்டர் இருக்கும். ஒரு ரெப்போவிலிருந்து (repo) மற்றொரு ரெப்போவிற்கு நீங்கள் நகலெடுக்கும் utils அல்லது helpers என்று பெயரிடப்பட்ட அந்த ஃபோல்டர். அதை நீங்கள் பேஸ்ட் செய்துவிட்டு, பழைய டேட்டாபேஸ் ஸ்கீமாக்களுக்கான (database schemas) குறிப்புகளை நீக்கவும், பொருந்தாத ஆத் (auth) சோதனைகளை அகற்றவும், புதிய லின்டர் (linter) பிழைகளைக் காட்டாமல் இருக்க வேரியபிள்களை (variables) மறுபெயரிடவும் இருபது நிமிடங்கள் செலவிடுவீர்கள். நான் முன்பு உருவாக்கிய Dynamic Theme Kit என்ற தீமிங் சிஸ்டத்தை வைத்து இப்படித்தான் செய்தேன். அது ஒரு அப்ளிகேஷனுக்குள் இருந்த ஒரு அம்சமாகத் தொடங்கியது, மேலும் பல மாதங்களாக, அதை ஒரு போர்ட்டபிள் டூலாகவே நான் கருதினேன். நான் செய்தது தவறு. குறியீட்டை நகலெடுப்பது என்பது மறுபயன்பாடு (reuse) அல்ல. அது கூடுதல் வேலைகளுடன் கூடிய நகலெடுப்பு (duplication) மட்டுமே.

ஒற்றை-திட்ட மனநிலை எனும் பொறி (The Trap of the Single-Project Mindset)

நீங்கள் ஒரு திட்டத்திற்குள் (project) ஒரு அம்சத்தை உருவாக்கும்போது, நூற்றுக்கணக்கான கண்ணுக்குத் தெரியாத ஊகங்களைச் செய்கிறீர்கள். அந்த வண்ணத் தொகுப்பு (color palette) ஒரு குறிப்பிட்ட CSS-in-JS அமைப்பை அடிப்படையாகக் கொண்டிருக்கலாம். இடைவெளி அளவு (spacing scale) உங்கள் நிறுவனத்தின் பிராண்ட் গাইடில் உள்ள ஒரு டிசைன் டோக்கனை (design token) குறிக்கலாம். லைட் மற்றும் டார்க் மோட் இடையிலான மாற்றம், அந்த அப்ளிகேஷனின் பேக்எண்டிற்கு மட்டுமே உரித்தான ஒரு பயனர் விருப்பத் தொடரி (user preference endpoint) அழைப்பதாக இருக்கலாம். இந்தத் சார்புகள் (dependencies) அந்தத் திட்டத்திற்குள் இருக்கும்போது பாதிப்பற்றவை போலத் தோன்றும். அவை அங்கிருக்க வேண்டியவைதான்.

அந்தக் குறியீட்டை வெளியே எடுக்க முயலும்போது பிரச்சனை தொடங்குகிறது. அந்த "மறுபயன்பாட்டு" (reusable) காம்பொனென்ட், உண்மையில் அந்த ஒரு கோட்பாட்டுத் தொகுப்புடன் (codebase) இணைக்கப்பட்ட மறைக்கப்பட்ட இணைப்புகளின் வலைப்பின்னல் என்பதை நீங்கள் கண்டறிவீர்கள். நான் இதை DTK மூலம் கற்றுக்கொண்டேன். அது தீம் வேரியபிள்களை (theme variables) உருவாக்கியது, உண்மைதான். ஆனால் அது ஒரு குறிப்பிட்ட ஃபோல்டர் அமைப்பையும் (folder structure) எதிர்பார்த்தது. அப்ளிகேஷனின் டைப்ஸ் டைரக்டரியில் (types directory) எங்கோ இருந்த ஒரு டைப் டெஃபினிஷனை (type definition) அது இறக்குமதி செய்தது. அந்த ஒரு ரெப்போவில் மட்டுமே இருந்த ஒரு குளோபல் கான்ஃபிக் ஆப்ஜெக்ட்டின் (global config object) இருப்பை அது எதிர்பார்த்தது. அந்தத் திட்டத்திற்குள் அனைத்தும் எப்போதும் இருந்ததால், நான் இதை ஒருபோதும் கவனிக்கவில்லை.

DTK-ஐ ஒரு தனித்த பேக்கேஜாக (standalone package) மாற்றுவது என்பது விரிவாக்கம் அல்ல, அது ஒரு அறுவை சிகிச்சை போன்றது. எனக்கு கூடுதல் அம்சங்கள் தேவையில்லை; எனக்குக் குறைவான இணைப்புகள் தான் தேவைப்பட்டன.

Dynamic Theme Kit-ஐ பிரித்தெடுத்தல்

மிகக் கடினமான வேலை, கோட்பாட்டுத் தொகுதியுடன் (codebase) அமர்ந்து ஒவ்வொரு பங்க்ஷன் (function) மற்றும் ஒவ்வொரு எக்ஸ்போர்ட்டையும் (export) ஆய்வு செய்வதுதான்: "இது தீமிங் லாஜிக்கிற்கு (theming logic) உதவுகிறதா அல்லது திட்டத்திற்கு (project) உதவுகிறதா?" என்று கேட்டதுதான். நான் ஸ்டைலிங் பிரீசெட்களை (styling presets) நீக்கினேன். இதைப் பயன்படுத்துபவர் ஒரு React அப்ளிகேஷனாகத்தான் இருக்க வேண்டும் என்ற ஊகத்தை அகற்றினேன். இயல்புநிலை வண்ணத் தொகுப்புகளை (default color palettes) முற்றிலும் நீக்கினேன். அசல் திட்டத்தில் நேவி மற்றும் ஸ்லேட் நிறத்திலான கார்ப்பரேட் அழகியல் (corporate aesthetic) இயல்புநிலையாகவே இருந்தது. அதை நீக்க வேண்டியிருந்தது. ஒரு பேக்கேஜ் உங்கள் பிராண்ட் வண்ணங்களை (brand colors) வழங்க முடியாது.

புதிய கிட் (kit) சரியாக ஒரு வேலையை மட்டுமே செய்யும். அது ஒரு கான்ஃபிகரேஷன் ஆப்ஜெக்ட்டை (configuration object) எடுத்துக்கொள்ளும்—சில வண்ண மதிப்புகள், சில இடைவெளி எண்கள், சில டைபோகிராபி அளவுகள்—மற்றும் அது CSS கஸ்டம் ப்ராப்பர்டிகளை (CSS custom properties) உருவாக்கும். அவ்வளவுதான். அது அவற்றை அப்ளை செய்யாது. அவை உங்கள் DOM-இல் எங்கு செல்ல வேண்டும் என்பதை அது தீர்மானிக்காது. நீங்கள் Tailwind, Styled Components அல்லது சாதாரண HTML பயன்படுத்துகிறீர்களா என்பதைப் பற்றி அது கவலைப்படாது. அது உங்கள் அப்ளிகேஷனுக்கு வேரியபிள்களை வழங்கும், உங்கள் திட்டம் அவற்றை எவ்வாறு பயன்படுத்துவதைத் தீர்மானிக்கும்.

அந்தக் கட்டுப்பாடு ஆரம்பத்தில் வரம்புக்குட்பட்டது போலத் தோன்றியது. ஆனால் அது ஒரு விடுதலையாக அமைந்தது.

நீங்கள் உண்மையில் அதை மறுபயன்பாடு செய்ய முயலும்போது என்ன உடைந்து போகிறது?

நான் எதையும் வெளியிடுவதற்கு முன்பு, இந்த அப்ஸ்ட்ராக்ஷன் (abstraction) உண்மையில் சரியாகச் செயல்படுகிறதா என்பதற்கு ஆதாரம் தேவைப்பட்டது. எனது ஆவணங்களிலிருந்து மூன்று சிறிய தனிப்பட்ட திட்டங்களை எடுத்தேன்: ஒரு மார்க்‌டவுன் பிரீவியூ டூல் (markdown preview tool), ஒரு ஹாபிட் டிராக்கர் (habit tracker) மற்றும் ஒரு நிகழ்விற்கான லேண்டிங் பேஜ் (landing page). அவற்றுள் எதுவுமே ஒரே ஃபிரேம்வொர்க்கையோ அல்லது ஃபோல்டர் அமைப்பையோ பகிர்ந்து கொள்ளவில்லை. ஒவ்வொன்றிலும் DTK-ஐ லோக்கலாக இன்ஸ்டால் செய்து, அவற்றுக்கு தீம் செய்ய முயன்றேன்.

முதல் முயற்சி உடனடியாகத் தோல்வியடைந்தது. DTK உருவாக்கிய வேரியபிள் பெயர்கள் மிகவும் குறிப்பிட்டதாக இருந்தன. அது --primary-action மற்றும் --background-overlay போன்ற டோக்கன்களை வெளியிட்டது, அவை ஒரு குறிப்பிட்ட UI லேஅவுட்டை (layout) உணர்த்தின. மார்க்‌டவுன் பிரீவியூயரில், அந்தப் பெயர்களுக்கு எந்தப் பொருளும் இல்லை. அங்கு எந்த ஆக்ஷன் பட்டனும் இல்லை, ஓவர்லேயும் இல்லை. எனவே, நான் உருவாக்கும் லாஜிக்கை மாற்றி, விட்ஜெட்டை (widget) விவரிப்பதற்குப் பதிலாக அதன் மதிப்பை விவரிக்கும் நடுநிலையான, கட்டமைப்பு சார்ந்த பெயர்களை (neutral, structural names) உருவாக்கினேன்.

எனது டீஃபால்ட் மதிப்புகள் (default values) மிகவும் தீவிரமாக இருப்பதையும் நான் கண்டறிந்தேன். ஒரு பயனர் முழுமையற்ற கான்ஃபிக்-ஐ வழங்கும்போது, DTK இடைவெளிகளை நிரப்ப முயன்றது. அந்த மதிப்புகள் ஒரு அடர்த்தியான டேஷ்போர்டில் (dashboard) நன்றாகத் தெரிந்தாலும், ஒரு எளிமையான லேண்டிங் பேஜில் சரியாகத் தெரியவில்லை. எனவே, நான் வெளிப்படையான டீஃபால்ட்களுக்கு (transparent defaults) மாறினேன்; அங்கு விடுபட்ட டோக்கன்கள் எதையும் ரெண்டர் செய்யாது, இதனால் அந்தத் திட்டம் தனது சொந்த ஃபால்பேக்குகளை (fallbacks) வரையறுத்துக் கொள்ள முடியும்.

அடுத்து ஆவணங்கள் (documentation). எனக்குத் தெளிவாகத் தெரிந்த விஷயம்—"வெறுமனே ஒரு கான்ஃபிக் ஆப்ஜெக்ட்டை வழங்கவும்"—என்பது நள்ளிரவில் README-ஐப் படிக்கும் ஒருவருக்குத் தெளிவற்றதாக இருந்தது. நான் அதை உண்மையான ஆப்ஜெக்ட்கள், உண்மையான ஃபைல் பாதைகள் மற்றும் ஒரு பங்க்ஷனை அழைக்கும்போது என்ன நடக்கும் மற்றும் அதன் பிறகு உங்கள் அப்ளிகேஷன் என்ன செய்ய வேண்டும் என்பது குறித்த தெளிவான விளக்கங்களுடன் மீண்டும் எழுதினேன்.

இந்தச் சிறிய தனிப்பட்ட திட்டங்கள் சோதனைத் தளங்களாக (test beds) செயல்பட்டன. அவற்றில் பெரிய பாதிப்புகள் இல்லை, ஆனால் மூலக் குறியீட்டை (source code) மட்டும் தனியாகப் பார்த்து நான் கண்டறிய முடியாத உண்மையான குறைகளை அவை வெளிப்படுத்தின.

உண்மையான சோதனை: Web Weavers World-ல் நேரடி பயன்பாடு (Production)

தனிப்பட்டத் திட்டங்கள் ஒரு சோதனைப் பெட்டகங்கள் (sandboxes) போன்றவை. அவற்றுக்கு காலக்கெடுவோ, பங்குதாரர்களோ அல்லது உங்கள் தொகுப்பிற்கு (package) முந்தைய பழைய CSS முறையோ இருக்காது. எனது வணிகத் தளமான Web Weavers World-இல் DTK-ஐ ஒருங்கிணைத்தபோதுதான் உண்மையான சோதனை ஏற்பட்டது. இது ஏற்கனவே உள்ள பாணிகள் (styles), வாடிக்கையாளர் எதிர்பார்ப்புகள் மற்றும் பகுப்பாய்வுகளை (analytics) கருத்தில் கொள்ள வேண்டிய ஒரு நேரடித் தளமாகும் (live property). அந்தத் தொகுப்பு (package) ஏதேனும் ஒன்றைச் சிதைத்துவிட்டால், என்னால் அந்தத் தொகுப்பினை (repo) நீக்கிவிட்டு மீண்டும் புதிதாகத் தொடங்க முடியாது.

நான் DTK-ஐ பில்ட் பைப்லைனில் (build pipeline) சேர்த்து, அதை ஒரு புதிய வண்ணக் கட்டமைப்பிற்கு (color configuration) வழிகாட்டி, புதிய CSS மாறிகளை (variables) உருவாக்கச் செய்தேன். இந்த ஒருங்கிணைப்பு ஒரு வாரத்திற்குப் பதிலாக ஒரு மதிய நேரமே ஆனது. அதுவே ஒரு முக்கிய அறிகுறியாகும். இதற்கு முன்பு, ஒரு புதிய தீம்-ஐ (theme) சேர்ப்பது என்பது புதிய CSS-ஐ எழுதுவதையும், இருபது கோப்புகளில் உள்ள ஹார்ட்கோட் செய்யப்பட்ட (hardcoded) ஹெக்ஸ் மதிப்புகளைத் (hex values) தேடிப் பிடிப்பதையும், ஏதேனும் ஒரு விளிம்பு நிலைச் சிக்கலை (edge case) நான் விட்டுவிடவில்லை என்று நம்புவதையும் குறித்தது. இப்போது நான் ஒரு வண்ணத் தொகுப்பை (palette) உள்ளமைவு கோப்பில் (configuration file) சேர்க்கிறேன், DTK மாறிகளை உருவாக்குகிறது, மீதமுள்ள தளம் அவற்றை அப்படியே பயன்படுத்துகிறது. தீம் லாஜிக் (theme logic) என்பது ஒரு பலவீனமான கைமுறைச் செயல்பாட்டிலிருந்து, சக பணியாளர்களிடம் (collaborators) ஒப்படைக்கத் தகுந்த நம்பிக்கைக்குரிய ஒன்றாக மாறியது.

நான் உருவாக்கும் முறையை மாற்றிய மூன்று கேள்விகள்

இந்தச் செயல்முறையின் மூலம், எதையும் சுருக்கி (abstract) உருவாக்கும் முன் நான் பயன்படுத்தும் ஒரு மனப் பட்டியலை (mental checklist) முறைப்படுத்த வேண்டிய கட்டாயம் ஏற்பட்டது:

  • இந்த மாறி (variable) உண்மையிலேயே பொதுவானதா? அதன் பெயர் அல்லது லாஜிக், அசல் திட்டத்தின் ஒரு குறிப்பிட்ட களக் கருத்தை (domain concept) குறிப்பதாக இருந்தால், அது அங்கே தங்கிவிட வேண்டும்.
  • இது தொகுப்பிற்குச் (package) சொந்தமானதா அல்லது பயன்பாட்டிற்குச் (application) சொந்தமானதா? வணிக விதிகள், பிராண்ட் அடையாளங்கள் மற்றும் லேஅவுட் அனுமானங்கள் பயன்பாட்டில் (app) இருக்க வேண்டும். தரப்படுத்தப்பட்ட வெளியீட்டை உருவாக்கும் அடிப்படை கட்டமைப்புகள் (plumbing) தொகுப்பில் (package) இருக்க வேண்டும்.
  • நான் மீண்டும் பயன்படுத்தக்கூடிய ஒரு சிக்கலைத் தீர்க்கிறேனா அல்லது ஒரு குறிப்பிட்ட திட்டத்திற்கான சிக்கலைத் தீர்க்கிறேனா? இதற்கு நேர்மையாகப் பதிலளிப்பது மிகவும் கடினம். நமது தீர்வுகள் உலகளாவியவை என்று நாம் நினைக்க விரும்புகிறோம். ஆனால் அவை பெரும்பாலும் குறிப்பிட்ட இடத்திற்கு மட்டுமே உரியவை.

இந்தக் கேள்விகளுக்குப் பதிலளிப்பது, குறியீடுகளை (code) அதிகரிப்பதற்குப் பதிலாக, அவற்றை நீக்குவதன் மூலம் எனது வடிவமைப்பை எளிமையாக்க என்னை வற்புறுத்தியது. மறுபயன்பாடு (reuse) என்பது உங்களுக்கு நீங்களே கொடுத்துக்கொள்ளும் பரிசு அல்ல; அது வசதிகளைத் தவிர்ப்பதன் மூலம் நீங்கள் கடைப்பிடிக்க வேண்டிய ஒரு ஒழுக்கம் என்று DTK எனக்குக் கற்பித்தது.

ரீஃபாக்டரிங் (Refactoring) பற்றிச் சிந்திப்பதற்கான ஒரு மாறுபட்ட வழி

ரீஃபாக்டரிங் (refactors) செய்வதன் மூலம் குறியீடு எவ்வளவு குறைகிறது என்பதைக் கொண்டே நான் அளவிடுவேன். குறைவான வரிகள் முன்னேற்றமாகத் தோன்றியது. இப்போது அவை எத்தனை புதிய வாய்ப்புகளைத் திறக்கின்றன என்பதைக் கொண்டு நான் அளவிடுகிறேன். Dynamic Theme Kit என்பது சுருக்கமாக இருப்பதால் நேர்த்தியானது அல்ல. அதன் உட்புற அமைப்புகளை (internals) மாற்றத் தேவையில்லாமல், தொடர்பில்லாத மூன்று தனிப்பட்ட திட்டங்கள் மற்றும் ஒரு நேரடி வணிகத் தளத்தில் அது நிலைத்து நின்றதுதான் அதன் பயன்.

அதுதான் முக்கியமான அளவுகோல். ஒருமுறை மட்டும் வேலை செய்யும் குறியீடு ஒரு செலவு. மீண்டும் மீண்டும் வேலை செய்யும் குறியீடு ஒரு சொத்து. இப்போது நான் எந்த ஒரு புதிய அம்சத்தையும் (feature) தொடங்குவதற்கு முன், சற்றுத் தயங்கி நிற்கிறேன். நான் மீண்டும் தேவைப்படக்கூடிய ஒன்றை உருவாக்குகிறேனா என்று கேட்டுக்கொள்கிறேன். பதில் 'ஆம்' என்றால், முதல் வரியிலிருந்தே அதை வேறு விதமாக உருவாக்குகிறேன். உள்ளீடுகளைத் (inputs) தனிமைப்படுத்துகிறேன். வெளியீடுகளைத் (outputs) வரையறுக்கிறேன். அனுமானங்களை நீக்குகிறேன்.

சிறந்த ரீஃபாக்டரிங் உங்கள் குறியீட்டைச் சுருக்குவதில்லை. அது நீங்கள் இன்னும் கற்பனை செய்யாத இடங்களிலும் உங்கள் குறியீடு வேலை செய்யச் செய்கிறது.