ਬੱਗ ਲੱਭਣ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਬਜਾਏ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਲਾਗੂ ਕਰੋ

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

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

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

ਰੈਚੇਟ (ਸਰੋਤ: ਵਿਕੀਪੀਡੀਆ).

ਜੋ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕ ਕਦੇ ਨਹੀਂ ਕਰ ਸਕਦੇ

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

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

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

ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਬੱਗ ਲੱਭਣ ਬਾਰੇ ਨਹੀਂ ਹੈ

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

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

ਕੀ ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ? ਬਿਲਕੁੱਲ ਨਹੀਂ! ਅਤੇ ਬਿਲਕੁਲ ਉਸੇ ਕਾਰਨ ਕਰਕੇ ਕਿ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਹਰੇਕ ਨਵੇਂ ਪਾਸਵਰਡ ਦੀ ਜਾਂਚ ਕਰਨਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਇਹ "ਸਧਾਰਨ" ਪਾਸਵਰਡਾਂ ਦੀ ਸਟਾਪ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ।

ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਬੱਗ ਲੱਭਣ ਨਾਲੋਂ ਵੱਧ ਹੈ

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

• ਸ਼ਬਦ ਦੇ ਵਿਆਪਕ ਅਰਥਾਂ ਵਿੱਚ ਕੋਡਿੰਗ ਸ਼ੈਲੀ ਦੀ ਜਾਂਚ ਕਰਨਾ। ਇਸ ਵਿੱਚ ਫਾਰਮੈਟਿੰਗ ਦੀ ਜਾਂਚ ਕਰਨਾ, ਖਾਲੀ/ਵਾਧੂ ਬਰੈਕਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸੈੱਟ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ ਜਿਵੇਂ ਕਿ ਲਾਈਨਾਂ ਦੀ ਸੰਖਿਆ/ਕਿਸੇ ਵਿਧੀ ਦੀ ਸਾਈਕਲੋਮੈਟਿਕ ਗੁੰਝਲਤਾ, ਆਦਿ - ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਕੋਡ ਦੀ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਉਂਦੀ ਹੈ। ਜਾਵਾ ਵਿੱਚ, ਅਜਿਹਾ ਟੂਲ ਚੈਕਸਟਾਇਲ ਹੈ, ਪਾਈਥਨ ਵਿੱਚ - flake8. ਇਸ ਕਲਾਸ ਦੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ "ਲਿਨਟਰ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
• ਨਾ ਸਿਰਫ਼ ਚੱਲਣਯੋਗ ਕੋਡ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਸਰੋਤ ਫ਼ਾਈਲਾਂ ਜਿਵੇਂ ਕਿ JSON, YAML, XML, .ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵੈਧਤਾ ਲਈ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਅਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ!)। ਆਖ਼ਰਕਾਰ, ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਬਿਹਤਰ ਹੈ ਕਿ ਜੇਐਸਓਐਨ ਢਾਂਚਾ ਆਟੋਮੈਟਿਕ ਪੁੱਲ ਬੇਨਤੀ ਤਸਦੀਕ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਟੈਸਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਜਾਂ ਰਨ ਟਾਈਮ ਦੇ ਦੌਰਾਨ ਕੁਝ ਅਨਪੇਅਰਡ ਕੋਟਸ ਦੇ ਕਾਰਨ ਟੁੱਟ ਗਿਆ ਹੈ? ਉਚਿਤ ਸਾਧਨ ਉਪਲਬਧ ਹਨ: ਉਦਾਹਰਨ ਲਈ YAMLlint, JSONLint.
• ਸੰਕਲਨ (ਜਾਂ ਗਤੀਸ਼ੀਲ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਲਈ ਪਾਰਸਿੰਗ) ਵੀ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਇੱਕ ਕਿਸਮ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਕੰਪਾਈਲਰ ਚੇਤਾਵਨੀਆਂ ਪੈਦਾ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੁੰਦੇ ਹਨ ਜੋ ਸਰੋਤ ਕੋਡ ਦੀ ਗੁਣਵੱਤਾ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਅਤੇ ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਕਈ ਵਾਰ ਕੰਪਾਈਲੇਸ਼ਨ ਸਿਰਫ਼ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਕੋਡ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਫਾਰਮੈਟ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਹਨ AsciiDoctor, ਫਿਰ ਇਸਨੂੰ HTML/PDF ਵਿੱਚ ਬਦਲਣ ਦੇ ਸਮੇਂ AsciiDoctor ਹੈਂਡਲਰ (Maven ਪਲੱਗਇਨ) ਚੇਤਾਵਨੀ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਟੁੱਟੇ ਹੋਏ ਅੰਦਰੂਨੀ ਲਿੰਕਾਂ ਬਾਰੇ। ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਤਬਦੀਲੀਆਂ ਦੇ ਨਾਲ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਸਵੀਕਾਰ ਨਾ ਕਰਨ ਦਾ ਇਹ ਇੱਕ ਚੰਗਾ ਕਾਰਨ ਹੈ।
• ਸ਼ਬਦ-ਜੋੜ ਜਾਂਚ ਵੀ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਇੱਕ ਕਿਸਮ ਹੈ। ਉਪਯੋਗਤਾ ਅਸਪੈਲ ਨਾ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ, ਸਗੋਂ C/C++, Java ਅਤੇ Python ਸਮੇਤ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਸਰੋਤ ਕੋਡਾਂ (ਟਿੱਪਣੀਆਂ ਅਤੇ ਲਿਟਰਲ) ਵਿੱਚ ਵੀ ਸਪੈਲਿੰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਹੈ। ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਜਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਇੱਕ ਸਪੈਲਿੰਗ ਗਲਤੀ ਵੀ ਇੱਕ ਨੁਕਸ ਹੈ!
• ਕੌਂਫਿਗਰੇਸ਼ਨ ਟੈਸਟ (ਇਸ ਬਾਰੇ ਕਿ ਉਹ ਕੀ ਹਨ - ਵੇਖੋ। ਇਹ и ਇਹ ਰਿਪੋਰਟਾਂ), ਹਾਲਾਂਕਿ ਪਾਈਟੈਸਟ ਵਰਗੇ ਯੂਨਿਟ ਟੈਸਟ ਰਨਟਾਈਮ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਇੱਕ ਕਿਸਮ ਵੀ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਆਪਣੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੌਰਾਨ ਸਰੋਤ ਕੋਡਾਂ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ ਹਨ।

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਇਸ ਸੂਚੀ ਵਿੱਚ ਬੱਗਾਂ ਦੀ ਖੋਜ ਕਰਨਾ ਸਭ ਤੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਮੁਫਤ ਓਪਨ ਸੋਰਸ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਪਲਬਧ ਹੈ।

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

ਇੱਕ ਮਲਟੀ-ਸਟੇਜ ਫਿਲਟਰ ਦੇ ਰੂਪ ਵਿੱਚ ਡਿਲਿਵਰੀ ਪਾਈਪਲਾਈਨ ਅਤੇ ਇਸਦੇ ਪਹਿਲੇ ਪੜਾਅ ਵਜੋਂ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ

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

1. ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ
2. ਸੰਕਲਨ
3. ਯੂਨਿਟ ਟੈਸਟ
4. ਏਕੀਕਰਣ ਟੈਸਟ
5. UI ਟੈਸਟ
6. ਦਸਤੀ ਜਾਂਚ

ਪਾਈਪਲਾਈਨ ਦੇ Nਵੇਂ ਪੜਾਅ 'ਤੇ ਰੱਦ ਕੀਤੇ ਗਏ ਬਦਲਾਅ ਪੜਾਅ N+1 'ਤੇ ਤਬਦੀਲ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

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

ਟੈਸਟ ਪਿਰਾਮਿਡ. ਸਰੋਤ: ਲੇਖ ਮਾਰਟਿਨ ਫੋਲਰ.

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

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

ਮਲਟੀ-ਸਟੇਜ ਫਿਲਟਰ। ਸਰੋਤ: ਗਿਆਨਕੋਸ਼

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

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

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

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

ਇੱਕ ਵਿਰਾਸਤੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ

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

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

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

ਕੁਆਲਿਟੀ ਗੇਟਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦੇ ਹੇਠ ਲਿਖੇ ਤਰੀਕੇ ਜਾਣੇ ਜਾਂਦੇ ਹਨ:

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

ਰੈਚੇਟ

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:

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

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

ਇਹ ਗ੍ਰਾਫ਼ ਅਜਿਹੇ "ਰੈਚੈਟ" ਦੇ ਛੇ ਮਹੀਨਿਆਂ ਦੇ ਸੰਚਾਲਨ ਲਈ ਚੈਕਸਟਾਇਲ ਚੇਤਾਵਨੀਆਂ ਦੀ ਕੁੱਲ ਸੰਖਿਆ ਦਿਖਾਉਂਦਾ ਹੈ ਸਾਡੇ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ. ਚੇਤਾਵਨੀਆਂ ਦੀ ਸੰਖਿਆ ਤੀਬਰਤਾ ਦੇ ਕ੍ਰਮ ਦੁਆਰਾ ਘਟੀ ਹੈ, ਅਤੇ ਇਹ ਉਤਪਾਦ ਵਿਕਾਸ ਦੇ ਸਮਾਨਾਂਤਰ, ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵਾਪਰਿਆ ਹੈ!

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

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

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

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

ਵਿਸ਼ਲੇਸ਼ਕ ਸੰਸਕਰਣ ਨੂੰ ਫਿਕਸ ਕਰਨ ਦੀ ਮਹੱਤਤਾ ਬਾਰੇ

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

ਸਿੱਟਾ

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

ਹਵਾਲੇ

1. ਲਗਾਤਾਰ ਡਿਲਿਵਰੀ
2. A. Kudryavtsev: ਪ੍ਰੋਗਰਾਮ ਵਿਸ਼ਲੇਸ਼ਣ: ਇਹ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਚੰਗੇ ਪ੍ਰੋਗਰਾਮਰ ਹੋ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਬਾਰੇ ਰਿਪੋਰਟ ਕਰੋ (ਸਿਰਫ ਸਥਿਰ ਹੀ ਨਹੀਂ!)

ਸਰੋਤ: www.habr.com