ਫਰੇਮਵਰਕ ਪਿਛਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਤੋਂ ਸਿੱਖਿਆ—ਪੈਟਰਨ, ਡੀਫੌਲਟ ਅਤੇ ਰਿਵਾਜ—ਕੈਦ ਕਰਦੇ ਹਨ। ਜਾਣੋ ਕਿ ਉਹ ਕਿਵੇਂ ਸਰਵੋਤਮ ਅਭਿਆਸਾਂ ਨੂੰ ਐਨਕੋਡ ਕਰਦੇ ਹਨ, ਕਿੱਥੇ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਚੰਗਾ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ।
"ਪਿਛਲੇ ਸਮੇਂ ਤੋਂ ਮਿਲੀਆਂ ਸਰਵੋਤਮ ਅਭਿਆਸਾਂ" ਕੋਈ ਪੁਰਾਣੀਆਂ ਬਲਾਗ ਪੋਸਟਾਂ ਵਾਲੀਆਂ ਧੁੱਪੀਆਂ ਨਿਯਮ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਅਮਲੀ ਰੂਪ ਵਿੱਚ, ਇਹ ਉਹਨਾਂ ਕਠੋਰ ਫੈਸਲਿਆਂ ਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ ਜੋ ਟੀਮਾਂ ਨੇ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਦੇ ਬਾਅਦ ਲਏ: ਸੁਰੱਖਿਆ ਭੁੱਲਾਂ, ਅਇੱਕਸਾਰ ਕੋਡਬੇਸ, ਨਾਜ਼ੁਕ ਡਿਪਲੋਇਮੈਂਟ, ਧੀਮਾ ਡਿਬੱਗਿੰਗ, ਅਤੇ ਐਸੀਆਂ ਫੀਚਰਾਂ ਜਿਹੜੀਆਂ ਬਦਲਣ ਵਿੱਚ ਦਰਦਦਾਇਕ ਸਾਬਤ ਹੋਈਆਂ।
ਫਰੇਮਵਰਕ "ਇਕ ਡੱਬੇ ਵਿੱਚ ਤਜਰਬਾ" ਅਸਲ ਵਿੱਚ ਇਸ ਕਰਕੇ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਸਿੱਖਿਆਵਾਂ ਨੂੰ ਨਾਰਮਲ ਸਾਫ਼ਾ ਵਿੱਚ ਬੰਡਲ ਕਰਦੇ ਹਨ। ਹਰ ਟੀਮ ਨੂੰ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਦੋਹਰਾਉਣ ਦੀ ਬਜਾਏ, ਫਰੇਮਵਰਕ ਆਮ ਫੈਸਲਿਆਂ ਨੂੰ ਡੀਫੌਲਟ, ਰਿਵਾਜ ਅਤੇ ਰਿਯੂਜ਼ੇਬਲ ਬਿਲਡਿੰਗ ਬਲਾਕ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦੇ ਹਨ।
ਸਹੂਲਤ ਅਹਿਮ ਹੈ—ਕਈ ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਲਈ ਸਕੈਫੋਲਡਿੰਗ ਮਿੰਟਾਂ ਵਿੱਚ ਬਣਾਉਣਾ ਚੰਗਾ ਲੱਗਦਾ ਹੈ—ਪਰ ਫਰੇਮਵਰਕ ਦਾ ਮਕਸਦ ਕੁਝ ਵੱਡਾ ਹੁੰਦਾ ਹੈ: ਅਨੁਮਾਨਯੋਗਤਾ।
ਉਹ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਐਪ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ, ਕੋਡ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਰਿਕਵੈਸਟ ਕਿਵੇਂ ਵਗਦੇ ਹਨ, ਗਲਤੀਆਂ ਕਿਵੇਂ ਸਾਂਭੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕੰਪੋਨੈਂਟ ਇਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹਨ। ਜਦ ਫਰੇਮਵਰਕ ਇਹ ਚੰਗੇ ਢੰਗ ਨਾਲ ਕਰਦਾ ਹੈ, ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝ ਸਕਦੇ ਹਨ, ਕੋਡ ਰਿਵਿਊਜ਼ ਮੈਨਿੰਗਫੁਲ ਚੋਣਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਰਹਿੰਦੇ ਹਨ (ਸਟਾਈਲ ਦੇ ਝਗੜਿਆਂ ਤੇ ਨਹੀਂ), ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਚੋਂ ਵਿਹਾਰ ਸਮਝਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਰਹਿਨੁਮਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਦਿੰਦੇ ਹਨ, ਪਰ ਇਹ ਚੰਗੇ ਨਤੀਜੇ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਸੁਰੱਖਿਆ ਡੀਫੌਲਟ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਿਫ਼ਾਰਸ਼ੀ ਪੈਟਰਨ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਹੋ ਸਕਦਾ ਹੈ। ਅਤੇ ਪੰਜ ਸਾਲ ਪਹਿਲਾਂ ਦੀ "ਸਰਵੋਤਮ ਅਭਿਆਸ" ਅੱਜ ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਲਈ ਠੀਕ ਨਾ ਵੀ ਹੋਵੇ।
ਸਹੀ ਸੋਚ ਇਹ ਹੈ: ਫਰੇਮਵਰਕ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਂਦੇ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਖੁਦ ਲੈਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ—ਅਤੇ ਉਹ ਉਨ੍ਹਾਂ ਫੈਸਲਿਆਂ ਦੀ ਬੇਸਲਾਈਨ ਗੁਣਵੱਤਾ ਉੱਪਰ ਚੜ੍ਹਾਉਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਜਾਣ-ਬੂਝ ਕੇ ਨਹੀਂ ਲੈਂਦੇ। ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ ਇਹ ਪਛਾਣਨਾ ਕਿ ਕਿਹੜੇ ਫੈਸਲੇ ਰਣਨੀਤਿਕ ਹਨ (ਡੋਮੇਨ ਮਾਡਲਿੰਗ, ਡੇਟਾ ਸੀਮਾਵਾਂ, ਸਕੇਲਿੰਗ ਦੀ ਲੋੜ) ਅਤੇ ਕਿਹੜੇ ਕਮੋਡੀਟੀ (ਰਾਊਟਿੰਗ, ਵੈਲਿਡੇਸ਼ਨ, ਲੋਗਿੰਗ)।
ਸਾਲਾਂ ਵਿੱਚ, ਫਰੇਮਵਰਕ ਕਈ ਢੰਗਾਂ ਵਿੱਚ ਸਿੱਖਿਆਵਾਂ ਨੂੰ ਕੈਦ ਕਰ ਲੈਂਦੇ ਹਨ: ਸੰਵੇਦਨਸ਼ੀਲ ਡੀਫੌਲਟ, ਰਿਵਾਜ, ਬਿਲਟ-ਇਨ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨ, ਸੁਰੱਖਿਆ ਗਾਰਡਰੇਲ, ਟੈਸਟਿੰਗ ਟੂਲਿੰਗ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ/ਅਬਜ਼ਰਵੇਬਿਲਟੀ ਲਈ ਇੱਕ ਸਟੀੰਡਰਡ ਹੂਕ। ਇਹ ਜਾਣਨਾ ਕਿ ਇਹ ਸਿੱਖਿਆ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ ਤੁਹਾਨੂੰ ਫਰੇਮਵਰਕ ਨੂੰ ਆਤਮ ਵਿਸ਼ਵਾਸ ਨਾਲ ਵਰਤਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ—ਬਿਨਾਂ ਫਰੇਮਵਰਕ ਨੂੰ ਅਦੂਟ ਯਥਾਰਥ ਮੰਨਣ ਦੇ।
ਲੋਕ ਅਕਸਰ “ਫਰੇਮਵਰਕ” ਅਤੇ “ਲਾਇਬ੍ਰੇਰੀ” ਨੂੰ ਇੱਕ ਸਮਾਨ ਅਰਥ ਵਿੱਚ ਵਰਤਦੇ ਹਨ, ਪਰ ਉਹ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਬਹੁਤ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਜਦੋਂ ਚਾਹੋ ਕਾਲ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ ਕਿ ਕਦੋਂ ਇਸ ਨੂੰ ਵਰਤਣਾ ਹੈ, ਕਿਵੇਂ ਵਾਇਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਕੋਡ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਡੇਟ ਲਾਇਬ੍ਰੇਰੀ, PDF ਲਾਇਬ੍ਰੇਰੀ, ਜਾਂ ਲੋਗਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ।
ਇੱਕ ਫਰੇਮਵਰਕ ਉਹ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਇਹ ਐਪ ਦੀ ਓਵਰਆਲ ਸਾਂਚਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣਾ ਕੋਡ ਉਸ ਦੀਆਂ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਥਾਂਵਾਂ 'ਚ ਪਲੱਗ ਕਰੋਗੇ।
ਇੱਕ ਟੂਲਕਿਟ ਥੋੜ੍ਹਾ ਢਿੱਲਾ ਬੰਡਲ ਹੁੰਦਾ ਹੈ (ਅਕਸਰ ਕਈ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਕਨვენਸ਼ਨ) ਜੋ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਫਰੇਮਵਰਕ ਵਾਂਗ ਅਪਲਿਕੇਸ਼ਨ ਦੇ ਫਲੋ ਤੇ ਕਾਬੂ ਨਹੀਂ ਰੱਖਦਾ।
ਫਰੇਮਵਰਕ ਇਨਵਰਸ਼ਨ ਆਫ਼ ਕੰਟਰੋਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਇਸਦੀ ਬਜਾਏ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ “ਮੇਨ ਲੂਪ” ਹੋ ਕੇ ਬਾਕੀ ਨੂੰ ਕਾਲ ਕਰੇ, ਫਰੇਮਵਰਕ ਮੇਨ ਲੂਪ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਸਹੀ ਸਮੇਂ ਤੇ ਤੁਹਾਡੀਆਂ ਹੈਂਡਲਰਾਂ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
ਇਹ ਇਕਲੋਤਾ ਡਿਜ਼ਾਈਨ ਚੋਣ ਕਈ ਫੈਸਲਿਆਂ ਨੂੰ ਮਜ਼ਬੂਤ ਅਤੇ ਸਧਾਰਨ ਕਰਦੀ ਹੈ: ਰਾਊਟਸ ਕਿੱਥੇ ਰਹਿਣਗੇ, ਰਿਕਵੈਸਟ ਕਿਵੇਂ ਪ੍ਰੋਸੈਸ ਹੁੰਦੇ ਹਨ, ਡਿਪੈਂਡੈਂਸੀਜ਼ ਕਿਵੇਂ ਬਣਦੀਆਂ ਹਨ, ਗਲਤੀਆਂ ਕਿਵੇਂ ਸਾਂਭੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਜੋੜੇ ਜਾਂਦੇ ਹਨ।
ਕਿਉਂਕਿ ਫਰੇਮਵਰਕ ਢਾਂਚਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਪ੍ਰਤੀ ਪ੍ਰੋਜੈਕਟ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਫਿਰ ਤੋਂ ਸਮਾਂ ਨਹੀਂ ਗੁਜ਼ਾਰਦੇ। ਇਸ ਨਾਲ ਘਟਦਾ ਹੈ:
ਇੱਕ ਵੈੱਬ ਐਪ ਬਾਰੇ ਸੋਚੋ।
ਲਾਇਬ੍ਰੇਰੀ ਪਹੁੰਚ ਨਾਲ, ਤੁਸੀਂ ਇੱਕ ਰਾਊਟਰ ਚੁਣ ਸਕਦੇ ਹੋ, ਫਿਰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਫਾਰਮ ਵੈਲਿਡੇਸ਼ਨ ਪੈਕੇਜ ਚੁਣੋਗੇ, ਫਿਰ ਸੈਸ਼ਨ ਹੈਂਡਲਿੰਗ ਹੱਥਾਂ-ਹੱਥ ਬਣਾਉਣੋਂ—ਤੈਅ ਕਰਦੇ ਹੋ ਕਿ ਉਹ কਿਵੇਂ ਇੰਟਰਐਕਟ ਕਰਨਗੇ, ਸਟੇਟ ਕਿੱਥੇ ਸਟੋਰ ਹੋਵੇਗੀ, ਅਤੇ ਗਲਤੀਆਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦਿਖਣਗੀਆਂ।
ਫਰੇਮਵਰਕ ਨਾਲ, ਰਾਊਟਿੰਗ ਫਾਇਲ/ਫੋਲਡਰ ਰਿਵਾਜ ਜਾਂ ਸੈਂਟਰਲ ਰੂਟ ਟੇਬਲ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਹੋ ਸਕਦੀ ਹੈ, ਫਾਰਮਜ਼ ਦਾ ਇੱਕ ਸਟੈਂਡਰਡ ਵੈਲਿਡੇਸ਼ਨ ਲਾਈਫਸਾਈਕਲ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਬਿਲਟ-ਇਨ ਮਿਡਲਵੇਅਰ ਨਾਲ ਇੰਟੀਗਰੇਟ ਹੋ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਫਿਰ ਵੀ ਚੋਣ ਕਰ ਰਹੇ ਹੋ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਡੀਫੌਲਟ ਪਹਿਲਾਂ ਹੀ ਚੁਣੇ ਹੋਏ ਹੁੰਦੇ ਹਨ—ਅਕਸਰ ਉਹ ਸਿੱਖਿਆ ਜੋ ਸਪੱਸ਼ਟਤਾ, ਸੁਰੱਖਿਆ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਦੀ ਮੁਰੰਮਤ ਲਈ ਮਿਲੀ ਸੀ।
ਫਰੇਮਵਰਕ ਸ਼ੁਰੂ ਵਿੱਚ ਅਕਸਰ "ਸਰਵੋਤਮ ਅਭਿਆਸ" ਵਜੋਂ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਛੋਟੇ ਸ਼ੌਰਟਕਟ ਵਜੋਂ: ਇੱਕ ਛੋਟੀ ਯੂਟਿਲਿਟੀ ਸੈੱਟ ਜੋ ਇੱਕ ਟੀਮ, ਇੱਕ ਉਤਪਾਦ, ਅਤੇ ਇੱਕ ਡੈਡਲਾਈਨ ਲਈ ਬਣਾਇਆ ਗਿਆ। ਦਿਲਚਸਪ ਹਿੱਸਾ ਉਹ ਹੈ ਜੋ 1.0 ਦੇ ਬਾਅਦ ਹੁੰਦਾ ਹੈ—ਜਦ ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਉਹੀ ਕੰਮ ਦੋਹਰਾਉਂਦੇ ਹਨ।
ਸਮੇਂ ਦੇ ਨਾਲ ਇੱਕ ਪੈਟਰਨ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ:
ਪ੍ਰੋਜੈਕਟ ਇਕੋ ਹੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹਨ → ਟੀਮਾਂ ਸਮਾਨ ਹੱਲ ਬਣਾਉਂਦੀਆਂ ਹਨ → ਮੇਨਟੇਨਰ ਇਸ ਦੁਹਰਾਵਟ ਨੂੰ ਨੋਟ ਕਰਦੇ ਹਨ → ਫਰੇਮਵਰਕ ਇਸਨੂੰ ਇੱਕ ਰਿਵਾਜ ਵਜੋਂ ਸਟੈਂਡਰਡ ਕਰ ਦਿੰਦਾ ਹੈ।
ਉਹ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਹੀ ਫਰੇਮਵਰਕ ਨੂੰ ਇकटਠੇ ਤਜਰਬੇ ਦਾ ਅਹਿਸਾਸ ਦਿੰਦੀ ਹੈ। ਰਾਊਟਿੰਗ ਅੰਦਾਜ਼, ਫੋਲਡਰ ਢਾਂਚਾ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਕੈਨਿਜ਼ਮ, ਜਾਂ ਗਲਤੀ-ਹੈਂਡਲਿੰਗ ਢੰਗ ਅਕਸਰ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿ ਇਹ ਬਹੁਤ ਸਾਰੇ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਗਲਤੀ ਘਟਾਉਂਦੇ ਹਨ—ਨਾ ਕਿ ਕਿਸੇ ਨੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਸੀ।
ਕਈ "ਨਿਯਮ" ਫਰੇਮਵਰਕ ਵਿੱਚ ਪਿਛਲੇ ਨਾਕਾਮੀਆਂ ਦੀ ਯਾਦਗਾਰ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਡੀਫੌਲਟ ਜੋ ਅਸੁਰੱਖਿਅਤ ਇਨਪੁੱਟ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਇੱਕ ਚੇਤਾਵਨੀ ਜਦੋਂ ਤੁਸੀਂ ਖਤਰਨਾਕ ਕੰਮ ਕਰਦੇ ਹੋ, ਜਾਂ ਇੱਕ API ਜੋ ਖੁਲ੍ਹੇ ਤੌਰ 'ਤੇ ਸੰਰਚਨਾ ਮੰਗਦਾ ਹੈ—ਅਕਸਰ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਆਉਟੇਜ, ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ, ਪ੍ਰਦਰਸ਼ਨ ਰਿਗ੍ਰੈਸ਼ਨ, ਜਾਂ ਮੁਸ਼ਕਲ-ਡਿਬੱਗ ਬਰੀਕੇਸ ਕੇਸ ਦੇ ਇਤਿਹਾਸ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।
ਜਦ ਕਾਫੀ ਵਾਰ ਟੀਮਾਂ ਇੱਕੋ ਹੀ ਰੇਕ 'ਤੇ ਪੈ ਜਾਂਦੀਆਂ ਹਨ, ਫਰੇਮਵਰਕ ਅਕਸਰ ਉਸ ਰੇਕ ਨੂੰ ਹਟਾ ਦੇਵੇਗਾ—ਜਾਂ ਉਸਦੇ ਨਾਲ ਚੇਤਾਵਨੀ ਲਗਾ ਦੇਵੇਗਾ।
ਮੇਨਟੇਨਰ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਆਧਿਕਾਰਿਕ ਬਣੇਗਾ, ਪਰ ਕੱਚ ਮਾਲ ਵਰਤੋਂ ਤੋਂ ਆਉਂਦਾ ਹੈ: ਬੱਗ ਰਿਪੋਰਟਾਂ, ਪੁੱਲ ਰਿਕਵੇਸਟ, ਘਟਨਾ ਰਿਪੋਰਟ, ਕਾਨਫਰੰਸ ਟਾਕਸ, ਅਤੇ ਜੋ ਲੋਕ ਪਲੱਗਇਨ ਬਣਾਉਂਦੇ ਹਨ। ਲੋਕਾਂ ਵੱਲੋਂ ਬਣਾਈਆਂ ਗਈਆਂ ਵਰਕਅਰਾਊਂਡਸ ਖ਼ਾਸ ਦਰਸਾਉਂਦੀਆਂ ਹਨ—ਜੇ ਹਰ ਕੋਈ ਇੱਕੋ ਹੀ ਮਿਡਲਵੇਅਰ ਜੋੜ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਹ ਪਹਿਲੀ-ਕਲਾਸ ਫੀਚਰ ਬਣ ਸਕਦਾ ਹੈ।
ਕੀ ਕੁਝ ਸਰਵੋਤਮ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਉਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਸੀਮਾਵਾਂ 'ਤੇ: ਟੀਮ ਆਕਾਰ, ਕੰਪਲਾਇੰਸ ਦੀ ਲੋੜ, ਡਿਪਲੋਇਮੈਂਟ ਮਾਡਲ, ਅਤੇ ਮੌਜੂਦਾ ਖ਼ਤਰਿਆਂ ਉੱਤੇ। ਫਰੇਮਵਰਕ ਵਿਕਸਿਤ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਇਤਿਹਾਸ ਵੀ ਲੈ ਕੇ ਚਲਦੇ ਹਨ—ਇਸ ਲਈ ਅਪਗ੍ਰੇਡ ਨੋਟਸ ਅਤੇ ਡਿਪ੍ਰਿਕੇਸ਼ਨ ਗਾਈਡ (see /blog) ਪੜ੍ਹਨਾ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਮਝ ਸکو ਕਿ ਰਿਵਾਜ ਕਿਉਂ ਮੌਜੂਦ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਕਿਵੇਂ ਓਸ ਨੂੰ ਫਾਲੋ ਕਰਨਾ ਹੈ।
ਫਰੇਮਵਰਕ ਦੇ ਡੀਫੌਲਟ ਚੁੱਪ-ਚਾਪ ਅਧਿਆਪਕ ਹੁੰਦੇ ਹਨ। ਕੋਈ ਮੀਟਿੰਗ, ਚੈਕਲਿਸਟ ਜਾਂ ਸीनਿਅਰ ਡਿਵੈਲਪਰ ਹਰ ਫੈਸਲੇ ਤੇ ਮੋੜ ਨਹੀਂ ਰੱਖਦਾ, ਫਿਰ ਵੀ ਉਹਨਾਂ ਨੇ ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਚੋਣਾਂ ਵੱਲ ਧੱਕਿਆ ਜੇਹੜੀਆਂ ਪਹਿਲਾਂ ਚੰਗੀਆਂ ਸਾਬਤ ਹੋਈਆਂ। ਜਦ ਤੁਸੀਂ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਇਹ "ਸਿਰਫ਼ ਕੰਮ ਕਰਦਾ ਹੈ", ਅਕਸਰ ਇਹ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਸ਼ੁਰੂਆਤੀ ਸੈਟਿੰਗ ਵਿੱਚ ਕਾਫ਼ੀ ਸਿੱਖਿਆ ਏਨਕੋਡ ਕੀਤੀ ਹੋਈ ਹੁੰਦੀ ਹੈ।
ਡੀਫੌਲਟ ਪਹਿਲੇ ਦਿਨ ਲੈਣੀਆਂ ਪਈਆਂ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਂਦੇ ਹਨ। “ਸਾਡਾ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚਾ ਕਿਵੇਂ ਹੋਵੇ?” ਜਾਂ “ਸੁਰੱਖਿਆ ਹੈਡਰ ਕਿਵੇਂ ਕੰਫਿਗਰ ਕਰਨੇ?” ਪੁੱਛਣ ਦੀ ਬਜਾਏ, ਫਰੇਮਵਰਕ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਸੁਰੱਖਿਅਤ, ਇੱਕਸਾਰ ਬੇਸਲਾਈਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ।
ਇਹ ਧੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਜੋ ਉਹ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਉਸੇ ਨਾਲ ਰਹਿਣ ਦਿਆਂ। ਜੇ ਸ਼ੁਰੂਆਤ sensible ਹੈ, ਪ੍ਰੋਜੈਕਟ ਸੰਭਵਤ: sensible ਰਹੇਗਾ।
ਕਈ ਫਰੇਮਵਰਕ ਆਊਟ-ਆਫ਼-ਬਾਕਸ ਸੁਰੱਖਿਅਤ ਕੰਫਿਗਰੇਸ਼ਨ ਨਾਲ ਆਉਂਦੇ ਹਨ: ਡਿਵੈਲਪਮੈਂਟ ਮੋਡ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਸਪਸ਼ਟ ਢੰਗ ਨਾਲ ਵੱਖ ਕੀਤਾ ਹੋਇਆ, secrets environment variables ਤੋਂ ਲੋਡ ਹੋਣ, ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗਾਂ 'ਤੇ ਚੇਤਾਵਨੀਆਂ।
ਉਹ ਇੱਕ ਸਮਝਦਾਰ ਫੋਲਡਰ ਢਾਂਚਾ ਵੀ ਦਿੰਦੇ ਹਨ—ਰਾਊਟਸ, ਕੰਟਰੋਲਰ, ਵਿਊਜ਼, ਕੰਪੋਨੈਂਟ, ਟੈਸਟਸ ਲਈ—ਤਾਂ ਜੋ ਨਵੇਂ ਯੋਗਦਾਨਕਾਰ ਤੇਜ਼ੀ ਨਾਲ ਚੀਜ਼ਾਂ ਲੱਭ ਸਕਣ ਅਤੇ ਹਰ ਸਪ੍ਰਿੰਟ ਵਿੱਚ ਨਵੀਂ ਵਿਵਸਥਾ ਨਹੀਂ ਬਣਾਉਣ।
ਅਤੇ ਕਾਫੀ ਸਾਰੇ ਸੈੱਟਅਪ 'ਤੇ ਰਾਇਤਤ ਰੱਖਦੇ ਹਨ: ਇੱਕ "ਬਲੇਸਡ" ਤਰੀਕਾ ਐਪ ਸ਼ੁਰੂ ਕਰਨ ਦਾ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣ ਦਾ, ਡਿਪੈਂਡੈਂਸੀ ਇੰਜੈਕਸ਼ਨ ਸੰਭਾਲਣ ਦਾ, ਜਾਂ ਮਿਡਲਵੇਅਰ ਰਜਿਸਟਰ ਕਰਨ ਦਾ। ਇਹ ਸੀਮਿਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸ਼ੁਰੂਆਤੀ ਅਵਰੋਧ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਲੋਕ ਅਕਸਰ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕਿਹੜੇ ਫੈਸਲੇ ਖਤਰਨਾਕ ਹਨ, ਜਾਂ ਕਿਹੜੇ "ਤੇਜ਼ ਫਿਕਸ" ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਸਮੱਸਿਆ ਬਣ ਜਾਣਗੇ। ਸੁਰੱਖਿਅਤ ਡੀਫੌਲਟ ਆਸਾਨ ਮਾਰਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਮਾਰਗ ਬਣਾਉਂਦੇ ਹਨ: ਘੱਟ ਅਕਸਿਡੈਂਟਲ ਏਕਸਪੋਜ਼ਰ, ਘੱਟ ਅਸੰਗਤ ਰਿਵਾਜ, ਅਤੇ ਘੱਟ ਨਾਜ਼ੁਕ ਇਕ-ਵਾਰੀ ਸੈਟਅਪ।
ਡੀਫੌਲਟ ਫਰੇਮਵਰਕ ਲੇਖਕਾਂ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਤੁਹਾਡੇ ਡੋਮੇਨ, ਕੰਪਲਾਇੰਸ ਦੀ ਲੋੜ, ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ, ਜਾਂ ਡਿਪਲੋਇਮੈਂਟ ਮਾਡਲ ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ। ਡੀਫੌਲਟਾਂ ਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬੇਸਲਾਈਨ ਵਜੋਂ ਲਓ, ਸੁਚਿੱਤ ਨਹੀਂ ਮੰਨੋ—ਉਹਨਾਂ ਦੀ ਸਪੱਸ਼ਟ ਸਮੀਖਿਆ ਕਰੋ, ਕੀਤੇ ਗਏ ਬਦਲਾਅ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਅਤੇ ਅਪਗ੍ਰੇਡ ਜਾਂ ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਲੋੜਾਂ ਬਦਲਣ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਫਿਰ ਵੇਖੋ।
ਫਰੇਮਵਰਕ ਰਿਵਾਜ ਆਮ ਤੌਰ 'ਤੇ "ਕਨਵੇਂਸ਼ਨ ਓਵਰ ਕੰਫਿਗਰੇਸ਼ਨ" ਵਜੋਂ ਵਰਣਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਘਰ ਦੇ ਨਿਯਮਾਂ ਨਾਲ ਸਹਿਮਤ ਹੋ ਜਾਂਦੇ ਹੋ ਤਾਂ ਜੋ ਹਰ ਚੀਜ਼ 'ਤੇ ਵੇਰਵਾ ਨਹੀ ਕਰਨਾ ਪਏ।
ਇੱਕ ਰਿਸ਼ਤੇਦਾਰ ਉਦਾਹਰਨ grocery store ਹੈ। ਤੁਸੀਂ ਦੁੱਧ ਲੱਭਣ ਲਈ ਨਕਸ਼ਾ ਨਹੀਂ ਚਾਹੀਦਾ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਸਟੋਰ ਦੁੱਧ ਨੂੰ ਜਾਣੂ ਥਾਂ 'ਤੇ ਰੱਖਦੇ ਹਨ। ਸਟੋਰ ਦੁੱਧ ਕਿਸੇ ਵੀ ਥਾਂ ਰੱਖ ਸਕਦਾ ਸੀ, ਪਰ ਸਾਂਝਾ ਰਿਵਾਜ ਸਭ ਲਈ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ।
ਰਿਵਾਜ ਉਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਡੀਫੌਲਟ ਜਵਾਬ ਵਜੋਂ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ ਜੋ ਟੀਮਾਂ ਹੋਰਥਾਂ ਵਿਚ ਗੱਲ ਕਰਦੀਆਂ:
User ਵਿਰੁੱਧ Users, getUser() ਵਿਰੁੱਧ fetchUser()—ਫਰੇਮਵਰਕ ਇਕ ਇੱਕਸਾਰ ਸਟਾਈਲ ਵੱਲ ਧੱਕਦੇ ਹਨ।ਜਦ ਇਹ ਰਿਵਾਜ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਅਪਨਾਏ ਜਾਂਦੇ ਹਨ, ਨਵਾਂ ਡਿਵੈਲਪਰ ਪ੍ਰੋਜੈਕਟ "ਪੜ੍ਹ" ਸਕਦਾ ਹੈ ਤੇਜ਼ੀ ਨਾਲ। ਉਹ ਪਤਾ ਲਾ ਲੈਂਦਾ ਹੈ ਕਿ ਲੌਗਿਨ ਫਲੋ ਕਿੱਥੇ ਹੈ, ਵੈਲਿਡੇਸ਼ਨ ਕਿੱਥੇ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਐਪ ਵਿੱਚ ਕਿਵੇਂ ਚਲਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਨੇਹਾਂcodebase ਪਹਿਲਾਂ ਨਾ ਵੇਖਿਆ ਹੋਵੇ।
ਪ੍ਰਡਿਕਟੇਬਲ ਢਾਂਚਾ ਛੋਟੇ ਫੈਸਲਿਆਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਸਮਾਂ ਅਤੇ ਧਿਆਨ ਖਿੱਚਦੇ ਹਨ। ਇਹ ਆਨਬੋਰਡਿੰਗ ਨੂੰ ਸੁਧਾਰਦਾ, ਕੋਡ ਰਿਵਿਊਜ਼ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ("ਇਹ ਆਮ ਪੈਟਰਨ ਨਾਲ ਮਿਲਦਾ ਹੈ"), ਅਤੇ ਅਣਜਾਣੇ ਅਸੰਗਤੀਆਂ ਨੂੰ ਰੋਕਦਾ ਜੋ ਬਾਅਦ ਵਿੱਚ ਬੱਗ ਜਾਂ ਮੁਰੰਮਤ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਣ ਸਕਦੀਆਂ ਹਨ।
ਰਿਵਾਜ ਲਚਕੀਲਤਾ ਘਟਾ ਸਕਦੇ ਹਨ। ਐਜ ਕੇਸ—ਅਸਧਾਰਨ ਰਾਊਟਿੰਗ ਲੋੜਾਂ, ਮਲਟੀ-ਟੈਨੈਂਟ ਡੇਟਾ ਮਾਡਲ, ਗੈਰ-ਮਿਆਰੀ ਡਿਪਲੋਇਮੈਂਟ—ਡੀਫੌਲਟ ਪ੍ਰੋਜੈਕਟ ਸੁਰਚਨਾ ਨਾਲ ਟਕਰਾਅ ਕਰ ਸਕਦੇ ਹਨ। ਜਦ ਐਸਾ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ workaround ਇਕੱਤਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਫਰੇਮਵਰਕ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮੋੜ ਸਕਦੀਆਂ ਹਨ ਜੋ ਭਵਿੱਖ ਦੇ ਮੇਨਟੇਨਰਾਂ ਨੂੰ ਉਲਝਨ ਵਿੱਚ ਪਾ ਦੇਵੇ। ਲਕਛ ਹੈ ਕਿ ਜਿੱਥੇ ਰਿਵਾਜ ਮਦਦ ਕਰਦਾ ਹੈ ਉਥੇ ਉਹਨਾਂ ਨੂੰ ਫਾਲੋ ਕਰੋ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਡਾਈਵਰਜ ਕਰਦੇ ਹੋ ਤਾਂ ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਟੂਲ ਨਹੀਂ ਦਿੰਦੇ—ਉਹ ਸੌਫ਼ਟਵੇਅਰ ਬਣਾਉਣ ਦਾ ਇੱਕ ਪ੍ਰਸਿੱਧ ਤਰੀਕਾ ਵੀ ਐਨਕੋਡ ਕਰਦੇ ਹਨ। ਇਸੀ ਲਈ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ "ਸੰਗਠਿਤ" ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਈ ਫੈਸਲੇ ਨਹੀਂ ਲਏ ਹੁੰਦੇ: ਆਮ ਪੈਟਰਨ ਪਹਿਲਾਂ ਹੀ ਫੋਲਡਰ ਲੇਆਊਟ, ਬੇਸ ਕਲਾਸ, ਰਾਊਟਿੰਗ ਨਿਯਮ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਮੈਥਡ ਦੇ ਨਾਮਾਂ ਵਿੱਚ ਦਰਸਾਏ ਜਾਂਦੇ ਹਨ।
ਕਈ ਫਰੇਮਵਰਕ ਇੱਕ ਡੀਫੌਲਟ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ ਜਿਵੇਂ MVC (Model–View–Controller), ਜੋ UI, ਬਿਜ਼ਨਸ ਲਾਜਿਕ, ਅਤੇ ਡੇਟਾ ਐਕਸੈਸ ਨੂੰ ਵੱਖ ਕਰਨਾ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਹੈ। ਹੋਰ dependency injection (DI) ਨੂੰ ਅੱਗੇ ਧੱਕਦੇ ਹਨ ਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਰਜਿਸਟਰ ਅਤੇ ਉਪਭੋਗ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਕੋਡ ਕੰਕਰੀਟ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਦੀ ਥਾਂ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿਰਭਰ ਰਹੇ। ਵੈੱਬ ਫਰੇਮਵਰਕ ਅਕਸਰ middleware ਰਾਹੀਂ ਰਿਕਵੈਸਟ ਹੈਂਡਲਿੰਗ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ ਕ੍ਰਾਸ-ਕੱਟਿੰਗ ਚਿੰਤਾਵਾਂ (auth, logging, rate limiting) ਨੂੰ ਕੰਪੋਜ਼ੇਬਲ ਕਦਮਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦੇ ਹਨ।
ਇਹ ਪੈਟਰਨ "ਖਾਲੀ ਪੰਨਾ" ਡਿਜ਼ਾਈਨ ਕੰਮ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਨੈਵੀਗੇਬਲ ਬਣਾਉਂਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਟੀਮਾਂ ਲਈ। ਜਦ ਢਾਂਚਾ ਅਨੁਮਾਨਯੋਗ ਹੁੰਦਾ ਹੈ, ਨਵੇਂ ਫੀਚਰ ਜੋੜਨਾ ਸੁਖਾਵਾਂ ਅਤੇ ਘੱਟ ਖਤਰੇ ਵਾਲਾ ਹੁੰਦਾ ਹੈ।
ਪੈਟਰਨ ਕੁਦਰਤੀ ਸਿਲਿਆਂ ਬਣਾਉਂਦੇ ਹਨ।
MVC ਨਾਲ, controllers ਪਤਲੇ ਐਂਟਰੀ ਪੁਆਇੰਟ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ request/response fixtures ਨਾਲ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ। DI ਨਾਲ, ਤੁਸੀਂ ਯੂਨਿਟ ਟੈਸਟਾਂ ਵਿੱਚ ਅਸਲ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਨੂੰ ਫੇਕਸ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕੋਡ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ। ਮਿਡਲਵੇਅਰ ਇੱਕ ਅਲੱਗ ਕਦਮ ਨੂੰ ਇਕੱਲਾ ਟੈਸਟ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ: ਤੁਸੀਂ ਪੂਰੀ ਐਪ ਚਲਾਏ ਬਿਨਾਂ ਇੱਕ ਸਿੰਗਲ ਸਟੈਪ ਦੀ ਵਿਹਾਰਿਤਾ ਨੂੰ ਵੇਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਜਦ ਪੈਟਰਨ ਸਮੱਸਿਆ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਤਾਂ ਇਹ ਰਸਮ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣਾਂ: ਹਰ ਚੀਜ਼ ਨੂੰ ਸੇਵਾ ਵੱਲ ਫੋਰਸ ਕਰਨਾ ਜਦ ਇੱਕ ਸਧਾਰਣ ਫੰਕਸ਼ਨ ਹੀ ਕਾਫ਼ੀ ਹੁੰਦਾ; ਫਾਈਲਾਂ ਨੂੰ ਐੱਫਾ-ਲਾਇਰਾਂ ਵਿੱਚ ਵੰਡਣਾ ਜੋ ਤਕਰੀਬਨ ਸਿਰਫ਼ ਡੇਟਾ ਭੇਜਦਾ ਹੈ; ਮਿਡਲਵੇਅਰ ਜੋ ਉਸ ਵਿਹਾਰ ਲਈ ਹੈ ਜੋ ਇੱਕ ਏਂਡਪੋਇੰਟ ਅੰਦਰ ਹੋਣਾ ਚਾਹੀਦਾ।
ਫਰੇਮਵਰਕ ਅਕਸਰ ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਨੂੰ ਯਾਦ ਰੱਖਦੇ ਹਨ ਤਾਂ ਜੋ ਟੀਮਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕਠੋਰ ਤਰੀਕੇ ਨਾਲ ਸਿਖਣਾ ਨਾ ਪਵੇ। ਹਰ ਡਿਵੈਲਪਰ ਨੂੰ ਸੁਰੱਖਿਆ ਦਾ ਤਜਰਬੇਕਾਰ ਮੰਨਣ ਦੀ ਥਾਂ, ਉਹ ਗਾਰਡਰੇਲ ਨਾਲ ਆਉਂਦੇ ਹਨ ਜੋ ਸੁਰੱਖਿਅਤ ਚੋਣ ਨੂੰ ਡੀਫੌਲਟ ਬਣਾਉਂਦੇ ਹਨ—ਅਤੇ ਖਤਰਨਾਕ ਚੋਣਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਇਰਾਦੇਵਾਰ ਬਣਾਉਂਦੇ ਹਨ।
ਹੁਣਕੱਲ੍ਹ ਦੈਨਿਕ ਸੁਰੱਖਿਆ ਦੇ ਕਈ ਅਭਿਆਸ ਆਮ ਫਰੇਮਵਰਕ ਫੀਚਰਾਂ ਵਜੋਂ ਮਿਲਦੇ ਹਨ:
HttpOnly, Secure, ਅਤੇ SameSite ਵਰਗੀਆਂ ਸੇਫ਼ ਡੀਫੌਲਟ।ਇਹ ਫੀਚਰ ਆਮ ਹਮਲਿਆਂ (ਟਰੈਮਪਰਿੰਗ, ਕ੍ਰਾਸ-ਸਾਈਟ ਰਿਕਵੈਸਟ, ਸੈਸ਼ਨ ਚੋਰੀ) ਤੋਂ ਮਿਲੀ ਸਿੱਖਿਆ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸਧਾਰਨ ਪਾਈਪਲਾਈਨ ਦੇ ਨੇੜੇ ਲਿਆਉਂਦੇ ਹਨ।
ਸੁਰੱਖਿਆ ਫਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਰੋਟੀਨ ਅਪਡੇਟਾਂ ਰਾਹੀਂ ਆਉਂਦੇ ਹਨ। ਫਰੇਮਵਰਕ ਅਤੇ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਨੂੰ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਕਈ ਪੈਚ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਨਹੀਂ ਬਦਲਦੇ—ਸਿਰਫ਼ ਤੁਹਾਡੀ ਖੁਲਾਸਗੀ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡਾ ਖ਼ਤਰਾ ਅਨਜਾਣੇ ਤੌਰ 'ਤੇ opt-out ਕਰ ਲੈਣਾ ਹੈ। ਆਮ ਗਲਤ ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਵਿੱਚ ਸ਼ਾਮِل ਹਨ:
ਫਰੇਮਵਰਕ ਸੁਰੱਖਿਆ ਡੀਫੌਲਟ ਨੂੰ ਇੱਕ ਬੇਸਲਾਈਨ ਸਮਝੋ, ਗਾਰੰਟੀ ਨਹੀਂ, ਅਤੇ ਅਪਗ੍ਰੇਡ ਦੌਰਾਨ ਬਦਲਾਵਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਨਾ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਅਣਸੂਚਿਤ ਤੌਰ 'ਤੇ ਪੋਸਟਪੋਨ ਕਰੋ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਕੋਡ ਲਿਖਣਾ ਆਸਾਨ ਨਹੀਂ ਬਣਾਉਂਦੇ—ਉਹ ਇਹ ਵੀ ਆਸਾਨ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਕਰੋ ਕਿ ਕੋਡ ਕੰਮ ਕਰਦਾ ਰਹੇ। ਸਿਰੇ-ਸਮੇਂ, ਕਮਿਊਨਿਟੀ ਆਪਣੀਆਂ ਕਠਿਨ ਸਿੱਖਿਆਵਾਂ ਨੂੰ ਡਿਫੌਲਟ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ, ਕਮਾਂਡਸ, ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨਜ਼ ਵਿੱਚ ਐਨਕੋਡ ਕਰ ਦੇਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਗੁਣਵੱਤਾ ਅਭਿਆਸ ਨਾਰਮਲ ਤਰੀਕੇ ਨਾਲ ਬਣ ਜਾਣ।
ਕਈ ਫਰੇਮਵਰਕ ਇੱਕ ਪ੍ਰਡਿਕਟੇਬਲ ਲੇਆਊਟ ਸਕੈਫੋਲਡ ਕਰਦੇ ਹਨ—ਐਪ ਕੋਡ, ਕੰਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਟੈਸਟਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖ ਕੇ—ਤਾਂ ਜੋ ਟੈਸਟ ਜੋੜਨਾ ਇੱਕ ਸਾਦਾ ਅਗਲਾ ਕਦਮ ਬਣ ਜਾਵੇ, ਕਿਸੇ ਵੱਖਰੀ ਮੁਹਿੰਮ ਵਾਂਗ। ਇੱਕ ਬਿਲਟ-ਇਨ ਟੈਸਟ ਕਮਾਂਡ (ਅਕਸਰ ਇੱਕ ਹੀ CLI ਐਂਟਰੀ ਪੁਆਇੰਟ) ਵੀ ਲੋਕਾਂ ਲਈ ਟੈਸਟ ਚਲਾਉਣ ਦੀ ਰੁਚੀ ਘਟਾਉਂਦੀ ਹੈ।
ਆਮ ਟੂਲਿੰਗ ਜੋ ਬੇਕ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਾਂ ਘਣੀ ਤਰੀਕੇ ਨਾਲ ਇੰਟੀਗਰੇਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
ਨਤੀਜਾ ਸੁੱਕਾ ਪਰ ਤਾਕਤਵਰ ਹੁੰਦਾ ਹੈ: ਫਰੇਮਵਰਕ ਦੀ "ਹੈਪੀ ਪਾਥ" ਚੁਪਚਾਪ ਉਹਨਾਂ ਅਭਿਆਸਾਂ ਨਾਲ ਸੰਰੇਖਤ ਹੁੰਦੀ ਹੈ ਜੋ ਟੀਮਾਂ ਨੇ ਕਠੋਰ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖੀਆਂ ਹੁੰਦੀਆਂ।
ਗੁਣਵੱਤਾ ਵੀ ਇਕਸਾਰਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਫਰੇਮਵਰਕ ਟੂਲਿੰਗ ਅਕਸਰ ਕੰਫਿਗਰੇਸ਼ਨ ਲੋਡਿੰਗ, environment variables, ਅਤੇ ਟੈਸਟ ਡੇਟਾਬੇਸ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਟੈਸਟ ਲੈਪਟੌਪ ਤੇ ਅਤੇ CI ਵਿੱਚ ਇੱਕ ਜਿਹੇ ਵਿਹਾਰ ਕਰਨ। ਜਦ ਪ੍ਰੋਜੈਕਟ ਦਾ canonical ਤਰੀਕਾ ਹੋਵੇ ਸੇਵਾਵਾਂ ਸ਼ੁਰੂ ਕਰਨ, ਸੀਡ ਡੇਟਾ ਪਾਉਣ, ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣ ਲਈ, ਤਦ ਫੇਲਿਯਰ ਡਿਬੱਗ ਕਰਨ ਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ: ਜੇ ਨਵਾਂ ਸਾਥੀ README ਪੜ੍ਹ ਕੇ test ਸਫਲਤਾਪੂਰਵਕ ਚਲਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਲੁਕਾਏ ਹੋਏ ਬਹੁਤ ਤੋਂ ਬਹੁਤ दोष ਘਟਾ ਦਿੱਤੇ ਹਨ।
ਫਰੇਮਵਰਕ ਗੁਣਵੱਤਾ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਪਰ ਚੰਗੀ ਟੂਲਿੰਗ ਨਿਰਾਕਾਰਕ ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਡੀਫੌਲਟ ਆਦਤ ਬਣਾਉਂਦੀ ਹੈ ਨਾ ਕਿ ਲੰਬੇ ਤੱਤੇ ਤਕਰਾਰਾਂ ਵਾਲਾ ਵਿਵਾਦ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਫੀਚਰਾਂ ਜ਼ਿਆਦਾ ਨਹੀਂ ਭੇਜਦੇ—ਉਹ ਚੁੱਪ-ਚਾਪ ਇਹ ਉਮੀਦ ਰੱਖਦੇ ਹਨ ਕਿ ਐਪ ਲੋਡ ਹੇਠ ਕੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗੀ ਅਤੇ ਜਦ ਕੋਈ ਗਲਤ ਹੋਏ ਤਾਂ ਤੁਸੀਂ ਕਿਵੇਂ ਸਮਝੋਗੇ।
ਕਈ ਪ੍ਰਦਰਸ਼ਨ ਅਭਿਆਸ ਡੀਫੌਲਟ ਅਤੇ ਆਇਡੀਅਮਸ ਰਾਹੀਂ ਆਉਂਦੇ ਹਨ ਨਾ ਕਿ ਚੈੱਕਲਿਸਟ ਦੁਆਰਾ। ਆਮ ਉਦਾਹਰਨ ਵਿੱਚ caching ਲੇਅਰ (response caching, ORM query caching), batch ਕਰਨਾ (bulk DB writes, request coalescing), ਅਤੇ lazy loading (ਸਿਰਫ਼ ਉਹ ਡੇਟਾ ਫੈਚ ਕਰਨਾ ਜਿੰਨ੍ਹਾਂ ਦੀ ਸੱਚੀ ਲੋੜ ਹੋਵੇ) ਸ਼ਾਮِل ਹਨ। ਛੋਟੀਆਂ ਸਹੂਲਤਾਂ—ਜਿਵੇਂ connection pooling ਜਾਂ ਸੌਝਾ pagination ਹੇਲਪਰ—ਵੀ ਸਾਲਾਂ ਦੀ ਗਿਆਨ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਖਰਾਬ ਹੁੰਦਾ ਹੈ।
ਇਸ ਦਾ ਅਰਥ ਇਹ ਹੈ ਕਿ "ਡਿਫੌਲਟ ਤੇ ਤੇਜ਼" ਅਤੇ "ਸਕੇਲ ਤੇ ਤੇਜ਼" ਵਿੱਚ ਫਰਕ ਹੈ। ਫਰੇਮਵਰਕ ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਸਹੀ ਡੀਫੌਲਟ ਨਾਲ ਚੁਸਤ ਬਣਾ ਸਕਦਾ ਹੈ, ਪਰ ਵਾਸਤਵਿਕ ਸਕੇਲ ਲਈ ਗਹਿਰੇ ਫੈਸਲੇ ਲੋੜੀਂਦੇ ਹਨ: ਡੇਟਾ ਮਾਡਲਿੰਗ, ਕਿਊਈਂਗ ਸਟ੍ਰੈਟਜੀ, ਰੀਡ/ਰਾਈਟ ਵੰਡ, CDN ਵਰਤੋਂ, ਅਤੇ N+1 ਕਵੇਰੀਜ਼ ਅਤੇ ਨੈਟਵਰਕ ਕਾਲਜ਼ ਉੱਤੇ ਧਿਆਨ।
ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਜ਼ਿਆਦातर ਬਿਲਟ-ਇਨ ਜਾਂ ਪਹਿਲੀ-ਕਲਾਸ ਇੰਟੀਗ੍ਰੇਸ਼ਨਜ਼ ਲਈ ਬਣ ਰਹੇ ਹਨ: ਸਟ੍ਰੱਕਚਰਡ ਲੋਗਿੰਗ, ਮੈਟ੍ਰਿਕਸ ਐਕਸਪੋਰਟਰ, ਅਤੇ ਟ੍ਰੇਸਿੰਗ ਹੂਕ ਜੋ ਰਿਕਵੈਸਟ ID ਨੂੰ ਸੇਵਾ-ਸੇਵਾ ਤੱਕ ਪ੍ਰਸਾਰਿਤ ਕਰਦੇ ਹਨ। ਉਹ ਸਟੈਂਡਰਡ ਮਿਡਲਵੇਅਰ/ਇੰਟਰਸੈਪਟਰ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਰਿਕਵੈਸਟ ਟਾਈਮਿੰਗ ਲੌਗ ਕਰਦੇ ਹਨ, ਐਕਸਪਸ਼ਨ ਕੈਪਚਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਸੰਦਰਭੀ ਖੇਤਰ (user ID, route name, correlation ID) ਜੋੜਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡਾ ਫਰੇਮਵਰਕ "ਬਲੇਸਡ" ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਭੇਜਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤੋ—ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਡੈਸ਼ਬੋਰਡਾਂ ਅਤੇ 온-ਕਾਲ ਰਨ-ਬੁਕਸ ਨੂੰ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਸਾਨੀ ਨਾਲ ਟਰਾਂਸਫਰ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਫਰੇਮਵਰਕ کنਵੇਂਸ਼ਨ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਡੀਫੌਲਟ ਵੱਲ ਰਾਹ ਦਿਖਾ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਤੁਹਾਡਾ ਬੋਟਲਨੈਕ ਦਾ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾ ਸਕਦੇ। ਕੋਡ ਦੁਬਾਰਾ ਲਿਖਣ ਜਾਂ ਨੋਬਸ ਨੂੰ ਮੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਮੈਜ਼ਰ ਕਰੋ (latency percentiles, database time, queue depth)। ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਤਦ ਹੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ ਜਦ ਇਹ ਸਬੂਤਾਂ 'ਤੇ ਆਧਾਰਤ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਅਨੁਮਾਨਾਂ 'ਤੇ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਫੀਚਰ ਨਹੀਂ ਜੋੜਦੇ—ਉਹ "ਸਹੀ ਤਰੀਕਾ" ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਦਿੰਦੇ ਹਨ। ਸਮੇਂ ਨਾਲ਼, ਇਹ ਵਿਕਾਸ ਡਿਪ੍ਰਿਕੇਸ਼ਨਾਂ, ਨਵੇਂ ਡੀਫੌਲਟ, ਅਤੇ ਕਈ ਵਾਰੀ ਬ੍ਰੇਕਿੰਗ ਚੇਂਜਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿੱਸਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਅਨੁਮਾਨਾਂ 'ਤੇ ਵਾਪਸ ਜਾਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਸਾਲਾਂ ਪਹਿਲਾਂ ਲੀ।
ਆਮ ਸਮਰੂਪ ਇਹ ਹੈ: ਇੱਕ ਪ੍ਰੈਕਟਿਸ ਪ੍ਰਸਿੱਧ ਬਣ ਜਾਂਦੀ ਹੈ, ਫਰੇਮਵਰਕ ਇਸਨੂੰ ਸਟੈਂਡਰਡ ਕਰ ਦਿੰਦਾ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਦ ਨਵੇਂ ਖਤਰੇ ਜਾਂ ਬਿਹਤਰ ਤਕਨੀਕ ਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਫਰੇਮਵਰਕ ਉਸਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਡਿਪ੍ਰਿਕੇਸ਼ਨ ਫਰੇਮਵਰਕ ਦਾ ਤਰੀਕਾ ਹੈ ਇਹ ਕਹਿਣ ਦਾ, "ਇਹ ਪਹਿਲਾਂ ਠੀਕ ਸੀ, ਪਰ ਅਸੀਂ ਹੋਰ ਸਿੱਖ ਚੁੱਕੇ ਹਾਂ।" ਨਵੇਂ ਡੀਫੌਲਟ ਅਕਸਰ ਸੁਰੱਖਿਅਤ ਵਿਹਾਰ ਵੱਲ ਧੱਕਦੇ ਹਨ, ਜਦਕਿ ਬ੍ਰੇਕਿੰਗ ਚੇਂਜ ਪੁਰਾਣੇ ਰਸਤੇ ਹਟਾ ਦਿੰਦੇ ਹਨ।
ਜੋ ਪਹਿਲਾਂ ਸਰਵੋਤਮ ਸੀ, ਉਹ ਅਣਕੱਲ੍ਹ ਇੱਕ ਪਾਬੰਦੀ ਬਣ ਸਕਦਾ ਹੈ ਜਦ:
ਇਸ ਨਾਲ "ਫਰੇਮਵਰਕ ਕਰਜ਼ਾ" ਬਣ ਸਕਦਾ ਹੈ: ਤੁਹਾਡਾ ਕੋਡ ਹਾਲਤ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਮੁਰੰਮਤ ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਭਰਤੀ ਕਰਨੀ ਔਖੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸੁਰੱਖਿਆ ਸਭਾਲਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅਪਗ੍ਰੇਡ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਕਿਰਿਆ ਦੇ ਤੌਰ 'ਤੇ ਸੋਚੋ, ਨ ਕਿ ਇੱਕ ਬਚਾਉਣ ਵਾਲੀ ਮੁਹਿੰਮ ਵੱਜੋਂ:
ਜੇ ਤੁਹਾਡੇ ਮੰਗਾਂ ਸਥਿਰ ਹਨ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕ-ਟੋਕੀ ਉਪਾਇਆ ਹੈ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ end-of-life ਯੋਜਨਾ ਹੈ, ਤਾਂ ਅਜੇ ਰਹਿਣਾ ਠੀਕ ਹੈ। ਜਦ ਸੁਰੱਖਿਆ ਸਮਰਥਨ ਖਤਮ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਅਪਗ੍ਰੇਡ ਅਣਟੂਟ ਹੋ ਰਹੇ ਹੋਣ, ਜਾਂ ਨਵੇਂ ਡੀਫੌਲਟ ਘੱਟ ਖਤਰਾ ਅਤੇ ਮੁਰੰਮਤ ਲਾਗਤ ਘਟਾਉਂਦੇ ਹੋਣ ਤਾਂ ਮੂਵ ਕਰੋ।
ਫਰੇਮਵਰਕ ਆਪਣਾ ਫੈਸਲਾ ਆਪ ਨਹੀਂ ਕਰਦੇ। ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਕਮਿਊਨਿਟੀ—ਮੇਨਟੇਨਰ, ਕੋਰ ਕਨਟ੍ਰੀਬਿਊਟਰ, ਵੱਡੇ ਉਪਭੋਗੀ, ਅਤੇ ਟੂਲ ਲੇਖਕ—ਕ੍ਰਮਸ਼: ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਸੁਰੱਖਿਅਤ, ਮੈਨਟੇਨਬਲ, ਅਤੇ ਵਿਅਾਪਕ ਤੌਰ 'ਤੇ ਲਾਗੂਯੋਗ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਉਹ ਫੈਸਲੇ ਡੀਫੌਲਟ, ਸਿਫ਼ਾਰਸ਼ੀ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ, ਅਤੇ ਆਧਿਕਾਰਿਕ APIs ਵਜੋਂ ਠਹਿਰ ਜਾਂਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਮਿਆਰ ਆਮ ਦਰਦ ਦੇ ਦੋਹਰਾਓ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਜਦ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਇੱਕੋ ਹੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ (ਰਾਊਟਿੰਗ ਜਟਿਲਤਾ, ਆਥ ਭੁੱਲਾਂ, ਅਸੰਗਤ ਗਲਤੀ-ਹੈਂਡਲਿੰਗ), ਕਮਿਊਨਿਟੀ ਅਸਲ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵਿਵਹਾਰ ਜਾਂਚਦੀ ਹੈ, ਮੁੱਦੇ ਅਤੇ RFCs ਵਿੱਚ ਤਰਕ-ਵਟਾਂਦਰਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਰਿਲੀਜ਼ ਰਾਹੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਨਿਖਾਰਦੀ ਹੈ।
ਜਿਹੜਾ ਜੀਵਤ ਰਹਿੰਦਾ ਹੈ ਉਹ ਆਮ ਤੌਰ 'ਤੇ:
ਇਕੋਸਿਸਟਮ ਅਕਸਰ ਜੀਤ ਨੂੰ ਪਹਿਲਾਂ ਐਜ 'ਤੇ ਪਰਖਦੇ ਹਨ। ਪਲੱਗਇਨ, ਐਕਸਟੇਂਸ਼ਨ, ਅਤੇ ਤੀਜੀ-ਪੱਖ ਪੈਕੇਜ ਨਵੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਹਰ ਕਿਸੇ 'ਤੇ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਐਕਸਪੇਰੀਮੈਂਟ ਕਰਨ ਲਈ ਮੌਕਾ ਦਿੰਦੇ ਹਨ। ਜੇ ਕੋਈ ਪਲੱਗਇਨ ਲੋਕਪ੍ਰਿਯ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹੀ ਤਰੀਕਾ ਵੱਖ-ਵੱਖ ਵਰਜਨਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੋਰ ਵਿੱਚ ਸ਼ਾਮِل ਹੋ ਸਕਦਾ ਹੈ—ਜਾਂ ਆਧਿਕਾਰਿਕ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਵਿੱਚ ਤਾਕਤ ਨਾਲ ਪ੍ਰਚਾਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਡੌਕਸ ਸਿਰਫ਼ ਸੰਦਰਭ ਸਮੱਗਰੀ ਨਹੀਂ ਹਨ; ਉਹ ਵਿਹਾਰਕ ਧੱਕ ਵੀ ਹਨ। "Getting started" ਟਿਊਟੋਰਿਅਲ, ਸਟਾਰਟਰ ਟੈਮਪਲੇਟ, ਅਤੇ ਆਧਿਕਾਰਿਕ ਉਦਾਹਰਣ ਰੇਪੋ ਪ੍ਰਤੱਖ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਕਿ "ਨਾਰਮਲ" ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ: ਫੋਲਡਰ ਲੇਆਊਟ, ਨਾਮਕਰਨ ਰਿਵਾਜ, ਟੈਸਟਿੰਗ ਸ਼ੈਲੀ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਕਿਵੇਂ ਬਣਾਈਏ।
ਜੇ ਤੁਸੀਂ ਜੈਨਰੇਟਰ ਜਾਂ ਸਟਾਰਟਰ ਕਿੱਟ ਵਰਤਦੇ ਹੋ, ਤੁਸੀਂ ਉਹਨਾਂ ਅਭਿਆਸਾਂ ਨੂੰ ਵਾਰਸਾ ਵਿੱਚ ਲੈ ਰਹੇ ਹੋ—ਅਕਸਰ ਲਾਭਦਾਇਕ, ਕਦੇ-ਕਦੇ ਸੀਮਿਤ।
ਕਮਿਊਨਿਟੀ ਮਿਆਰ ਹਿਲਦੇ-ਮੁੜਦੇ ਰਹਿੰਦੇ ਹਨ। ਡੀਫੌਲਟ ਬਦਲਦੇ ਹਨ, ਪੁਰਾਣੇ APIs ਨੂੰ ਦੁਰੂਸਤ ਨਹੀਂ ਕਹਿ ਕੇ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਵੀਆੰ ਸੁਰੱਖਿਆ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਦਿਸ਼ਾਵਾਂ ਆਉਂਦੀਆਂ ਹਨ। ਅਪਗ੍ਰੇਡ (ਜਾਂ ਨਵਾਂ ਮੇਜ਼ਰ ਵਰਜਨ) ਅਪਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਧਿਕਾਰਿਕ ਡੌਕਸ ਅਤੇ ਰਿਲੀਜ਼ ਨੋਟਸ ਨੂੰ ਤੁਰੰਤ ਪੜ੍ਹਨਾ ਤੁਹਾਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਕਿ ਕਿਉਂ ਰਿਵਾਜ ਬਦਲੇ ਅਤੇ ਕਿਹੜੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਅਣਟਾਲੀਆਂ ਹਨ।
ਫਰੇਮਵਰਕ ਸੈਂਕੜੇ ਘੰਟਿਆਂ ਦੀ ਕੋਸ਼ਿਸ਼-ਗਲਤੀ ਬਚਾ ਸਕਦੇ ਹਨ—ਪਰ ਉਹ ਧਾਰਨਾਵਾਂ ਨੂੰ ਵੀ ਐਨਕੋਡ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਣਾ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਰੇਮਵਰਕ ਨੂੰ ਇੱਕ ਡੀਫੌਲਟ ਸੈੱਟ ਦੇ ਤੌਰ 'ਤੇ ਸਿੱਖੋ, ਨ ਕਿ ਪ੍ਰੋਡਕਟ ਸੋਚ ਦੀ ਥਾਂ।
ਫਰੇਮਵਰਕ ਨੂੰ ਆਪਣੀ ਸਥਿਤੀ ਨਾਲ ਮਿਲਾਉਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਸ਼ੁਰੂਆਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਲਿਸਟ ਬਣਾਓ ਕਿ ਫਰੇਮਵਰਕ ਕੀ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਕੀ-ਕੀ ਚੁਣਨ ਦੀ ਆਜ਼ਾਦੀ ਹੈ:
ਜਿੱਥੇ ਰਿਵਾਜ ਸੰਗਤਤਾ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਉਥੇ ਫਰੇਮਵਰਕ ਦੇ ਰਿਵਾਜ ਅਪਣਾਓ, ਪਰ ਆਪਣੇ ਪੁਰਾਣੇ ਆਦਤਾਂ ਲਈ ਇਸਨੂੰ ਮੁੜ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ ਵੱਡੀ ਵਿਭਿੰਨਤਾ ਦੀ ਲੋੜ ਹੈ (ਕਸਟਮ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚਾ, ਕੋਰ ਕੰਪੋਨੈਂਟ ਬਦਲਣਾ), ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਸੀਂ ਗਲਤ ਟੂਲ ਚੁਣ ਰਹੇ ਹੋ—ਜਾਂ ਤੁਹਾਨੂੰ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਇੱਕ ਪਤਲੀ ਪਰਤ ਦੇ ਪਿੱਛੇ ਆਈਸੋਲੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਨੂੰ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰਨ ਲਈ: ਇੱਕ ਨਜਿੱਠੀ ਫਲੋ (auth → data write → background work → UI update) ਦਾ ਪੂਰਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ, ਅਤੇ ਦੇਖੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨਾ "ਗਲੂ" ਬਣਾਉਣਾ ਪਿਆ। ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਗਲੂ, ਉਤਨਾ ਇਹ ਸੰਭਾਵਨਾ ਕਿ ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਦੀ ਕੁਝ ਮੂਲ ਧਾਰਨਾਵਾਂ ਦੇ ਵਿਰੁੱਧ ਕੰਮ ਕਰ ਰਹੇ ਹੋ।
ਫਰੇਮਵਰਕ ਤਜਰਬਾ ਐਨਕੋਡ ਕਰਦੇ ਹਨ; ਚੁਣੌਤੀ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਕਿਹੜੇ ਰਿਵਾਜ ਤੁਸੀਂ ਵਾਰਸਾ ਵਿੱਚ ਲੈਣਾ ਚਾਹੁੰਦੇ ਹੋ—ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਮਹੀਨੇ ਮੂਰ੍ਹੇ ਕੋਡਬੇਸ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ। Koder.ai ਤੁਹਾਨੂੰ ਉਸ "ਛੋਟੇ ਸਪਾਇਕ" ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਐਪ ਦਾ ਵਰਣਨ ਦੇ ਸਕਦੇ ਹੋ, ਇੱਕ ਵਰਕਿੰਗ ਬੇਸਲਾਈਨ (ਅਕਸਰ React ਫਰੰਟ ਐਂਡ ਨਾਲ Go + PostgreSQL ਬੈਕਐਂਡ, ਜਾਂ ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ) ਜਨਰੇਟ ਕਰਵਾ ਸਕਦੇ ਹੋ, ਅਤੇ planning mode ਵਿੱਚ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲੇ ਸਪੱਸ਼ਟ ਕਰ ਸਕਦੇ ਹੋ।
Koder.ai source code export, snapshots, ਅਤੇ rollback ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਆਰਕੀਟੈਕਚਰਲ ਰਿਵਾਜਾਂ (ਰਾਊਟਿੰਗ ਅੰਦਾਜ਼, ਵੈਲਿਡੇਸ਼ਨ ਸੀਮਾਵਾਂ, ਆਥ ਮਿਡਲਵੇਅਰ ਚੋਣਾਂ) ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇੱਕ ਪਹਿਲੇ ਨਿਰਧਾਰਤ ਫੈਸਲੇ 'ਚ ਫਸਣ ਦੇ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਦੀਆਂ ਸਰਵੋਤਮ ਅਭਿਆਸਾਂ ਨੂੰ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਅਪਣਾਉਂਦੇ ਹੋ—ਡੀਫੌਲਟ ਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਮੰਨਦਿਆਂ, ਪਰ ਲੋੜਾਂ ਸਾਫ ਹੋਣ 'ਤੇ ਅਸਾਨੀ ਨਾਲ ਵਿਕਸਿਤ ਕਰਨ ਦੀ स्वतੰਤਰਤਾ ਰੱਖਦੇ ਹੋ।
A framework feels like “experience in a box” because it bundles repeated lessons from many projects into defaults, conventions, and built-in patterns. Instead of each team re-learning the same failures (security gaps, inconsistent structure, brittle deployments), the framework makes a safer, more predictable path the easiest path.
The key difference is inversion of control:
That control over the app’s “skeleton” is why frameworks decide more for you.
Predictability means a project has a standard shape and flow so production behavior and code navigation are easier to reason about.
In practice, frameworks standardize things like where code lives, how requests move through the system, how errors are handled, and how cross-cutting concerns (auth/logging) are applied—reducing surprises across environments and teams.
Frameworks tend to turn common pain into convention via a feedback loop:
That’s why many “rules” are effectively memorials of past outages, security incidents, or debugging nightmares.
Defaults quietly set your baseline because teams often keep the initial configuration.
Common examples include:
These reduce early decision load and prevent common beginner mistakes.
Not automatically. Defaults reflect the framework authors’ assumptions, which may not match your constraints (compliance, traffic patterns, deployment model).
A practical approach:
Conventions reduce time spent on low-value debates (naming, file placement, workflows) and improve:
They’re most valuable in team settings where consistency beats local optimization.
Common baked-in patterns include MVC, dependency injection, and middleware pipelines.
They help by creating clear seams:
The risk is adding ceremony (extra layers/indirection) when the problem doesn’t need it.
Framework guardrails commonly include:
HttpOnly, Secure, SameSite)They reduce risk, but only if you (e.g., disabling CSRF to “make the form work”) and if you to receive patches.
“Framework debt” is when your code still runs, but the framework’s older conventions and APIs make it harder to upgrade, secure, hire for, or operate.
To reduce it:
Move off old patterns when security support is ending or upgrades become all-or-nothing.