ਜੂਨੀਅਰ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ
ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਡ ਸ਼ਿਪ ਕਰਨਾ ਇੱਕ ਬੁਨਿਆਦੀ ਸਟੈਂਡਰਡ ਹੈ। ਇਹ ਅੰਤਿਮ ਟੀਚਾ ਨਹੀਂ ਹੈ।
ਮੈਂ ਇੱਕ ਵਾਰ ਇੱਕ ਅਜਿਹੀ pull request ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ ਜਿਸ ਨੂੰ ਸਮਝਣ ਵਿੱਚ 45 ਮਿੰਟ ਲੱਗੇ। ਲੌਜਿਕ ਸਹੀ ਸੀ। ਟੈਸਟ ਪਾਸ ਹੋ ਗਏ ਸਨ। ਪਰ ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਗਿਆ ਸੀ ਜਿਵੇਂ ਕਿ ਇਸਨੂੰ ਸਿਰਫ਼ ਲੇਖਕ ਹੀ ਪੜ੍ਹੇਗਾ।
ਜਦੋਂ ਮੈਂ ਫੀਡਬੈਕ ਦਿੱਤਾ, ਤਾਂ ਡਿਵੈਲਪਰ ਨੇ ਕਿਹਾ, "ਪਰ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।"
ਉਹ ਸਹੀ ਸਨ। ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ। ਇਹੀ ਤਾਂ ਅਸਲ ਸਮੱਸਿਆ ਸੀ।
ਜੂਨੀਅਰ ਡਿਵੈਲਪਰ ਅਕਸਰ ਤਕਨੀਕੀ ਹੁਨਰਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਨ। ਪਰ ਅਸਲ ਕਮੀਆਂ ਅਕਸਰ ਆਦਤਾਂ ਅਤੇ ਮਾਨਸਿਕਤਾ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਥੇ ਉਹ ਸੂਖਮ ਗਲਤੀਆਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਹੌਲੀ ਕਰਦੀਆਂ ਹਨ:
ਦੂਜਿਆਂ ਦੀ ਬਜਾਏ ਆਪਣੇ ਲਈ ਲਿਖਣਾ ਕੋਡ ਲਿਖਣ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਵਾਰ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਅੱਜ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਇੱਕ ਫੰਕਸ਼ਨ ਦੋ ਸਾਲਾਂ ਵਿੱਚ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਅਣਜਾਣ ਵਿਅਕਤੀ 30 ਸੈਕਿੰਡ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ ਅਸਫਲ ਰਹੇ।
ਬਿਨਾਂ ਸਮਝੇ ਕੋਡ ਦੀ ਕਾਪੀ ਕਰਨਾ Stack Overflow ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਠੀਕ ਹੈ। ਪਰ ਇਹ ਜਾਣੇ ਬਿਨਾਂ ਕਿ ਇੱਕ regex pattern ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਉਸਦੀ ਕਾਪੀ ਕਰਨਾ ਖ਼ਤਰਨਾਕ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ codebase ਵਿੱਚ ਇੱਕ
black boxਬਣਾ ਲੈਂਦੇ ਹੋ। ਜਦੋਂ ਇਹ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ debug ਨਹੀਂ ਕਰ ਸਕਦੇ।ਬੇਲੋੜੀ ਜਟਿਲਤਾ (complexity) ਜੋੜਨਾ ਜੂਨੀਅਰ ਅਕਸਰ ਜਟਿਲਤਾ ਨੂੰ ਹੁਨਰ ਸਮਝ ਲੈਂਦੇ ਹਨ। ਉਹ ਸਧਾਰਨ ਕੰਮਾਂ ਲਈ ਵੀ design patterns ਲਾਗੂ ਕਰਦੇ ਹਨ। ਬੇਲੋੜੀ abstraction ਕੋਡ ਨੂੰ debug ਕਰਨਾ ਅਤੇ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੰਦੀ ਹੈ। abstraction ਉਦੋਂ ਹੀ ਜੋੜੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇਸਦੀ ਘਾਟ ਮਹਿਸੂਸ ਹੋਵੇ।
Error messages ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ Error messages ਮੁਫ਼ਤ ਦਸਤਾਵੇਜ਼ (documentation) ਹਨ। ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ stack trace ਦੇਖੋ, ਤੁਰੰਤ Google 'ਤੇ ਨਾ ਭੱਜੋ। ਪੂਰਾ ਸੰਦੇਸ਼ ਪੜ੍ਹੋ। ਇਹ ਅਕਸਰ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਲਾਈਨ ਫੇਲ ਹੋਈ ਅਤੇ ਕਿਉਂ।
ਬਹੁਤ ਜਲਦੀ ਜਾਂ ਬਹੁਤ ਦੇਰ ਨਾਲ ਮਦਦ ਮੰਗਣਾ 10 ਮਿੰਟ ਦੀ ਸਮੱਸਿਆ 'ਤੇ ਤਿੰਨ ਘੰਟੇ ਨਾ ਫਸੋ। ਇਹ ਅਕਸਮਰਤ (inefficient) ਹੈ। ਪਰ ਕਿਸੇ ਸੀਨੀਅਰ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ੌਟ ਭੇਜ ਕੇ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਸੰਦਰਭ (context) ਦੇ ਮੈਸੇਜ ਨਾ ਕਰੋ। 20-ਮਿੰਟ ਦਾ ਨਿਯਮ ਵਰਤਓ: ਇਸਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਿੱਚ 20 ਮਿੰਟ ਲਗਾਓ। ਜੋ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ ਉਸਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ। ਫਿਰ ਉਸ ਦਸਤਾਵੇਜ਼ ਦੇ ਨਾਲ ਮਦਦ ਮੰਗੋ।
ਜੋ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ ਉਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਇੱਕ ਨਵਾਂ utility ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, codebase ਵਿੱਚ ਸਰਚ ਕਰੋ। ਤੁਹਾਡੀ ਟੀਮ ਨੇ ਸ਼ਾਇਦ ਉਹ ਸਮੱਸਿਆ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਕਰ ਲਈ ਹੋਵੇਗੀ।
ਮਾੜੇ commit messages "fix bug" ਵਰਗਾ commit message ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਦੱਸੋ ਕਿ ਕੀ ਬਦਲਿਆ ਹੈ ਅਤੇ ਕਿਉਂ। Git history ਨੂੰ documentation ਵਜੋਂ ਲਵੋ।
Requirements ਨੂੰ ਕਾਨੂੰਨ ਮੰਨਣਾ Requirements ਵਿੱਚ ਅਕਸਰ edge cases ਰਹਿ ਜਾਂਦੇ ਹਨ। ਸਿਰਫ਼ ਉਹੀ ਨਾ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਦੱਸਿਆ ਗਿਆ ਹੈ। ਪੁੱਛੋ ਕਿ ਜਦੋਂ ਚੀਜ਼ਾਂ ਗਲਤ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
"Merged" ਬਟਨ 'ਤੇ ਰੁਕ ਜਾਣਾ ਜਦੋਂ ਤੁਹਾਡਾ PR merge ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜ਼ਿੰਮੇਵਾਰੀ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀ। ਆਪਣੇ feature ਨੂੰ QA ਤੱਕ ਫੋਲੋ ਕਰੋ। ਇਸਨੂੰ production ਵਿੱਚ ਦੇਖੋ। error reports ਪੜ੍ਹੋ।
ਸਭ ਤੋਂ ਵੱਡੀ ਕਮੀ ਜਵਾਬਦੇਹੀ ਦੀ ਹੈ। ਸੀਨੀਅਰ ਡਿਵੈਲਪਰ ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ ਲਿਖਦੇ। ਉਹ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ।
"done" (ਪੂਰਾ ਹੋਣ) ਲਈ ਆਪਟੀਮਾਈਜ਼ ਕਰਨਾ ਬੰਦ ਕਰੋ। "good" (ਚੰਗਾ ਹੋਣ) ਲਈ ਆਪਟੀਮਾਈਜ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।