ਪ੍ਰੋਗਰਾਮਰ, ਡਿਵੋਪਸ ਅਤੇ ਸ਼੍ਰੋਡਿੰਗਰ ਦੀਆਂ ਬਿੱਲੀਆਂ

ਇੱਕ ਨੈਟਵਰਕ ਇੰਜੀਨੀਅਰ ਦੀ ਅਸਲੀਅਤ (ਨੂਡਲਜ਼ ਅਤੇ... ਨਮਕ ਨਾਲ?)

ਹਾਲ ਹੀ ਵਿੱਚ, ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਵੱਖ-ਵੱਖ ਘਟਨਾਵਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਇੱਕ ਦਿਲਚਸਪ ਨਮੂਨਾ ਦੇਖਿਆ।

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

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

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

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

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

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

ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਦੀ ਮੂਲ ਧਾਰਨਾ: ਉਹੀ ਇਨਪੁਟ ਡੇਟਾ ਭਰੋਸੇਯੋਗ ਅਤੇ ਨਿਰਧਾਰਿਤ ਤੌਰ 'ਤੇ ਉਹੀ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰਦਾ ਹੈ।

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

ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਨਿਰਣਾਇਕਤਾ ਇੱਕ ਬੁਨਿਆਦੀ, ਲਗਭਗ ਮੰਨੀ ਗਈ ਧਾਰਨਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਕੰਮ ਪ੍ਰੋਗਰਾਮਰ ਕਰਦੇ ਹਨ।

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

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

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

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

ਇਹ ਦੇਖਿਆ ਗਿਆ ਵਿਕਾਸਕਾਰ ਪ੍ਰਤੀਕਰਮਾਂ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਰੀਮਾਈਂਡਰ ਹੈ ਕਿ ਸਾਡੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ ਬਹੁਤ ਸਾਰੇ ਕਾਰਕਾਂ ਦਾ ਇੱਕ ਗੁੰਝਲਦਾਰ ਮਿਸ਼ਰਣ ਹਨ।

ਇਸ ਜਟਿਲਤਾ ਨੂੰ ਯਾਦ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਭਾਵੇਂ ਅਸੀਂ ਕਿਸੇ ਇੱਕ ਘਟਨਾ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਹਾਂ, ਇੱਕ ਸੌਫਟਵੇਅਰ ਡਿਲੀਵਰੀ ਪਾਈਪਲਾਈਨ 'ਤੇ ਸਹਿਯੋਗ ਕਰ ਰਹੇ ਹਾਂ, ਜਾਂ ਵਿਆਪਕ ਸੰਸਾਰ ਨੂੰ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ।

ਸਰੋਤ: www.habr.com