QA ਤੋਂ ਕੰਪੋਨੈਂਟ ਆਰਕੀਟੈਕਟ ਤੱਕ
AI ਕੋਡ ਐਡੀਟਰ ਹੁਣ ਜ਼ਿਆਦਾਤਰ ਬੋਇਲਰਪਲੇਟ (boilerplate) ਕੋਡ ਨੂੰ ਸੰਭਾਲ ਲੈਂਦੇ ਹਨ। ਇਹ ਇੱਕ ਖ਼ਤਰਨਾਕ ਭਰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਜੇਕਰ AI ਕੋਡ ਲਿਖਦਾ ਹੈ ਅਤੇ ਉਹ ਕੰਪਾਈਲ (compile) ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਇਹ ਸੋਚ ਛੋਟੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (features) ਲਈ ਤਾਂ ਠੀਕ ਹੈ, ਪਰ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮਾਂ ਲਈ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ।
ਇੱਕ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਕੰਪੋਨੈਂਟ ਕੋਈ ਇੱਕ ਵਾਰ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਫੀਚਰ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ (infrastructure) ਹੈ। ਇੱਕ ਬਟਨ ਜਾਂ ਇਨਪੁਟ ਫੀਲਡ ਸੈਂਕੜੇ ਉਤਪਾਦਾਂ ਵਿੱਚ ਲੱਖਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰੇਗੀ।
ਅਸਲ ਫਾਇਦਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲਿਖਦੇ ਹੋ। ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਅਸਫਲਤਾ ਦਾ ਅੰਦਾਜ਼ਾ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਗਾਉਂਦੇ ਹੋ।
ਤੁਹਾਨੂੰ 'ਬਿਲਡਰ' (builder) ਮਾਨਸਿਕਤਾ ਤੋਂ 'ਬ੍ਰੇਕਰ' (breaker) ਮਾਨਸਿਕਤਾ ਵੱਲ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਨੂੰ TDD, BDD, ਅਤੇ Spec-Driven Development ਰਾਹੀਂ ਟੈਸਟਿੰਗ ਨੂੰ ਅਪਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ "Happy Path" ਲਈ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਉਹ Figma ਫਾਈਲ ਨਾਲ ਮੇਲ ਕਰਦੇ ਹਨ ਅਤੇ ਰੁਕ ਜਾਂਦੇ ਹਨ। ਪਰ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਅਸਲ ਦੁਨੀਆ ਦੀ ਉਲਝਣ (chaos) ਵਿੱਚ ਟਿਕਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਟੀਮ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਔਖੇ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ:
- ਡਿਜ਼ਾਈਨਰ: ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਕੋਈ ਟੈਕਸਟ ਸਟ੍ਰਿੰਗ 400 ਅੱਖਰਾਂ ਦੀ ਹੋਵੇ? ਕੀ UI ਟੁੱਟ ਜਾਵੇਗਾ?
- ਇੰਜੀਨੀਅਰ: ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਕੋਈ ਉਪਭੋਗਤਾ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਦਸ ਵਾਰ ਟੌਗਲ (toggle) 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ? ਕੀ ਸਟੇਟ (state) ਖਰਾਬ ਹੋ ਜਾਵੇਗੀ?
- ਐਕਸੈਸਬਿਲਟੀ (Accessibility): ਇੱਕ ਸਕ੍ਰੀਨ ਰੀਡਰ ਸਿਰਫ਼ ਕੀਬੋਰਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਡ੍ਰੌਪਡਾਊਨ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲੇਗਾ?
AI ਟੂਲ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਚੰਗੇ ਹਨ ਪਰ ਅੰਦਾਜ਼ੇ ਲਗਾਉਣ ਵਿੱਚ ਮਾੜੇ ਹਨ। ਉਹ ਕਮਜ਼ੋਰ (brittle) ਕੰਪੋਨੈਂਟਸ ਬਣਾਉਂਦੇ ਹਨ।
ਆਪਣੇ ਕੰਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਇਸ ਵਰਕਫਲੋ (workflow) ਦੀ ਵਰਤੋਂ ਕਰੋ:
- ਸਪੈਕ (Spec) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (Tokens, Accessibility, API)।
- ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਟੈਸਟ ਅਤੇ ਸਟੋਰੀਜ਼ ਲਿਖੋ।
- ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਕੋਡ ਤਿਆਰ ਕਰਨ ਲਈ AI ਦੀ ਵਰਤੋਂ ਕਰੋ।
TDD ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਲਟਾ ਦਿੰਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਬੱਗ (bugs) ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਪਹਿ
QA ਤੋਂ ਕੰਪੋਨੈਂਟ ਆਰਕੀਟੈਕਟ ਤੱਕ: ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਤੋੜਨਾ ਵਿਸ਼ਵ-ਦਰਜੇ ਦੇ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮਾਂ ਦਾ ਰਾਜ਼ ਕਿਉਂ ਹੈ
ਮੈਂ ਕਈ ਸਾਲ ਕੁਆਲਿਟੀ ਐਸ਼ੋਰੈਂਸ (QA) ਦੇ ਮੈਦਾਨ ਵਿੱਚ ਬਿਤਾਏ ਹਨ, ਬੱਗਸ (bugs), ਐਜ ਕੇਸ (edge cases), ਅਤੇ ਉਹਨਾਂ ਬਾਰੀਕ ਤਰੀਕਿਆਂ ਦੀ ਭਾਲ ਕਰਦੇ ਹੋਏ ਜਿਨ੍ਹਾਂ ਰਾਹੀਂ ਇੱਕ ਯੂਜ਼ਰ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਮੈਂ ਕੰਪੋਨੈਂਟ ਆਰਕੀਟੈਕਟ (Component Architect) ਦੀ ਭੂਮਿਕਾ ਵਿੱਚ ਆਇਆ, ਤਾਂ ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੇਰੀ ਸਭ ਤੋਂ ਕੀਮਤੀ ਕੌਸ਼ਲ ਕੋਡ ਲਿਖਣ ਦੀ ਮੇਰੀ ਯੋਗਤਾ ਨਹੀਂ ਸੀ, ਸਗੋਂ ਕੋਡ ਨੂੰ ਤੋੜਨ ਦੀ ਮੇਰੀ ਯੋਗਤਾ ਸੀ।
ਡਿਜ਼ਾਈਨ ਸਿਸਟਮਾਂ ਦੀ ਦੁਨੀਆ ਵਿੱਚ, ਅਸੀਂ ਅਕਸਰ 'ਹੈਪੀ ਪਾਥ' (happy path) 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਾਂ—ਕਿ ਇੱਕ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਸਭ ਕੁਝ ਸੰਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਪਰ ਇੱਕ ਵਿਸ਼ਵ-ਦਰਜੇ ਦਾ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਇਸ ਗੱਲ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ 'ਅਨਹੈਪੀ ਪਾਥ' (unhappy path) ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ।
ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ QA ਮਾਈਂਡਸੈੱਟ
ਇੱਕ QA ਵਜੋਂ, ਮੇਰਾ ਕੰਮ ਇਹ ਪੁੱਛਣਾ ਸੀ: 'ਕੀ ਹੋਵੇਗਾ ਜੇ...?'
- ਕੀ ਹੋਵੇਗਾ ਜੇ ਯੂਜ਼ਰ ਟੈਕਸਟ ਫੀਲਡ ਵਿੱਚ ਇੱਕ ਇਮੋਜੀ ਭਰਦਾ ਹੈ?
- ਕੀ ਹੋਵੇਗਾ ਜੇ API ਇੱਕ 500 error ਵਾਪਸ ਕਰਦਾ ਹੈ?
- ਕੀ ਹੋਵੇਗਾ ਜੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਕੰਟੇਨਰ ਵਿੱਚ ਰੈਂਡਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਬਹੁਤ ਛੋਟਾ ਹੈ?
ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਮਾਈਂਡਸੈੱਟ ਕੰਪੋਨੈਂਟ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੇ ਕੰਪੋਨੈਂਟ ਬਣਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਜੋ ਸਿਰਫ਼ 'ਕੰਮ ਕਰਦੇ' ਹਨ ਅਤੇ ਅਜਿਹੇ ਕੰਪੋਨੈਂਟ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ ਜੋ 'ਲਚਕਦਾਰ' (resilient) ਹੁੰਦੇ ਹਨ।
ਬਿਹਤਰ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਕੋਡ ਨੂੰ ਤੋੜਨਾ
ਇੱਕ ਲਚਕਦਾਰ ਕੰਪੋਨੈਂਟ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ:
- ਗ੍ਰੇਸਫੁੱਲੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ (Fails Gracefully): ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਕਰਦਾ।
- ਐਜ ਕੇਸਾਂ (Edge Cases) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ: ਇਹ ਅਣਕਿਆਸੇ ਇਨਪੁਟ ਜਾਂ ਸਟੇਟਸ ਨੂੰ ਬਿਨਾਂ ਟੁੱਟੇ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ।
- ਐਕਸੈਸਿਬਲ (Accessible) ਹੈ: ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਚਾਹੇ ਉਹ ਸਕ੍ਰੀਨ ਨਾਲ ਕਿਵੇਂ ਵੀ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੋਵੇ।
ਇਹਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਡਿਜ਼ਾਈਨ ਫੇਜ਼ ਦੌਰਾਨ ਜਾਣਬੁੱਝ ਕੇ ਆਪਣੇ ਕੰਪੋਨ