ਸਭ ਕੁਝ ਸਵੀਕਾਰ ਕਰੋ, ਕੁਝ ਵੀ ਨਾ ਸਮਝੋ

ਸਭ ਕੁਝ ਸਵੀਕਾਰ ਕਰੋ, ਕੁਝ ਵੀ ਨਾ ਸਮਝੋ

ਕੋਡ ਸੁਝਾਵਾਂ (code suggestions) ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ 'enter' ਦਬਾਉਣਾ, ਉਨ੍ਹਾਂ ਨੂੰ ਸਕ੍ਰੋਲ ਕਰਕੇ ਲੰਘਣ ਨਾਲੋਂ ਘੱਟ ਮਿਹਨਤ ਵਾਲਾ ਕੰਮ ਹੈ। ਇੱਕ ਕੀ-ਸਟ੍ਰੋਕ (keystroke) ਕੋਡ ਨੂੰ ਤੁਹਾਡਾ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਪਰ ਉਸ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਾ ਅਤੇ ਸਮਝਣਾ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਤੇਜ਼ ਨਹੀਂ ਹੋਇਆ ਹੈ।

ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ ਅਤੇ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਉਸਨੂੰ ਸਮਝਦੇ ਹੋ, ਇਸ ਵਿਚਕਾਰ ਇੱਕ ਪਾੜਾ ਹੈ। ਇਹ ਪਾੜਾ ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

ਟੈਕਨੀਕਲ ਡੈਬਟ (Technical debt) ਦੇ ਪਹਿਲਾਂ ਸਪੱਸ਼ਟ ਕਾਰਨ ਹੁੰਦੇ ਸਨ। ਜਾਂ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਸਮਾਂ ਬਹੁਤ ਘੱਟ ਸੀ ਜਾਂ ਤੁਸੀਂ ਕੰਮ ਵਿੱਚ ਕੁੱਟਿੰਗ ਕਾਰਨਰ (cut corners) ਕਰ ਰਹੇ ਸੀ। ਤੁਸੀਂ ਕਾਰਨ ਦੱਸ ਸਕਦੇ ਸੀ। ਹੁਣ ਤੁਸੀਂ ਇੱਕ ਸ਼ਾਂਤ ਮੰਗਲਵਾਰ ਨੂੰ ਵੀ ਡੈਬਟ ਬਣਾ ਲੈਂਦੇ ਹੋ। ਤੁਸੀਂ ਲਗਾਤਾਰ ਛੇ ਸੁਝਾਵਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿਉਂਕਿ ਉਹ ਠੀਕ ਲੱਗਦੇ ਹਨ। ਕਿਸੇ ਨੇ ਤੁਹਾਨੂੰ ਜਲਦਬਾਜ਼ੀ ਨਹੀਂ ਕਰਵਾਈ, ਪਰ ਕੋਡ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ।

ਬ੍ਰਾਇਨ ਕਰਨੀਘਨ (Brian Kernighan) ਨੇ 1974 ਵਿੱਚ ਕਿਹਾ ਸੀ ਕਿ ਡੀਬੱਗਿੰਗ (debugging) ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਨਾਲੋਂ ਦੁੱਗਣੀ ਮੁਸ਼ਕਲ ਹੈ। ਉਹ ਉਸ ਕੋਡ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਸਨ ਜੋ ਇਨਸਾਨ ਲਿਖਦੇ ਹਨ। ਘੱਟੋ-ਘੱਟ ਇਨਸਾਨ ਆਪਣੇ ਕੰਮ ਨੂੰ ਸਮਝਦੇ ਹਨ।

ਅੱਜ, ਇੱਕ ਸੁਝਾਅ ਲਿੰਟਰ (linter) ਨੂੰ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਟੈਸਟਾਂ ਨੂੰ ਵੀ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਰ ਵੀ ਇਹ ਇੱਕ ਗਲਤ ਅਨੁਮਾਨ 'ਤੇ ਅਧਾਰਤ ਹੋ ਸਕਦਾ ਹੈ। ਅਜਿਹਾ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਸੁਝਾਅ ਨੂੰ ਕੋਡ ਦੀ ਬਜਾਏ ਆਉਟਪੁੱਟ (output) ਵਜੋਂ ਪੜ੍ਹਦੇ ਹਨ। ਜੋ ਆਉਟਪੁੱਟ ਵਧੀਆ ਲੱਗਦਾ ਹੈ, ਉਸ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਜੇਕਰ ਕੋਈ ਮਾਡਲ ਕੋਡ ਅਤੇ ਟੈਸਟ ਦੋਵੇਂ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਵਿਦਿਆਰਥੀ ਦੇ ਆਪਣੇ ਜਵਾਬਾਂ ਨਾਲ ਹੀ ਹੋਮਵਰਕ ਦੀ ਗ੍ਰੇਡਿੰਗ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਲੌਜਿਕ (logic) ਸਹੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਐਜ ਕੇਸ (edge cases) ਕਵਰ ਕੀਤੇ ਗਏ ਹਨ ਜਾਂ ਨਹੀਂ। ਜਦੋਂ ਕੋਡ ਤੁਹਾਡੇ ਆਪਣੇ ਐਡੀਟਰ ਅਤੇ ਤੁਹਾਡੀ ਆਪਣੀ ਸ਼ੈਲੀ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਸ ਗੱਲ ਨੂੰ ਭੁੱਲਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਹ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ:

• ਤੁਸੀਂ ਉਸ ਕੋਡ ਨੂੰ ਡੀਬੱਗ ਕਰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਕਦੇ ਪੜ੍ਹਿਆ ਹੀ ਨਹੀਂ। ਜਦੋਂ ਹਫ਼ਤਿਆਂ ਬਾਅਦ ਕੁਝ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜ਼ੀਰੋ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।
• ਐਜ ਕੇਸ (Edge cases) ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸੁਝਾਅ 'ਹੈਪੀ ਪਾਥ' (happy path) ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਨਲ ਚੈੱਕ (null check) ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਪਰ ਇਹ ਉਸ ਖਾਸ ਲੌਜਿਕ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਨੂੰ ਲੋੜ ਹੈ।
• ਤੁਸੀਂ ਆਪਣੇ ਪਲ ਰਿਕੁਐਸਟ (pull requests) ਦਾ ਬਚਾਅ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜੇਕਰ ਕੋਈ ਰਿਵਿਊਅਰ ਪੁੱਛਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਵਿਧੀ (method) ਕਿਉਂ ਚੁਣੀ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਫੈਸਲਾ ਨਹੀਂ ਲਿਆ ਸੀ। ਤੁਸੀਂ ਬੱਸ ਉਸਨੂੰ ਰੱਦ ਨਹੀਂ ਕੀਤਾ ਸੀ।

ਇਹ ਟੂਲ (tools) ਉਪਯੋਗੀ ਹਨ। ਉਹ ਤੁਹਾਨੂੰ ਕੋਡਬੇਸ (codebases) ਦੀ ਖੋਜ ਕਰਨ ਜਾਂ ਨਵੇਂ ਫੀਚਰਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਸਮੱਸਿਆ ਤੁਹਾਡੇ ਰਵੱਈਏ (posture) ਵਿੱਚ ਹੈ। ਤੁਹਾਨੂੰ ਹਰ ਸੁਝਾਅ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਉਸ 'ਤੇ ਫੈਸਲਾ ਲੈਣ ਵਾਲੀ ਚੀਜ਼ ਵਜੋਂ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਝਲਕ ਮਾਰਨ ਵਾਲੀ ਚੀਜ਼ ਵਜੋਂ।

ਬੁਆਇਲਰਪਲੇਟ (boilerplate) ਜਾਂ ਤੇਜ਼ ਸਕ੍ਰਿਪਟਾਂ ਲਈ, ਰਫ਼ਤਾਰ ਠੀਕ ਹੈ। ਪਰ ਬਿਜ਼ਨਸ ਲੌਜਿਕ (business logic) ਜਾਂ ਸੁਰੱਖਿਆ ਲਈ, ਤੁਹਾਡਾ ਤਰੀਕਾ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਡ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹੋ ਜਿਵੇਂ ਕਿ ਇਹ ਤੁਹਾਡਾ ਹੋਵੇਗਾ। ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡਾ ਹੀ ਹੋਵੇਗਾ।

ਇਸ ਦੀ ਬਜਾਏ ਇਹ ਕੰਮ ਕਰੋ:

• ਕੋਡ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ ਨਾਲ ਆਪਣੇ ਹੱਲ ਬਾਰੇ ਚਰਚਾ ਕਰੋ।
• ਡਿਫ (diff) ਦੀ ਸਮੀਖਿਆ ਇਸ ਤਰ੍ਹਾਂ ਕਰੋ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਖੁਦ ਲਿਖਿਆ ਹੋਵੇ।
• ਕੋਡ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੂਲ ਨੂੰ ਆਪਣੇ ਤਰਕ (reasoning) ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਕਹੋ।
• ਸੁਝਾਵਾਂ ਨੂੰ ਇੱਕ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰ (junior developer) ਦੇ ਕੰਮ ਵਾਂਗ ਸਮਝੋ। ਇਹ ਉਪਯੋਗੀ ਹੈ ਪਰ ਇਹ ਅੰਤਿਮ ਸੱਚ (ground truth) ਨਹੀਂ ਹੈ।
• ਉਹਨਾਂ ਲਾਈਨਾਂ 'ਤੇ ਰਫ਼ਤਾਰ ਘਟਾਓ ਜੋ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰਦੀਆਂ ਹਨ। ਹੈਰਾਨੀ ਇੱਕ ਸੰਕੇਤ ਹੈ।

ਕੀ-ਸਟ੍ਰੋਕ ਸਸਤਾ ਹੋ ਗਿਆ ਹੈ। ਪਰ ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ। ਸਮਝ ਤੋਂ ਬਿਨਾਂ ਰਫ਼ਤਾਰ ਸਿਰਫ਼ ਤੇਜ਼ ਡੈਬਟ (fast debt) ਹੈ।

ਸੋਮਾ: https://dev.to/cloudx/accept-all-understand-none-4dob

ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi