દરેક ડેવલપર પાસે એવું એક ફોલ્ડર હોય જ છે. એવું ફોલ્ડર જેને utils અથવા helpers કહેવામાં આવે છે અને તમે તેને એક રિપોઝિટરીમાંથી બીજી રિપોઝિટરીમાં કોપી કરો છો. તમે તેને પેસ્ટ કરો છો, વીસ મિનિટ જૂના ડેટાબેઝ સ્કીમાના સંદર્ભો કાઢી નાખવામાં, લાગુ ન પડતા auth ચેક્સ દૂર કરવામાં અને વેરિયેબલ્સનું નામ બદલવામાં વિતાવો છો જેથી તમારો નવો લિન્ટર (linter) ભૂલો બતાવવાનું બંધ કરે. હું પણ મારા દ્વારા બનાવવામાં આવેલી થીમિંગ સિસ્ટમ, Dynamic Theme Kit સાથે આવું જ કરતો હતો. તે એક એપ્લિકેશનની અંદરના ફીચર તરીકે શરૂ થયું હતું, અને મહિનાઓ સુધી, મેં તેને એક પોર્ટેબલ ટૂલ તરીકે ગણ્યું. હું ખોટો હતો. કોડ કોપી કરવો એ તેનો પુનઃઉપયોગ (reuse) નથી. તે વધારાના સ્ટેપ્સ સાથેનું ડુપ્લીકેશન છે.
સિંગલ-પ્રોજેક્ટ માઇન્ડસેટનો ફાંસો
જ્યારે તમે કોઈ પ્રોજેક્ટની અંદર ફીચર બનાવો છો, ત્યારે તમે સેંકડો અદ્રશ્ય ધારણાઓ કરો છો. કલર પેલેટ કદાચ ચોક્કસ CSS-in-JS સેટઅપની ધારણા કરતું હોય. સ્પેસિંગ સ્કેલ કદાચ તમારી કંપનીના બ્રાન્ડ ગાઈડમાંથી કોઈ ડિઝાઇન ટોકનનો સંદર્ભ લેતું હોય. લાઇટ અને ડાર્ક મોડ વચ્ચેનું ટૉગલ કદાચ તે એપના બેકએન્ડ માટેના યુઝર પ્રેફરન્સ એન્ડપોઇન્ટને કોલ કરતું હોય. આ ડિપેન્ડન્સીઝ હાનિકારક લાગતી નથી કારણ કે પ્રોજેક્ટની અંદર તે હાનિકારક નથી. તે ત્યાં હોવા જ જોઈએ.
સમસ્યા ત્યારે શરૂ થાય છે જ્યારે તમે તે કોડને બહાર કાઢવાનો પ્રયાસ કરો છો. તમને ખબર પડે છે કે તે "રીયુઝેબલ" કમ્પોનન્ટ વાસ્તવમાં તે એક કોડબેઝ સાથે જોડાયેલ છુપાયેલા સ્ટ્રિંગ્સનું જાળું છે. મેં DTK સાથે આ શીખ્યું. તેણે થીમ વેરિયેબલ્સ જનરેટ કર્યા, હા. પરંતુ તેણે એક ચોક્કસ ફોલ્ડર સ્ટ્રક્ચરની પણ અપેક્ષા રાખી હતી. તેણે મૂળ એપના ટાઇપ્સ ડિરેક્ટરીમાં ક્યાંકથી ટાઇપ ડેફિનેશન ઇમ્પોર્ટ કર્યું હતું. તેણે એક ગ્લોબલ કોન્ફિગ ઓબ્જેક્ટની હાજરીની ધારણા કરી હતી જે ફક્ત તે એક જ રિપોઝિટરીમાં અસ્તિત્વ ધરાવતો હતો. મેં ક્યારેય નોંધ્યું નહોતું કારણ કે તે પ્રોજેક્ટની અંદર, બધું હંમેશા હાજર હતું.
DTK ને સ્ટેન્ડઅલોન પેકેજમાં બદલવાનો અર્થ વિસ્તરણ (expansion) નહીં, પણ સર્જરી (surgery) હતો. મને વધુ ફીચર્સની જરૂર નહોતી. મને ઓછા કનેક્શનની જરૂર હતી.
Dynamic Theme Kit ને અલગ પાડવું
સૌથી અઘરું કામ કોડબેઝ સાથે બેસીને દરેક ફંક્શન અને દરેક એક્સપોર્ટ માટે પૂછવું હતું: શું આ થીમિંગ લોજિક માટે કામ કરે છે, કે પછી તે પ્રોજેક્ટ માટે કામ કરે છે? મેં સ્ટાઇલિંગ પ્રીસેટ્સ કાઢી નાખ્યા. મેં એ ધારણા દૂર કરી કે તેનો ઉપયોગ કરનાર (consumer) એક React એપ્લિકેશન હશે. મેં ડિફોલ્ટ કલર પેલેટ્સ સંપૂર્ણપણે કાઢી નાખ્યા. મૂળ પ્રોજેક્ટમાં ડિફોલ્ટ તરીકે નેવી-એન્ડ-સ્લેટ કોર્પોરેટ એસ્થેટિક (aesthetic) હતું. તે દૂર કરવું પડ્યું. પેકેજ તમારી બ્રાન્ડના રંગો સાથે શિપ કરી શકતું નથી.
નવું કિટ બરાબર એક જ કામ કરશે. તે એક કોન્ફિગરેશન ઓબ્જેક્ટ લેશે—કેટલીક કલર વેલ્યુઝ, કેટલાક સ્પેસિંગ નંબર્સ, કેટલાક ટાઇપોગ્રાફી સ્કેલ્સ—અને તે CSS કસ્ટમ પ્રોપર્ટીઝ જનરેટ કરશે. બસ એટલું જ. તે તેને એપ્લાય કરતું નથી. તે નક્કી કરતું નથી કે તમારા DOM માં તે ક્યાં જશે. તેને કોઈ ફરક પડતો નથી કે તમે Tailwind, Styled Components અથવા પ્લેન HTML વાપરો છો. તે તમારી એપ્લિકેશનને વેરિયેબલ્સ આપે છે, અને તમારો પ્રોજેક્ટ નક્કી કરે છે કે તેનો ઉપયોગ કેવી રીતે કરવો.
તે મર્યાદા શરૂઆતમાં મર્યાદિત લાગી હતી. પરંતુ તે મુક્તિ આપનારી સાબિત થઈ.
જ્યારે તમે ખરેખર તેનો પુનઃઉપયોગ કરવાનો પ્રયાસ કરો છો ત્યારે શું તૂટે છે
મેં કંઈપણ પબ્લિશ કરતા પહેલા, મને પુરાવાઓની જરૂર હતી કે એબસ્ટ્રેક્શન (abstraction) ખરેખર કામ કરે છે. મેં મારા આર્કાઇવમાંથી ત્રણ નાના પર્સનલ પ્રોજેક્ટ્સ લીધા: એક માર્કડાઉન પ્રિવ્યૂ ટૂલ, એક હેબિટ ટ્રેકર અને એક ઇવેન્ટ માટે લેન્ડિંગ પેજ. તેમાંથી કોઈ પણ ફ્રેમવર્ક અથવા ફોલ્ડર સ્ટ્રક્ચર શેર કરતા નહોતા. મેં દરેકમાં સ્થાનિક રીતે (locally) DTK ઇન્સ્ટોલ કર્યું અને તેમને થીમ કરવાનો પ્રયાસ કર્યો.
પ્રથમ પ્રયાસ તરત જ નિષ્ફળ ગયો. DTK દ્વારા જનરેટ કરવામાં આવેલા વેરિયેબલના નામ ખૂબ જ ચોક્કસ હતા. તે --primary-action અને --background-overlay જેવા ટોકન્સ આઉટપુટ કરી રહ્યું હતું જે ચોક્કસ UI લેઆઉટ સૂચવતા હતા. માર્કડાઉન પ્રિવ્યૂઅરમાં, તે નામનો કોઈ અર્થ નહોતો. ત્યાં કોઈ એક્શન બટન નહોતું. ત્યાં કોઈ ઓવરલે નહોતું. મેં જનરેશન લોજિકનું નામ બદલીને ન્યુટ્રલ, સ્ટ્રક્ચરલ નામ રાખ્યા જે વિજેટને બદલે તેની વેલ્યુનું વર્ણન કરે.
મને એ પણ જાણવા મળ્યું કે મારી ડિફોલ્ટ વેલ્યુઝ ખૂબ જ આક્રમક હતી. જ્યારે યુઝરે અધૂરી કોન્ફિગ પસાર કરી, ત્યારે DTK એ એવી વેલ્યુઝથી ખાલી જગ્યાઓ ભરી દીધી જે ડેન્સ ડેશબોર્ડમાં સારી લાગતી હતી પરંતુ સ્પાર્સ લેન્ડિંગ પેજ પર બગડી ગઈ હતી. હું ટ્રાન્સપરન્ટ ડિફોલ્ટ્સ પર સ્વિચ થઈ ગયો જ્યાં ખૂટતા ટોકન્સ ફક્ત રેન્ડર જ ન થાય, જેથી ઉપયોગ કરતો પ્રોજેક્ટ તેના પોતાના ફોલબેક્સ (fallbacks) વ્યાખ્યાયિત કરી શકે.
પછી ડોક્યુમેન્ટેશનની વાત હતી. જે મને સ્પષ્ટ લાગતું હતું—"બસ એક કોન્ફિગ ઓબ્જેક્ટ પાસ કરો"—તે મધ્યરાત્રિએ README વાંચતા કોઈ વ્યક્તિ માટે અસ્પષ્ટ હતું. મેં તેને વાસ્તવિક ઓબ્જેક્ટ્સ, વાસ્તવિક ફાઇલ પાથ અને તમે ફંક્શન કૉલ કરો ત્યારે શું થાય છે અને તેના પછી તમારી એપ્લિકેશને શું કરવાની જરૂર છે તેની સ્પષ્ટ સમજૂતી સાથે ફરીથી લખ્યું.
આ નાના પર્સનલ પ્રોજેક્ટ્સ ટેસ્ટ બેડ તરીકે કામ કરી ગયા. તેમાં જોખમ ઓછું હતું, પરંતુ તેઓ વાસ્તવિક ખામીઓ ખુલ્લી પાડી જે હું સોર્સ કોડને અલગથી જોતા પકડી શક્યો ન હોત.
અસલી પરીક્ષા: Web Weavers World માં પ્રોડક્શન
વ્યક્તિગત પ્રોજેક્ટ્સ એ સેન્ડબોક્સ છે. તેમાં કોઈ ડેડલાઇન, સ્ટેકહોલ્ડર્સ, અથવા તમારા પેકેજ પહેલાના લેગસી CSS હોતા નથી. સાચી કસોટી ત્યારે આવી જ્યારે મેં DTK ને મારા બિઝનેસ સાઇટ, Web Weavers World માં ઇન્ટિગ્રેટ કર્યું. આ એક લાઈવ પ્રોપર્ટી હતી જેમાં અસ્તિત્વમાં રહેલી સ્ટાઇલ્સ, ક્લાયન્ટની અપેક્ષાઓ અને એનાલિટિક્સ ધ્યાનમાં લેવાના હતા. જો પેકેજથી કંઈક બગડી જાય, તો હું ફક્ત રિપોઝિટરી ડિલીટ કરીને ફરીથી શરૂ કરી શકતો નહોતો.
મેં DTK ને બિલ્ડ પાઇપલાઇનમાં ઉમેર્યું, તેને નવા કલર કોન્ફિગરેશન તરફ નિર્દેશિત કર્યું, અને તેને CSS વેરિયેબલ્સનો નવો સેટ જનરેટ કરવા દીધો. આ ઇન્ટિગ્રેશનમાં માત્ર એક બપોરનો સમય લાગ્યો, અઠવાડિયું નહીં. તે એક સંકેત હતો. અગાઉ, નવો થીમ ઉમેરવાનો અર્થ હતો નવું CSS લખવું, વીસ ફાઇલોમાં હાર્ડકોડેડ હેક્સ (hex) વેલ્યુઝ શોધવી, અને એવી આશા રાખવી કે હું કોઈ એજ કેસ (edge case) ચૂકી ન જાઉં. હવે હું કોન્ફિગરેશન ફાઇલમાં પેલેટ ઉમેરું છું, DTK વેરિયેબલ્સ જનરેટ કરે છે, અને સાઇટનો બાકીનો ભાગ તેનો ઉપયોગ કરે છે. થીમ લોજિક એક નાજુક મેન્યુઅલ પ્રક્રિયામાંથી એવી વસ્તુમાં પરિવર્તિત થયું જેના પર હું સહયોગીઓને સોંપવા માટે પૂરતો વિશ્વાસ કરી શકું છું.
ત્રણ પ્રશ્નો જેણે મારી બનાવવાની રીત બદલી નાખી
આ પ્રક્રિયામાંથી પસાર થવાથી મને એક માનસિક ચેકલિસ્ટ તૈયાર કરવા મજબૂર કર્યો, જેનો ઉપયોગ હું હવે કોઈપણ વસ્તુને એબ્સ્ટ્રેક્ટ કરતા પહેલા કરું છું:
- શું આ વેરિયેબલ ખરેખર જનરિક છે? જો નામ અથવા લોજિક મૂળ પ્રોજેક્ટના કોઈ ડોમેન કોન્સેપ્ટનો સંદર્ભ આપે છે, તો તેને પાછળ જ રહેવા દો.
- શું આ પેકેજમાં હોવું જોઈએ કે એપ્લિકેશનમાં? બિઝનેસ નિયમો, બ્રાન્ડ ઓળખ અને લેઆઉટની ધારણાઓ એપ્લિકેશનમાં હોય છે. સ્ટાન્ડર્ડ આઉટપુટ જનરેટ કરતી પ્લમ્બિંગ પેકેજમાં હોય છે.
- શું હું ફરીથી ઉપયોગ કરી શકાય તેવી સમસ્યાનો ઉકેલ લાવી રહ્યો છું કે પ્રોજેક્ટ-વિશિષ્ટ સમસ્યાનો? આનો પ્રમાણિકતાથી જવાબ આપવો સૌથી મુશ્કેલ છે. આપણને લાગે છે કે આપણા ઉકેલો યુનિવર્સલ છે, પરંતુ સામાન્ય રીતે તેઓ લોકલ હોય છે.
આ પ્રશ્નોના જવાબ આપવાથી મને મારું ડિઝાઇન સરળ બનાવવાની ફરજ પડી, જે ઘણીવાર કોડ ઉમેરવાને બદલે તેને દૂર કરીને કરવામાં આવી હતી. DTK એ મને શીખવ્યું કે રિ-યુઝ એ તમારી જાતને આપેલી ભેટ નથી. તે એક શિસ્ત છે જે તમે સુવિધાને 'ના' કહીને કેળવો છો.
રિફેક્ટરિંગ વિશે વિચારવાની એક અલગ રીત
હું પહેલા રિફેક્ટર્સને કોડ કેટલો ટૂંકો બનાવે છે તેનાથી માપતો હતો. ઓછી લાઇનનો અર્થ પ્રગતિ જેવો લાગતો હતો. હવે હું તેને તે કેટલા દરવાજા ખોલે છે તેનાથી માપું છું. Dynamic Theme Kit એટલા માટે સુંદર નથી કારણ કે તે સંક્ષિપ્ત છે. તે ઉપયોગી છે કારણ કે તે તેના ઇન્ટર્નલ્સ બદલ્યા વિના ત્રણ અસંબંધિત વ્યક્તિગત પ્રોજેક્ટ્સ અને એક પ્રોડક્શન બિઝનેસ સાઇટમાં ટકી રહ્યું છે.
એ જ માપદંડ મહત્વનો છે. જે કોડ એકવાર કામ કરે છે તે ખર્ચ છે. જે કો