ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ: ਪਹਿਲੀ ਜਾਣ-ਪਛਾਣ

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

ਸਾਡੇ ਅੰਦਰੂਨੀ ਸਮਾਗਮ 'ਤੇ ਭਾਸ਼ਣਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਲਿਖੇ ਲੇਖਾਂ ਦੀ ਲੜੀ ਦੀ ਨਿਰੰਤਰਤਾ ਦੇਵਫੋਰਮ:

1. ਬਿਨਾਂ ਡੱਬੇ ਦੇ ਸ਼੍ਰੋਡਿੰਗਰ ਦੀ ਬਿੱਲੀ: ਵੰਡੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਸਹਿਮਤੀ ਦੀ ਸਮੱਸਿਆ।
2. ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ। (ਤੁਸੀਂ ਇੱਥੇ ਹੋ)
3. C# ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟਾਈਪਸਕ੍ਰਿਪਟ ਕੰਟਰੈਕਟਸ ਦੀ ਉਤਪੱਤੀ। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)
4. ਰਾਫਟ ਸਹਿਮਤੀ ਐਲਗੋਰਿਦਮ ਦੀ ਜਾਣ-ਪਛਾਣ। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)
...

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

ਟੀਮ ਕੋਲ ਹੇਠ ਲਿਖੇ ਸਿਖਲਾਈ ਕਾਰਜ ਸਨ:

• ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਵਰਣਨ ਕਰੋ, ਜੋ ਕਿ ਜ਼ਿਆਦਾਤਰ ਮਾਈਕ੍ਰੋਸਾਫਟ ਅਜ਼ੁਰ ਵਿੱਚ ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਹੈ (ਟੇਰਾਫਾਰਮ ਅਤੇ ਆਲੇ ਦੁਆਲੇ ਦੀ ਹਰ ਚੀਜ਼)।
• ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਿਖਾਓ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ।
• ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਡਿਊਟੀ ਲਈ ਤਿਆਰ ਕਰੋ।

ਅਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਧਾਰਨਾ ਨੂੰ ਕੋਡ ਵਜੋਂ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ

ਸੰਸਾਰ ਦੇ ਆਮ ਮਾਡਲ (ਕਲਾਸੀਕਲ ਪ੍ਰਸ਼ਾਸਨ) ਵਿੱਚ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਬਾਰੇ ਗਿਆਨ ਦੋ ਸਥਾਨਾਂ ਵਿੱਚ ਸਥਿਤ ਹੈ:

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

ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਨਿਰਭਰ ਬਣਨ ਵਿੱਚ ਫਸਦੇ ਹਾਂ:

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

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

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

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

ਨਵੇਂ SRE ਇੰਜੀਨੀਅਰ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ?ਇਸ ਲਈ, ਅਸੀਂ ਨਵੇਂ SRE ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਕਿੱਥੋਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ? ਸਹੀ ਜਵਾਬਾਂ ਨਾਲ ਬੁੱਕ ਕਰੋ (ਗੂਗਲ ਐਸਆਰਈ ਬੁੱਕ) ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ: ਡਿਵੈਲਪਰਾਂ ਤੋਂ। ਆਖ਼ਰਕਾਰ, ਉਹ ਕੋਡ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਆਦਰਸ਼ ਸਥਿਤੀ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ.

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

ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ

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

ਟੈਰਾਫਾਰਮਾ ਤੋਂ ਉਦਾਹਰਨ ਕੋਡ।

Ansible ਤੋਂ ਉਦਾਹਰਨ ਕੋਡ।

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

1. ਪਹਿਲੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ IaC ਕਿਸੇ ਕਿਸਮ ਦਾ dsl ਹੈ।

ਅਤੇ DSL, ਬਦਲੇ ਵਿੱਚ, ਬਣਤਰ ਦਾ ਵਰਣਨ ਹੈ. ਵਧੇਰੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ, ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: Json, Yaml, ਕੁਝ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਤੋਂ ਸੋਧਾਂ ਜੋ ਆਪਣੇ ਖੁਦ ਦੇ dsl ਨਾਲ ਆਈਆਂ ਹਨ (HCL ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ)।

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਅਜਿਹੀਆਂ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ ਜਿਵੇਂ ਕਿ:

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

2. ਅਜਿਹੇ ਕੋਡ ਨਾਲ ਦੂਜੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਕਸਰ ਇਹ ਇੱਕ ਵਿਭਿੰਨ ਵਾਤਾਵਰਣ ਹੁੰਦਾ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ C# ਨਾਲ ਬੈਠ ਕੇ ਕੰਮ ਕਰਦੇ ਹੋ, ਯਾਨੀ. ਇੱਕ ਭਾਸ਼ਾ, ਇੱਕ ਸਟੈਕ, ਇੱਕ ਈਕੋਸਿਸਟਮ ਦੇ ਨਾਲ। ਅਤੇ ਇੱਥੇ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਹਨ.

ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਅਸਲ ਸਥਿਤੀ ਹੈ ਜਦੋਂ python ਨਾਲ bash ਕੁਝ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ Json ਨੂੰ ਪਾਇਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋ, ਫਿਰ ਕੋਈ ਹੋਰ ਜਨਰੇਟਰ ਹੋਰ 30 ਫਾਈਲਾਂ ਬਣਾਉਂਦਾ ਹੈ. ਇਸ ਸਭ ਲਈ, ਇਨਪੁਟ ਵੇਰੀਏਬਲ Azure Key Vault ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ Go ਵਿੱਚ ਲਿਖੇ drone.io ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਦੁਆਰਾ ਇਕੱਠੇ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਹ ਵੇਰੀਏਬਲ yaml ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ, ਜੋ ਕਿ jsonnet ਟੈਂਪਲੇਟ ਇੰਜਣ ਤੋਂ ਉਤਪੰਨ ਹੋਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹਾ ਵਿਭਿੰਨ ਵਾਤਾਵਰਣ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸਖਤੀ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਣਨ ਕੀਤਾ ਕੋਡ ਹੋਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਕਾਰਜ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਪਰੰਪਰਾਗਤ ਵਿਕਾਸ ਇੱਕ ਭਾਸ਼ਾ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਇੱਥੇ ਅਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ।

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

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

ਇਸ ਲਿਖਤ ਦੇ ਸਮੇਂ vscode-terraform ਪਲੱਗਇਨ ਅਜੇ ਤੱਕ ਸੰਸਕਰਣ 0.12 ਦੇ ਸਮਰਥਨ ਲਈ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ 3 ਮਹੀਨਿਆਂ ਲਈ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਹੈ।

ਇਹ ਭੁੱਲਣ ਦਾ ਸਮਾਂ ਹੈ ...

1. ਡੀਬੱਗਿੰਗ.
2. ਰੀਫੈਕਟਰਿੰਗ ਟੂਲ।
3. ਆਟੋ ਸੰਪੂਰਨਤਾ।
4. ਸੰਕਲਨ ਦੌਰਾਨ ਗਲਤੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ।

ਇਹ ਮਜ਼ਾਕੀਆ ਹੈ, ਪਰ ਇਹ ਵਿਕਾਸ ਦੇ ਸਮੇਂ ਨੂੰ ਵੀ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਗਲਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਜੋ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਵਾਪਰਦੀਆਂ ਹਨ।

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

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

ਟੈਸਟਾਂ ਬਾਰੇ ਕੀ?

ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ: "ਟੈਸਟਾਂ ਬਾਰੇ ਕੀ, ਸੱਜਣ ਪ੍ਰੋਗਰਾਮਰ?" ਗੰਭੀਰ ਲੋਕ ਉਤਪਾਦਨ 'ਤੇ ਹਰ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਮੁਸ਼ਕਲ ਹੈ. ਇੱਥੇ ਵੈਬਸਾਈਟ ਤੋਂ ਟੈਰਾਫਾਰਮ ਮੋਡੀਊਲ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ Microsoft ਦੇ.

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

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

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

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

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

ਚਲੋ ਅੱਗੇ ਵਧਦੇ ਹਾਂ। ਜੇਕਰ IaC ਵਿੱਚ ਕੋਈ ਟੈਸਟ ਨਹੀਂ ਹਨ, IDE ਅਤੇ ਟਿਊਨਿੰਗ ਖਰਾਬ ਹਨ, ਤਾਂ ਘੱਟੋ ਘੱਟ ਵਧੀਆ ਅਭਿਆਸ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ. ਮੈਂ ਹੁਣੇ ਗੂਗਲ ਵਿਸ਼ਲੇਸ਼ਣ 'ਤੇ ਗਿਆ ਅਤੇ ਦੋ ਖੋਜ ਪ੍ਰਸ਼ਨਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ: ਟੈਰਾਫਾਰਮ ਵਧੀਆ ਅਭਿਆਸ ਅਤੇ c# ਵਧੀਆ ਅਭਿਆਸ।

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

IaC ਬੇਨਤੀ ਲਈ: ਇੱਥੇ ਤੁਸੀਂ ਹਾਈਲੋਡ ਜਾਂ HashiConf ਰਿਪੋਰਟਾਂ ਤੋਂ, ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਅਤੇ ਗਿਥਬ 'ਤੇ ਕਈ ਮੁੱਦਿਆਂ ਤੋਂ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ। ਇਹਨਾਂ ਮੋਡੀਊਲਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਵੰਡਣਾ ਹੈ, ਉਹਨਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ? ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਹੈ... ਇੱਕ ਭਾਈਚਾਰਾ ਹੈ, ਸੱਜਣ, ਜਿੱਥੇ ਕਿਸੇ ਵੀ ਸਵਾਲ ਲਈ ਤੁਹਾਨੂੰ ਗਿਥਬ 'ਤੇ 10 ਟਿੱਪਣੀਆਂ ਦਿੱਤੀਆਂ ਜਾਣਗੀਆਂ। ਪਰ ਇਹ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ।

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

ਇਹ ਸਭ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਕੀ ਕਰਨਾ ਹੈ

ਤੁਸੀਂ ਸਭ ਕੁਝ ਛੱਡ ਸਕਦੇ ਹੋ ਅਤੇ C#, ਰਾਈਡਰ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ। ਪਰ ਨਹੀਂ। ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਹੱਲ ਨਹੀਂ ਲੱਭ ਸਕਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਨ ਦੀ ਪਰੇਸ਼ਾਨੀ ਕਿਉਂ ਕਰੋਗੇ। ਹੇਠਾਂ ਮੈਂ ਆਪਣੇ ਵਿਅਕਤੀਗਤ ਸਿੱਟੇ ਪੇਸ਼ ਕਰਦਾ ਹਾਂ। ਤੁਸੀਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਮੇਰੇ ਨਾਲ ਬਹਿਸ ਕਰ ਸਕਦੇ ਹੋ, ਇਹ ਦਿਲਚਸਪ ਹੋਵੇਗਾ.

ਨਿੱਜੀ ਤੌਰ 'ਤੇ, ਮੈਂ ਕੁਝ ਚੀਜ਼ਾਂ 'ਤੇ ਸੱਟਾ ਲਗਾ ਰਿਹਾ ਹਾਂ:

1. ਇਸ ਖੇਤਰ ਵਿੱਚ ਵਿਕਾਸ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਹੋ ਰਿਹਾ ਹੈ। ਇੱਥੇ DevOps ਲਈ ਬੇਨਤੀਆਂ ਦਾ ਸਮਾਂ-ਸਾਰਣੀ ਹੈ।

   
   
   ਵਿਸ਼ਾ ਹਾਈਪ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਤੱਥ ਕਿ ਗੋਲਾ ਵਧ ਰਿਹਾ ਹੈ ਕੁਝ ਉਮੀਦ ਦਿੰਦਾ ਹੈ।

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

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

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

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

ਸਿੱਟਾ

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਮੇਰਾ ਤਰਕ ਨਿਰਾਸ਼ਾਵਾਦੀ ਲੱਗ ਸਕਦਾ ਹੈ, ਮੈਂ ਉਮੀਦ ਨਾਲ ਭਵਿੱਖ ਵੱਲ ਦੇਖਦਾ ਹਾਂ ਅਤੇ ਦਿਲੋਂ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਸਭ ਕੁਝ ਸਾਡੇ (ਅਤੇ ਤੁਹਾਡੇ) ਲਈ ਕੰਮ ਕਰੇਗਾ।

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

ਸਰੋਤ: www.habr.com