04 ਦਸੰ 2025·8 ਮਿੰਟ
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਅਨੁਭਵੀ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਿਉਂ ਪਸੰਦ ਆਉਂਦੇ ਹਨ
ਜਾਣੋ ਕਿ ਅਨੁਭਵੀ ਡਿਵੈਲਪਰ ਕਿਉਂ ਮਿਨੀਮਲਿਸਟ ਫ੍ਰੇਮਵਰਕ ਪਸੰਦ ਕਰਦੇ ਹਨ: ਵੱਧ ਕਾਬੂ, ਘੱਟ ਡਿਪੈਂਡੈਂਸੀਜ਼, ਸਪਸ਼ਟ ਆਰਕੀਟੈਕਚਰ, ਆਸਾਨ ਟੈਸਟਿੰਗ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸੰਭਾਲ।
ਜਾਣੋ ਕਿ ਅਨੁਭਵੀ ਡਿਵੈਲਪਰ ਕਿਉਂ ਮਿਨੀਮਲਿਸਟ ਫ੍ਰੇਮਵਰਕ ਪਸੰਦ ਕਰਦੇ ਹਨ: ਵੱਧ ਕਾਬੂ, ਘੱਟ ਡਿਪੈਂਡੈਂਸੀਜ਼, ਸਪਸ਼ਟ ਆਰਕੀਟੈਕਚਰ, ਆਸਾਨ ਟੈਸਟਿੰਗ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸੰਭਾਲ।
ਇੱਕ “ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ” ਉਹ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਇੱਕ ਛੋਟਾ ਕੋਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਘੱਟ-ਮਿਆਰੀ ਫੈਸਲੇ ਬਣਾਏ ਜਾਂਦੇ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਦਿੰਦਾ—ਰਾਊਟਿੰਗ, ਰਿਕਵੇਸਟ/ਰੇਸਪਾਂਸ ਹੈਂਡਲਿੰਗ, ਬੇਸਿਕ ਮਿਡਲਵੇਅਰ ਹੋਕ—ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ “ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਕਰੀਏ?” ਵਾਲੀਆਂ ਚੋਣਾਂ ਟੀਮ 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਡਿਫ਼ਾਲਟ, ਘੱਟ ਜਨਰੇਟਰ, ਅਤੇ ਘੱਟ ਬੰਡਲ ਕੀਤੇ ਸਬਸਿਸਟਮ (ਜਿਵੇਂ ORM, ਟੈਂਪਲੇਟਿੰਗ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼, ਜਾਂ ਆਥ) ਹੁੰਦਾ ਹੈ।
ਅਮਲ ਵਿੱਚ, ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ:
ਇਹ ਗੱਲ ਫੀਚਰਾਂ ਦੀ ਘਾਟ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਫੀਚਰਾਂ ਦੇ ਵਿਕਲਪਿਕ ਅਤੇ ਐਕੰਪੋਜ਼ੇਬਲ ਹੋਣ ਬਾਰੇ ਹੈ, ਨਾ ਕਿ ਪਹਿਲਾਂ ਤੋਂ ਚੁਣੇ ਹੋਏ ਹੋਣ ਬਾਰੇ।
“ਅਨੁਭਵੀ ਡਿਵੈਲਪਰ” ਇੱਥੇ ਸਿਰਫ਼ ਵੇਹਲੇ ਸਾਲਾਂ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਲੋਕ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਬਣਾਏ ਅਤੇ ਸੰਭਾਲੇ ਹਨ ਜਿਸ ਤਕ ਉਹ ਇਨ੍ਹਾਂ ਗੱਲਾਂ ਲਈ ਓਪਟੀਮਾਈਜ਼ ਕਰ ਸਕਦੇ ਹਨ:
ਉਹ ਅਕਸਰ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਇਨ ਕਰਨ, ਲਾਇਬਰੇਰੀਆਂ ਚੁਣਨ ਅਤੇ ਫੈਸਲਿਆਂ ਨੂੰ ਡੌਕਯੂਮੈਂਟ ਕਰਨ ਵਿੱਚ ਆਰਾਮਦਾਇਕ ਹੁੰਦੇ ਹਨ—ਉਹ ਕੰਮ ਜੋ ਕਿਸੇ ਹੋਰ ਰਾਇ ਵਾਲਾ ਫ੍ਰੇਮਵਰਕ ਤੁਹਾਡੇ ਲਈ ਕਰਦਾ ਹੈ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਆਪੋ-ਆਪਣੇ “ਵਧੀਆ” ਨਹੀਂ ਹੁੰਦੇ। ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਕਾਬੂ ਚਾਹੁੰਦੀ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰ ਕਰਨ ਲਈ ਪੈਟਰਨ, ਗਾਰਡਰੇਲ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ ਤਿਆਰ ਕਰਨ ਲਈ ਰਾਜੀ ਹੋਵੇ, ਤਾਂ ਇਹ ਆਪਣੀ ਜਗ੍ਹਾ 'ਤੇ ਚੰਗੇ ਫਿੱਟ ਹੁੰਦੇ ਹਨ। ਕੁਝ ਐਪ ਲਈ, ਇੱਕ ਫੁੱਲ-ਸਟੈਕ ਫ੍ਰੇਮਵਰਕ ਦੇ ਡਿਫ਼ਾਲਟ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਹਿਣਗੇ।
ਤੁਸੀਂ ਅਜਿਹੇ ਸਧਾਰਣ ਰਵੱਈਏ ਨੂੰ Express/Fastify (Node.js), Flask (Python), Sinatra (Ruby) ਅਤੇ ਵੱਡੇ ਏਕੋਸਿਸਟਮਾਂ ਦੇ ਵੈੱਬ “ਮਾਈਕ੍ਰੋ” ਮੋਡ ਵਿੱਚ ਵੇਖੋਂਗੇ। ਮਸਲਾ ਨਾਮਾਂ ਦਾ ਨਹੀਂ—ਦਰਸਕਸ਼ ਇਹ ਹੈ: ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਸਿਰਫ ਉਹੀ ਜੋ ਚਾਹੀਦਾ ਹੈ ਸ਼ਾਮਲ ਕਰੋ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ “ਪੇਵ ਕੀਤੀ ਰੋਡ” ਦੀ ਤراجੀ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਚੰਗੀ ਨਿਸ਼ਾਨ-ਦਰਸ਼ਿਕ ਨਕਸ਼ਾ ਦੇਂਦੇ ਹਨ। ਪੂਰੇ ਸਟੈਕ ਦੇ ਰਿਵਾਜਾਂ (ਫੋਲਡਰਾਂ ਦੀ ਬਣਤਰ, ਕਾਰੋਬਾਰੀ ਲੌਜਿਕ ਕਿੱਥੇ ਰਹੇਗੀ, ਕਿਹੜਾ ORM ਵਰਤਣਾ) ਨੂੰ ਉਤਰਾਅਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ ਛੋਟੇ ਕੋਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਅਤੇ ਕੇਵਲ ਉਹੀ ਜੋ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲੋੜੀਦਾ ਹੈ ਜੋੜਦੇ ਹੋ।
ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡੇਡ ਫ੍ਰੇਮਵਰਕ ਪਹਿਲੀ ਵਿਸ਼ੇਸ਼ਤਾ ਤੱਕ ਤੇਜ਼ੀ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਜਨਰੇਟਰ, ਡਿਫ਼ਾਲਟ ਪੈਟਰਨ, ਪਹਿਲਾਂ ਹੀ ਵਾਇਰਡ ਮਿਡਲਵੇਅਰ, ਅਤੇ ਐਕੋਸਿਸਟਮ ਜੋ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਹਾਊਸ ਸਟਾਈਲ ਫੋਲੋ ਕਰੋਗੇ। ਇਹ ਸੁਵਿਧਾ ਅਸਲੀ ਹੈ, ਪਰ ਇਹ ਵੀ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਅਪਨਾਉਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਸਕਦੇ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਇਸ ਬਰੌਇਨ ਨੂੰ ਅਲਟ ਕਰਦੇ ਹਨ। ਤੁਸੀਂ ਆਪਣਾ ਰਾਊਟਿੰਗ ਅੰਦਾਜ਼, ਵੈਲਿਡੇਸ਼ਨ ਦਰਜਾ, ਡਾਟਾ ਐਕਸੈਸ ਲੇਅਰ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ ਚੁਣਦੇ ਹੋ। ਇਹ ਆਜ਼ਾਦੀ ਅਨੁਭਵੀ ਡਿਵੈਲਪਰਾਂ ਲਈ ਅਹੰਕਾਰਪੂਰਨ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੇ “ਹਰ ਚੀਜ਼ ਡਿਫ਼ਾਲਟ” ਦੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਖਰਚੇ ਦੇਖੇ ਹੁੰਦੇ ਹਨ—ਸ਼ੁਰੂ ਵਿੱਚ ਉਤਪਾਦਕ ਪਰੰਤੂ ਜਦੋਂ ਮੰਗਾਂ ਵਿਸ਼ੇਸ਼ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਣ ਵਾਲੀ ਕੋਡਬੇਸ।
ਡਿਫ਼ਾਲਟ ਸਿਰਫ਼ ਰਾਏ ਨਹੀਂ; ਉਹ ਛੁਪੇ ਹੋਏ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ। ਇੱਕ ਫ੍ਰੇਮਵਰਕ ਜੋ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਆਟੋ-ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਗਲੋਬਲ ਸਟੇਟ ਇੰਜੈਕਟ ਕਰਦਾ ਹੈ, ਜਾਂ ਫਾਈਲ ਸਕੈਨਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ, ਉਹ ਟਾਈਪਿੰਗ ਬਚਾ ਸਕਦਾ ਹੈ, ਪਰ ਵਿਹਾਰ ਨੂੰ ਵਿਆਖਿਆ ਕਰਨਾ ਮੁਸ਼ਕਲ ਕਰ ਸਕਦਾ ਹੈ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਹੋਂਦੇ ਹਨ: ਤੁਸੀਂ ਟੁਕੜੇ ਆਪਸ ਵਿੱਚ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਕਿ ਸਿਸਟਮ ਦਾ ਵਿਹਾਰ ਸੋਚਣਾ, ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਬਦਲਣਾ ਆਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਨੁਕਸਾਨ ਸਪਸ਼ਟ ਹੈ: ਸ਼ੁਰੂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਫੈਸਲੇ ਕਰਨੇ ਪੈਣਗੇ। ਤੁਸੀਂ ਲਾਇਬਰੇਰੀਆਂ ਚੁਣੋਗੇ, ਮਿਆਰ ਸੈੱਟ ਕਰੋਗੇ, ਅਤੇ ਪੈਟਰਨ ਨਿਰਧਾਰਤ ਕਰੋਗੇ ਜੋ ਟੀਮ ਅਨੁਸਰਣ ਕਰੇਗੀ। ਅਨੁਭਵੀ ਡਿਵੈਲਪਰ ਅਕਸਰ ਇਸ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਐਸੀ ਕੋਡਬੇਸ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਸਮੱਸਿਆ ਦੇ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ—ਫਰੇਮਵਰਕ ਦੀਆਂ ਧਾਰਨਾਂ ਨਾਲ ਨਹੀਂ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਛੋਟੇ ਕੋਰ ਨਾਲ ਆਉਂਦੇ ਹਨ: ਘੱਟ ਬਿਲਟ-ਇਨ ਮੌਡੀਊਲ, ਘੱਟ “ਸੁਵਿਧਾ” ਲੇਅਰ, ਅਤੇ ਇਸ ਲਈ ਘੱਟ ਟਰਾਂਸੀਟਿਵ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਜੋ ਤੁਹਾਡੇ ਪਿੱਠ-ਅੰਦਰ ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ। ਅਨੁਭਵੀ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਸਾਦਗੀ ਇੱਕ ਸੁੰਦਰਤਾ ਨਹੀਂ—ਇਹ ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਹੈ।
ਹਰ ਇਕ ਵਾਧੂ ਪੈਕੇਜ ਤੁਹਾਡੇ ਡਿਪੈਂਡੈਂਸੀ ਟ੍ਰੀ ਵਿੱਚ ਇੱਕ ਹੋਰ ਚਲਦਾ ਹਿੱਸਾ ਹੈ ਜਿਸ ਦੀ ਆਪਣੀ ਰਿਲੀਜ਼ ਸਕੈਜੂਲ, ਖਾਮੀਆਂ ਅਤੇ ਤੋੜ-ਮਰੋੜ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਫ੍ਰੇਮਵਰਕ ਬਹੁਤ ਸਾਰੀਆਂ ਫੀਚਰਾਂ ਨੂੰ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਬੰਡਲ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਇੱਕ ਵਿਸ਼ਾਲ ਗੁੰਝਲਦਾਰ ਗ੍ਰਾਫ ਵਾਰਸ੍ਥਾਪਤ ਕਰ ਲੈਂਦੇ ਹੋ—ਭਾਵੇਂ ਤੁਸੀਂ ਅੱਧੀ ਫੰਕਸ਼ਨਾਲਿਟੀ ਵੀ ਵਰਤੋਂ ਨਾ ਕਰੋ।
ਇਹ ਵਿਆਪਾਰਕਤਾ ਅਪਗਰੇਡ ਖਤਰੇ ਨੂੰ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਵਧਾਉਂਦੀ ਹੈ:
ਮਿਨੀਮਲਿਸਮ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਆਂ ਅਤੇ ਆਰਕੀਟੈਕਚਰਲ ਆਡਿਟ ਨੂੰ ਆਸਾਨ ਬਣਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ “ਡਿਫ਼ਾਲਟ ਸਟੈਕ” ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ:
ਇਹ ਸਪਸ਼ਟਤਾ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦੀ ਹੈ: ਘੱਟ ਛੁਪੇ ਰਿਵਾਜ਼ ਅਤੇ ਘੱਟ ਬੰਡਲ ਕੀਤੇ ਹੇਲਪਰਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਮੀਖਿਆਕਾਰ ਕੋਡਬੇਸ ਅਤੇ ਇੱਕ ਛੋਟੀ ਡਿਪੈਂਡੈਂਸੀ ਸੂਚੀ ਤੋਂ ਵਿਹਾਰ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹਨ।
ਉਲਟ ਪਾਸਾ ਸੱਚਮੁਚੀ ਹੈ: ਤੁਹਾਨੂੰ ਖੁਦ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਜੋੜਣੀਆਂ ਪੈ ਸਕਦੀਆਂ ਹਨ (auth, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼, ਵੈਲਿਡੇਸ਼ਨ, ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ)। ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਜਟਿਲਤਾ ਨੂੰ ਹਟਾਉਂਦੇ ਨਹੀਂ—ਉਹ ਉਸਨੂੰ ਸਪਸ਼ਟ ਚੋਣਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹਨ। ਅਨੁਭਵੀ ਲੋਕਾਂ ਲਈ, ਇਹ ਅਕਸਰ ਇੱਕ ਫੀਚਰ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਕੰਪੋਨੈਂਟ ਚੁਣਦੇ ਹੋ, ਵਰਜਨਾਂ ਨਿਸ਼ਾਨਦੇਹ ਕਰਦੇ ਹੋ, ਅਤੇ ਡਿਪੈਂਡੈਂਸੀ ਟ੍ਰੀ ਨੂੰ ਐਪ ਦੀ ਲੋੜਾਂ ਨਾਲ ਮਿਲਾਓਂਦੇ ਹੋ।
ਨਵੇਂ ਲੋਕਾਂ ਲਈ ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਪਹਿਲੇ ਵਾਰੀ ਵਿੱਚ ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਲ ਲੱਗ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਫੈਸਲੇ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਨ। ਉਥੇ ਘੱਟ "ਡਿਫ਼ਾਲਟ ਸੈਫੋਲਡਿੰਗ" ਹੁੰਦੀ ਹੈ ਜੋ ਦੱਸੇ ਕਿ ਫਾਇਲਾਂ ਕਿੱਥੇ ਜਾਣ, ਕਿਵੇਂ ਰਿਕਵੇਸਟਾਂ ਦੇ ਨਾਲ ਨਿਭਣਾ, ਜਾਂ ਕਿਸ ਪੈਟਰਨ ਨੂੰ ਫੋਲੋ ਕਰਨਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਬਣਾਇਆ ਹੋਇਆ ਵੈੱਬ ਐਪ ਦਾ ਮენტਲ ਮਾਡਲ ਰੱਖਦੇ, ਤਾਂ ਇਹ ਆਜ਼ਾਦੀ ਉਲਝਣ ਵਾਲੀ ਹੋ ਸਕਦੀ ਹੈ।
ਅਨੁਭਵੀ ਡਿਵੈਲਪਰਾਂ ਲਈ, ਉਹੀ ਗੁਣ ਅਕਸਰ ਸਿੱਖਣ ਦੀ ਘਾਤ ਘਟਾਉਂਦੇ ਹਨ।
ਛੋਟੀ API ਸਤਹ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੁਝ ਗਿਣਤੀ-ਤੱਤਾਂ ਨੂੰ ਯਾਦ ਰੱਖ ਕੇ ਤੁਸੀਂ ਕੁਝ ਹੀ ਸਮੇਂ ਵਿੱਚ ਕੰਮਕਾਜੀ ਐਂਡਪਾਇੰਟ ਚਲਾ ਸਕਦੇ ਹੋ: ਰਾਊਟ, ਹੈਂਡਲਰ, ਮਿਡਲਵੇਅਰ, ਟੈਂਪਲੇਟ (ਵਿਕਲਪ), ਅਤੇ ਕਨਫਿਗरेशन।
ਇਹ ਛੋਟਾ, ਸੁਸੰਗਤ ਕੋਰ ਤੁਹਾਨੂੰ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਿਆਂ ਯਾਦ ਰੱਖਣ ਵਿੱਚ ਤੇਜ਼ੀ ਦਿੰਦਾ—ਖ਼ਾਸ ਕਰਕੇ ਉਨ੍ਹਾਂ ਫਰੇਮਵਰਕਾਂ ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ ਜਿੱਥੇ ਇੱਕੋ ਕੰਮ ਨੂੰ ਕਈ ਰਸਤੇ ਨਾਲ ਅਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਉਹ ਗੱਲਾਂ ਵੇਖਾਉਂਦੇ ਹਨ ਜੋ ਵਾਕਈ ਹੋ ਰਿਹਾ ਹੈ: HTTP ਰਿਕਵੇਸਟ ਕਿਸ ਤਰ੍ਹਾਂ ਕੋਡ ਨਾਲ ਜੁੜਦੀ ਹੈ, ਡੇਟਾ ਕਿੱਥੇ ਵੈਲਿਡੇਟ ਹੁੰਦਾ ਹੈ, ਗਲਤੀ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਰਿਸਪਾਂਸ ਕਿਸ ਤਰ੍ਹਾਂ ਬਣਦਾ ਹੈ। ਖਾਸ ਡੇਕੋਰੇਟਰਾਂ, ਜਨਰੇਟਰਾਂ ਜਾਂ ਛੁਪੇ ਰਿਵਾਜ਼ਾਂ ਨੂੰ ਯਾਦ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਅਜਿਹੀਆਂ ਬੁਨਿਆਦੀਆਂ ਤੇ ਸਮਾਂ ਵਿਤਾਉਂਦੇ ਹੋ ਜੋ ਸਟੈਕਾਂ ਵਿੱਚ ਤਬਦੀਲ ਹੁੰਦੀਆਂ ਹਨ।
ਇਸੇ ਕਾਰਨ ਨਾਲ ਵਰਿਟਨ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ: ਉਹ ਪਹਿਲਾਂ ਹੀ ਰਾਊਟਿੰਗ, ਸਟੇਟ, ਕੈਸ਼ਿੰਗ, ਸੁਰੱਖਿਆ ਸੀਮਾਵਾਂ ਅਤੇ ਡਿਪਲੋਯਮੈਂਟ ਮੁਢਲੀਆਂ ਗੱਲਾਂ ਨੂੰ ਸਮਝਦੇ ਹਨ। ਇੱਕ ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਰਾਹ ਵਿੱਚੋਂ ਹਟ ਕੇ ਰਹਿੰਦਾ ਹੈ।
ਜਦੋਂ ਘੱਟ ਚਲਦੇ ਹਿੱਸੇ ਅਤੇ ਘੱਟ “ਪ੍ਰਸਿੱਧ ਪੈਟਰਨ” ਹੁੰਦੇ ਹਨ, ਟੀਮ ਅਕਸਰ ਤੇਜ਼ੀ ਨਾਲ ਔਨਬੋਰਡ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਛੋਟਾ ਫਰੇਮਵਰਕ + ਇੱਕ ਸਪਸ਼ਟ ਅੰਦਰੂਨੀ ਟੈਮਪਲੇਟ (ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ, ਲੌਗਿੰਗ, ਲਿੰਟਿੰਗ, ਟੈਸਟਿੰਗ) ਇੱਕ ਵੱਡੇ ਫਰੇਮਵਰਕ ਨਾਲੋਂ ਅਨੁਮਾਨਿਤ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਦਰਜਨਾਂ ਵਿਕਲਪਿਤ ਮੌਡੀਊਲ ਹੁੰਦੇ ਹਨ।
ਛੋਟੇ ਫਰੇਮਵਰਕ ਆਪਣੇ-ਆਪ ਵਿੱਚ ਆਸਾਨ ਨਹੀਂ ਹੁੰਦੇ। ਜੇ ਡੌਕਸ ਥਿੰਨ ਹਨ, ਉਦਾਹਰਨ ਅਪ-ਟੂ-ਡੇਟ ਨਹੀਂ ਹਨ, ਜਾਂ ਮੁੱਖ ਫੈਸਲੇ ਅਣਦਸਤਾਵੇਜ਼ ਹਨ (auth, validation, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼), ਤਾਂ ਨਵੇਂ ਆਉਣ ਵਾਲੇ ਮੁਸ਼ਕਲੀਆਂ ਨਾਲ ਦੰਭ ਰਹਿਣਗੇ ਅਤੇ ਸੀਨੀਅਰ ਸਮਾਂ ਖਰਚ ਕਰਾਂਗੇ। ਸ਼ਾਨਦਾਰ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਇੱਕ ਟੀਮ ਪਲੇਬੁੱਕ ਮਿਨੀਮਲ ਦ੍ਰਿਸ਼ਟੀ ਨੂੰ ਫ਼ਾਇਦਾ ਪਹੁੰਚਾਉਂਦੇ ਹਨ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਤੁਹਾਡੀ ਐਪ "ਆਪਣੇ ਲਈ ਠੀਕ ਢੰਗ" ਨਹੀਂ ਬਣਾਉਂਦੇ। ਇਸ ਨਾਲ ਪਹਿਲੇ ਵਾਰ ਕੁਝ ਵਾਧੂ ਕੰਮ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਹੀ ਨیتੀਜਾ ਦਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਰਾਦੇ ਨਾਲ ਆਰਕੀਟੈਕਚਰ ਬਨਾਓ: ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਕਿੱਥੇ ਰਹੇਗਾ, ਕਿਹੜੇ ਲੇਅਰ ਹੋਣਗੇ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਕਿਵੇਂ ਵੰਡੀਆਂ ਜਾਣ।
ਘੱਟ ਡਿਫ਼ਾਲਟਾਂ ਨਾਲ, ਟੀਮਾਂ ਅਕਸਰ ਢਾਂਚਾ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਉਤਪਾਦ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਫਰੇਮਵਰਕ ਨੂੰ। ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਕਾਰੋਬਾਰੀ ਯੋਗਤਾ (ਬਿੱਲਿੰਗ, ਆਨਬੋੜਿੰਗ, ਰਿਪੋਰਟਿੰਗ) ਦੇ ਅਧਾਰ 'ਤੇ ਗਰੁੱਪ ਕਰ ਸਕਦੇ ਹੋ, ਨ ਕਿ ਟੈਕਨੀਕੀ ਕਿਸਮ (ਕੰਟਰੋਲਰ, ਸਰਵਿਸ, ਰਿਪੋਜ਼ਿਟਰੀ) ਦੇ ਅਧਾਰ 'ਤੇ। ਇਸਦਾ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਆਰਕੀਟੈਕਚਰ ਉਸੇ ਕਿਸੇ ਵਿਅਕਤੀ ਲਈ ਪੜ੍ਹਨ ਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਉਤਪਾਦ ਨੂੰ ਸਮਝਦਾ ਹੈ—ਭਾਵੇਂ ਉਹ ਫਰੇਮਵਰਕ ਦੀਆਂ ਧਾਰਾਂ ਨੂੰ ਯਾਦ ਨਾ ਕਰਦਾ ਹੋਵੇ।
ਮਿਨੀਮਲਿਸਮ ਸਭ ਤੋਂ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਨੇ ਫੈਸਲੇ ਸਪਸ਼ਟ ਕੀਤੇ ਹੋਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਲਿਖਿਆ ਹੋਵੇ। ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ “ਐਪ ਕਨਵੇਂਸ਼ਨ” ਪੰਨਾ ਇਹ ਕਵਰ ਕਰ ਸਕਦਾ ਹੈ:
ਜਦੋਂ ਇਹ ਚੋਣ ਲਿਖੇ ਹੋਏ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਪਸ਼ਟਤਾ ਕਬਜੇਦਾਰੀ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਨਵੇਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਐਕਸੀਡੈਂਟਲ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖਣਾ ਨਹੀਂ ਪੈਂਦਾ, ਅਤੇ ਸੀਨੀਅਰ ਡਿਵੈਲਪਰ ਸੁਭਾਅਤ ਆਟੋ-ਗੇਟਕੀਪਰ ਨਹੀਂ ਬਣਦੇ।
ਜਦੋਂ ਆਰਕੀਟੈਕਚਰ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ, ਕੋਡ ਰਿਵਿਊ ਸਧਾਰਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਸਮੀਖਿਆਕਾਰ ਸਹੀਤਾ ਅਤੇ ਡਿਜ਼ਾਈਨ ਟਰੇਡ-ਆਫ ਉੱਤੇ ਧਿਆਨ ਦੇ ਸਕਦਾ ਹੈ ਬਜਾਏ ਇਹ ਅਨੁਮਾਨ ਲਾਉਣ ਦੇ ਕਿ "ਫਰੇਮਵਰਕ ਇਹ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿੱਥੇ ਜਾਵੇ।" ਇਸ ਨਾਲ ਗੱਲ-ਬਾਤ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੋਡਬੇਸ ਇੱਕਰੂਪ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਹਾਲਾਂਕਿ ਉਹ ਕਸਟਮ ਹੋ ਸਕਦੀ ਹੈ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਅਕਸਰ “ਤੇਜ਼” ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਪਰ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿ ਇਸਦਾ ਅਰਥ ਕੀ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਪੇਰਫਾਰਮੈਂਸ ਤਿੰਨ ਥਾਵਾਂ 'ਤੇ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਹਨ: ਸਟਾਰਟਅਪ ਸਮਾਂ (ਐਪ ਕਿੰਨੀ ਜਲਦੀ ਬੂਟ ਹੁੰਦੀ ਹੈ ਜਾਂ ਜ਼ੀਰੋ ਤੋਂ ਸਕੇਲ ਹੁੰਦੀ ਹੈ), ਮੇਮੋਰੀ ਉਪਯੋਗ (ਹਰ ਇਨਸਟੈਂਸ ਕਿੰਨੀ RAM ਖਾਂਦਾ ਹੈ), ਅਤੇ ਰਿਕਵੇਸਟ ਓਵਰਹੈੱਡ (ਤੁਹਾਡੇ ਕੋਡ ਕੋਲ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨਾ ਕੰਮ ਹੁੰਦਾ ਹੈ)।
ਘੱਟ ਬਿਲਟ-ਇਨ ਲੇਅਰਾਂ ਨਾਲ, ਇੱਕ ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਰਿਕਵੇਸਟ ਪ੍ਰਤੀ ਘੱਟ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ: ਘੱਟ ਆਟੋਮੈਟਿਕ ਮਿਡਲਵੇਅਰ, ਘੱਟ ਰਿਫਲੈਕਸ਼ਨ-ਭਰਿਆ ਰਾਊਟਿੰਗ, ਘੱਟ ਗਲੋਬਲ ਹੋਕ, ਅਤੇ ਘੱਟ ਡਿਫ਼ਾਲਟ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ। ਇਸ ਨਾਲ CPU ਸਾਈਕਲ ਘਟ ਸਕਦੇ ਹਨ ਅਤੇ ਬੇਸਲਾਈਨ ਮੇਮੋਰੀ ਘਟ ਸਕਦੀ ਹੈ। ਸਟਾਰਟਅਪ ਵੀ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਘੱਟ ਚੀਜ਼ਾਂ ਹੌਰਟਜ਼ ਹੋਣਗੀਆਂ।
ਇਹ ਫਾਇਦੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਮਹਿਸੂਸ ਹੋਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਇਨਸਟੈਂਸ ਚਲਾਉਂਦੇ ਹੋ (ਕਨਟੇਨਰ, ਸਰਵਰਲੈਸ, ਐਜ ਵਰਕਰ) ਜਾਂ ਜਦੋਂ ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਕੀਤਾ ਕੰਮ ਥੋੜ੍ਹਾ ਹੈ ਅਤੇ ਫਰੇਮਵਰਕ ਓਵਰਹੈੱਡ ਕੁੱਲ ਸਮੇਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਚੋਣ ਅਕਸਰ ਮੁੱਖ ਪ੍ਰਦਰਸ਼ਨ ਹਥਿਆਰ ਨਹੀਂ ਹੁੰਦੀ। ਡੇਟਾਬੇਜ਼ ਕਵੈਰੀਜ਼, ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀਆਂ, ਪੇਲੋਡ ਆਕਾਰ, ਲੌਗਿੰਗ, ਨੈਟਵਰਕ ਲੇਟੈਂਸੀ, ਅਤੇ ਇੰਫ੍ਰਾਸਟਰਕਚਰ ਕਨਫਿਗਰੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਬਲ ਪ੍ਰਭਾਵ ਵਾਲੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਉਹ ਐਪ ਨਹੀਂ ਬਚਾ ਸਕਦਾ ਜੋ N+1 ਕਵੈਰੀਜ਼ ਕਰ ਰਿਹਾ ਹੈ, ਵੱਡੇ ਆਬਜੈਕਟ ਸਿਰੀਲਾਈਜ਼ ਕਰਦਾ ਹੈ, ਜਾਂ ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਤਿੰਨ ਡਾਊਨਸਟ੍ਰੀਮ ਸਰਵਿਸز ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੇ ਬਦਲੇ, ਆਪਣੇ ਪ੍ਰਤੀਨਿਧੀ ਐਂਡਪਾਇੰਟ 'ਤੇ ਇੱਕ ਸਧਾਰਨ ਬੈਂਚਮਾਰਕ ਚਲਾਓ:
ਹਲਕੀ PoC ਵੀ ਇਹ ਦਿਖਾ ਸਕਦੀ ਹੈ ਕਿ "ਹਲਕਾ" ਫਰੇਮਵਰਕ ਲਾਗਤ ਅਤੇ ਲੇਟੈਂਸੀ ਵਿੱਚ ਵਾਸਤਵਿਕ ਸੁਧਾਰ ਲਿਆਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਪਿਛੋਂ ਘੱਟ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਹ ਟੈਸਟ ਲਿਖਦੇ ਸਮੇਂ ਇੱਕ ਚੁੱਪੀ-ਸੂਪਰਪਾਵਰ ਹੈ: ਘੱਟ ਨਿਰਪੱਖ ਹੋਕ, ਘੱਟ ਆਟੋ-ਜਨਰੇਟ ਕੀਤੇ ਆਬਜੈਕਟ, ਅਤੇ ਘੱਟ "ਇਹ ਟੈਸਟ ਵਿੱਚ ਕਿੰਝ ਵੱਖਰਾ ਹੋ ਰਿਹਾ ਹੈ?" ਵਾਲੇ ਲਹਜੇ।
ਜਦੋਂ ਰਾਊਟਿੰਗ, ਰਿਕਵੇਸਟ ਪਾਰਸਿੰਗ ਅਤੇ ਰਿਸਪਾਂਸ ਬਣਾਉਣਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਟੈਸਟ ਇਨਪੁੱਟ ਅਤੇ ਆਉਟਪੁੱਟ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਫ੍ਰੇਮਵਰਕ ਅੰਦਰੂਨੀ ਗੱਲਾਂ 'ਤੇ। ਇੱਕ ਹੈਂਡਲਰ ਜੋ ਇੱਕ ਰਿਕਵੇਸਟ ਆਬਜੈਕਟ ਲੈਂਦਾ ਅਤੇ ਇੱਕ ਰਿਸਪਾਂਸ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ ਟੈਸਟ ਕਰਨਾ ਸਿੱਧਾ ਹੁੰਦਾ ਹੈ। ਅਕਸਰ ਇੱਕ ਸਿੰਗਲ ਲੌਜਿਕ ਬਰਾਂਚ ਦੀ ਜਾਂਚ ਲਈ ਪੂਰੀ ਐਪ ਕੰਟੇਨਰ ਬੂਟ ਕਰਨ ਦੀ ਲੋੜ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਮਿਨੀਮਲ ਸੈਟਅੱਪ ਤੁਹਾਨੂੰ ਦਿੱਖਣ ਯੋਗ ਸੀਮਾਵਾਂ ਵੱਲ ਧਕੇਲਦਾ ਹੈ: ਹੈਂਡਲਰ/ਕੰਟਰੋਲਰ ਸਰਵਿਸਜ਼ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਸਰਵਿਸਜ਼ ਐਡਾਪਟਰ (ਡੈਟਾਬੇਸ, HTTP, ਕਿਊ) ਵਰਤਦੇ ਹਨ। ਇਹ ਸੀਮਾਵਾਂ ਮੌਕਿੰਗ ਨੂੰ ਭਵਿੱਖਵਾਣੀਯੋਗ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ:
ਇਸਦਾ ਨਤੀਜਾ ਸਾਫ਼ ਯੂਨਿਟ ਟੈਸਟ ਅਤੇ ਘੱਟ ਭੰਗਰਹੀ ਫਿਕਸਚਰ ਹੁੰਦੇ ਹਨ।
ਕਿਉਂਕਿ ਉੱਥੇ ਘੱਟ ਰਨਟਾਈਮ “ਜਾਦੂ” ਹੁੰਦੀ ਹੈ, ਲੋਕਲ ਤੌਰ 'ਤੇ ਜੋ ਵਿਹਾਰ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵੀ ਉਹੀ ਹੁੰਦਾ ਹੈ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਇੱਕ ਛੋਟੀ ਐਪ ਸਤਹ ਉੱਪਰ ਸੱਚੀ ਰਾਊਟਿੰਗ ਅਤੇ ਮਿਡਲਵੇਅਰ ਚੇਨ ਚਲਾਕੇ, ਫਿਰ ਯੂਜ਼ਰ ਵਾਂਗੂ ਉਸਨੂੰ ਹਿੱਟ ਕਰ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਉਹਨਾਂ ਫਰੇਮਵਰਕ-ਨਿਰਧਾਰਿਤ ਰਾਜਾਂ ਦੀਆਂ ਵੱਡੀਆਂ ਮਾਤਰਾਵਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਦੇ ਜੋ ਮੁਸ਼ਕਲ ਹੁੰਦੀਆਂ ਹਨ।
ਡੀਬੱਗਿੰਗ ਨੂੰ ਵੀ ਲਾਭ ਹੁੰਦਾ ਹੈ: ਕੋਡ ਵਿੱਚ ਸਟੀਪ ਕਰਨ ਲਾਈਨਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਲੌਗ ਤੁਹਾਡੇ ਫੰਕਸ਼ਨਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ (ਫਰੇਮਵਰਕ ਗਲੂ ਨਾਲ ਨਹੀਂ), ਅਤੇ ਸਟੈਕ ਟ੍ਰੇਸ ਛੋਟੇ ਹੁੰਦੇ ਹਨ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਤੁਹਾਡੀ ਟੈਸਟ ਸਟੈਕ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ। ਤੁਹਾਨੂੰ ਟੈਸਟ ਰਨਰ, ਅਸਰਸ਼ਨ ਸ਼ੈਲੀ, ਮੌਕਿੰਗ ਦ੍ਰਿਸ਼ਟੀ ਅਤੇ ਫੇਕ/ਫਿਕਸਚਰਾਂ ਲਈ ਪੈਟਰਨ ਚੁਣਣੇ ਪੈਣਗੇ। ਅਨੁਭਵੀ ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਆਜ਼ਾਦੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ—ਪਰ ਇਹ ਲਗਾਤਾਰਤਾ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ “ਸਰਫੇਸ ਏਰੀਆ” ਰੱਖਦੇ ਹਨ: ਘੱਟ ਬਿਲਟ-ਇਨ ਮੌਡੀਊਲ, ਘੱਟ ਵਿਸਤਾਰ ਬਿੰਦੂ, ਅਤੇ ਘੱਟ ਜਨਰੇਟ ਕੀਤੇ ਸਟ੍ਰਕਚਰ। ਇਹ ਸਾਦਗੀ ਸਾਲਾਂ ਲਈ ਐਪ ਨੂੰ ਸੰਭਾਲਣ 'ਤੇ ਫਾਇਦਾ ਪਹੁੰਚਾਉਂਦੀ ਹੈ। ਅਪਗਰੇਡ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਫਾਈਲਾਂ ਨੂੰ ਛੂਹਦੇ ਹਨ, ਅਤੇ ਫਰੇਮਵਰਕ-ਨਿਰਧਾਰਿਤ ਕੋਡ ਘੱਟ ਤਰ੍ਹਾਂ ਨਾਲ ਤੁਹਾਡੇ ਕੋਰ ਲੌਜਿਕ ਵਿੱਚ ਮਿਲਿਆ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਇੱਕ ਫ੍ਰੇਮਵਰਕ ਸਿਰਫ਼ ਜਰੂਰੀ ਚੀਜ਼ਾਂ ਦਿੰਦਾ ਹੈ, ਤੁਹਾਡਾ ਐਪ ਇਕਸਾਰ ਫੈਸਲਿਆਂ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ (ਰਾਊਟਿੰਗ, ਵੈਰੀਫਿਕੇਸ਼ਨ, ਡਾਟਾ ਐਕਸੈਸ). ਸਮੇਂ ਦੇ ਨਾਲ ਇਹ ਛੁਪੇ ਕੱਪਲਿੰਗ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਅਪਗਰੇਡ ਨੇ ਰਾਊਟਿੰਗ API ਬਦਲ ਦਿੱਤੀ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਰਾਊਟਿੰਗ ਲੇਅਰ ਅੱਪਡੇਟ ਕਰੋਗੇ—ਨਾ ਕਿ ਡਜ਼ਨ ਫਰੇਮਵਰਕ-ਦਿੰਦਾਨੇ ਰਿਵਾਜ਼ਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ।
ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਅਕਸਰ ਘੱਟ ਤੋੜ-ਮਰੋੜ ਵਾਲੇ ਬਦਲਾਅ ਤਿਆਰ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਟੁੱਟਣ ਲਈ ਘੱਟ ਫੀਚਰ ਹੁੰਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ "ਕੋਈ ਤੋੜ-ਮਰੋੜ ਨਹੀਂ," ਪਰ ਅਕਸਰ ਅਪਗਰੇਡ ਪੱਧਰ ਘੱਟ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡਾਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।
ਦੀਰਘਕਾਲੀ ਰੱਖ-ਰਖਾਅ ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ—ਇਹ ਕਮਿਉਨਿਟੀ ਹੈ। ਫੈਸਲੇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੱਸ ਫੈਕਟਰ ਨੂੰ ਦੇਖੋ (ਕਿੰਨੇ ਸਰਗਰਮ ਮੈਨਟੇਨਰ), ਰਿਲੀਜ਼ ਰੇਗੁਲਰਿਟੀ, ਮੁੱਦੇ ਦਾ ਜਵਾਬ ਸਮਾਂ, ਅਤੇ ਕਿਸ ਕੰਪਨੀ ਨੇ ਇਸਤੇਮਾਲ ਕੀਤਾ ਹੈ। ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਜੈਕਟ ਸ਼ਾਨਦਾਰ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਜੋਖਿਮ ਭਰਿਆ ਹੈ ਜੇ ਇਹ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਅਤਿਰਿਕਤ ਮੁਫ਼ਤ ਸਮੇਂ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ।
ਵਰਜਨ ਪਿਨ ਕਰੋ (ਲੌਕਫਾਈਲ, ਕੰਟੇਨਰ ਟੈਗ), ਫਿਰ ਨਿਯਮਤ ਸਮੀਖਿਆ ਨਿਰਧਾਰਤ ਕਰੋ:
ਇਹ ਤਰੀਕਾ ਅਪਗਰੇਡਾਂ ਨੂੰ ਐਮਰਜੈਂਸੀ ਰੀਰਾਈਟ ਦੀ ਥਾਂ ਰੋਟੀਨ ਰਖ-ਰਖਾਅ ਬਣਾਉਂਦਾ ਹੈ।
ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ ਕੋਰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ: ਰਾਊਟਿੰਗ, ਰਿਕਵੇਸਟ/ਰੇਸਪਾਂਸ ਹੈਂਡਲਿੰਗ, ਅਤੇ ਇੱਕ ਸਾਫ਼ ਢੰਗ ਨਾਲ ਆਪਣੀਆਂ ਚੋਣਾਂ ਪਲੱਗ-ਇਨ ਕਰਨ ਦਾ ਤਰੀਕਾ। ਇਸ ਨਾਲ ਉਹ ਅਨੁਭਵੀ ਡਿਵੈਲਪਰਾਂ ਨੂੰ "ਭਵਿੱਖ-ਪਰੂਫ" ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ—ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਮੰਗ ਨਹੀਂ ਬਦਲੇਗੀ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਬਦਲਾਅ ਉਮੀਦ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਐਪ ਆਰੰਭਿਕ ਧਾਰਨਾਵਾਂ ਤੋਂ ਵੱਧ ਜਾਓਂਦੀਆਂ ਹਨ। ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਸਧਾਰਨ ਫਾਰਮ ਵੈਲਿਡੇਸ਼ਨ, ਬੇਸਿਕ ਟੈਂਪਲੇਟਿੰਗ ਏੰਜਿਨ, ਅਤੇ ਇੱਕ ਹੀ ਡੇਟਾਬੇਸ ਨਾਲ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ। ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਤੁਹਾਨੂੰ ਹੋਰ ਸਖਤ ਵੈਲਿਡੇਸ਼ਨ ਨੀਤੀਆਂ, ਵੱਖਰਾ ਡੇਟਾ ਸਟੋਰ, SSO, ਸਟਰੱਕਚਰਡ ਲੌਗਿੰਗ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਦੇ ਨਾਲ, ਇਹ ਅਕਸਰ ਤਬਦੀਲੀਯੋਗ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਜਿੰਮੇਵਾਰ ਫੀਚਰ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਬੰਡਲ ਤੌਰ 'ਤੇ ਮਨਜ਼ੂਰ ਕਰਨੇ ਪੈਂਦੇ ਹਨ।
ਕਿਉਂਕਿ ਫਰੇਮਵਰਕ ਕੋਰ ਇਕ "ਅਧਿਕਾਰਕ" ਸਟੈਕ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ, ਇਹ ਅਕਸਰ ਐਸੀ ਚੀਜ਼ਾਂ ਨੂੰ ਬਦਲਣਾ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ:
ਅਨੁਭਵੀ ਡਿਵੈਲਪਰ ਇਹ ਲਚਕੀਲਾਪਣ ਮਾਹਣੀ ਕਦਰ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੇ ਦੇਖਿਆ ਹੈ ਕਿ ਛੋਟੀ ਸ਼ੁਰੂਆਤੀ ਫੈਸਲਿਆਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਲੰਬੇ ਸਮੇਂ 'ਤੇ ਕਿਵੇਂ ਵੱਡੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਉਸੇ ਆਜ਼ਾਦੀ ਨਾਲ ਮਿਸ਼ਰਿਤ ਅਤੇ ਅਣਮੇਚੜ ਲਾਇਬਰੇਰੀਆਂ ਅਤੇ ਪੈਟਰਨਾਂ ਦੀ ਇੱਕ ਕਪੜੀ ਬਣ ਸਕਦੀ ਹੈ ਜੇ ਟੀਮ ਮਿਆਰ ਨਹੀਂ ਨਿਰਧਾਰਤ ਕਰਦੀ। ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਸਭ ਤੋਂ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਮਨਜ਼ੂਰ ਕੀਤੇ ਕੰਪੋਨੈਂਟ, ਇੱਕ ਰੈਫਰੰਸ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ, ਅਤੇ ਨਿਯਮਾਂ ਲਈ ਮਾਰਗਦਰਸ਼ਕ ਨਿਰਧਾਰਤ ਕਰੋ—ਤਾਂ ਜੋ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਣਾ ਨਿਰੰਤਰ ਹੋਵੇ ਨਾ ਕਿ ਅਨਿਯੰਤਰਤ।
ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਰਸਤਾ ਵਿੱਖ ਤੋਂ ਦੂਰ ਰਹਿੰਦੇ ਹਨ—ਇਸ ਲਈ ਉਹ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਵਧੀਆ ਹੁੰਦੇ ਹਨ ਜੋ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੀਆਂ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸੋਫਟਵੇਅਰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ। ਜਦੋਂ "ਖਾਸ ਤਰੀਕੇ" ਘੱਟ ਹੋਂਦੇ ਹਨ (ਕਸਟਮ ਡੈਕੋਰੇਟਰ, ਛੁਪਾ ਵਾਇਰਿੰਗ, ਫਰੇਮਵਰਕ-ਨਿਰਧਾਰਿਤ ਪੈਟਰਨ), ਦੋ ਡਿਵੈਲਪਰਾਂ ਦੇ ਵੱਖਰੇ ਅੰਦਾਜ਼ ਨਾਲੋ ਉੱਤਪੰਨ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਨਾਲ ਕੋਡ ਰਿਵਿਊ ਚਰਚਾ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦਿਨ-ਪ੍ਰਤੀ-ਦਿਨ ਘਰਣਾਵਾਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਹੋਰ ਰਾਇ ਵਾਲੇ ਫਰੇਮਵਰਕ ਵਿੱਚ, "ਸਹੀ ਤਰੀਕ" ਅਕਸਰ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਹੁੰਦੀ ਹੈ। ਮਿਨੀਮਲ ਸਟੈਕ ਦੇ ਨਾਲ, ਟੀਮ ਉਹ ਮਿਆਰ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਉਤਪਾਦ, ਉਦਯੋਗ ਅਤੇ ਕਾਪਲੇਅੰਸ ਲੋੜਾਂ ਨਾਲ ਫਿੱਟ ਹੋਣ—ਤੇ ਉਹਨਾਂ ਨੂੰ ਇਕਸਾਰ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੀ ਹੈ।
ਆਮ ਖੇਤਰ ਜਿਨ੍ਹਾਂ 'ਤੇ ਮਿਲ ਕੇ ਫੈਸਲਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
ਇਹ ਛੋਟੇ ਫੈਸਲੇ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਛੋਟੇ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ "ਹਰ ਕੋਈ ਵੱਖਰਾ ਕਰਦਾ ਹੈ" ਦੀ ਰੁਝਾਨ ਰੋਕਦੇ ਹਨ।
ਇੱਕ ਮਿਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਤੁਹਾਨੂੰ ਪੂਰਾ ਢਾਂਚਾ ਨਹੀਂ ਦਿੰਦਾ—ਪਰ ਤੁਸੀਂ ਉਹ ਬਣਾਉ ਸਕਦੇ ਹੋ। ਕਈ ਅਨੁਭਵੀ ਟੀਮ ਇੱਕ ਸਟਾਰਟਰ ਰਿਪੋ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਮਨਜ਼ੂਰ ਕੀਤੇ ਮਿਆਰਾਂ ਨੂੰ ਬੇਕ ਕਰਦਾ ਹੈ:
ਉਹ ਸਟਾਰਟਰ ਨਵੇਂ ਸੇਵਾ ਲਈ ਡਿਫ਼ਾਲਟ ਬਣ ਜਾਂਦਾ ਹੈ, ਔਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਰੱਖ-ਰਖਾਅ ਆਸਾਨ ਬਣਾਂਦਾ ਹੈ।
ਚੀਜ਼ਾਂ ਲਿਖਣੀਆਂ ਜ਼ਰੂਰੀ ਹਨ: ਜੋ ਫੈਸਲੇ ਟੀਮ ਲੈਂਦੀ ਹੈ ਉਹ ਕੁਝ "ਡਿਫ਼ਾਲਟ" ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ ਗਾਈਡ (ਇੱਕ /docs/standards ਪੰਨਾ ਵੀ) ਲਚਕੀਲਾਪਣ ਨੂੰ ਦੁਹਰਾਉਣਯੋਗਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ—ਬਿਨਾਂ ਫਰੇਮਵਰਕ ਜਾਦੂ 'ਤੇ ਨਿਰਭਰ ਰਹੇ।
ਸਧਾਰਣ ਫਰੇਮਵਰਕ ਉਹ ਸਮੇਂ ਚਮਕਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਡੋਮੇਨ ਵਿਲੱਖਣ ਹੋ ਅਤੇ ਤੁਸੀਂ ਕੇਵਲ ਉਹੀ ਜੋੜਨ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਲੋੜੀਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਮੁੱਖ ਤੌਰ 'ਤੇ "ਮਿਆਰੀ ਵੈੱਬ ਐਪ" ਹੈ, ਤਾਂ ਫੁੱਲ-ਫੀਚਰ ਵਾਲਾ ਫਰੇਮਵਰਕ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੀਆਂ ਲੋੜਾਂ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਚੈਕਲਿਸਟ ਵਰਗੀਆਂ ਹਨ—ਯੂਜ਼ਰ, ਰੋਲ, CRUD ਸਕ੍ਰੀਨ, ਐਡਮਿੰ ਟੂਲ, ਰਿਪੋਰਟਸ—ਤਾਂ ਫੀਚਰ-ਰਿੱਚ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਜਲਦੀ ਨਤੀਜਾ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਬਿਲਡਿੰਗ ਬਲਾਕ ਪਹਿਲਾਂ ਹੀ ਇਕੱਠੇ ਅਤੇ ਅਚ੍ਛੇ ਤਰੀਕੇ ਨਾਲ ਜੋੜੇ ਹੋਏ ਹੁੰਦੇ ਹਨ।
ਟਿੱਪਣੀ ਯੋਗ ਉਦਾਹਰਨ:
ਮਿਨੀਮਲਿਸਮ ਤੁਹਾਨੂੰ ਖੂਬਸੂਰਤੀ ਨਾਲ ਮੁੜ- ਬਣਾਉਣ 'ਤੇ ਧੱਕ ਸਕਦਾ ਹੈ—ਕਈ ਸੁਚੇਤ ਕੀਤੇ ਫੀਚਰਾਂ ਨੂੰ ਤੁਸੀਂ ਘੱਟ ਅੰਦਾਜ਼ੇ ਨਾਲ ਮੁੜ-ਬਣਾ ਲੈਂਦੇ ਹੋ। ਆਥ, ਆਥਜ਼, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼, ਕੈਸ਼ਿੰਗ, ਰੇਟ ਲਿਮਿਟਿੰਗ, ਵੈਲਿਡੇਸ਼ਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਹੇਡਰ ਇਹ ਸਭ ਸਧਾਰਨ ਲੱਗਦੇ ਹਨ—ਤਕ ਤੱਕ ਜਦ ਤੱਕ ਤੁਹਾਨੂੰ ਏਜ ਕੇਸ, ਆਡਿਟ, ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਦਰਜਨਾਂ ਤੀਜੇ-ਪਾਸੇ ਪੈਕੇਜਾਂ ਨੂੰ ਵਰਤਣ ਲਈ ਵਰਗਦੇ ਹੋ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਫਰੇਮਵਰਕ-ਭਰਪੂਰ ਹੱਲ ਨਾਲੋਂ ਵੱਧ ਜਟਿਲਤਾ ਹੋ ਸਕਦੀ ਹੈ—ਸਿਰਫ਼ ਇਹ ਜਟਿਲਤਾ ਵੱਖ-ਵੱਖ ਲਾਇਬਰੇਰੀਆਂ ਅਤੇ ਕਸਟਮ ਗਲੂ ਕੋਡ ਵਿੱਚ ਫੈਲੀ ਹੋਈ ਹੋਵੇਗੀ।
ਇੱਕ ਮਦਦਗਾਰ ਤਰੀਕਾ ਦੋ ਕurve ਦੀ ਤੁਲਨਾ ਹੈ:
ਜੇ ਬਹੁਤ ਸਾਰਾ ਜਟਿਲਤਾ ਸਧਾਰਨ ਪਲੰਬਿੰਗ ਹੈ, ਤਾਂ ਮਿਨੀਮਲਿਸਮ ਡਿਲਿਵਰੀ ਨੂੰ ਧੀਰਾ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਜ਼ਿਆਦਾਤਰ ਜਟਿਲਤਾ ਡੋਮੇਨ-ਨਿਰਧਾਰਿਤ ਹੈ, ਤਾਂ ਮਿਨੀਮਲ ਫਰੇਮਵਰਕ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਇਰਾਦੇ ਵਾਲਾ ਰੱਖ ਸਕਦਾ ਹੈ।
ਮਿਨੀਮਲਿਸਟ ਫਰੇਮਵਰਕ ਨੀਤੀਵਤ ਫੈਸਲਿਆਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। ਕਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਚੈੱਕਲਿਸਟ ਯਕੀਨੀ ਬਣਾਓ ਕਿ "ਹਲਕਾ" "ਜੋ ਕੁਝ ਸਾਡੀ ਲੋੜ ਹੈ ਉਹ ਨਹੀਂ ਮਿਲ ਰਿਹਾ" ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ।
"ਹੈਲੋ ਵਰਲਡ" ਰਸਤੇ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾ ਬਣਾਉ—ਉਸ ਹਿੱਸੇ ਦਾ PoC ਬਣਾਓ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੇਰਾ ਨੁਕਸਾਨ ਕਰੇਗਾ। ਇੱਕ ਜਾਂ ਦੋ ਸੰਘਰਸ਼ੀਲ ਫਲੋ ਚੁਣੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਲਾਗੂ ਕਰੋ:
ਇਸਨੂੰ ਸਮਾਂ-ਬੱਧ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ 1–3 ਦਿਨ). ਜੇ PoC ਅਸਹਜ ਲੱਗੇ, ਤਾਂ ਇਹ ਘਰਭਰ ਵਿਆਪਕ ਹੋ ਕੇ ਟੀਮ 'ਤੇ ਭਾਰੀ ਪੈ ਗਿਆ।
ਜੇ ਤੁਹਾਡਾ ਲਕਸ਼੍ਯ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ (ਨ ਕਿ ਸਕੈਫੋਲਡਿੰਗ ਤੇ ਬਹਿਸ), ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਨੂੰ ਚੈਟ ਪ੍ਰامਪਟ ਤੋਂ ਇੱਕ ਯਥਾਰਥੀ PoC ਉਤਪੰਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਫਿਰ "ਯੋਜਨਾ ਮੋਡ" ਵਿੱਚ ਇਟਰੈਟ ਕਰਨ। Koder.ai React ਫਰੰਟਐਂਡ ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਨੈਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਲਈ ਸਹਾਇਤਾ ਦਿੰਦਾ—ਇਸ ਤਰ੍ਹਾਂ ਟੀਮਾਂ ਜੋਖਿਮੀ ਹਿੱਸਿਆਂ (auth ਫਲੋ, ਵੈਲਿਡੇਸ਼ਨ/ਐਰਰ ਆਕਾਰ, ਲੌਗਿੰਗ ਕਨਵੇਂਸ਼ਨ) ਨੂੰ ਪ੍ਰਯੋਗ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਫੈਸਲਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ ਮਿਨੀਮਲ ਦ੍ਰਿਸ਼ਟੀ ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਸੰਭਾਲਯੋਗ ਰਹੇਗੀ ਕਿ ਨਹੀਂ।
ਛੋਟਾ ਕੋਰ ਠੀਕ ਹੈ ਜੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਐਕੋਸਿਸਟਮ ਸਿਹਤਮੰਦ ਹੋਵੇ:
ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਕਾਬੂ ਅਤੇ ਲਗਾਤਾਰਤਾ ਚਾਹੁੰਦੀ ਹੈ, ਤਾਂ ਮਿਨੀਮਲ ਫਰੇਮਵਰਕ ਵਧੀਆ ਫਿੱਟ ਹੋ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਭਾਰੀ-ਬਿਲਟ-ਇਨ ਫੀਚਰਾਂ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਕੋਲ ਭਰੋਸੇਯੋਗ ਡਿਫ਼ਾਲਟਾਂ ਨੂੰ ਜੋੜਨ ਦਾ ਸਮਾਂ ਨਹੀਂ, ਤਾਂ ਉਹ ਗਲਤ ਚੋਣ ਹੋ ਸਕਦੇ ਹਨ।
ਸੋਚ-ਸਮਝ ਕੇ ਚੁਣੋ: PoC ਚਲਾਓ, ਇਕੋਸਿਸਟਮ ਦੀ ਪਕਿਆਈ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਕੰਮ ਕਰੋ ਜੇ ਸੈਟਅੱਪ ਟੀਮ ਦੇ ਨਿਯਮ ਬਣ ਸਕਣ।
ਇੱਕ ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਇੱਕ ਛੋਟੇ ਕੋਰ (ਅਮੂਮਨ ਰਾਊਟਿੰਗ + ਰਿਕਵੇਸਟ/ਰੇਸਪਾਂਸ + ਮਿੱਡਲਵੇਅਰ ਹੋਕ) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਤੇ ਬਾਕੀ "ਸਟੈਕ ਦੀਆਂ ਫੈਸਲਾਂ" ਤੁਹਾਡੇ ਉੱਪਰ ਛੱਡ ਦਿੰਦਾ ਹੈ.
ਅਮਲ ਵਿੱਚ, ਤੁਸੀਂ ਆਪਣਾ ਆਪਣੇ ਆਪ ਚੁਣਣ ਅਤੇ ਵਾਇਰ ਕਰਨ ਦੀ ਉਮੀਦ ਰੱਖੋਗੇ:
ਉਹ ਇਹਨਾਂ ਗੱਲਾਂ ਲਈ ਅਨੁਕੂਲ ਹੁੰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਪੈਟਰਨ ਨਿਰਧਾਰਤ ਕਰਨ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ ਵਿੱਚ ਸੁਖੀ ਹੋ, ਤਾਂ "ਘੱਟ ਜਾਦੂ" ਵਾਲਾ ਰਵੱਈਆ ਅਕਸਰ ਸਿਸਟਮ ਦੀ ਉਮਰ ਭਰ ਤੇਜ਼ੀ ਲਿਆਉਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਫ੍ਰੇਮਵਰਕ ਚੁਣੋ ਜਦੋਂ:
ਜੇ ਤੁਹਾਡਾ ਐਪ ਜ਼ਿਆਦਾਤਰ ਸਧਾਰਨ ਵੈੱਬ ਪਲੰਬਿੰਗ ਹੈ ਅਤੇ ਤੁਰੰਤ ਸ਼ਿਪ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਫੁੱਲ-ਸਟੈਕ ਫ੍ਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਆਮ ਨੁਕਸਾਨ:
ਕਮੀ ਨੂੰ ਘਟਾਉਣ ਲਈ: ਕੁਝ ਮਨਜ਼ੂਰ ਕੀਤੇ ਕੰਪੋਨੈਂਟ ਚੁਣੋ, ਇੱਕ ਸਟਾਰਟਰ ਰਿਪੋ ਬਣਾਓ ਅਤੇ ਛੋਟਾ ਟੀਮ ਪਲੇਬੁੱਕ ਲਿਖੋ।
ਛੋਟਾ ਕੋਰ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਨਾਲ ਸਪਰੀਟ-ਚੁਣੇ ਹੋਏ ਡਿਪੈਂਡੇਂਸੀਜ਼ ਘਟਾਉਂਦਾ ਹੈ।
ਇਸ ਦਾ ਫਾਇਦਾ:
ਵਿਆਵਹਾਰਕ ਸੁਝਾਅ: ਹਰ ਮੁੱਖ ਲਾਇਬਰੇਰੀ ਲਈ ਇੱਕ ਸੰਖੇਪ “ਡਿਪੈਂਡੈਂਸੀ ਕਾਰਨ” ਨੋਟ ਰੱਖੋ (ਇਹ ਕੀ ਕਰਦੀ ਹੈ, ਮਾਲਿਕ, ਅਪਗ੍ਰੇਡ ਕੈਡੰਸ)।
ਹੋ ਸਕਦਾ ਹੈ—ਕੁਝ ਹਾਲਤਾਂ ਵਿੱਚ ਬੇਸਲਾਈਨ ਓਵਰਹੈੱਡ ਘਟ ਸਕਦਾ ਹੈ (ਸਟਾਰਟਅਪ ਸਮਾਂ, ਮੇਮੋਰੀ, ਰਿਕਵੇਸਟ ਪਲੰਬਿੰਗ), ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਇਨਸਟੈਂਸ ਹਨ (ਕਨਟੇਨਰ/ਸਰਵਰਲੈਸ).
ਪਰ: ਫ੍ਰੇਮਵਰਕ ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਮੁੱਖ ਪ੍ਰਦਰਸ਼ਨ ਫੈਕਟਰ ਨਹੀਂ ਹੁੰਦੀ। ਡੇਟਾਬੇਜ਼ ਕਵੈਰੀਜ਼, ਕੈਸ਼ਿੰਗ, ਪੇਲੋਡ ਆਕਾਰ, ਅਤੇ ਨੈਟਵਰਕ ਲેટੈਂਸੀ ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ.
ਸੁਝਾਅ: ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਐਂਡਪਾਇੰਟ 'ਤੇ ਬੈਂਚਮਾਰਕ ਚਲਾਓ (ਕੋਲਡ-ਸਟਾਰਟ, ਮੇਮੋਰੀ, p95 ਲੇਟੈਂਸੀ) ਆਪਣੀ ਅਸਲ ਮਿਡਲਵੇਅਰ ਨਾਲ।
ਅਕਸਰ ਹਾਂ—ਕਿਉਂਕਿ ਘੱਟ ਛੁਪੇ ਹੋਏ ਰਿਵਾਜ਼ ਅਤੇ ਹੋਕ ਹੁੰਦੇ ਹਨ:
ਇਸ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਘਟੀਆ ਫਿਕਸਟਿਚਰ ਅਤੇ ਘੁੰਮਣ-ਫਿਰਣ ਵਾਲੇ ਟੈਸਟ ਘਟਦੇ ਹਨ ਅਤੇ ਡੀਬੱਗਿੰਗ ਸਿੱਧੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਛੋਟੀ ਸਤਹ ਆਮ ਤੌਰ 'ਤੇ ਅਪਗ੍ਰੇਡ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ: ਘੱਟ ਫੀਚਰ, ਘੱਟ ਤੋੜ-ਮਰੋੜ ਵਾਲੇ ਬਿੰਦੂ, ਅਤੇ ਫਰੇਮਵਰਕ-ਨਿਰਧਾਰਿਤ ਕੋਡ ਘੱਟ ਮਿਸ਼ਰਿਤ ਹੁੰਦਾ ਹੈ.
ਪਰ ਲੋਕ ਵੀ ਮਾਇਨੇ ਰਖਦੇ ਹਨ—ਕਮਿਉਨਟੀ ਹੈਲਥ ਦੇਖੋ: ਮੈਨਟੇਨਰ ਗਿਣਤੀ, ਰਿਲੀਜ਼ ਰੇਗੁਲਰਿਟੀ, ਅਤੇ ਮੁੱਦਿਆਂ ਦਾ ਜਵਾਬ.
ਸਰਗਰਮੀ ਲਈ:
ਇਸ ਨਾਲ ਅਪਗ੍ਰੇਡ ਹੁੰਦੇ ਹਨ ਨਿਮਨੀਤ ਇਮਰਜੈਂਸੀ ਰੀਰਾਈਟ ਦੀ ਬਜਾਏ ਰੁਟੀਨ ਰੱਖ-ਰਖਾਅ ਬਣ ਜਾਂਦਾ ਹੈ।
ਚੋਟੇ ਕੋਰ ਨਾਲ ਵੱਧ ਬਦਲਾਅ ਆਸਾਨ ਹੁੰਦੇ ਹਨ—ਕਿਉਂਕਿ ਰਾਊਟਿੰਗ, ਰਿਕਵੇਸਟ/ਰੇਸਪਾਂਸ ਹੈਂਡਲਿੰਗ ਆਦਿ ਵੱਖਰੇ ਅਤੇ ਸਾਫ਼ ਹੋਂਦੇ ਹਨ.
ਆਮ ਤੌਰ 'ਤੇ ਟੀਮ ਇਹ ਬਦਲਾਅ ਕਰਦੀ ਹੈ:
ਪਰ ਇਸ ਆਜ਼ਾਦੀ ਨਾਲ ਕਨਸਿਸਟੈਂਸੀ ਆਪਣੇ ਆਪ ਨਹੀਂ ਆਉਂਦੀ—ਟੀਮ ਨੂੰ ਨਿਰਧਾਰਤ ਨਿਯਮ, ਪ੍ਰਸੰਪਰਿਤ ਸਟਾਰਟਰ ਰਿਪੋ, ਅਤੇ ਨਿਰਣੇ-ਮੁੱਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਮੌਖਿਕ ਤੌਰ 'ਤੇ—ਜੇ ਟੀਮ ਨੇ ਪਹਿਲਾਂ ਨਿਯਮਾਂ ਤੇ ਦਸਤਾਵੇਜ਼ ਬਣਾਏ ਹਨ।
ਫਾਇਦੇ:
ਟੀਮ ਲਈ ਸਧਾਰਨ ਏਰੀਆ:
ਸਟਾਰਟਰ ਰਿਪੋ ਅਤੇ ਇੱਕ "ਗੋਲਡਨ ਪਾਥ" ਉਦਾਹਰਨ ਨਾਲ, ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਅਸਾਨ ਹੁੰਦਾ ਹੈ।