ਹਰ ਡਿਵੈਲਪਰ ਕੋਲ ਉਹ ਫੋਲਡਰ ਹੁੰਦਾ ਹੈ। ਉਹ ਜਿਸਦਾ ਨਾਮ utils ਜਾਂ helpers ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਇੱਕ ਰੈਪੋ ਤੋਂ ਦੂਜੀ ਰੈਪੋ ਵਿੱਚ ਕਾਪੀ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਇਸਨੂੰ ਪੇਸਟ ਕਰਦੇ ਹੋ, ਵੀਹ ਮਿੰਟ ਪੁਰਾਣੇ ਡੇਟਾਬੇਸ ਸਕੀਮਾਵਾਂ ਦੇ ਰੈਫਰੈਂਸਾਂ ਨੂੰ ਡਿਲੀਟ ਕਰਨ, ਉਹਨਾਂ ਆਥਰ (auth) ਚੈਕਸ ਨੂੰ ਕੱਢਣ ਵਿੱਚ ਬਿਤਾਉਂਦੇ ਹੋ ਜੋ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਵੇਰੀਏਬਲਜ਼ ਦਾ ਨਾਮ ਬਦਲਦੇ ਹੋ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਨਵਾਂ ਲਿੰਟਰ (linter) ਚੀਕਣਾ ਬੰਦ ਕਰ ਦੇਵੇ। ਮੈਂ ਪਹਿਲਾਂ ਆਪਣੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਇੱਕ ਥੀਮਿੰਗ ਸਿਸਟਮ, Dynamic Theme Kit ਨਾਲ ਅਜਿਹਾ ਹੀ ਕਰਦਾ ਸੀ। ਇਹ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਇੱਕ ਫੀਚਰ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਅਤੇ ਮਹੀਨਿਆਂ ਤੱਕ, ਮੈਂ ਇਸਨੂੰ ਇੱਕ ਪੋਰਟੇਬਲ ਟੂਲ ਵਜੋਂ ਵਰਤਿਆ। ਮੈਂ ਗਲਤ ਸੀ। ਕੋਡ ਦੀ ਕਾਪੀ ਕਰਨਾ reuse ਨਹੀਂ ਹੈ। ਇਹ ਵਾਧੂ ਕਦਮਾਂ ਦੇ ਨਾਲ ਡੁਪਲੀਕੇਸ਼ਨ ਹੈ।

ਸਿੰਗਲ-ਪ੍ਰੋਜੈਕਟ ਮਾਈਂਡਸੈੱਟ ਦਾ ਜਾਲ

ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ ਕੋਈ ਫੀਚਰ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੈਂਕੜੇ ਅਦਿੱਖ ਅੰਦਾਜ਼ੇ (assumptions) ਲਗਾ ਲੈਂਦੇ ਹੋ। ਕਲਰ ਪੈਲੇਟ ਸ਼ਾਇਦ ਕਿਸੇ ਖਾਸ CSS-in-JS ਸੈੱਟਅੱਪ ਨੂੰ ਮੰਨ ਕੇ ਚੱਲਦਾ ਹੋਵੇ। ਸਪੇਸਿੰਗ ਸਕੇਲ ਸ਼ਾਇਦ ਤੁਹਾਡੀ ਕੰਪਨੀ ਦੇ ਬ੍ਰਾਂਡ ਗਾਈਡ ਦੇ ਕਿਸੇ ਡਿਜ਼ਾਈਨ ਟੋਕਨ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੋਵੇ। ਲਾਈਟ ਅਤੇ ਡਾਰਕ ਮੋਡ ਦੇ ਵਿਚਕਾਰ ਟੌਗਲ ਸ਼ਾਇਦ ਉਸ ਐਪ ਦੇ ਬੈਕਐਂਡ ਦੇ ਵਿਲੱਖਣ ਯੂਜ਼ਰ ਪ੍ਰੈਫਰੈਂਸ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੋਵੇ। ਇਹ ਡਿਪੈਂਡੈਂਸੀਆਂ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ ਲੱਗਦੀਆਂ ਕਿਉਂਕਿ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ ਉਹ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਉੱਥੇ ਹੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਸਮੱਸਿਆ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਕੋਡ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ "reusable" ਕੰਪੋਨੈਂਟ ਅਸਲ ਵਿੱਚ ਉਹਨਾਂ ਲੁਕੀਆਂ ਹੋਈਆਂ ਸਟ੍ਰਿੰਗਾਂ ਦਾ ਇੱਕ ਜਾਲ ਹੈ ਜੋ ਇਸਨੂੰ ਉਸ ਇੱਕ ਕੋਡਬੇਸ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਮੈਂ ਇਹ DTK ਨਾਲ ਸਿੱਖਿਆ। ਇਸਨੇ ਥੀਮ ਵੇਰੀਏਬਲਸ ਤਿਆਰ ਕੀਤੇ, ਹਾਂ। ਪਰ ਇਸਨੇ ਇੱਕ ਖਾਸ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ ਦੀ ਵੀ ਉਮੀਦ ਕੀਤੀ। ਇਸਨੇ ਅਸਲ ਐਪ ਦੇ types ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕਿਤੇ ਡੂੰਘੇ ਤੋਂ ਇੱਕ type definition ਇੰਪੋਰਟ ਕੀਤੀ। ਇਸਨੇ ਇੱਕ ਗਲੋਬਲ ਕੌਂਫਿਗ ਆਬਜੈਕਟ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਮੰਨ ਲਿਆ ਜੋ ਸਿਰਫ਼ ਉਸ ਇੱਕ ਰੈਪੋਜ਼ੀਟਰੀ ਵਿੱਚ ਮੌਜੂਦ ਸੀ। ਮੈਂ ਇਸਨੂੰ ਕਦੇ ਨੋਟ ਨਹੀਂ ਕੀਤਾ ਸੀ ਕਿਉਂਕਿ ਉਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ, ਸਭ ਕੁਝ ਹਮੇਸ਼ਾ ਮੌਜੂਦ ਸੀ।

DTK ਨੂੰ ਇੱਕ ਸਟੈਂਡਅਲੋਨ ਪੈਕੇਜ ਵਿੱਚ ਬਦਲਣ ਦਾ ਮਤਲਬ ਵਿਸਥਾਰ ਨਹੀਂ, ਸਗੋਂ ਸਰਜਰੀ ਸੀ। ਮੈਨੂੰ ਹੋਰ ਫੀਚਰਾਂ ਦੀ ਨਹੀਂ, ਸਗੋਂ ਘੱਟ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਲੋੜ ਸੀ।

Dynamic Theme Kit ਨੂੰ ਐਕਸਟ੍ਰੈਕਟ ਕਰਨਾ

ਸਭ ਤੋਂ ਔਖਾ ਕੰਮ ਕੋਡਬੇਸ ਨਾਲ ਬੈਠ ਕੇ ਇਹ ਪੁੱਛਣਾ ਸੀ, ਹਰ ਫੰਕਸ਼ਨ ਅਤੇ ਹਰ ਐਕਸਪੋਰਟ ਲਈ: ਕੀ ਇਹ ਥੀਮਿੰਗ ਲੌਜਿਕ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਜਾਂ ਇਹ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ? ਮੈਂ ਸਟਾਈਲਿੰਗ ਪ੍ਰੈਸੈਟਸ ਨੂੰ ਹਟਾ ਦਿੱਤਾ। ਮੈਂ ਇਸ ਅੰਦਾਜ਼ੇ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਕਿ ਇਸਨੂੰ ਵਰਤਣ ਵਾਲਾ ਇੱਕ React ਐਪਲੀਕੇਸ਼ਨ ਹੋਵੇਗਾ। ਮੈਂ ਡਿਫੌਲਟ ਕਲਰ ਪੈਲੇਟਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਿਲੀਟ ਕਰ ਦਿੱਤਾ। ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਡਿਫੌਲਟਸ ਵਿੱਚ ਇੱਕ navy-and-slate ਕਾਰਪੋਰੇਟ ਐਸਥੈਟਿਕ ਸ਼ਾਮਲ ਸੀ। ਉਸਨੂੰ ਹਟਾਉਣਾ ਪਿਆ। ਇੱਕ ਪੈਕੇਜ ਤੁਹਾਡੇ ਬ੍ਰਾਂਡ ਦੇ ਰੰਗ ਸ਼ਿਪ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਨਵਾਂ ਕਿੱਟ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕੰਮ ਕਰੇਗਾ। ਇਹ ਇੱਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਆਬਜੈਕਟ ਲੈਂਦਾ ਹੈ—ਕੁਝ ਕਲਰ ਵੈਲਯੂਜ਼, ਕੁਝ ਸਪੇਸਿੰਗ ਨੰਬਰ, ਕੁਝ ਟਾਈਪੋਗ੍ਰਾਫੀ ਸਕੇਲ—ਅਤੇ ਇਹ CSS custom properties ਤਿਆਰ ਕਰਦਾ ਹੈ। ਬੱਸ ਇੰਨਾ ਹੀ। ਇਹ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਉਹ ਤੁਹਾਡੇ DOM ਵਿੱਚ ਕਿੱਥੇ ਜਾਣਗੇ। ਇਸਨੂੰ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਜੇਕਰ ਤੁਸੀਂ Tailwind, Styled Components, ਜਾਂ plain HTML ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਇਹ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਵੇਰੀਏਬਲਜ਼ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਚੁਣਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ।

ਉਹ ਪਾਬੰਦੀ ਪਹਿਲਾਂ ਸੀਮਤ ਲੱਗੀ। ਪਰ ਬਾਅਦ ਵਿੱਚ ਇਹ ਆਜ਼ਾਦੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਈ।

ਜਦੋਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਟੁੱਟਦਾ ਹੈ

ਕੁਝ ਵੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਨੂੰ ਸਬੂਤ ਦੀ ਲੋੜ ਸੀ ਕਿ ਇਹ ਐਬਸਟਰੈਕਸ਼ਨ (abstraction) ਅਸਲ ਵਿੱਚ ਸਹੀ ਕੰਮ ਕਰ ਰਹੀ ਹੈ। ਮੈਂ ਆਪਣੇ ਆਰਕਾਈਵ ਵਿੱਚੋਂ ਤਿੰਨ ਛੋਟੇ ਨਿੱਜੀ ਪ੍ਰੋਜੈਕਟ ਕੱਢੇ: ਇੱਕ markdown preview tool, ਇੱਕ habit tracker, ਅਤੇ ਇੱਕ ਇਵੈਂਟ ਲਈ landing page। ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇੱਕੋ ਫਰੇਮਵਰਕ ਜਾਂ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ ਸਾਂਝਾ ਨਹੀਂ ਸੀ। ਮੈਂ ਹਰੇਕ ਵਿੱਚ DTK ਨੂੰ ਲੋਕਲ ਇੰਸਟਾਲ ਕੀਤਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਥੀਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ।

ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਤੁਰੰਤ ਫੇਲ੍ਹ ਹੋ ਗਈ। DTK ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਵੇਰੀਏਬਲ ਦੇ ਨਾਮ ਬਹੁਤ ਜ਼ਿਆਦਾ ਖਾਸ ਸਨ। ਇਹ --primary-action ਅਤੇ --background-overlay ਵਰਗੇ ਟੋਕਨ ਆਊਟਪੁੱਟ ਕਰ ਰਿਹਾ ਸੀ ਜੋ ਇੱਕ ਖਾਸ UI ਲੇਆਉਟ ਦਾ ਸੰਕੇਤ ਦਿੰਦੇ ਸਨ। Markdown previewer ਵਿੱਚ, ਉਹ ਨਾਮ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਰੱਖਦੇ ਸਨ। ਉੱਥੇ ਕੋਈ action ਬਟਨ ਨਹੀਂ ਸੀ। ਉੱਥੇ ਕੋਈ overlay ਨਹੀਂ ਸੀ। ਮੈਂ ਜਨਰੇਸ਼ਨ ਲੌਜਿਕ ਨੂੰ ਬਦਲ ਕੇ ਨਿਊਟਰਲ, ਸਟ੍ਰਕਚਰਲ ਨਾਮ ਬਣਾਏ ਜੋ ਵਿਜੇਟ ਦੀ ਬਜਾਏ ਵੈਲਯੂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਸਨ।

ਮੈਨੂੰ ਇਹ ਵੀ ਪਤਾ ਲੱਗਾ ਕਿ ਮੇਰੀਆਂ ਡਿਫੌਲਟ ਵੈਲਯੂਜ਼ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਸਨ। ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਅਧੂਰੀ ਕੌਂਫਿਗ ਭੇਜਦਾ ਸੀ, ਤਾਂ DTK ਉਹਨਾਂ ਖਾਲੀਆਂ ਥਾਵਾਂ ਨੂੰ ਅਜਿਹੀਆਂ ਵੈਲਯੂਜ਼ ਨਾਲ ਭਰ ਦਿੰਦਾ ਸੀ ਜੋ ਇੱਕ ਸੰਘਣੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਤਾਂ ਠੀਕ ਲੱਗਦੀਆਂ ਸਨ ਪਰ ਇੱਕ ਖਾਲੀ landing page 'ਤੇ ਟੁੱਟ ਜਾਂਦੀਆਂ ਸਨ। ਮੈਂ transparent defaults ਵੱਲ ਚਲੇ ਗਿਆ ਜਿੱਥੇ ਗੁੰਮ ਹੋਏ ਟੋਕਨ ਸਿਰਫ਼ ਰੈਂਡਰ ਹੀ ਨਹੀਂ ਹੁੰਦੇ ਸਨ, ਜਿਸ ਨਾਲ ਵਰਤਣ ਵਾਲਾ ਪ੍ਰੋਜੈਕਟ ਆਪਣੇ ਆਪ ਫਾਲਬੈਕਸ (fallbacks) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦਾ ਸੀ।

ਫਿਰ ਗੱਲ ਆਈ ਡੌਕੂਮੈਂਟੇਸ਼ਨ ਦੀ। ਜੋ ਮੇਰੇ ਲਈ ਸਪੱਸ਼ਟ ਸੀ—"ਬੱਸ ਇੱਕ ਕੌਂਫਿਗ ਆਬਜੈਕਟ ਪਾਸ ਕਰੋ"—ਉਹ ਅੱਧੀ ਰਾਤ ਨੂੰ README ਪੜ੍ਹਨ ਵਾਲੇ ਕਿਸੇ ਵਿਅਕਤੀ ਲਈ ਅਸਪਸ਼ਟ ਸੀ। ਮੈਂ ਇਸਨੂੰ ਅਸਲ ਆਬਜੈਕਟਸ, ਅਸਲ ਫਾਈਲ ਪਾਥਾਂ, ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਸਪਸ਼ਟ ਵਿਆਖਿਆ ਦੇ ਨਾਲ ਦੁਬਾਰਾ ਲਿਖਿਆ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ ਬਨਾਮ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਛੋਟੇ ਨਿੱਜੀ ਪ੍ਰੋਜੈਕਟ ਟੈਸਟ ਬੈੱਡ ਵਜੋਂ ਕੰਮ ਕਰੇ। ਉਹਨਾਂ ਵਿੱਚ ਜੋਖਮ ਘੱਟ ਸੀ, ਪਰ ਉਹਨਾਂ ਨੇ ਅਸਲ 결ਲਾਂ (flaws) ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਂਦਾ ਜੋ ਮੈਂ ਸਿਰਫ਼ ਸੋਰਸ ਕੋਡ ਨੂੰ ਇਕੱਲੇ ਦੇਖ ਕੇ ਨਹੀਂ ਫੜ ਸਕਦਾ ਸੀ।

ਅਸਲੀ ਟੈਸਟ: Web Weavers World ਵਿਖੇ ਪ੍ਰੋਡਕਸ਼ਨ

ਨਿੱਜੀ ਪ੍ਰੋਜੈਕਟ ਸੈਂਡਬਾਕਸ (sandboxes) ਹੁੰਦੇ ਹਨ। ਉਹਨਾਂ ਵਿੱਚ ਕੋਈ ਸਮਾਂ ਸੀਮਾ (deadlines), ਸਟੇਕਹੋਲਡਰ (stakeholders), ਜਾਂ ਕੋਈ ਪੁਰਾਣਾ (legacy) CSS ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਤੁਹਾਡੇ ਪੈਕੇਜ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਹੋਵੇ। ਅਸਲੀ ਪਰਖ ਉਦੋਂ ਹੋਈ ਜਦੋਂ ਮੈਂ DTK ਨੂੰ ਆਪਣੀ ਬਿਜ਼ਨਸ ਸਾਈਟ, Web Weavers World ਵਿੱਚ ਇੰਟੀਗ੍ਰੇਟ ਕੀਤਾ। ਇਹ ਇੱਕ ਲਾਈਵ ਪ੍ਰਾਪਰਟੀ ਸੀ ਜਿਸ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸਟਾਈਲ, ਕਲਾਇੰਟ ਦੀਆਂ ਉਮੀਦਾਂ ਅਤੇ ਐਨਾਲਿਟਿਕਸ (analytics) ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਸੀ। ਜੇਕਰ ਪੈਕੇਜ ਨਾਲ ਕੁਝ ਖਰਾਬ ਹੋ ਜਾਂਦਾ, ਤਾਂ ਮੈਂ ਸਿਰਫ਼ ਰੈਪੋ (repo) ਡਿਲੀਟ ਕਰਕੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ।

ਮੈਂ DTK ਨੂੰ ਬਿਲਡ ਪਾਈਪਲਾਈਨ (build pipeline) ਵਿੱਚ ਜੋੜਿਆ, ਇਸਨੂੰ ਇੱਕ ਨਵੇਂ ਰੰਗ ਦੇ ਕਨਫਿਗਰੇਸ਼ਨ (color configuration) ਵੱਲ ਮੋੜਿਆ, ਅਤੇ ਇਸਨੂੰ CSS ਵੇਰੀਏਬਲਜ਼ (variables) ਦਾ ਇੱਕ ਨਵਾਂ ਸੈੱਟ ਤਿਆਰ ਕਰਨ ਦਿੱਤਾ। ਇਸ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਦੁਪਹਿਰ ਲੱਗੀ, ਇੱਕ ਹਫ਼ਤਾ ਨਹੀਂ। ਇਹ ਇੱਕ ਸੰਕੇਤ ਸੀ। ਪਹਿਲਾਂ, ਇੱਕ ਨਵਾਂ ਥੀਮ ਜੋੜਨ ਦਾ ਮਤਲਬ ਸੀ ਨਵਾਂ CSS ਲਿਖਣਾ, ਵੀਹ ਫਾਈਲਾਂ ਵਿੱਚ ਹਾਰਡਕੋਡਡ (hardcoded) ਹੈਕਸ (hex) ਵੈਲਯੂਜ਼ ਲੱਭਣਾ, ਅਤੇ ਇਹ ਉਮੀਦ ਕਰਨਾ ਕਿ ਮੈਂ ਕੋਈ ਐਜ ਕੇਸ (edge case) ਨਾ ਛੱਡ ਦੇਵਾਂ। ਹੁਣ ਮੈਂ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਇੱਕ ਪੈਲੇਟ (palette) ਜੋੜਦਾ ਹਾਂ, DTK ਵੇਰੀਏਬਲਜ਼ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਾਈਟ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਥੀਮ ਲੌਜਿਕ ਇੱਕ ਕਮਜ਼ੋਰ ਮੈਨੂਅਲ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਦਲ ਕੇ ਅਜਿਹੀ ਚੀਜ਼ ਬਣ ਗਿਆ ਹੈ ਜਿਸ 'ਤੇ ਮੈਂ ਇੰਨਾ ਭਰੋਸਾ ਕਰਦਾ ਹਾਂ ਕਿ ਇਸਨੂੰ ਸਹਿਯੋਗੀਆਂ (collaborators) ਨੂੰ ਸੌਂਪ ਸਕਦਾ ਹਾਂ।

ਤਿੰਨ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਨੇ ਮੇਰੇ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੱਤਾ

ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚੋਂ ਲੰਘਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਇੱਕ ਮਾਨਸਿਕ ਚੈੱਕਲਿਸਟ (checklist) ਤਿਆਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੋ ਗਿਆ, ਜਿਸਦੀ ਵਰਤੋਂ ਮੈਂ ਹੁਣ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਐਬਸਟਰੈਕਟ (abstract) ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਰਦਾ ਹਾਂ:

  • ਕੀ ਇਹ ਵੇਰੀਏਬਲ ਸੱਚਮੁੱਚ ਜੈਨਰਿਕ (generic) ਹੈ? ਜੇਕਰ ਨਾਮ ਜਾਂ ਲੌਜਿਕ ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਦੇ ਕਿਸੇ ਡੋਮੇਨ ਸੰਕਲਪ (domain concept) ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਉੱਥੇ ਹੀ ਰਹਿਣ ਦਿਓ।
  • ਕੀ ਇਹ ਪੈਕੇਜ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ? ਬਿਜ਼ਨਸ ਨਿਯਮ, ਬ੍ਰਾਂਡ ਪਛਾਣ, ਅਤੇ ਲੇਆਉਟ ਅਸੰਪਸ਼ਨਜ਼ (layout assumptions) ਐਪ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। ਸਟੈਂਡਰਡਾਈਜ਼ਡ ਆਉਟਪੁੱਟ (standardized output) ਤਿਆਰ ਕਰਨ ਵਾਲਾ ਪਲੰਬਿੰਗ (plumbing) ਪੈਕੇਜ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
  • ਕੀ ਮੈਂ ਇੱਕ ਮੁੜ ਵਰਤੋਂਯੋਗ (reusable) ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਜਾਂ ਪ੍ਰੋਜੈਕਟ-ਵਿਸ਼ੇਸ਼ ਸਮੱਸਿਆ ਨੂੰ? ਇਸਦਾ ਇਮਾਨਦਾਰੀ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਸਭ ਤੋਂ ਔਖਾ ਹੈ। ਅਸੀਂ ਸੋਚਣਾ ਪਸੰਦ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਹੱਲ ਸਰਵਵਿਆਪੀ (universal) ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਸਥਾਨਕ (local) ਹੁੰਦੇ ਹਨ।

ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਨਾਲ ਮੈਂ ਆਪਣੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਹੋ ਗਿਆ, ਅਕਸਰ ਕੋਡ ਜੋੜਨ ਦੀ ਬਜਾਏ ਉਸਨੂੰ ਹਟਾ ਕੇ। DTK ਨੇ ਮੈਨੂੰ ਸਿਖਾਇਆ ਕਿ ਮੁੜ ਵਰਤੋਂ (reuse) ਕੋਈ ਅਜਿਹਾ ਤੋਹਫ਼ਾ ਨਹੀਂ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਦਿੰਦੇ ਹੋ। ਇਹ ਇੱਕ ਅਨੁਸ਼ਾਸਨ ਹੈ ਜੋ ਤੁਸੀਂ ਸਹੂਲਤ ਨੂੰ ਨਾ ਕਹਿ ਕੇ ਅਭਿਆਸ ਕਰਦੇ ਹੋ।

ਰੀਫੈਕਟਰੀੰਗ (Refactoring) ਬਾਰੇ ਸੋਚਣ ਦਾ ਇੱਕ ਵੱਖਰਾ ਤਰੀਕਾ

ਮੈਂ ਪਹਿਲਾਂ ਰੀਫੈਕਟਰਸ (refactors) ਨੂੰ ਇਸ ਗੱਲ ਨਾਲ ਮਾਪਦਾ ਸੀ ਕਿ ਉਹਨਾਂ ਨੇ ਕੋਡ ਨੂੰ ਕਿੰਨਾ ਛੋਟਾ ਕਰ ਦਿੱਤਾ ਹੈ। ਘੱਟ ਲਾਈਨਾਂ ਪ੍ਰਗਤੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਸਨ। ਹੁਣ ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਇਸ ਗੱਲ ਨਾਲ ਮਾਪਦਾ ਹਾਂ ਕਿ ਉਹ ਕਿੰਨੇ ਨਵੇਂ ਰਾਹ ਖੋਲ