NGINX ਤੋਂ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਸਿਧਾਂਤ। ਭਾਗ 1

ਹੈਲੋ ਦੋਸਤੋ. ਕੋਰਸ ਦੀ ਸ਼ੁਰੂਆਤ ਦੀ ਉਮੀਦ ਵਿੱਚ PHP ਬੈਕਐਂਡ ਡਿਵੈਲਪਰ, ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਨਾਲ ਉਪਯੋਗੀ ਸਮੱਗਰੀ ਦਾ ਅਨੁਵਾਦ ਸਾਂਝਾ ਕਰਦਾ ਹੈ।

ਸੌਫਟਵੇਅਰ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਗੁੰਝਲਦਾਰ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਮਾਰਕ ਐਂਡਰੇਸਨ ਨੇ ਇੱਕ ਵਾਰ ਕਿਹਾ ਸੀ, ਇਹ ਸੰਸਾਰ ਨੂੰ ਖਪਤ ਕਰਦਾ ਹੈ.

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

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

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

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

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

ਇੱਕ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨ ਕੀ ਹੈ?

ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨ? ਆਧੁਨਿਕ ਸਟੈਕ? "ਆਧੁਨਿਕ" ਦਾ ਅਸਲ ਵਿੱਚ ਕੀ ਅਰਥ ਹੈ?

ਬਹੁਤੇ ਡਿਵੈਲਪਰਾਂ ਕੋਲ ਸਿਰਫ ਇੱਕ ਆਮ ਵਿਚਾਰ ਹੈ ਕਿ ਇੱਕ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੈ, ਇਸਲਈ ਇਸ ਸੰਕਲਪ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

ਇੱਕ ਆਧੁਨਿਕ ਐਪ ਇੱਕ ਤੋਂ ਵੱਧ ਕਲਾਇੰਟਸ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਭਾਵੇਂ ਇਹ ਇੱਕ React JavaScript ਲਾਇਬ੍ਰੇਰੀ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਹੋਵੇ, ਇੱਕ Android ਜਾਂ iOS ਮੋਬਾਈਲ ਐਪ, ਜਾਂ ਇੱਕ ਐਪ ਜੋ ਕਿਸੇ ਹੋਰ API ਨਾਲ ਜੁੜਦੀ ਹੈ। ਇੱਕ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜਿਸ ਲਈ ਇਹ ਡੇਟਾ ਜਾਂ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇੱਕ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਕੀਤੇ ਡੇਟਾ ਅਤੇ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਇੱਕ API ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। API ਨੂੰ ਅਟੱਲ ਅਤੇ ਸਥਿਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਕਿਸੇ ਖਾਸ ਕਲਾਇੰਟ ਤੋਂ ਖਾਸ ਬੇਨਤੀ ਲਈ ਨਹੀਂ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। API HTTP(S) ਉੱਤੇ ਉਪਲਬਧ ਹੈ ਅਤੇ GUI ਜਾਂ CLI ਵਿੱਚ ਉਪਲਬਧ ਸਾਰੀਆਂ ਕਾਰਜਕੁਸ਼ਲਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਡੇਟਾ ਇੱਕ ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕੀਤੇ, ਇੰਟਰਓਪਰੇਬਲ ਫਾਰਮੈਟ ਵਿੱਚ ਉਪਲਬਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਕਿ JSON। ਇੱਕ API ਵਸਤੂਆਂ ਅਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਸਾਫ਼, ਸੰਗਠਿਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ RESTful API ਜਾਂ GraphQL ਇੱਕ ਵਧੀਆ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

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

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

ਅਸੂਲ

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

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

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

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

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

ਆਉ ਇਹਨਾਂ ਤਿੰਨਾਂ ਸਿਧਾਂਤਾਂ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖੀਏ.

ਛੋਟੀਤਾ ਦਾ ਸਿਧਾਂਤ

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

ਐਪਲੀਕੇਸ਼ਨਾਂ ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਰਨਾਂ ਕਰਕੇ ਕੰਪੋਜ਼ ਹੁੰਦੀਆਂ ਹਨ:

• ਡਿਵੈਲਪਰਾਂ 'ਤੇ ਬੋਧਾਤਮਕ ਲੋਡ ਘਟਾਇਆ;
• ਟੈਸਟਿੰਗ ਦਾ ਪ੍ਰਵੇਗ ਅਤੇ ਸਰਲੀਕਰਨ;
• ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਤੇਜ਼ ਸਪੁਰਦਗੀ.

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

ਇਸ ਲਈ ਇੱਥੇ ਬੋਧਾਤਮਕ ਲੋਡ ਨੂੰ ਘਟਾਉਣ ਦੇ ਤਿੰਨ ਤਰੀਕੇ ਹਨ:

1. ਇੱਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵੇਲੇ ਉਹਨਾਂ ਨੂੰ ਵਿਚਾਰਨ ਵਾਲੀ ਸਮਾਂ ਸੀਮਾ ਨੂੰ ਘਟਾਓ - ਸਮਾਂ ਸੀਮਾ ਜਿੰਨਾ ਛੋਟਾ ਹੋਵੇਗਾ, ਬੋਧਾਤਮਕ ਲੋਡ ਓਨਾ ਹੀ ਘੱਟ ਹੋਵੇਗਾ।
2. ਕੋਡ ਦੀ ਮਾਤਰਾ ਨੂੰ ਘਟਾਓ ਜਿਸ 'ਤੇ ਇਕ ਵਾਰ ਕੰਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਘੱਟ ਕੋਡ - ਘੱਟ ਲੋਡ।
3. ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਵਾਧੇ ਵਾਲੇ ਬਦਲਾਅ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਰਲ ਬਣਾਓ।

ਵਿਕਾਸ ਸਮਾਂ ਸੀਮਾ ਨੂੰ ਘਟਾਉਣਾ

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

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

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

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

ਛੋਟੇ ਕੋਡਬੇਸ

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

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

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

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

ਛੋਟੇ ਵਾਧੇ ਵਾਲੇ ਬਦਲਾਅ

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

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

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

1. ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰੋ agileਸਮਾਂ ਸੀਮਾ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਜਿਸ ਵਿੱਚ ਟੀਮ ਨੂੰ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਮਲਟੀਪਲ ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼ ਵਜੋਂ ਲਾਗੂ ਕਰੋ। ਇਹ ਉਹਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਸੀਮਿਤ ਕਰੇਗਾ ਜੋ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ​​​​ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਕੰਮ 'ਤੇ ਬੋਧਾਤਮਕ ਭਾਰ ਨੂੰ ਬਣਾਈ ਰੱਖਦੀਆਂ ਹਨ।
3. ਵੱਡੇ ਅਤੇ ਬੇਢੰਗੇ ਬਦਲਾਵਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਕੋਡ ਦੇ ਛੋਟੇ ਟੁਕੜਿਆਂ ਨੂੰ ਬਦਲੋ। ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ਤਾ ਲੁਕਾਉਣ ਦੀ ਵਰਤੋਂ ਕਰੋ ਭਾਵੇਂ ਉਹ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਦਿਖਾਈ ਨਹੀਂ ਦੇਣਗੀਆਂ।

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

ਪਹਿਲੇ ਭਾਗ ਦਾ ਅੰਤ.

ਜਲਦੀ ਹੀ ਅਸੀਂ ਅਨੁਵਾਦ ਦਾ ਦੂਜਾ ਭਾਗ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਾਂਗੇ, ਅਤੇ ਹੁਣ ਅਸੀਂ ਤੁਹਾਡੀਆਂ ਟਿੱਪਣੀਆਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ ਅਤੇ ਤੁਹਾਨੂੰ ਸੱਦਾ ਦਿੰਦੇ ਹਾਂ ਖੁੱਲਾ ਦਿਨ, ਜੋ ਅੱਜ 20.00 ਵਜੇ ਹੋਵੇਗੀ।

ਸਰੋਤ: www.habr.com