ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਪੁਰਾਣੇ ਕੋਡ ਤੋਂ ਸ਼ਰਮਿੰਦਾ ਨਹੀਂ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਵਜੋਂ ਨਹੀਂ ਵਧ ਰਹੇ ਹੋ - ਅਤੇ ਮੈਂ ਇਸ ਰਾਏ ਨਾਲ ਸਹਿਮਤ ਹਾਂ. ਮੈਂ 40 ਸਾਲ ਪਹਿਲਾਂ, ਅਤੇ ਪੇਸ਼ੇਵਰ ਤੌਰ 'ਤੇ 30 ਸਾਲ ਪਹਿਲਾਂ ਮਨੋਰੰਜਨ ਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸ਼ੁਰੂ ਕੀਤੀ ਸੀ, ਇਸ ਲਈ ਮੇਰੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਹਨ। ਬਹੁਤ ਬਹੁਤ. ਕੰਪਿਊਟਰ ਸਾਇੰਸ ਦੇ ਪ੍ਰੋਫੈਸਰ ਹੋਣ ਦੇ ਨਾਤੇ, ਮੈਂ ਆਪਣੇ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਗਲਤੀਆਂ ਤੋਂ ਸਿੱਖਣਾ ਸਿਖਾਉਂਦਾ ਹਾਂ—ਉਨ੍ਹਾਂ ਦੀਆਂ, ਮੇਰੀਆਂ ਅਤੇ ਹੋਰਾਂ ਦੀਆਂ। ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਇਹ ਮੇਰੀਆਂ ਗਲਤੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ ਤਾਂ ਕਿ ਮੇਰੀ ਨਿਮਰਤਾ ਨਾ ਗੁਆਏ. ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਉਹ ਕਿਸੇ ਲਈ ਲਾਭਦਾਇਕ ਹੋਣਗੇ.

ਤੀਜਾ ਸਥਾਨ - ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਸੀ ਕੰਪਾਈਲਰ

ਮੇਰੇ ਸਕੂਲ ਦੇ ਅਧਿਆਪਕ ਦਾ ਮੰਨਣਾ ਸੀ ਕਿ ਰੋਮੀਓ ਅਤੇ ਜੂਲੀਅਟ ਨੂੰ ਇੱਕ ਤ੍ਰਾਸਦੀ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਪਾਤਰਾਂ ਵਿੱਚ ਕੋਈ ਦੁਖਦਾਈ ਦੋਸ਼ ਨਹੀਂ ਸੀ - ਉਹ ਸਿਰਫ਼ ਮੂਰਖਤਾ ਨਾਲ ਵਿਹਾਰ ਕਰਦੇ ਸਨ, ਜਿਵੇਂ ਕਿ ਕਿਸ਼ੋਰਾਂ ਨੂੰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਮੈਂ ਉਦੋਂ ਉਸ ਨਾਲ ਸਹਿਮਤ ਨਹੀਂ ਸੀ, ਪਰ ਹੁਣ ਮੈਂ ਉਸਦੀ ਰਾਏ ਵਿੱਚ ਤਰਕਸ਼ੀਲਤਾ ਦਾ ਇੱਕ ਅਨਾਜ ਵੇਖਦਾ ਹਾਂ, ਖਾਸ ਕਰਕੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੇ ਸਬੰਧ ਵਿੱਚ.

ਜਦੋਂ ਮੈਂ ਐਮਆਈਟੀ ਵਿੱਚ ਆਪਣਾ ਦੂਜਾ ਸਾਲ ਪੂਰਾ ਕੀਤਾ, ਮੈਂ ਜੀਵਨ ਅਤੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਜਵਾਨ ਅਤੇ ਤਜਰਬੇਕਾਰ ਸੀ। ਗਰਮੀਆਂ ਵਿੱਚ, ਮੈਂ ਮਾਈਕਰੋਸਾਫਟ ਵਿੱਚ, C ਕੰਪਾਈਲਰ ਟੀਮ ਵਿੱਚ ਇੰਟਰਨ ਕੀਤਾ। ਪਹਿਲਾਂ ਮੈਂ ਪ੍ਰੋਫਾਈਲਿੰਗ ਸਹਾਇਤਾ ਵਰਗੀਆਂ ਰੁਟੀਨ ਦੀਆਂ ਚੀਜ਼ਾਂ ਕੀਤੀਆਂ, ਅਤੇ ਫਿਰ ਮੈਨੂੰ ਕੰਪਾਈਲਰ ਦੇ ਸਭ ਤੋਂ ਮਜ਼ੇਦਾਰ ਹਿੱਸੇ (ਜਿਵੇਂ ਕਿ ਮੈਂ ਸੋਚਿਆ) - ਬੈਕਐਂਡ ਓਪਟੀਮਾਈਜੇਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸੌਂਪੀ ਗਈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਮੈਨੂੰ ਬ੍ਰਾਂਚ ਸਟੇਟਮੈਂਟਾਂ ਲਈ x86 ਕੋਡ ਨੂੰ ਸੁਧਾਰਨਾ ਪਿਆ.

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

ਇਹ ਇੱਕ ਭੈੜਾ ਸੁਪਨਾ ਸੀ। ਕਈ ਸਾਲਾਂ ਬਾਅਦ ਮੈਨੂੰ ਦੱਸਿਆ ਗਿਆ ਕਿ ਮੇਰਾ ਕੋਡ ਵਿਰਾਸਤ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਗਰਾਮਰ ਮੈਨੂੰ ਨਫ਼ਰਤ ਕਰਦਾ ਸੀ।

ਸਬਕ ਸਿੱਖਿਆ

ਜਿਵੇਂ ਕਿ ਡੇਵਿਡ ਪੈਟਰਸਨ ਅਤੇ ਜੌਨ ਹੈਨਸੀ ਕੰਪਿਊਟਰ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਕੰਪਿਊਟਰ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਲਿਖਦੇ ਹਨ, ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਡਿਜ਼ਾਈਨ ਦੇ ਮੁੱਖ ਸਿਧਾਂਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਆਮ ਤੌਰ 'ਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਜਿੰਨੀ ਜਲਦੀ ਸੰਭਵ ਹੋ ਸਕੇ ਕੰਮ ਕਰਨਾ।

ਆਮ ਕੇਸਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਨਾਲ ਦੁਰਲੱਭ ਕੇਸਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਸੁਧਾਰ ਹੋਵੇਗਾ। ਵਿਅੰਗਾਤਮਕ ਤੌਰ 'ਤੇ, ਆਮ ਕੇਸ ਅਕਸਰ ਦੁਰਲੱਭ ਮਾਮਲਿਆਂ ਨਾਲੋਂ ਸਰਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਲਾਜ਼ੀਕਲ ਸਲਾਹ ਇਹ ਮੰਨਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਕੇਸ ਆਮ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ - ਅਤੇ ਇਹ ਸਿਰਫ਼ ਧਿਆਨ ਨਾਲ ਜਾਂਚ ਅਤੇ ਮਾਪ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਸੰਭਵ ਹੈ।

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

ਮੈਨੂੰ ਇੱਕ ਤਜਰਬੇਕਾਰ ਡਿਵੈਲਪਰ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਲੋੜ ਸੀ ਅਤੇ, ਉਸਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਇਸ ਬਾਰੇ ਸੋਚੋ ਕਿ ਆਮ ਕੇਸ ਕੀ ਸਨ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਖਾਸ ਤੌਰ 'ਤੇ ਨਜਿੱਠਣ ਲਈ. ਮੈਂ ਘੱਟ ਕੋਡ ਲਿਖਾਂਗਾ, ਪਰ ਇਹ ਚੰਗੀ ਗੱਲ ਹੈ। ਜਿਵੇਂ ਕਿ ਸਟੈਕ ਓਵਰਫਲੋ ਦੇ ਸੰਸਥਾਪਕ ਜੈਫ ਐਟਵੁੱਡ ਨੇ ਲਿਖਿਆ, ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਦਾ ਸਭ ਤੋਂ ਬੁਰਾ ਦੁਸ਼ਮਣ ਖੁਦ ਪ੍ਰੋਗਰਾਮਰ ਹੈ:

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

ਜੇ ਮੈਂ ਸਧਾਰਨ ਕੋਡ ਲਿਖਿਆ ਹੁੰਦਾ ਜੋ ਆਮ ਕੇਸਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਲੋੜ ਪੈਣ 'ਤੇ ਅਪਡੇਟ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੁੰਦਾ। ਮੈਂ ਇੱਕ ਗੜਬੜ ਛੱਡ ਦਿੱਤੀ ਜਿਸ ਨਾਲ ਕੋਈ ਵੀ ਨਜਿੱਠਣਾ ਨਹੀਂ ਚਾਹੁੰਦਾ ਸੀ।

ਦੂਜਾ ਸਥਾਨ: ਸੋਸ਼ਲ ਨੈੱਟਵਰਕ 'ਤੇ ਵਿਗਿਆਪਨ

ਜਦੋਂ ਮੈਂ ਸੋਸ਼ਲ ਮੀਡੀਆ ਵਿਗਿਆਪਨ 'ਤੇ ਗੂਗਲ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ (ਮਾਈਸਪੇਸ ਨੂੰ ਯਾਦ ਰੱਖੋ?), ਮੈਂ C++ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਸੀ:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

ਪ੍ਰੋਗਰਾਮਰ ਤੁਰੰਤ ਗਲਤੀ ਦੇਖ ਸਕਦੇ ਹਨ: ਆਖਰੀ ਆਰਗੂਮੈਂਟ j ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, i ਨਹੀਂ। ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਨੇ ਗਲਤੀ ਦਾ ਖੁਲਾਸਾ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਨਾ ਹੀ ਮੇਰੇ ਸਮੀਖਿਅਕ ਨੇ. ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਇੱਕ ਰਾਤ ਮੇਰਾ ਕੋਡ ਸਰਵਰ ਤੇ ਚਲਾ ਗਿਆ ਅਤੇ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਸਾਰੇ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਕਰੈਸ਼ ਕਰ ਦਿੱਤਾ.

ਕੁਝ ਵੀ ਮਾੜਾ ਨਹੀਂ ਹੋਇਆ। ਕਿਸੇ ਲਈ ਵੀ ਕੁਝ ਨਹੀਂ ਟੁੱਟਿਆ, ਕਿਉਂਕਿ ਗਲੋਬਲ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕੋਡ ਨੂੰ ਇੱਕ ਡਾਟਾ ਸੈਂਟਰ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੀ। ਜਦੋਂ ਤੱਕ SRE ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਕੁਝ ਸਮੇਂ ਲਈ ਬਿਲੀਅਰਡ ਖੇਡਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਅਤੇ ਥੋੜਾ ਰੋਲਬੈਕ ਕੀਤਾ. ਅਗਲੀ ਸਵੇਰ ਮੈਨੂੰ ਕ੍ਰੈਸ਼ ਡੰਪ ਵਾਲੀ ਇੱਕ ਈਮੇਲ ਮਿਲੀ, ਕੋਡ ਨੂੰ ਠੀਕ ਕੀਤਾ ਅਤੇ ਯੂਨਿਟ ਟੈਸਟ ਸ਼ਾਮਲ ਕੀਤੇ ਜੋ ਗਲਤੀ ਨੂੰ ਫੜ ਲੈਣਗੇ। ਕਿਉਂਕਿ ਮੈਂ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਪਾਲਣਾ ਕੀਤੀ - ਨਹੀਂ ਤਾਂ ਮੇਰਾ ਕੋਡ ਚਲਾਉਣ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ - ਕੋਈ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਸਨ.

ਸਬਕ ਸਿੱਖਿਆ

ਬਹੁਤ ਸਾਰੇ ਨਿਸ਼ਚਤ ਹਨ ਕਿ ਅਜਿਹੀ ਵੱਡੀ ਗਲਤੀ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਦੋਸ਼ੀ ਨੂੰ ਬਰਖਾਸਤਗੀ ਦੀ ਕੀਮਤ ਦੇਵੇਗੀ, ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੈ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਰ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਦੂਜਾ, ਉਹ ਸ਼ਾਇਦ ਹੀ ਦੋ ਵਾਰ ਇੱਕੋ ਗਲਤੀ ਕਰਦੇ ਹਨ.

ਵਾਸਤਵ ਵਿੱਚ, ਮੇਰਾ ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਦੋਸਤ ਹੈ ਜੋ ਇੱਕ ਹੁਸ਼ਿਆਰ ਇੰਜੀਨੀਅਰ ਸੀ ਅਤੇ ਉਸਨੂੰ ਇੱਕ ਗਲਤੀ ਕਰਨ ਲਈ ਕੱਢ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਉਸ ਤੋਂ ਬਾਅਦ, ਉਸ ਨੂੰ ਗੂਗਲ 'ਤੇ ਨੌਕਰੀ 'ਤੇ ਰੱਖਿਆ ਗਿਆ ਸੀ (ਅਤੇ ਜਲਦੀ ਹੀ ਤਰੱਕੀ ਦਿੱਤੀ ਗਈ ਸੀ) - ਉਸਨੇ ਇੱਕ ਇੰਟਰਵਿਊ ਵਿੱਚ ਕੀਤੀ ਗਲਤੀ ਬਾਰੇ ਇਮਾਨਦਾਰੀ ਨਾਲ ਗੱਲ ਕੀਤੀ ਸੀ, ਅਤੇ ਇਸਨੂੰ ਘਾਤਕ ਨਹੀਂ ਮੰਨਿਆ ਗਿਆ ਸੀ।

ਜੋ ਕਿ ਦੱਸੋ IBM ਦੇ ਮਹਾਨ ਮੁਖੀ ਥਾਮਸ ਵਾਟਸਨ ਬਾਰੇ:

ਲਗਭਗ ਇੱਕ ਮਿਲੀਅਨ ਡਾਲਰ ਦੇ ਸਰਕਾਰੀ ਆਦੇਸ਼ ਦਾ ਐਲਾਨ ਕੀਤਾ ਗਿਆ ਸੀ। IBM ਕਾਰਪੋਰੇਸ਼ਨ - ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਥਾਮਸ ਵਾਟਸਨ ਸੀਨੀਅਰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ - ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ. ਬਦਕਿਸਮਤੀ ਨਾਲ, ਵਿਕਰੀ ਪ੍ਰਤੀਨਿਧੀ ਅਜਿਹਾ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ ਅਤੇ IBM ਨੇ ਬੋਲੀ ਗੁਆ ਦਿੱਤੀ। ਅਗਲੇ ਦਿਨ, ਇਹ ਕਰਮਚਾਰੀ ਮਿਸਟਰ ਵਾਟਸਨ ਦੇ ਦਫਤਰ ਵਿਚ ਆਇਆ ਅਤੇ ਉਸ ਦੇ ਡੈਸਕ 'ਤੇ ਇਕ ਲਿਫਾਫਾ ਰੱਖ ਦਿੱਤਾ। ਮਿਸਟਰ ਵਾਟਸਨ ਨੇ ਇਸ ਨੂੰ ਦੇਖਣ ਦੀ ਖੇਚਲ ਵੀ ਨਹੀਂ ਕੀਤੀ - ਉਹ ਇੱਕ ਕਰਮਚਾਰੀ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਸੀ ਅਤੇ ਜਾਣਦਾ ਸੀ ਕਿ ਇਹ ਅਸਤੀਫਾ ਪੱਤਰ ਸੀ।

ਵਾਟਸਨ ਨੇ ਪੁੱਛਿਆ ਕਿ ਕੀ ਗਲਤ ਹੋਇਆ ਹੈ।

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

ਵਾਟਸਨ ਦਰਵਾਜ਼ੇ 'ਤੇ ਉਸ ਕੋਲ ਆਇਆ, ਉਸ ਦੀਆਂ ਅੱਖਾਂ ਵਿਚ ਦੇਖਿਆ ਅਤੇ ਲਿਫਾਫੇ ਨੂੰ ਸ਼ਬਦਾਂ ਨਾਲ ਵਾਪਸ ਕਰ ਦਿੱਤਾ: "ਮੈਂ ਤੁਹਾਨੂੰ ਕਿਵੇਂ ਜਾਣ ਦੇ ਸਕਦਾ ਹਾਂ? ਮੈਂ ਹੁਣੇ ਤੁਹਾਡੀ ਸਿੱਖਿਆ ਵਿੱਚ ਇੱਕ ਮਿਲੀਅਨ ਡਾਲਰ ਦਾ ਨਿਵੇਸ਼ ਕੀਤਾ ਹੈ।

ਮੇਰੇ ਕੋਲ ਇੱਕ ਟੀ-ਸ਼ਰਟ ਹੈ ਜਿਸ ਵਿੱਚ ਲਿਖਿਆ ਹੈ: "ਜੇ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਗਲਤੀਆਂ ਤੋਂ ਸਿੱਖਦੇ ਹੋ, ਤਾਂ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਮਾਸਟਰ ਹਾਂ।" ਅਸਲ ਵਿੱਚ, ਜਦੋਂ ਗਲਤੀਆਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਮੈਂ ਵਿਗਿਆਨ ਦਾ ਡਾਕਟਰ ਹਾਂ।

ਪਹਿਲਾ ਸਥਾਨ: ਐਪ ਇਨਵੈਂਟਰ API

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

ਜਿੰਨਾ ਭੈੜਾ ਓਨਾ ਹੀ ਚੰਗਾ

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

ਇਹ ਕਿਵੇਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਡਿਜ਼ਾਈਨ ਲਾਗੂ ਕਰਨ ਅਤੇ ਇੰਟਰਫੇਸ ਵਿੱਚ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੰਟਰਫੇਸ ਦੀ ਸਾਦਗੀ ਲਾਗੂ ਕਰਨ ਦੀ ਸਾਦਗੀ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ.

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

ਆਓ ਇੱਕ ਮਿੰਟ ਲਈ ਇਸ ਬਾਰੇ ਭੁੱਲ ਜਾਈਏ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਮੈਂ ਕਈ ਸਾਲਾਂ ਤੋਂ ਇਸ ਬਾਰੇ ਭੁੱਲ ਗਿਆ.

ਐਪ ਖੋਜਕਰਤਾ

ਗੂਗਲ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਮੈਂ ਟੀਮ ਦਾ ਹਿੱਸਾ ਸੀ ਐਪ ਖੋਜਕਰਤਾ, ਚਾਹਵਾਨ Android ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਡਰੈਗ-ਐਂਡ-ਡ੍ਰੌਪ ਔਨਲਾਈਨ ਵਿਕਾਸ ਵਾਤਾਵਰਣ। ਇਹ 2009 ਸੀ, ਅਤੇ ਅਸੀਂ ਸਮੇਂ ਸਿਰ ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਜਾਰੀ ਕਰਨ ਦੀ ਕਾਹਲੀ ਵਿੱਚ ਸੀ ਤਾਂ ਜੋ ਗਰਮੀਆਂ ਵਿੱਚ ਅਸੀਂ ਅਧਿਆਪਕਾਂ ਲਈ ਮਾਸਟਰ ਕਲਾਸਾਂ ਰੱਖ ਸਕੀਏ ਜੋ ਪਤਝੜ ਵਿੱਚ ਪੜ੍ਹਾਉਂਦੇ ਸਮੇਂ ਵਾਤਾਵਰਣ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ। ਮੈਂ ਸਪ੍ਰਾਈਟਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸਵੈ-ਇੱਛੁਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕੀਤਾ, ਮੈਂ TI-99/4 'ਤੇ ਗੇਮਾਂ ਕਿਵੇਂ ਲਿਖਣ ਲਈ ਵਰਤਦਾ ਸੀ ਇਸ ਲਈ ਉਦਾਸੀਨ ਹਾਂ। ਉਹਨਾਂ ਲਈ ਜੋ ਨਹੀਂ ਜਾਣਦੇ, ਇੱਕ ਸਪ੍ਰਾਈਟ ਇੱਕ ਦੋ-ਅਯਾਮੀ ਗ੍ਰਾਫਿਕਲ ਆਬਜੈਕਟ ਹੈ ਜੋ ਹੋਰ ਸੌਫਟਵੇਅਰ ਤੱਤਾਂ ਨਾਲ ਹਿਲਾ ਅਤੇ ਇੰਟਰੈਕਟ ਕਰ ਸਕਦਾ ਹੈ। ਸਪ੍ਰਾਈਟਸ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਵਿੱਚ ਸਪੇਸਸ਼ਿਪ, ਐਸਟਰਾਇਡ, ਮਾਰਬਲ ਅਤੇ ਰੈਕੇਟ ਸ਼ਾਮਲ ਹਨ।

ਅਸੀਂ ਜਾਵਾ ਵਿੱਚ ਆਬਜੈਕਟ-ਓਰੀਐਂਟਿਡ ਐਪ ਇਨਵੈਂਟਰ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ, ਇਸਲਈ ਉੱਥੇ ਬਸ ਇੱਕ ਸਮੂਹ ਹੈ। ਕਿਉਂਕਿ ਗੇਂਦਾਂ ਅਤੇ ਸਪ੍ਰਾਈਟਸ ਬਹੁਤ ਸਮਾਨ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਮੈਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਫੀਲਡਾਂ) X, Y, ਸਪੀਡ (ਸਪੀਡ) ਅਤੇ ਹੈਡਿੰਗ (ਦਿਸ਼ਾ) ਦੇ ਨਾਲ ਇੱਕ ਐਬਸਟ੍ਰੈਕਟ ਸਪ੍ਰਾਈਟ ਕਲਾਸ ਬਣਾਇਆ ਹੈ। ਉਹਨਾਂ ਕੋਲ ਟੱਕਰਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ, ਸਕ੍ਰੀਨ ਦੇ ਕਿਨਾਰੇ ਨੂੰ ਉਛਾਲਣ ਆਦਿ ਲਈ ਇੱਕੋ ਜਿਹੇ ਤਰੀਕੇ ਸਨ।

ਇੱਕ ਗੇਂਦ ਅਤੇ ਇੱਕ ਸਪ੍ਰਾਈਟ ਵਿੱਚ ਮੁੱਖ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਖਿੱਚਿਆ ਗਿਆ ਹੈ - ਇੱਕ ਭਰਿਆ ਚੱਕਰ ਜਾਂ ਇੱਕ ਰਾਸਟਰ। ਕਿਉਂਕਿ ਮੈਂ ਪਹਿਲਾਂ ਸਪ੍ਰਾਈਟਸ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਸੀ, ਇਸ ਲਈ ਜਿੱਥੇ ਚਿੱਤਰ ਸਥਿਤ ਸੀ ਉਸ ਦੇ ਉੱਪਰਲੇ ਖੱਬੇ ਕੋਨੇ ਦੇ x- ਅਤੇ y- ਕੋਆਰਡੀਨੇਟਸ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨਾ ਲਾਜ਼ੀਕਲ ਸੀ।

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

ਵਾਸਤਵ ਵਿੱਚ, ਚੱਕਰ ਦੇ ਕੇਂਦਰ ਦੇ x- ਅਤੇ y- ਕੋਆਰਡੀਨੇਟਸ ਨੂੰ ਦਰਸਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ, ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਵੀ ਗਣਿਤ ਦੀ ਪਾਠ-ਪੁਸਤਕ ਅਤੇ ਕਿਸੇ ਹੋਰ ਸਰੋਤ ਵਿੱਚ ਸਿਖਾਇਆ ਗਿਆ ਹੈ ਜੋ ਚੱਕਰਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਦਾ ਹੈ।

ਮੇਰੀਆਂ ਪਿਛਲੀਆਂ ਗਲਤੀਆਂ ਦੇ ਉਲਟ, ਇਸ ਨੇ ਨਾ ਸਿਰਫ਼ ਮੇਰੇ ਸਹਿਕਰਮੀਆਂ ਨੂੰ, ਸਗੋਂ ਲੱਖਾਂ ਐਪ ਇਨਵੈਂਟਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਬੱਚੇ ਸਨ ਜਾਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਲਈ ਬਿਲਕੁਲ ਨਵੇਂ ਸਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਬਹੁਤ ਸਾਰੇ ਬੇਲੋੜੇ ਕਦਮ ਚੁੱਕਣੇ ਪੈਂਦੇ ਸਨ ਜਿਸ ਵਿੱਚ ਗੇਂਦ ਮੌਜੂਦ ਸੀ। ਜੇ ਹੱਸ ਕੇ ਮੇਰੀਆਂ ਹੋਰ ਗਲਤੀਆਂ ਯਾਦ ਆ ਜਾਣ ਤਾਂ ਅੱਜ ਵੀ ਮੈਨੂੰ ਪਸੀਨਾ ਆ ਜਾਂਦਾ ਹੈ।

ਮੈਂ ਆਖਰਕਾਰ ਇਸ ਬੱਗ ਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ, ਦਸ ਸਾਲਾਂ ਬਾਅਦ ਪੈਚ ਕੀਤਾ। “ਪੈਚ”, “ਸਥਿਰ” ਨਹੀਂ, ਕਿਉਂਕਿ ਜੋਸ਼ੂਆ ਬਲੋਚ ਕਹਿੰਦਾ ਹੈ, API ਸਦੀਵੀ ਹਨ। ਮੌਜੂਦਾ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਤਬਦੀਲੀਆਂ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ, ਅਸੀਂ ਪੁਰਾਣੇ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਮੁੱਲ ਗਲਤ ਅਤੇ ਭਵਿੱਖ ਦੇ ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਸਹੀ ਦੇ ਨਾਲ OriginAtCenter ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਜੋੜਿਆ ਹੈ। ਉਪਭੋਗਤਾ ਇੱਕ ਤਰਕਪੂਰਨ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹਨ: ਜਿਨ੍ਹਾਂ ਨੇ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਨੂੰ ਕੇਂਦਰ ਤੋਂ ਇਲਾਵਾ ਕਿਤੇ ਹੋਰ ਰੱਖਣ ਬਾਰੇ ਵੀ ਸੋਚਿਆ ਸੀ। ਕਿਸਦੇ ਲਈ? ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਲਈ ਜੋ ਦਸ ਸਾਲ ਪਹਿਲਾਂ ਇੱਕ ਆਮ API ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਆਲਸੀ ਸੀ।

ਸਬਕ ਸਿੱਖਿਆ ਹੈ

APIs 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ (ਜੋ ਲਗਭਗ ਹਰ ਪ੍ਰੋਗਰਾਮਰ ਨੂੰ ਕਈ ਵਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ), ਤੁਹਾਨੂੰ ਜੋਸ਼ੂਆ ਬਲੋਚ ਦੇ ਵੀਡੀਓ ਵਿੱਚ ਦੱਸੀ ਗਈ ਸਭ ਤੋਂ ਵਧੀਆ ਸਲਾਹ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ "ਇੱਕ ਚੰਗਾ API ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਅਤੇ ਇਹ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ"ਜਾਂ ਇਸ ਛੋਟੀ ਸੂਚੀ ਵਿੱਚ:

• ਇੱਕ API ਤੁਹਾਨੂੰ ਬਹੁਤ ਲਾਭ ਅਤੇ ਬਹੁਤ ਨੁਕਸਾਨ ਦੋਵੇਂ ਲਿਆ ਸਕਦਾ ਹੈ।. ਇੱਕ ਚੰਗਾ API ਦੁਹਰਾਉਣ ਵਾਲੇ ਗਾਹਕ ਬਣਾਉਂਦਾ ਹੈ। ਬੁਰਾ ਤੁਹਾਡਾ ਸਦੀਵੀ ਸੁਪਨਾ ਬਣ ਜਾਂਦਾ ਹੈ।
• ਜਨਤਕ API, ਹੀਰਿਆਂ ਵਾਂਗ, ਸਦਾ ਲਈ ਰਹਿੰਦੇ ਹਨ. ਇਸਨੂੰ ਆਪਣਾ ਸਭ ਕੁਝ ਦਿਓ: ਸਭ ਕੁਝ ਸਹੀ ਕਰਨ ਦਾ ਕੋਈ ਹੋਰ ਮੌਕਾ ਨਹੀਂ ਹੋਵੇਗਾ।
• API ਰੂਪਰੇਖਾ ਸੰਖੇਪ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ - ਕਲਾਸ ਅਤੇ ਵਿਧੀ ਦੇ ਹਸਤਾਖਰਾਂ ਅਤੇ ਵਰਣਨਾਂ ਵਾਲਾ ਇੱਕ ਪੰਨਾ, ਇੱਕ ਲਾਈਨ ਤੋਂ ਵੱਧ ਨਹੀਂ ਲੈਂਦਾ। ਇਹ ਤੁਹਾਨੂੰ API ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪੁਨਰਗਠਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ ਜੇਕਰ ਇਹ ਪਹਿਲੀ ਵਾਰ ਸੰਪੂਰਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।
• ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਦਾ ਵਰਣਨ ਕਰੋAPI ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਇਸਦੇ ਨਿਰਧਾਰਨ 'ਤੇ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ. ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੈਰ-ਕਾਰਜਸ਼ੀਲ API ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਨਿਰਧਾਰਤ ਕਰਨ ਤੋਂ ਬਚੋਗੇ।

ਜੇ ਮੈਂ ਇੱਕ ਨਕਲੀ ਲਿਪੀ ਦੇ ਨਾਲ ਇੱਕ ਛੋਟਾ ਸੰਖੇਪ ਵੀ ਲਿਖਿਆ ਹੁੰਦਾ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਮੈਂ ਗਲਤੀ ਨੂੰ ਪਛਾਣ ਲਿਆ ਹੁੰਦਾ ਅਤੇ ਇਸਨੂੰ ਠੀਕ ਕਰ ਲੈਂਦਾ। ਜੇ ਨਹੀਂ, ਤਾਂ ਮੇਰਾ ਕੋਈ ਸਾਥੀ ਜ਼ਰੂਰ ਕਰੇਗਾ। ਕੋਈ ਵੀ ਫੈਸਲਾ ਜਿਸ ਦੇ ਦੂਰਗਾਮੀ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ, ਘੱਟੋ ਘੱਟ ਇੱਕ ਦਿਨ ਲਈ ਸੋਚਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ (ਇਹ ਸਿਰਫ ਪ੍ਰੋਗਰਾਮਿੰਗ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ)।

ਰਿਚਰਡ ਗੈਬਰੀਅਲ ਦੇ ਲੇਖ ਦਾ ਸਿਰਲੇਖ, "ਵੌਰਸ ਇਜ਼ ਬੈਟਰ," ਉਸ ਫਾਇਦੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਮਾਰਕੀਟ ਵਿੱਚ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣ ਲਈ ਜਾਂਦਾ ਹੈ - ਭਾਵੇਂ ਇੱਕ ਅਪੂਰਣ ਉਤਪਾਦ ਦੇ ਨਾਲ - ਜਦੋਂ ਕਿ ਕੋਈ ਹੋਰ ਸੰਪੂਰਨ ਉਤਪਾਦ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਿੱਚ ਸਦੀਵੀ ਸਮਾਂ ਬਿਤਾਉਂਦਾ ਹੈ। ਸਪ੍ਰਾਈਟ ਕੋਡ 'ਤੇ ਪ੍ਰਤੀਬਿੰਬਤ ਕਰਦੇ ਹੋਏ, ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਇਸ ਨੂੰ ਸਹੀ ਕਰਨ ਲਈ ਮੈਨੂੰ ਹੋਰ ਕੋਡ ਲਿਖਣ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਕੋਈ ਜੋ ਵੀ ਕਹੇ, ਮੈਂ ਬਹੁਤ ਗਲਤ ਸੀ.

ਸਿੱਟਾ

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

ਮੈਂ ਲਗਾਤਾਰ ਉਹਨਾਂ ਵਿਦਿਆਰਥੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹਾਂ ਜੋ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਕਿ ਉਹ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ ਲਈ ਨਹੀਂ ਕੱਟੇ ਜਾਂਦੇ ਹਨ। ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ IT ਵਿੱਚ ਇੰਪੋਸਟਰ ਸਿੰਡਰੋਮ ਕਿੰਨਾ ਆਮ ਹੈ। ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹ ਸਬਕ ਸਿੱਖੋਗੇ ਜੋ ਮੈਂ ਸੂਚੀਬੱਧ ਕੀਤੇ ਹਨ - ਪਰ ਮੁੱਖ ਨੂੰ ਯਾਦ ਰੱਖੋ: ਸਾਡੇ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਗਲਤੀ ਕਰਦਾ ਹੈ - ਸ਼ਰਮਨਾਕ, ਮਜ਼ਾਕੀਆ, ਭਿਆਨਕ। ਮੈਂ ਹੈਰਾਨ ਅਤੇ ਪਰੇਸ਼ਾਨ ਹੋਵਾਂਗਾ ਜੇਕਰ ਭਵਿੱਖ ਵਿੱਚ ਮੇਰੇ ਕੋਲ ਲੇਖ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ ਲੋੜੀਂਦੀ ਸਮੱਗਰੀ ਨਹੀਂ ਹੈ।

ਸਰੋਤ: www.habr.com