ਅਭਿਆਸ ਵਜੋਂ ਨਿਰੰਤਰ ਏਕੀਕਰਣ, ਜੇਨਕਿੰਸ ਨਹੀਂ। ਐਂਡਰੀ ਅਲੈਗਜ਼ੈਂਡਰੋਵ

ਆਉ ਚਰਚਾ ਕਰੀਏ ਕਿ CI ਟੂਲ ਅਤੇ CI ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਕਿਉਂ ਹਨ।

CI ਦਾ ਕਿਹੜਾ ਦਰਦ ਹੱਲ ਕਰਨ ਦਾ ਇਰਾਦਾ ਹੈ, ਇਹ ਵਿਚਾਰ ਕਿੱਥੋਂ ਆਇਆ, ਨਵੀਨਤਮ ਪੁਸ਼ਟੀਕਰਣ ਕੀ ਹਨ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਭਿਆਸ ਹੈ ਅਤੇ ਸਿਰਫ ਜੇਨਕਿਨਸ ਨੂੰ ਸਥਾਪਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ.

ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਬਾਰੇ ਇੱਕ ਰਿਪੋਰਟ ਬਣਾਉਣ ਦਾ ਵਿਚਾਰ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਪ੍ਰਗਟ ਹੋਇਆ, ਜਦੋਂ ਮੈਂ ਇੰਟਰਵਿਊ ਲਈ ਜਾ ਰਿਹਾ ਸੀ ਅਤੇ ਨੌਕਰੀ ਲੱਭ ਰਿਹਾ ਸੀ। ਮੈਂ 10-15 ਕੰਪਨੀਆਂ ਨਾਲ ਗੱਲ ਕੀਤੀ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇਣ ਦੇ ਯੋਗ ਸੀ ਕਿ CI ਕੀ ਹੈ ਅਤੇ ਇਹ ਸਮਝਾਉਣ ਦੇ ਯੋਗ ਸੀ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਉਨ੍ਹਾਂ ਕੋਲ ਇਹ ਨਹੀਂ ਹੈ। ਬਾਕੀ ਜੇਨਕਿੰਸ ਬਾਰੇ ਬੇਸਮਝੀ ਬਕਵਾਸ ਗੱਲ ਕਰ ਰਹੇ ਸਨ :) ਠੀਕ ਹੈ, ਸਾਡੇ ਕੋਲ ਜੇਨਕਿੰਸ ਹੈ, ਇਹ ਬਿਲਡ ਕਰਦਾ ਹੈ, ਸੀਆਈ! ਰਿਪੋਰਟ ਦੇ ਦੌਰਾਨ, ਮੈਂ ਇਹ ਦੱਸਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਕਿ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ ਅਤੇ ਜੇਨਕਿਨਜ਼ ਅਤੇ ਸਮਾਨ ਟੂਲਸ ਦਾ ਇਸ ਨਾਲ ਬਹੁਤ ਕਮਜ਼ੋਰ ਰਿਸ਼ਤਾ ਕਿਉਂ ਹੈ।

ਇਸ ਲਈ, ਜਦੋਂ ਤੁਸੀਂ CI ਸ਼ਬਦ ਸੁਣਦੇ ਹੋ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੀ ਮਨ ਵਿੱਚ ਆਉਂਦਾ ਹੈ? ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਜੇਨਕਿੰਸ, ਗਿਟਲਬ ਸੀਆਈ, ਟ੍ਰੈਵਿਸ, ਆਦਿ ਬਾਰੇ ਸੋਚਣਗੇ.

ਭਾਵੇਂ ਅਸੀਂ ਇਸਨੂੰ ਗੂਗਲ ਕਰਦੇ ਹਾਂ, ਇਹ ਸਾਨੂੰ ਇਹ ਟੂਲ ਦੇਵੇਗਾ.

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

ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਸਾਧਨਾਂ ਬਾਰੇ ਨਹੀਂ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਸ਼ਾਖਾ ਵਿੱਚ ਟੈਸਟਾਂ ਵਾਲੀਆਂ ਅਸੈਂਬਲੀਆਂ ਬਾਰੇ! ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਨਵੇਂ ਕੋਡ ਦੇ ਬਹੁਤ ਵਾਰ-ਵਾਰ ਏਕੀਕਰਣ ਦਾ ਅਭਿਆਸ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਜੇਨਕਿੰਸ, ਗਿੱਟਲੈਬ, ਆਦਿ ਨੂੰ ਵਾੜਨਾ ਬਿਲਕੁਲ ਵੀ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ।

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

ਅਤੇ ਉਹਨਾਂ ਨੇ ਇੱਕ ਟੀਮ ਦੇ ਰੂਪ ਵਿੱਚ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਦੇ ਦਰਦ ਨੂੰ ਹੱਲ ਕੀਤਾ!

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

ਅਤੇ ਉਹ ਕੰਮ 'ਤੇ ਚਲੇ ਗਏ ਜਿਵੇਂ ਕਿ ਹਰ ਕੋਈ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਆਦੀ ਸੀ. ਅਸੀਂ ਚੀਜ਼ਾਂ ਦੀ ਵਿਸ਼ਾਲ ਯੋਜਨਾ ਵਿੱਚ ਇੱਕ ਕੰਮ ਲਿਆ, ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾ ਬਣਾਈ, ਅਤੇ ਕੋਡ ਲਿਖਿਆ।

ਇੱਕ ਨੇ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰਾ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਮਾਸਟਰ ਵਿੱਚ ਮਿਲਾਇਆ।

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

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

ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਮਾਸਟਰ ਹੈ ਅਤੇ ਕੁਝ ਡਿਵੈਲਪਰ ਕੁਝ ਕਰ ਰਹੇ ਹਨ.

ਉਨ੍ਹਾਂ ਨੇ ਇੱਕ ਟਹਿਣੀ ਬਣਾਈ।

ਇੱਕ ਦੀ ਮੌਤ ਹੋ ਗਈ, ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਉਸਨੇ ਕੰਮ ਪਾਸ ਕਰ ਦਿੱਤਾ.

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

ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਦੂਜੇ ਡਿਵੈਲਪਰ ਨੇ ਕੁਝ ਹੋਰ ਕੀਤਾ.

ਪਹਿਲੇ ਨੇ ਤੀਜਾ ਕੰਮ ਪੂਰਾ ਕੀਤਾ।

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

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

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

ਇਕੱਠੇ ਕੁਝ ਕਰਨਾ ਦਰਦਨਾਕ ਹੈ! ਅਸੀਂ ਹਮੇਸ਼ਾ ਇੱਕ ਦੂਜੇ ਦੇ ਰਾਹ ਵਿੱਚ ਆਉਂਦੇ ਹਾਂ।

ਇਹ ਸਮੱਸਿਆ 20 ਤੋਂ ਵੱਧ ਸਾਲ ਪਹਿਲਾਂ ਦੇਖੀ ਗਈ ਸੀ। ਮੈਨੂੰ ਐਕਸਟ੍ਰੀਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦੇ ਅਭਿਆਸ ਦਾ ਪਹਿਲਾ ਜ਼ਿਕਰ ਮਿਲਿਆ।

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

ਹੁਣ ਅਸੀਂ "ਨਿਰੰਤਰ ਏਕੀਕਰਣ" ਵਾਕਾਂਸ਼ ਦਾ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ। ਜੇਕਰ ਅਸੀਂ ਇਸਦਾ ਸਿੱਧਾ ਅਨੁਵਾਦ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਲਗਾਤਾਰ ਏਕੀਕਰਣ ਮਿਲਦਾ ਹੈ। ਪਰ ਇਹ ਕਿੰਨਾ ਨਿਰੰਤਰ ਹੈ, ਇਹ ਬਹੁਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ; ਇਹ ਬਹੁਤ ਹੀ ਨਿਰੰਤਰ ਹੈ। ਪਰ ਇਸ ਵਿੱਚ ਕਿੰਨਾ ਏਕੀਕਰਣ ਹੈ ਇਹ ਵੀ ਬਹੁਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ।

ਅਤੇ ਇਸ ਲਈ ਮੈਂ ਤੁਹਾਨੂੰ ਹੁਣ ਐਕਸਟ੍ਰੀਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੇ ਹਵਾਲੇ ਦੇ ਰਿਹਾ ਹਾਂ। ਅਤੇ ਅਸੀਂ ਦੋਵਾਂ ਸ਼ਬਦਾਂ ਦਾ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ।

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

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

ਆਮ ਤੌਰ 'ਤੇ, ਏਕੀਕਰਣ ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡਾ ਕੋਡ ਲੈਣਾ ਅਤੇ ਇਸਨੂੰ ਮਾਸਟਰ ਵਿੱਚ ਖਿੱਚਣਾ।

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

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

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

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

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

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

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

ਪਰ ਕੀ ਸਾਡੇ ਕੋਲ ਇਸ ਸਮੇਂ ਕੋਈ ਢੁਕਵਾਂ ਸਬੂਤ ਹੈ ਜੋ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸ ਅਭਿਆਸ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਅਰਥ ਰੱਖਦਾ ਹੈ?

ਪਹਿਲੀ ਚੀਜ਼ ਜੋ ਮੇਰੇ ਦਿਮਾਗ ਵਿੱਚ ਆਈ ਉਹ ਸੀ ਦੇਵਓਪਸ ਦੀ ਸਟੇਟ. ਇਹ ਇੱਕ ਅਧਿਐਨ ਹੈ ਜੋ ਮੁੰਡੇ 7 ਸਾਲਾਂ ਤੋਂ ਕਰ ਰਹੇ ਹਨ। ਹੁਣ ਉਹ ਇਸਨੂੰ ਇੱਕ ਸੁਤੰਤਰ ਸੰਸਥਾ ਵਜੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਗੂਗਲ ਦੇ ਅਧੀਨ.

ਅਤੇ ਉਹਨਾਂ ਦੇ 2018 ਦੇ ਅਧਿਐਨ ਨੇ ਉਹਨਾਂ ਕੰਪਨੀਆਂ ਵਿਚਕਾਰ ਇੱਕ ਸਬੰਧ ਦਿਖਾਇਆ ਜੋ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਸ਼ਾਖਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਅਕਸਰ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਬਿਹਤਰ IT ਪ੍ਰਦਰਸ਼ਨ ਸੂਚਕ ਹੁੰਦੀਆਂ ਹਨ।

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

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

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

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

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

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ Gitflow ਮਾੜਾ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ। ਇਹ ਹੋਰ ਮੌਕਿਆਂ ਲਈ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਿਸੇ ਸੇਵਾ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕਈ ਸੰਸਕਰਣਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਭਾਵ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

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

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਕਰ ਰਹੇ ਹਾਂ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਅਭੇਦ ਹੋ ਰਹੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਕਿਵੇਂ ਸਮਝ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਹੈ, ਕਿ ਅਸੀਂ ਅਕਸਰ ਅਭੇਦ ਹੋ ਰਹੇ ਹਾਂ?

ਜੇਜ਼ ਨਿਮਰ ਹੈਂਡਬੁੱਕ, ਐਕਸਲੇਰੇਟ, ਕੰਟੀਨਿਊਅਸ ਡਿਲੀਵਰੀ ਵੈੱਬਸਾਈਟ, ਅਤੇ ਕੰਟੀਨਿਊਅਸ ਡਿਲੀਵਰੀ ਕਿਤਾਬ ਦਾ ਲੇਖਕ ਹੈ। ਉਹ ਇਹ ਟੈਸਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ:

• ਇੰਜੀਨੀਅਰ ਦਾ ਕੋਡ ਹਰ ਰੋਜ਼ ਮਾਸਟਰ ਨੂੰ ਮਿਲਦਾ ਹੈ।
• ਹਰ ਕਮਿਟ ਲਈ ਤੁਸੀਂ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਂਦੇ ਹੋ।
• ਮਾਸਟਰ ਵਿੱਚ ਬਿਲਡ ਡਿੱਗ ਗਿਆ, ਇਹ ਲਗਭਗ 10 ਮਿੰਟਾਂ ਵਿੱਚ ਠੀਕ ਹੋ ਗਿਆ।

ਉਹ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਟੈਸਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਾਫ਼ੀ ਅਭਿਆਸ ਹੈ।

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

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

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

ਇਹ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦੀ ਇੱਕ ਸੰਖੇਪ ਜਾਣ-ਪਛਾਣ ਹੈ। ਇਸ ਅਭਿਆਸ ਲਈ ਇਹ ਸਭ ਕੁਝ ਹੈ. ਮੈਂ ਸਵਾਲਾਂ ਲਈ ਤਿਆਰ ਹਾਂ।

ਮੈਂ ਦੁਬਾਰਾ ਸੰਖੇਪ ਵਿੱਚ ਸੰਖੇਪ ਕਰਾਂਗਾ:

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

ਤੁਹਾਡੇ ਸਵਾਲ

ਨਾ-ਸੜਨ ਵਾਲੇ ਕੰਮਾਂ ਦਾ ਕੀ ਕਰੀਏ?

ਕੰਪੋਜ਼. ਸਮੱਸਿਆ ਕੀ ਹੈ? ਕੀ ਤੁਸੀਂ ਇੱਕ ਉਦਾਹਰਣ ਦੇ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਕੰਮ ਹੈ ਅਤੇ ਇਹ ਸੜਿਆ ਨਹੀਂ ਹੈ?

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

ਜੇ ਮੈਂ ਤੁਹਾਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਸਮਝਦਾ ਹਾਂ, ਤਾਂ ਕੋਈ ਵੱਡਾ ਅਤੇ ਗੁੰਝਲਦਾਰ ਕੰਮ ਹੈ, ਜਿਸ ਦਾ ਨਤੀਜਾ ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ ਹੀ ਦਿਖਾਈ ਦੇਵੇਗਾ?

ਹਾਂ ਓਹ ਠੀਕ ਹੈ. ਹਾਂ, ਨਤੀਜੇ ਦਾ ਮੁਲਾਂਕਣ ਇੱਕ ਮਹੀਨੇ ਤੋਂ ਪਹਿਲਾਂ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗਾ।

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

ਜੁਰਮਾਨਾ. ਫਿਰ ਗੱਲ ਕੀ ਹੈ?

ਨਿੱਤ ਨਿੱਕੀਆਂ ਨਿੱਕੀਆਂ ਗੱਲਾਂ ਮਾਰਨ ਦਾ ਕੀ ਮਤਲਬ?

ਹਾਂ

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

ਤੁਹਾਡਾ ਧੰਨਵਾਦ, ਮੁੱਦਾ ਬੰਦ ਹੋ ਗਿਆ ਹੈ!

(ਓਲੇਗ ਸੋਰੋਕਾ) ਕੀ ਮੈਂ ਜੋੜ ਸਕਦਾ ਹਾਂ? ਤੁਸੀਂ ਸਭ ਕੁਝ ਸਹੀ ਕਿਹਾ, ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਵਾਕਾਂਸ਼ ਜੋੜਨਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਇਸ ਲਈ.

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

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

ਕੀ ਮੈਂ ਤੁਹਾਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸਮਝਿਆ ਹੈ ਕਿ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਅਭਿਆਸਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ ਜੇਕਰ ਕੋਈ ਕੰਮ ਪੂਰਾ ਹੋਣ ਵਿੱਚ ਇੱਕ ਮਹੀਨਾ ਲੈਂਦਾ ਹੈ?

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

ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਬਦਲ ਹੈ? ਜੇਕਰ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੁਣ ਇਸ ਅੱਪਡੇਟ ਕੀਤੇ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

ਅਧਾਰ ਸਿਰਫ ਅੱਗੇ ਵਧਦਾ ਹੈ, ਹਾਂ.

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

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

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

ਕੀ ਤੁਸੀਂ ਟ੍ਰਾਂਸਬੇਸ ਵਿਕਾਸ ਨੂੰ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਦਿੱਤਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਅਭਿਆਸਾਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਜਾਂ ਕੀ ਤੁਸੀਂ ਸੁਝਾਅ ਦਿੰਦੇ ਹੋ ਕਿ ਲੋਕ ਟ੍ਰਾਂਸਬੇਸ ਡਿਬੇਲਪਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ?

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

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

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

ਚੈਟ ਤੋਂ ਇੱਕ ਸਵਾਲ ਹੈ: "ਜੇ ਇੱਕ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਇੱਕ ਲੰਮਾ ਸਮਾਂ ਲੈਂਦੀ ਹੈ, ਸ਼ਾਇਦ ਇੱਕ ਦਿਨ ਜਾਂ ਵੱਧ?"

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

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

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

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

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

ਅਤੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ ਹੈ: "ਕੀ ਜੇਨਕਿੰਸ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ?"

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

ਭਾਵ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਅਭਿਆਸ ਹਨ, ਤਾਂ ਕੀ ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ?

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

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

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

ਰੋਕੋ, ਰੋਕੋ, ਇੱਕ ਬੈਸ਼ ਸਕ੍ਰਿਪਟ ਵੀ ਕੋਡ ਹੈ। ਮੇਰੇ ਪੁਰਾਣੇ ਪਿਆਰ ਨੂੰ ਨਾ ਛੂਹੋ.

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

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

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

ਜੇ ਕਿਸੇ ਹੋਰ ਕੋਲ ਸਵਾਲ ਹਨ?

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

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

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

ਜੇਕਰ ਤੁਸੀਂ ਦਿਨ ਵਿੱਚ 10 ਵਾਰ ਲਗਾਤਾਰ ਏਕੀਕਰਣ ਕਰਦੇ ਹੋ, ਤਾਂ 10 ਵਾਰ ਨੂੰ 30 ਮਿੰਟਾਂ ਨਾਲ ਗੁਣਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਇਹ ਇਸ ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਸਮੇਂ ਦੀ ਮਾਤਰਾ ਤੋਂ ਵੱਧ ਹੈ। ਉਹ ਕਰ-ਕਰ ਕੇ ਥੱਕ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਅਭਿਆਸਾਂ ਲਈ ਨਿਸ਼ਚਿਤ ਲਾਗਤਾਂ ਹਨ। ਇਹ ਸਭ ਹੈ.

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

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

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

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

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

ਹਾਂ, ਇਹ ਚੀਜ਼ਾਂ ਆਪਸ ਵਿੱਚ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ।

ਕਾਰੋਬਾਰ ਵੀ ਹਮੇਸ਼ਾ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਕਿ ਉਹਨਾਂ ਨੂੰ ਇਸ ਪਾਸੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ।

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

(ਦਮਿਤਰੀ) ਮੈਂ ਚੈਟ ਤੋਂ ਇੱਕ ਸਪਸ਼ਟੀਕਰਨ ਪੜ੍ਹਾਂਗਾ: “ਪਰ ਸਾਨੂੰ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਟੈਸਟ ਕਵਰੇਜ ਦੀ ਲੋੜ ਹੈ। ਟੈਸਟਾਂ ਲਈ ਕਿੰਨਾ ਸਮਾਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ? ਇਹ ਥੋੜਾ ਮਹਿੰਗਾ ਹੈ ਅਤੇ ਬਹੁਤ ਸਮਾਂ ਲੈਂਦਾ ਹੈ।"

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

ਇੱਥੇ ਤੁਹਾਨੂੰ, ਜ਼ਰੂਰ, ਸਜਾਇਆ.

(ਦਮਿਤਰੀ) ਮੈਂ ਇੱਥੇ ਸਹਿਮਤ ਨਹੀਂ ਹਾਂ। ਇੱਕ ਅਭਿਆਸ ਹੈ - ਟੈਸਟ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਵਿਕਾਸ, ਜੋ ਤੁਹਾਨੂੰ ਇਸ ਤੋਂ ਬਚਾਏਗਾ.

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

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

ਅਤੇ ਇਸ ਲਈ, ਜਦੋਂ ਤੁਸੀਂ ਸ਼ੁੱਕਰਵਾਰ ਸ਼ਾਮ ਨੂੰ ਤਿਆਰ ਹੋ ਅਤੇ ਘਰ ਜਾਂਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇਸ ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰੋਗੇ, ਇਹ ਇਕ ਹੋਰ ਸਵਾਲ ਹੈ. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਦਲੇਰ ਬਦਮਾਸ਼ ਹੋ।

ਚਲੋ ਲਗਾਤਾਰ ਏਕੀਕਰਣ ਵੱਲ ਥੋੜਾ ਜਿਹਾ ਪਿੱਛੇ ਚੱਲੀਏ। ਅਸੀਂ ਇੱਕ ਥੋੜੇ ਵੱਖਰੇ ਗੁੰਝਲਦਾਰ ਅਭਿਆਸ ਵਿੱਚ ਭੱਜ ਗਏ।

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

ਇਸ ਲਈ ਇਨ੍ਹਾਂ ਭਰਮਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਇੰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ। MVP ਅਤੇ ਟੈਸਟ ਇੱਕ ਦੂਜੇ ਦਾ ਵਿਰੋਧ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਇੱਥੋਂ ਤੱਕ ਕਿ, ਇਸਦੇ ਉਲਟ, ਜੇਕਰ ਤੁਸੀਂ TDD ਅਭਿਆਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ MVP ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਬਿਹਤਰ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕਰੋਗੇ ਜੇਕਰ ਤੁਸੀਂ ਬਿਨਾਂ ਅਭਿਆਸ ਦੇ ਕਰਦੇ ਹੋ, ਪਰ ਇੱਕ ਗੇਂਦ 'ਤੇ।

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

(ਦਮਿਤਰੀ) ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕ, ਜਦੋਂ ਉਹ ਐਮਵੀਪੀ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਲੋਕ ਕੁਝ ਆਮ ਲਿਖਣ ਲਈ ਬਹੁਤ ਆਲਸੀ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ. MVP ਨੂੰ ਕਿਸੇ ਬੁਰੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ ਜੋ ਕੰਮ ਨਹੀਂ ਕਰਦੀ.

ਹਾਂ, ਹਾਂ, ਤੁਸੀਂ ਸਹੀ ਹੋ।

ਅਤੇ ਫਿਰ ਅਚਾਨਕ ਉਤਪਾਦ ਵਿੱਚ MVP.

ਹਮੇਸ਼ਾਂ ਤੇ ਕਦੀ ਕਦੀ.

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

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

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

ਇਹ ਅਭਿਆਸ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਜਾਣੇ ਜਾਂਦੇ ਹਨ. ਅਸੀਂ ਇਸ ਬਾਰੇ 4 ਸਾਲ ਪਹਿਲਾਂ ਚਰਚਾ ਕੀਤੀ ਸੀ। ਪਰ 4 ਸਾਲਾਂ ਵਿੱਚ ਅਮਲੀ ਤੌਰ 'ਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ ਹੈ।

ਪਰ ਇਸ ਨੋਟ 'ਤੇ, ਮੈਂ ਅਧਿਕਾਰਤ ਚਰਚਾ ਨੂੰ ਖਤਮ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ।

ਵੀਡੀਓ (ਮੀਡੀਆ ਤੱਤ ਵਜੋਂ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਕੰਮ ਨਹੀਂ ਕਰਦਾ):

https://youtu.be/zZ3qXVN3Oic

ਸਰੋਤ: www.habr.com