ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ ਕੋਡ ਦੀਆਂ 100,000 ਲਾਈਨਾਂ ਨੂੰ ਕਿਵੇਂ ਪੜ੍ਹਨਾ ਅਤੇ ਠੀਕ ਕਰਨਾ ਹੈ

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

ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ ਕੋਡ ਦੀਆਂ 100k ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਲਾਈਨਾਂ ਦੇ ਪ੍ਰੋਜੈਕਟ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਜਦੋਂ ਕਿ ਅਜੇ ਵੀ ਨਤੀਜੇ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋਏ ਜੋ ਗਾਹਕ ਲਈ ਅਸਲ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹਨ।

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

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

ਸਾਡੀ ਕੰਪਨੀ ਦੀ ਪਹੁੰਚ

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

ਆਰਕੀਟੈਕਚਰ ਮੁਲਾਂਕਣ ਦੀਆਂ ਦੋ ਕਿਸਮਾਂ ਹਨ।

ਅੰਦਰੂਨੀ - ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਅਜਿਹਾ ਕਰਦੇ ਹਾਂ। ਕੋਈ ਵੀ ਪ੍ਰੋਜੈਕਟ ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਆਰਕੀਟੈਕਚਰ ਮੁਲਾਂਕਣ ਲਈ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ:

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

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

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

ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪ੍ਰੋਜੈਕਟ ਆਰਕੀਟੈਕਚਰ ਮੁਲਾਂਕਣ

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

ਸਮੱਸਿਆਵਾਂ ਜਿਹਨਾਂ ਬਾਰੇ ਗਾਹਕ ਸ਼ਿਕਾਇਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਬਾਰੇ ਜਾਣੂ ਹੋ ਸਕਦਾ ਹੈ:

• ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦੇ
• ਉਪਯੋਗਤਾ ਮੁੱਦੇ
• ਲੰਬੇ ਸਮੇਂ ਦੀ ਤੈਨਾਤੀ
• ਯੂਨਿਟ ਅਤੇ ਹੋਰ ਟੈਸਟਾਂ ਦੀ ਘਾਟ

ਸਮੱਸਿਆਵਾਂ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਗਾਹਕ ਨੂੰ ਸ਼ਾਇਦ ਪਤਾ ਨਹੀਂ ਹੈ, ਪਰ ਉਹ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਮੌਜੂਦ ਹੋ ਸਕਦੀਆਂ ਹਨ:

• ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ
• ਡਿਜ਼ਾਈਨ ਸਮੱਸਿਆਵਾਂ
• ਗਲਤ ਆਰਕੀਟੈਕਚਰ
• ਐਲਗੋਰਿਦਮਿਕ ਤਰੁੱਟੀਆਂ
• ਅਣਉਚਿਤ ਤਕਨਾਲੋਜੀਆਂ
• ਤਕਨੀਕੀ ਕਰਜ਼ਾ
• ਗਲਤ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ

ਰਸਮੀ ਆਰਕੀਟੈਕਚਰ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ

ਇਹ ਇੱਕ ਰਸਮੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸਦੀ ਅਸੀਂ ਇੱਕ ਕੰਪਨੀ ਵਜੋਂ ਪਾਲਣਾ ਕਰਦੇ ਹਾਂ, ਪਰ ਤੁਸੀਂ ਆਪਣੀ ਕੰਪਨੀ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅਧਾਰ ਤੇ ਇਸਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਇੱਕ ਗਾਹਕ ਤੋਂ ਬੇਨਤੀ

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

ਹੱਲ ਆਰਕੀਟੈਕਟ - ਮੁਲਾਂਕਣ ਅਤੇ ਤਾਲਮੇਲ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਮੁੱਖ ਵਿਅਕਤੀ (ਅਤੇ ਅਕਸਰ ਇੱਕ ਹੀ)।
ਸਟੈਕ ਖਾਸ ਮਾਹਰ - .ਨੈੱਟ, ਜਾਵਾ, ਪਾਈਥਨ, ਅਤੇ ਹੋਰ ਤਕਨੀਕੀ ਮਾਹਰ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਤਕਨਾਲੋਜੀਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ
ਕਲਾਉਡ ਮਾਹਰ - ਇਹ Azure, GCP ਜਾਂ AWS ਕਲਾਉਡ ਆਰਕੀਟੈਕਟ ਹੋ ਸਕਦੇ ਹਨ।
ਬੁਨਿਆਦੀ - DevOps, ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ, ਆਦਿ।
ਹੋਰ ਮਾਹਰ - ਜਿਵੇਂ ਕਿ ਵੱਡਾ ਡੇਟਾ, ਮਸ਼ੀਨ ਸਿਖਲਾਈ, ਪ੍ਰਦਰਸ਼ਨ ਇੰਜੀਨੀਅਰ, ਸੁਰੱਖਿਆ ਮਾਹਰ, QA ਲੀਡ।

ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ

ਤੁਹਾਨੂੰ ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਵੱਧ ਤੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਤੁਸੀਂ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ:

• ਪ੍ਰਸ਼ਨਾਵਲੀ ਅਤੇ ਡਾਕ ਰਾਹੀਂ ਸੰਚਾਰ ਦੇ ਹੋਰ ਤਰੀਕੇ। ਸਭ ਤੋਂ ਬੇਅਸਰ ਤਰੀਕਾ.
• ਆਨਲਾਈਨ ਮੀਟਿੰਗਾਂ।
• ਜਾਣਕਾਰੀ ਦੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਟੂਲ ਜਿਵੇਂ: Google doc, Confluence, Repositories, ਆਦਿ।
• ਸਾਈਟ 'ਤੇ "ਲਾਈਵ" ਮੀਟਿੰਗਾਂ। ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਅਤੇ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਤਰੀਕਾ.

ਤੁਹਾਨੂੰ ਗਾਹਕ ਤੋਂ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਮੁੱਢਲੀ ਜਾਣਕਾਰੀ। ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਕੀ ਹੈ? ਇਸਦਾ ਉਦੇਸ਼ ਅਤੇ ਮੁੱਲ. ਭਵਿੱਖ ਲਈ ਮੁੱਖ ਟੀਚੇ ਅਤੇ ਯੋਜਨਾਵਾਂ। ਵਪਾਰਕ ਟੀਚੇ ਅਤੇ ਰਣਨੀਤੀਆਂ। ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਲੋੜੀਂਦੇ ਨਤੀਜੇ।

ਪ੍ਰੋਜੈਕਟ ਦੀ ਜਾਣਕਾਰੀ. ਤਕਨਾਲੋਜੀ ਸਟੈਕ, ਫਰੇਮਵਰਕ, ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ। ਆਨ-ਪ੍ਰੀਮਿਸ ਜਾਂ ਕਲਾਉਡ ਤੈਨਾਤੀ। ਜੇਕਰ ਪ੍ਰੋਜੈਕਟ ਕਲਾਊਡ ਵਿੱਚ ਹੈ, ਤਾਂ ਕਿਹੜੀਆਂ ਸੇਵਾਵਾਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਕਿਹੜੇ ਆਰਕੀਟੈਕਚਰਲ ਅਤੇ ਡਿਜ਼ਾਈਨ ਪੈਟਰਨ ਵਰਤੇ ਗਏ ਸਨ.

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

ਬੁਨਿਆਦੀ ਵਰਤੋਂ ਦੇ ਕੇਸ ਅਤੇ ਡੇਟਾ ਪ੍ਰਵਾਹ।

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

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

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

ਆਰਕੀਟੈਕਚਰ ਮੁਲਾਂਕਣ ਪ੍ਰਕਿਰਿਆ

ਇੰਨੇ ਥੋੜੇ ਸਮੇਂ ਵਿੱਚ ਇੰਨੀ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ? ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਕੰਮ ਨੂੰ ਸਮਾਨਾਂਤਰ ਕਰੋ.

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

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

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

ਪ੍ਰੋਜੈਕਟ ਮੁਲਾਂਕਣ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ ਉਪਯੋਗੀ ਸਾਧਨ

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

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

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

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

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

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

ਨਵਾਂ ਰਿਲੀਕ - ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਇੱਕ ਸਾਧਨ
ਡੇਟਾਡੌਗ - ਕਲਾਉਡ ਸਿਸਟਮ ਨਿਗਰਾਨੀ ਸੇਵਾ

ਸੁਰੱਖਿਆ ਜਾਂਚ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸਾਧਨ ਉਪਲਬਧ ਹਨ। ਇਸ ਵਾਰ ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਮੁਫਤ ਸਿਸਟਮ ਸਕੈਨਿੰਗ ਟੂਲ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਾਂਗਾ।

OWASP ZAP - ਸੁਰੱਖਿਆ ਮਾਪਦੰਡਾਂ ਦੀ ਪਾਲਣਾ ਲਈ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਲਈ ਇੱਕ ਸਾਧਨ।

ਆਉ ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਪੂਰੇ ਵਿੱਚ ਪਾ ਦੇਈਏ.

ਇੱਕ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੈ

ਗਾਹਕ ਤੋਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਇਕੱਤਰ ਕੀਤੇ ਡੇਟਾ ਨਾਲ ਆਪਣੀ ਰਿਪੋਰਟ ਸ਼ੁਰੂ ਕਰੋ। ਪ੍ਰੋਜੈਕਟ ਦੇ ਟੀਚਿਆਂ, ਰੁਕਾਵਟਾਂ, ਗੈਰ-ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਦਾ ਵਰਣਨ ਕਰੋ। ਇਸ ਤੋਂ ਬਾਅਦ, ਸਾਰੇ ਇਨਪੁਟ ਡੇਟਾ ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਸਰੋਤ ਕੋਡ, ਦਸਤਾਵੇਜ਼, ਬੁਨਿਆਦੀ ਢਾਂਚਾ।

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

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

ਛੋਟੇ ਦੁਹਰਾਓ ਦੇ ਨਾਲ ਇੱਕ ਰੋਡਮੈਪ ਤਿਆਰ ਕਰੋ। ਹਰੇਕ ਦੁਹਰਾਓ ਵਿੱਚ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ, ਵਰਣਨ, ਸੁਧਾਰ ਲਈ ਲੋੜੀਂਦੇ ਸਰੋਤਾਂ ਦੀ ਮਾਤਰਾ, ਤਕਨੀਕੀ ਮੁੱਲ ਅਤੇ ਵਪਾਰਕ ਮੁੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਸੀਂ ਆਰਕੀਟੈਕਚਰ ਮੁਲਾਂਕਣ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਗਾਹਕ ਨੂੰ ਇੱਕ ਰਿਪੋਰਟ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ

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

ਤੁਹਾਡੀ ਮੀਟਿੰਗ ਦੇ ਸੰਖੇਪ ਵਜੋਂ, ਆਪਣੀ ਰਿਪੋਰਟ ਗਾਹਕ ਨੂੰ ਭੇਜੋ।

ਅੰਤ ਵਿੱਚ

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

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

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

ਤੁਹਾਡਾ ਟੀਚਾ ਗਾਹਕ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਕੀਮਤ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਸੁਧਾਰ ਦਿਖਾਉਣਾ ਹੈ।

ਸੈਕਸ਼ਨ ਤੋਂ ਹੋਰ ਲੇਖ ਆਰਕੀਟੈਕਚਰ ਤੁਸੀਂ ਆਪਣੇ ਵਿਹਲੇ ਸਮੇਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ।

ਮੈਂ ਤੁਹਾਨੂੰ ਸਾਫ਼ ਕੋਡ ਅਤੇ ਚੰਗੇ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲਿਆਂ ਦੀ ਕਾਮਨਾ ਕਰਦਾ ਹਾਂ।

ਸਾਡਾ ਫੇਸਬੁੱਕ ਗਰੁੱਪ - ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਵਿਕਾਸ.

ਸਰੋਤ: www.habr.com