ਰਾਏ-ਵਾਲੇ (opinionated) ਫਰੇਮਵਰਕ ਨਵੇਂ ਲੋਕਾਂ ਲਈ ਡਿਫਾਲਟ, ਢਾਂਚਾ ਅਤੇ ਆਮ ਪੈਟਰਨ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਪਹਿਲੇ ਪ੍ਰੋਜੈਕਟ ਤੇਜ਼ੀ ਨਾਲ ਤਿਆਰ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਚੁਣਨ ਦਾ ਤਰੀਕਾ ਅਤੇ ਆਪਣਾ ਪਹਿਲਾ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦੇ ਨੁਸਖੇ ਝਲਕੋ।
ਇੱਕ opinionated framework ਤੁਹਾਡੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕਈ ਨਿਰਣਯ ਲੈ ਲੈਂਦਾ ਹੈ—ਜਿਸ ਨਾਲ ਤੁਹਾਨੂੰ ਇਹ ਸਭ ਨਹੀਂ ਸੋਚਣਾ ਪੈਂਦਾ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ “ਡਿਫਾਲਟ ਤਰੀਕਾ” ਵੱਲ ਧੱਕਦਾ ਹੈ ਕਿ ਐਪ ਦੇ ਹਿੱਸੇ ਕਿਵੇਂ ਬਣਣੇ, ਕਿਵੇਂ ਨਾਮ ਰੱਖਣੇ ਅਤੇ ਇਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਜੁੜਨ।
ਇਸ ਨੂੰ ਇਸ ਤਰਾਂ ਸੋਚੋ: ਇੱਕ ਫਰਨਿਸ਼ਡ ਅਪਾਰਟਮੈਂਟ ਵਿੱਚ ਵਸਨਾ—ਤੁਸੀਂ ਚੀਜ਼ਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਗਾ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਡੇ ਕੋਲ ਖਾਲੀ ਕਮਰਾ ਨਹੀਂ ਹੁੰਦਾ।
ਜ਼ਿਆਦਾ DIY ਜਾਂ ਘੱਟ ਰਾਇਦਾਰ ਰਸਤੇ ਵਿੱਚ, ਤੁਸੀਂ ਅਕਸਰ ਹਰ ਚੀਜ਼ ਖ਼ੁਦ ਚੁਣਦੇ ਹੋ: ਫੋਲਡਰ ਲੇਆਊਟ, URLs ਦਾ ਕੋਡ ਨਾਲ ਨਕਸ਼ਾ, ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲਬਾਤ, ਟੈਸਟ ਕਿਵੇਂ ਚਲਾਉਣੇ, authentication ਕਿਵੇਂ ਕਰਨੀ—ਅਤੇ ਹੋਰ। ਇਹ ਲਚਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ—ਪਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਵਧੇਰੇ ਫੈਸਲੇ, ਵਧੇਰੇ ਸੈਟਅੱਪ, ਅਤੇ ਵਧੇਰੇ ਮੁਸ਼ਕਲਾਂ ਤੇ ਰੁਕਾਵਟਾਂ।
Opinionated frameworks (ਰਵਾਇਤੀ ਉਦਾਹਰਨ: Rails ਅਤੇ Django) ਇਨ੍ਹਾਂ ਚੋਣਾਂ ਨੂੰ ਘਟਾ ਦਿੰਦੇ ਹਨ ਰਿਵਾਜ਼ਾਂ ਨੂੰ ਬੇਕ ਕਰਕੇ। ਨਵੇਂ ਟੂਲ ਜਿਹੜੇ ਮਜ਼ਬੂਤ ਕੰਵੈਨਸ਼ਨਾਂ ਨਾਲ ਆਉਂਦੇ ਹਨ—ਜਿਵੇਂ Next.js—ਤੁਹਾਨੂੰ ਇੱਕ ਖਾਸ ਢਾਂਚੇ ਵੱਲ ਮਾਰਗ ਦਰਸ਼ਨ ਕਰਦੇ ਹਨ।
ਇਹ ਰਾਇਅਾਂ ਆਮ ਤੌਰ ਤੇ ਹੇਠਾਂ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਰੂਪ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ:
ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਮਿਲਦੀ ਹੈ ਕਿਉਂਕਿ ਰਾਹ ਪਹਿਲਾਂ ਹੀ ਪੱਕਾ ਹੈ: ਘੱਟ ਟੂਲ ਚੁਣਨ, ਘੱਟ ਫਾਈਲਾਂ ਬਣਾਉਣ, ਪਹਿਲੇ ਦਿਨ ਵਿਕਾਸਕ ਫੈਸਲੇ ਘੱਟ।
ਵਿਵਾਦ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਘੱਟ ਆਜ਼ਾਦੀ ਮਿਲਦੀ ਹੈ। ਤੁਸੀਂ ਫਿਰ ਵੀ ਕਸਟਮਾਈਜ਼ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਜਦ ਤੱਕ ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਦੀਆਂ ਰਿਵਾਜ਼ਾਂ ਦੇ ਨਾਲ ਚੱਲਦੇ ਹੋ, ਤੁਸੀਂ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋਗੇ।
ਨਵੇਂ ਲੋਕ ਅਕਸਰ ਇਸ ਲਈ ਅਟਕਦੇ ਨਹੀਂ ਕਿ ਉਹ “ਕੋਡ ਨਹੀਂ ਕਰ ਸਕਦੇ।” ਅਕਸਰ ਉਹ ਇਸ ਲਈ ਰੁਕ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਹਰ ਕਦਮ ਇੱਕ ਐਸਾ ਫੈਸਲਾ ਮੰਗਦਾ ਹੈ ਜੋ ਉਹ ਅਜੇ ਤੱਕ ਆਸਾਨੀ ਨਾਲ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਲੈ ਸਕਦੇ।
ਨਵੇਂ ਹੋਣ 'ਤੇ, ਇੱਕ ਸਧਾਰਨ ਲਕੜੀ ਵੀ ਸਵਾਲਾਂ ਦੀ ਲੜੀ ਖੜੀ ਕਰ ਸਕਦੀ ਹੈ:
ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਚੋਣ “ਗਲਤ” ਨਹੀਂ ਹੈ, ਪਰ ਹਰ ਇੱਕ ਇੱਕ ਖੋਜ ਦਾ ਰੱਬਿਟ ਹੋਲ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਤੁਲਨਾਵਾਂ ਪੜ੍ਹਦੇ ਹੋ, ਟਿਊਟੋਰੀਅਲ ਦੇਖਦੇ ਹੋ, ਹੋਰਾਂ ਦੇ ਕੋਡ ਰਿਪੋ ਠੋੜਦੇ ਹੋ—ਫਿਰ ਵੀ ਸ਼ੱਕ ਰਹਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ “ਗਲਤ” ਚੁਣਿਆ। ਇਹ ਦੋਹਰਿਆ ਸੋਚਣਾ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ: ਇਹ ਮੋਮੇਟਮ ਭੰਗ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੋਮੇਟਮ ਹੀ ਹੈ ਜੋ ਨਵੇਂ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਪੂਰੇ ਕਰਨ ਲਾਇਕ ਬਣਾਉਂਦਾ ਹੈ।
Opinionated frameworks ਬਹੁਤ ਸਾਰੇ ਸ਼ੁਰੂਆਤੀ ਫੈਸਲੇ ਹਟਾ ਦਿੰਦੇ ਹਨ ਇਹ ਕਹਿ ਕੇ, “ਇਥੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।” ਉਹ ਕੰਵੈਨਸ਼ਨ (ਤਾ ਕਿ ਚੀਜ਼ਾਂ ਅਕਸਰ ਕਿਵੇਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ) ਅਤੇ ਡਿਫਾਲਟ ਦਿੰਦੇ ਹਨ (ਜੋ ਪਹਿਲਾਂ ਹੀ ਸੈਟ ਅਪ ਹੈ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਅੱਗੇ ਵਧ ਸਕੋ ਜਦੋਂਕਿ ਤੁਹਾਡੀ ਸਮਝ ਪਿਛੇ ਆ ਰਹੀ ਹੋਵੇ।
ਘੱਟ ਚੋਣਾਂ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ:
ਕਲਪਨਾ ਕਰੋ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਐਪ ਚਾਹੁੰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਸਾਈਨ-ਅਪ, ਪ੍ਰੋਫ਼ਾਈਲ ਫਾਰਮ ਅਤੇ ਇਨਪੁਟ ਵੈਲਿਡੇਸ਼ਨ ਹੋਵੇ। ਇੱਕ ਘੱਟ ਰਾਇਦਾਰ ਰਾਹ ਅਤਿਵਾਦੀ ਤੌਰ 'ਤੇ ਓਹਦਾ ਰੂਪ ਇੰਝ ਹੋ ਸਕਦਾ ਹੈ:
ਇੱਕ opinionated framework ਆਮ ਤੌਰ ਤੇ ਤਿੰਨੋ ਲਈ ਇੱਕ ਸੁਝਾਈ ਰਾਹ ਦਿੰਦਾ—ਅਕਸਰ ਕੰਮ ਕਰਦੇ ਉਦਾਹਰਨਾਂ ਨਾਲ—ਤਾਂ ਜੋ ਤੁਸੀਂ “ਕਾਫ਼ੀ ਚੰਗਾ” ਜਲਦੀ ਲਾਗੂ ਕਰ ਸਕੋ ਅਤੇ ਬਾਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ। ਇਹ ਕੇਵਲ ਸਹੂਲਤ ਨਹੀਂ; ਇਹ ਉਹੀ ਹੈ ਜੋ ਨਵੇਂ ਲੋਕਾਂ ਨੂੰ ਲਗਾਤਾਰ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਨ ਦਿੰਦਾ ਹੈ ਬਜਾਏ ਫੈਸਲਿਆਂ 'ਚ ਭਟਕਣ ਦੇ।
Opinionated frameworks ਤੁਹਾਨੂੰ ਦਹਾਕਾਂ “ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ?” ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਘੱਟ ਕਰਕੇ ਤੇਜ਼ੀ ਦਿੰਦੇ ਹਨ—ਇਸਦੀ ਥਾਂ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਜਿਹੀ "ਖ਼ਾਲੀ ਥਾਂ ਭਰੋ" ਕਿਸਮ ਦੀਆਂ ਚੀਜ਼ਾਂ ਕਰੋ। ਹਰ ਫੋਲਡਰ, ਫਾਈਲ ਨਾਂ ਅਤੇ ਵਰਕਫਲੋ ਲਈ ਆਪਣੀ ਰਣਨੀਤੀ ਬਣਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ ਅਜਿਹਾ ਰਸਤਾ ਫਾਲੋ ਕਰਦੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਹਜ਼ਾਰਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨੇ آزਮਾਇਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ।
ਕੰਵੈਨਸ਼ਨ ਇਕ ਸ਼ਾਂਤ ਪਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਚੀਜ਼ ਹੈ। ਜਦੋਂ framework ਕਂਟਰੋਲਰ ਇੱਕ ਥਾਂ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਰੂਟਾਂ ਹੋਰ ਥਾਂ ਤੇ, ਅਤੇ ਫਾਈਲਾਂ ਨਿਰਦੇਸ਼ਤ ਨਾਂ ਰੱਖੀਆਂ ਹੋਣ, ਤਾਂ ਤੁਸੀਂ ਲੁਕਣ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲਾਉਂਦੇ ਹੋ ਅਤੇ ਇਮਿਤਿਆਜ਼ ਬਣਾਉਂਦੇ ਹੋ।
ਇਹ ਪੇਸ਼ਗੋਈ ਵੀ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਟਿਊਟੋਰੀਅਲ, ਐਰਰ ਸੁਨੇਹੇ ਅਤੇ ਸਟੈਕ ਟ੍ਰੇਸ ਤੁਹਾਡੇ ਢਾਂਚੇ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਨਵੇਂ ਲੋਕ ਇਸਨੂੰ ਅਜੇਹੀ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ: “ਮੈਂ ਚੀਜ਼ਾਂ ਜਲਦੀ ਲੱਭ ਲੈਂਦਾ/ਦੀ ਹਾਂ” ਅਤੇ “ਉਦਾਹਰਨ ਮੇਰੇ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹਨ।”
ਜ਼ਿਆਦਾਤਰ ਐਪਾਂ ਨੂੰ ਉਹੀ ਬੁਨਿਆਦੀ ਇਮਾਰਤੀ ਬਲਾਕ ਚਾਹੀਦੇ ਹਨ: routing, ਫਾਰਮ, ਵੈਲਿਡੇਸ਼ਨ, ਡੇਟਾਬੇਸ ਐਕਸੇੱਸ, auth ਪੈਟਰਨ, ਸੁਰੱਖਿਆ ਸੁਰੱਖਿਆ, ਲਾਗਿੰਗ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਦਾ ਰਸਤਾ। Opinionated frameworks ਇਹ ਨੁਕਤੇ ਜਾਂ ਤਾਂ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ ਜਾਂ ਮਜ਼ਬੂਤ ਤੌਰ 'ਤੇ ਸਿਫਾਰਸ਼ ਜੀ ਪੈਕੇਜ ਦਿੰਦੇ ਹਨ।
ਗਤੀ ਦਾ ਫਾਇਦਾ ਕੇਵਲ ਘੱਟ ਇੰਸਟਾਲ ਨਹੀਂ—ਇਹ ਘੱਟ ਵਿਚਾਰ-ਵਟਾਂਦਰੇ ਵੀ ਹੁੰਦਾ ਹੈ। ਪਹਿਲੇ ਦਿਨ 'ਤੇ ਇਕੋ ਕੰਮ ਲਈ ਦਸ ਲਾਈਬ੍ਰੇਰੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਰਹਿੰਦੀ। ਤੁਸੀਂ ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫਾਲਟ ਲੈ ਲੈਂਦੇ ਹੋ ਤੇ ਅੱਗੇ ਵਧਦੇ ਹੋ।
Scaffolding ਟੂਲ ਹਕੀਕਤ ਵਿੱਚ ਜੁੜੇ ਹੋਏ ਹਿੱਸੇ—ਮਾਡਲ, ਪੇਜ਼, migration, APIs—ਬਣਾ ਦਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਤੋਂ ਜੋ ਪਹਿਲਾਂ ਹੀ ਚੱਲਦੀ ਹੋ ਉਹੀ ਤੋਂ ਇਤਰਾਫ਼ ਕਰ ਸਕੋ।
ਇੱਕ ਨਵੇਂ ਲਈ ਇਹ ਵੱਡਾ ਹੈ: ਤੁਸੀਂ ਜਲਦੀ ਹੀ end-to-end slice ਵੇਖਦੇ ਹੋ (ਡਾਟਾ → ਲਾਜਿਕ → UI) ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਸੁਧਾਰਦੇ ਹੋ। ਤੁਸੀਂ ਇਹ ਵੀ ਸਿੱਖਦੇ ਹੋ ਕਿ ਉਸ ecosystem ਵਿੱਚ “ਨਾਰਮਲ” ਕੋਡ ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ।
ਉਚਿਤ ਕਮਾਂਡ-ਲਾਈਨ ਵਰਕਫਲੋ ਸੈਟਅੱਪ friction ਘਟਾਉਂਦੀ ਹੈ:
ਇਹ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀ ਛੱਡਦੀ ਕਿ ਤੁਸੀਂ ਕਿਸ ਕਦਮ ਦੀ ਲੜੀ ਚਲਾਉਂਦਿਆਂ ਹੋ—ਤੁਸੀਂ ਕੁਝ ਕਮਾਂਡਾਂ ਦੇ ਆਦਤ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਉਹ ਸਥਿਰਤਾ ਤੁਹਾਨੂੰ ਮੋਮੇਟਮ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
Opinionated frameworks ਆਪਣੀ ਵਰਤੋਂ ਦੀ ਕਦਰ ਉਹਨਾਂ ਛੋਟੇ-ਛੋਟੇ ਫੈਸਲਿਆਂ 'ਤੇ ਕਰਦੇ ਹਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਜ਼ਰੂਰੀ ਸੋਧ ਲਈ ਸਮਾਂ ਖਾਂਦੇ ਹਨ। ਬੇਗਿਨਰ ਵੈੱਬ ਡਿਵੈਲਪਮੈਂਟ ਲਈ, ਇਹ ਡਿਫਾਲਟ ਗਾਰਡਰੇਲ ਵਾਂਗ ਹਨ: ਤੁਸੀਂ ਢਾਂਚਾ ਇਕੱਠਾ ਕਰਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲਗਾਉਂਦੇ ਹੋ ਅਤੇ ਫੀਚਰ ਬਣਾਉਣ ਵਿੱਚ ਵਧੇਰੇ।
ਜ਼ਿਆਦਾਤਰ opinionated frameworks ਤੁਹਾਨੂੰ URLs ਨੂੰ pages ਜਾਂ controllers ਨਾਲ ਮੈਪ ਕਰਨ ਦਾ ਇੱਕ ਸਪੱਸ਼ਟ, ਪੇਸ਼ਗੋਈਯੋਗ ਤਰੀਕਾ ਦਿੰਦੇ ਹਨ। Rails ਅਤੇ Django ਤੁਹਾਨੂੰ ਰਿਵਾਜਤ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ ਅਤੇ ਨਾਮਕਰਨ ਦੀ ਓਰ ਧੱਕਦੇ ਹਨ। Next.js conventions ਫਾਇਲ-ਆਧਾਰਤ ਰੂਟਿੰਗ ਨਾਲ ਹੋਰ ਵੀ ਅੱਗੇ ਜਾਂਦੀਆਂ ਹਨ: ਇੱਕ ਫਾਇਲ ਬਣਾਉਣ ਨਾਲ ਇਕ ਰੂਟ ਬਣ ਸਕਦੀ ਹੈ।
ਫਾਇਦਾ ਕੇਵਲ ਕੋਡ ਦੀ ਘੱਟ ਲਾਈਨਾਂ ਨਹੀਂ—ਤੁਸੀਂ ਹਰ ਪ੍ਰੋਜੈਕਟ 'ਤੇ URL ਡਿਜ਼ਾਈਨ ਨੂੰ ਨਵਾਂ ਨਹੀਂ ਸੋਚਦੇ। ਫਰੇਮਵਰਕ ਦੀਆਂ ਰਿਵਾਜ਼ਾਂ ਫੋਲੋ ਕਰੋ ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਵੱਡੀ ਹੋਣ 'ਤੇ ਵੀ ਸੰਗਤ ਰਹੇਗੀ।
ਨਵੇਂ ਲੋਕਾਂ ਲਈ ਆਮ ਫੰਸਲੇ ਵਿੱਚ ਇੱਕ ਖਤਰਾ ਹੈ: ਡਾਟਾਬੇਸ ਵਿੱਚ ਹੱਥ ਨਾਲ ਬਦਲਾਅ ਕਰਨਾ ਅਤੇ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਬਦਲਾਅ ਗੁੰਮ ਹੋ ਜਾਣਾ। Rails, Django, ਅਤੇ Laravel ਵਰਗੇ framework ਮਾਈਗਰੇਸ਼ਨ ਡਿਫਾਲਟ ਨਾਲ ਆਉਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ORM ਜੋ ਤੁਹਾਨੂੰ ਡੇਟਾ ਮਾਡਲ ਕਰਨ ਦੀ ਮਿਆਰੀ ਰਾਹ ਦਿਖਾਉਂਦਾ ਹੈ।
“Convention over configuration” ਅਪ੍ਰੋਚ ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਦਿੰਦੀ ਹੈ:
Authentication ਉਹ جگہ ਹੈ ਜਿੱਥੇ ਨਵੇਂ ਆਸਾਨੀ ਨਾਲ ਗੰਭੀਰ ਘਾਟਲੀਆਂ ਬਣਾ ਬੈਠਦੇ ਹਨ। Opinionated frameworks ਅਕਸਰ ਸ਼ੁਰੂਆਤੀ implementations (ਜਾਂ ਅਧਿਕਾਰਿਕ starter kits) ਦਿੰਦੇ ਹਨ ਜੋ sessions, password hashing, CSRF ਸੁਰੱਖਿਆ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਕੁਕੀ ਸੈਟਿੰਗਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ। Laravel starter kits ਅਤੇ ਕਈ Django ਸੈਟਅਪ ਇਥੇ ਲੋਕਪ੍ਰਿਯ ਹਨ ਕਿਉਂਕਿ ਉਹ “ਸੁਰੱਖਿਅਤ ਰਾਹ” ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਆਧੁਨਿਕ ਫਰੰਟ-ਐਂਡ ਇੱਕ ਬਿਲਡ-ਟੂਲ ਭੁੰਨਾਲ ਬਣ ਸਕਦਾ ਹੈ। Opinionated frameworks ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕੰਮ ਕਰਨਯੋਗ ਬੇਸਲਾਈਨ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ: bundling, environment configs, ਅਤੇ dev ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਵਾਇਰਡ। Next.js conventions ਅਚਛਾ ਉਦਾਹਰਨ ਹਨ—ਕਈ ਡਿਫਾਲਟ ਪਸੰਦ ਕੀਤਾ ਗਿਆ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇੱਕ ਹਫ਼ਤੇਐਕਲ ਮਗਰੋਂ ਬਿਲਡ ਟੂਲਿੰਗ ਸੈੱਟ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ।
ਇਹ ਡਿਫਾਲਟ ਸਿੱਖਣ ਨਹੀਂ ਹਟਾਉਂਦੇ—ਪਰ ਉਹ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾ ਦਿੰਦੇ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਤਰੱਕੀ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣੇ ਪੈਂਦੇ।
Opinionated frameworks ਦੀ ਇਕ ਚੁੱਪ ਚ਼ੀਜ਼ ਇਹ ਹੈ ਕਿ ਉਹ ਤੁਹਾਡੀ ਏਪ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਹੀ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਸਿਖਾਉਂਦੇ ਹਨ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਐਪ ਕਿਵੇਂ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਢਾਂਚਾ, ਨਾਮਕਰਨ ਸਕੀਮ, ਅਤੇ "ਕੋਡ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ" ਦੇ ਨਿਯਮ ਬਿਨਾਂ ਤੁਹਾਡੇ ਦੀ ਆਪਣੀ ਲਾਇਕੀ ਗੰਭੀਰਤਾ ਤੋਂ ਦੇਖੇ ਜਾ ਰਹੇ ਹਨ।
ਜਦੋਂ ਇੱਕ framework ਉਮੀਦ ਕਰਦਾ ਹੈ controllers ਇਥੇ, templates ਉਥੇ, ਅਤੇ ਡੇਟਾਬੇਸ ਲਾਜਿਕ ਕਿਤੇ ਹੋਰ, ਟਿਊਟੋਰੀਅਲ ਬਹੁਤ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ। ਗਾਈਡ ਦੇ ਕਦਮ ਤੁਹਾਡੇ ਸਕ੍ਰੀਨ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ "ਉਹਨਾਂ ਦੇ ਪ੍ਰੋਜੈਕਟ" ਨੂੰ "ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ" ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲਈ ਘੱਟ ਸਮਾਂ ਖਪਾਉਂਦੇ ਹੋ। ਇਹ ਛੋਟੀ-ਛੋਟੀ ਅੰਤਰਾਂ 'ਤੇ ਰੁਕ ਜਾਣ ਦੇ ਮਾਮਲੇ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਸਬਕ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ।
ਕੰਵੈਨਸ਼ਨਾਂ ਤੁਹਾਨੂੰ ਮੁੜ-ਵਰਤਣ ਯੋਗ ਪੈਟਰਨਾਂ ਵੱਲ ਧੱਕਦੀਆਂ ਹਨ: ਵੈਲਿਡੇਸ਼ਨ ਕਿੱਥੇ ਜਾਣੀ ਹੈ, ਬੇਨਤੀ ਐਪ ਵਿੱਚ ਕਿਸ ਤਰ੍ਹਾਂ ਬਹਿੰਦੀ ਹੈ, ਗਲਤੀਆਂ ਕਿਵੇਂ ਹਟਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਫੀਚਰਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਮੇਂ ਨਾਲ, ਤੁਸੀਂ ਕੇਵਲ ਰੈਂਡਮ ਕੋਡ ਸਟ੍ਰਿੰਗਾਂ ਇਕੱਠਾ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਇੱਕ ਦੁਹਰਾਊ ਪੰਚੜੀ ਸਿੱਖ ਰਹੇ ਹੋ ਜੋ ਉਸੇ ਕਿਸਮ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਦਿੰਦੀ ਹੈ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਅਸਲ ਤਰੱਕੀ ਇਹ ਸਮਝਣ ਵਿੱਚ ਆਉਂਦੀ ਹੈ: "ਓਹ, ਇਹ ਉਹ ਮਿਆਰੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਅਸੀਂ ਫਾਰਮ ਜੋੜਦੇ ਹਾਂ / ਏਂਡਪੋਇੰਟ ਬਣਾਉਂਦੇ ਹਾਂ / ਮਾਡਲ ਨੂੰ ਕਨੈਕਟ ਕਰਦੇ ਹਾਂ"—ਨਾ ਕਿ ਹਰ ਵਾਰੀ ਇਸਨੂੰ ਨਵਾਂ ਬਣਾਉਣਾ।
ਜਦੋਂ ਤੁਹਾਡਾ ਕੋਡ ਆਮ ਕੰਵੈਨਸ਼ਨਾਂ ਨੂੰ ਫੋਲੋ ਕਰਦਾ ਹੈ, ਡੀਬੱਗਿੰਗ ਸਾਦਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ, ਅਤੇ ਹੋਰ ਲੋਕ ਵੀ ਜਾਣ ਸਕਦੇ ਹਨ। ਕਈ ਫਿਕਸਰ routine ਹੋ ਜਾਂਦੇ ਹਨ: route ਚੈੱਕ ਕਰੋ, controller/action ਚੈੱਕ ਕਰੋ, template ਚੈੱਕ ਕਰੋ, model ਚੈੱਕ ਕਰੋ।
ਭਾਵੇਂ ਤੁਸੀਂ ਇਕੱਲੇ ਹੋ, ਇਹ ਤੁਹਾਡੇ ਭਵਿੱਖ ਦੇ ਆਪ ਲਈ ਇੱਕ ਸਾਫ਼ ਵਰਕਸਪੇਸ ਵਰਗਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੋਡ ਰਿਵਿਊ ਮੰਗਦੇ ਹੋ, ਇਕ ਕਾਂਟ੍ਰੈਕਟਰ ਹਾਇਰ ਕਰਦੇ ਹੋ, ਜਾਂ ਕਿਸੇ ਦੋਸਤ ਨਾਲ ਮਿਲਕੇ ਕੰਮ ਕਰਦੇ ਹੋ, ਇੱਕ ਪਾਰੰਪਰਿਕ ਢਾਂਚਾ Onboarding ਦਾ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ। ਉਹ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹਨ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਹਨ, ਤੁਹਾਡੇ ਫੈਸਲਿਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝ ਸਕਦੇ ਹਨ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਸੁਧਾਰਨ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਢਾਂਚਾ ਸਮਝਣ 'ਤੇ।
Scaffolding ਉਹ “ਸਟਾਰਟਰ ਘਰ” ਹੈ ਜੋ ਕਈ opinionated frameworks ਤੁਹਾਡੇ ਲਈ ਬਣਾ ਸਕਦੇ ਹਨ: ਪੇਜ਼, ਰੂਟ, ਅਤੇ ਡਾਟਾਬੇਸ ਵਾਇਰਿੰਗ ਦਾ ਇੱਕ ਕੰਮ ਕਰਨਯੋਗ ਸੈੱਟ ਜੋ ਇੱਕ ਵਿਚਾਰ ਨੂੰ ਕੁਝ ਐਸੇ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਆਖ਼ਰੀ ਉਤਪਾਦ ਲਈ ਨਹੀਂ—ਇਹ blank-page ਸਮੱਸਿਆ ਨੂੰ ਹਟਾਉਣ ਲਈ ਹੈ।
ਜ਼ਿਆਦਾਤਰ scaffold ਇਹਨੀਂ ਜਰੂਰੀ ਪਰ ਘਰੇਲੂ ਪੀਸਾਂ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ:
ਤੁਸੀਂ ਜੋ ਅਜੇ ਵੀ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਹੋਵੇਗਾ ਉਹ ਪ੍ਰੋਡਕਟ ਹੈ: ਯੂਜ਼ਰ ਫਲੋ, ਸਮੱਗਰੀ, ਕੀ “ਵਧੀਆ” ਹੈ, ਅਤੇ ਕਿਥੇ ਨਿਯਮ ਸਿਰਫ਼ “ਲਾਜ਼ਮੀ ਫੀਲਡ” ਤੋਂ ਵੱਧ ਹਨ। ਸਕੈਫੋਲਡਿੰਗ ਤੁਹਾਨੂੰ ਇੱਕ ਕਾਰਗਰ ਡੈਮੋ ਦਿੰਦੀ ਹੈ, ਨਾ ਕਿ ਵਿਲੱਖਣ ਅਨੁਭਵ।
ਇੱਕ ਆਮ ਨਵੇਂ ਫਲੈਵਾ ਹੈ ਕਿ generated screens ਨੂੰ ਅੰਤਿਮ ਐਪ ਸਮਝ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਦੀ ਥਾਂ, scaffolds ਨੂੰ ਪਹਿਲੇ ਤੌਰ 'ਤੇ ਬਿਹेवਿਯਰ ਨੂੰ ਤਸਦੀਕ ਕਰਨ ਲਈ ਵਰਤੋਂ:
ਇਸ ਨਾਲ ਮੋਮੈਂਟਮ ਬਣਾ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਜਨਰਿਕ UI ਦੀ ਬਜਾਏ progressively product-specific ਚੋਣਾਂ ਰੱਖਦੇ ਹੋ।
Generated ਕੋਡ ਸਭ ਤੋਂ ਆਸਾਨ ਤੌਰ ਤੇ ਉਹ ਵੇਲੇ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਹੋਰ ਫੀਚਰ ਉਸ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਵੱਈਆ:
ਜੇ ਤੁਸੀਂ unsure ਹੋ, generated ਫਾਈਲ ਨੂੰ ਨਕਲ ਕਰੋ ਅਤੇ ਛੋਟੇ commits ਵਿੱਚ ਬਦਲਾਅ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵਾਪਸ ਜਾ ਸਕੋ।
Scaffolding ਨੂੰ ਇੱਕ ਗਾਈਡਡ ਟੂਰ ਵਾਂਗ ਲੋ। ਇੱਕ ਫੀਚਰ generate ਕਰਨ ਤੋਂ ਬਾਅਦ, ਫਾਈਲਾਂ ਨੂੰ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ: routes → controller/handler → model → view. ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਦੀਆਂ ਰਿਵਾਜ਼ਾਂਜ਼ ਨੂੰ docs ਪੜ੍ਹਣ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋਗੇ—ਅਤੇ ਇਹ ਵੀ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਅੱਗੇ ਕੀ ਕਸਟਮਾਈਜ਼ ਕਰਨਾ ਹੈ।
ਗਤੀ ਚੰਗੀ ਹੈ—ਪਰ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੁਝ ਐੱਸਾ ਨਾਹ ਸ਼ਿਪ ਕਰੋ ਜੋ ਡੇਟਾ ਲੀਕ ਕਰੇ ਜਾਂ ਹੈਕ ਹੋ ਜਾਵੇ। ਇੱਕ ਘੱਟ ਜਿਹੀ ਫਾਇਦਾ opinionated frameworks ਦਾ ਇਹ ਹੈ ਕਿ ਉਹ “pit of success” ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ: ਡਿਫਾਲਟ ਰਾਹ ਸੁਰੱਖਿਅਤ ਰਾਹ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਇਕ ਦਿਨ ਵਿੱਚ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਜ्ञ ਨਹੀਂ ਬਣੇ ਬਗੈਰ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਕੋਈ framework ਮਜ਼ਬੂਤ ਕੰਵੈਨਸ਼ਨ ਰੱਖਦਾ ਹੈ, ਉਹ ਆਮ ਗਲਤੀਆਂ ਨੂੰ ਸ਼ਾਂਤ ਤਰੀਕੇ ਨਾਲ ਰੋਕ ਸਕਦਾ ਹੈ। ਇਸ ਦੀ ਥਾਂ ਕਿ ਤੁਹਾਨੂੰ ਹਰ ਨਿਯਮ ਯਾਦ ਰੱਖਣਾ ਪਏ, ਇਹ ਤੁਹਾਨੂੰ ਆਪਣੇ-ਆਪ ਨੂੰ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ।
ਕੁਝ ਰੋਜ਼ਾਨਾ ਉਦਾਹਰਨ ਜਿਹੜੇ ਡਿਫਾਲਟ ਤੌਰ ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ:
ਨਵੇਂ ਲੋਕ ਅਕਸਰ ਟਿਊਟੋਰੀਅਲਾਂ, ਜਵਾਬਾਂ, ਜਾਂ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਤੋਂ ਕੋਡ ਨਕਲ ਕਰਦੇ ਹਨ। ਇਹ ਆਮ ਗੱਲ ਹੈ—ਪਰ ਇਸ ਦਾ ਨਤੀਜਾ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਵਿੱਚ ਵੀ ਨਿਕਲ ਸਕਦਾ ਹੈ:
Opinionated frameworks ਇਸ ਖ਼ਤਰੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ “ਮਿਆਰੀ ਤਰੀਕਾ” ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੁੰਦੀ ਹੈ। ਜੇ ਹਰ ਫਾਰਮ ਇੱਕੋ helpers ਵਰਤਦਾ ਹੈ, ਹਰ controller ਇੱਕੋ flow ਫੋਲੋ ਕਰਦਾ ਹੈ, ਅਤੇ authentication ਇੱਕੋ official components ਵਰਤਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਇਕ-ਆਫ ਸੁਰੱਖਿਆ ਪਾਥ ਬਣਾਉਣ ਤੋਂ ਬਚਦੇ ਹੋ।
ਡਿਫਾਲਟ ਇੱਕ head start ਹਨ, ਗੈਰੰਟੀ ਨਹੀਂ। ਜਦੋਂ ਤੁਸੀਂ ship ਕਰਣ ਦੇ ਨੇੜੇ ਹੋ, ਤਦ framework ਦੀ ਅਧਿਕਾਰਿਕ ਸੁਰੱਖਿਆ ਗਾਈਡ ਨਾਲ ਇੱਕ ਅਖੀਰੀ ਪਾਸ ਕਰੋ। sessions, CSRF, password ਸਟੋਰੇਜ, ਫਾਇਲ ਅੱਪਲੋਡ ਅਤੇ production ਸੈਟਿੰਗਾਂ ਤੇ ਚੈੱਕਲਿਸਟ ਵੇਖੋ।
ਜੇ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ, ਤਾਂ ਆਪਣੇ release checklist ਵਿੱਚ “Security” ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਉਸ ਨੂੰ ਉਹ docs ਜੜੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ (ਜਾਂ ਆਪਣੇ ਨੋਟ /docs ਵਿੱਚ)।
Opinionated frameworks ਨਵੇਂ ਲੋਕਾਂ ਦਾ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਡੇ ਲਈ ਫੈਸਲੇ ਕਰਦੇ ਹਨ। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਉਹ ਫੈਸਲੇ ਹਰ ਵੇਲੇ ਤੁਹਾਡੇ ਮਨਪਸੰਦ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦੇ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ "ਮਿਆਰੀ" ਐਪ ਤੋਂ ਅੱਗੇ ਵਧ ਰਹੇ ਹੋ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਤੁਸੀਂ ਬੰਦ محسوس ਕਰ ਸਕਦੇ ਹੋ: ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਰੂਟਿੰਗ ਸ਼ੈਲੀ, ਫਾਈਲ ਨਾਂ, ਅਤੇ ਆਮ ਕੰਮ ਕਰਨ ਦੇ “ਸਹੀ ਤਰੀਕੇ” ਅਕਸਰ ਬਦਲਦੇ ਨਹੀਂ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ—ਬੰਧਨ ਫੈਸਲੇ ਥਕਾਵਟ ਘਟਾਉਂਦੇ ਹਨ।
ਪਰ ਜੇ ਤੁਸੀਂ ਕੁਝ ਅਨੋਖਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ (ਕਸਟਮ auth, ਗੈਰ-ਮਿਆਰੀ ਡੇਟਾਬੇਸ, ਅਨੋਖਾ UI ਆਰਕੀਟੈਕਚਰ), ਤਾਂ ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਨੂੰ ਮੋੜਨ ਵਿੱਚ ਵਧੇਰਾ ਸਮਾਂ ਜਾ ਸਕਦੇ ਹੋ ਬਜਾਏ ਫੀਚਰ ਬਣਾਉਣ ਦੇ।
Opinionated ਟੂਲ ਹਨ ਜੋ ਅਕਸਰ ਆਪਣੀਆਂ ਰਿਵਾਜ਼ਾਂ ਸਿੱਖਣ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਵੋ। ਨਵੇਂ ਲਈ, ਇਹ ਅਹਿਸਾਸ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕ ਵਾਰੀ ਦੋ ਚੀਜ਼ਾਂ ਸਿੱਖ ਰਹੇ ਹੋ: ਵੈੱਬ ਡਿਵੈਲਪਮੈਂਟ ਦੀ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਅਤੇ ਫਰੇਮਵਰਕ-ਖਾਸ ਰਵੱਈਆ।
ਇਹ ਫਿਰ ਵੀ ਆਪ ਆਪਣੇ ਆਪ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਨਿਰਾਸ਼ਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜਦ framework ਕੁਝ ਵਿਸਥਾਰਾਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਬੇਨਤੀ ਕਿਵੇਂ ਫਲੋ ਕਰਦੀ ਹੈ ਜਾਂ ਵੈਲਿਡੇਸ਼ਨ ਅਤੇ ਪਰਮੀਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਹੋ ਰਹੀ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡੀ ਸਮਾਂ-ਤਰਾਸੀ ਉਹ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ "ਰਸਤੇ ਤੋਂ ਉਤਰ" ਜਾਂਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਕੰਵੈਨਸ਼ਨਾਂ ਨੂੰ ਅਣਡਿੱਖਾ ਕਰਦੇ ਹੋ—ਕੋਡ ਅਣਉਮਪਾਇਆ ਥਾਂ ਤੇ ਰੱਖਦੇ ਹੋ, ਬਿਲਟ-ਇਨ ਪੈਟਰਨਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹੋ, ਜਾਂ ਕੋਰ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਬਦਲਦੇ ਹੋ—ਤਾਂ ਤੁਸੀਂ ਉਲਝਣ ਵਾਲੇ ਬੱਗ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਸੁੱਖ ਨਾਲ ਵਧ ਸਕਦੇ ਹੋ।
ਅੱਛਾ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਲਈ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਸਥਾਨਾਂ 'ਤੇ ਫਰੇਮਵਰਕ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਸੋਚੋ ਕਿ ਕੀ ਤੁਸੀਂ ਸਹੀ ਸਮੱਸਿਆ ਸਲਾਹ ਕਰ ਰਹੇ ਹੋ।
ਡਿਫਾਲਟ ਸ਼ੁਰੂਆਤ ਲਈ optimized ਹੁੰਦੇ ਹਨ, ਸਾਰੇ ਹਾਲਾਤਾਂ ਲਈ ਨਹੀਂ। ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਹਾਡੀ ਐਪ ਵੱਧਦੀ ਹੈ, ਤੁਹਾਨੂੰ caching, ਡਾਟਾਬੇਸ ਇੰਡੈਕਸਿੰਗ, ਬੈਕਗ੍ਰਾਊਂਡ ਜ਼ੌਬਜ਼, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਵੇਰਵਿਆਂ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਪਏਗੀ ਜੋ ਪਹਿਲਾਂ framework ਨੇ ਛੁਪਾ ਰੱਖੇ ਹੋ ਸਕਦੇ ਹਨ।
ਤੁਸੀਂ ਡਿਫਾਲਟ ਤੋਂ ਬਾਹਰ ਜਾ ਰਹੇ ਹੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੇ ਫੀਚਰਾਂ ਲਈ ਇਕਸਾਰ ਕਸਟਮ ਪੈਟਰਨਾਂ ਦੀ ਲੋੜ ਹੋਵੇ, ਅੱਪਡੇਟ ਤੁਹਾਡੇ ਓਵਰਰਾਈਡਸ तोੜ ਰਹੇ ਹੋਣ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਕਿਵੇਂ framework ਵਰਤਦਾ ਹੈ ਇਸ ਦਾ ਕਾਰਨ ਨਹੀਂ ਸਮਝ ਸਕਦੇ—ਸਿਰਫ ਇਹ ਜਾਣਦੇ ਹੋ ਕਿ ਐਸਾ ਹੋ ਰਿਹਾ ਹੈ।
ਫਰੇਮਵਰਕਾਂ 'ਚੋਂ ਚੁਣਨਾ ਇਨਾਟਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਤੁਸੀਂ ਕੋਈ “ਹਮੇਸ਼ਾ ਲਈ” ਟੂਲ ਚੁਣ ਰਹੇ ਹੋ। ਇਹ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਪਹਿਲੇ ਪ੍ਰੋਜੈਕਟ ਲਈ, ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕਿਸੇ ਅਸਲੀ ਚੀਜ਼—MVP, ਪੋਰਟਫੋਲੀਓ ਟੁਕੜਾ, ਜਾਂ ਛੋਟੇ ਕਾਰੋਬਾਰੀ ਐਪ—ਕੋ ਬਿਨਾਂ ਰੋਕਾਵਟਾਂ ਦੇ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ।
ਵੱਖ-ਵੱਖ framework ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਵਿੱਚ ਚਮਕਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਐਪ ਇਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਲਪਾਂ ਦਾ ਆਧਾ ਹਿੱਸਾ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ।
ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ 30 ਮਿੰਟ ਲਗਾ ਕੇ ਦੇਖੋ:
ਇੱਕ framework ਚੰਗਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਸਿੱਖਣ ਵਾਲੀ ਸਮੱਗਰੀ ਪੁਰਾਣੀ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਅਟਕ ਸਕਦੇ ਹੋ।
ਉਹ ਚੀਜ਼ਾਂ ਲੱਭੋ ਜੋ ਫੈਸਲੇ ਘਟਾਉਂਦੀਆਂ ਹਨ: ਸਮਝਦਾਰ ਫੋਲਡਰ ਡਿਫਾਲਟ, authentication ਪੈਟਰਨ, environment configuration, ਅਤੇ testing ਮਾਰਗਦਰਸ਼ਨ।
ਇੱਕੋ ਸਮੇਂ, ਇਹ ਵੀ ਦੇਖੋ:
Framework ਹੀ ਇੱਕੋ ਤਰੀਕਾ ਨਹੀਂ ਹੈ early decisions ਘਟਾਉਣ ਦਾ। ਟੂਲਾਂ ਜਿਵੇਂ Koder.ai ਇੱਕੋ ਵਿਚਾਰ—ਡਿਫਾਲਟ, ਕੰਵੈਨਸ਼ਨ, ਅਤੇ ਸਕੈਫੋਲਡਿੰਗ—ਨੂੰ ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਵਿੱਚ ਲੈ ਆਉਂਦੇ ਹਨ।
Koder.ai ਨਾਲ, ਤੁਸੀਂ ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ ਆਪਣੀ ਐਪ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਕੰਮ ਕਰਨਯੋਗ ਪ੍ਰੋਜੈਕਟ end-to-end (ਵੈੱਬ, ਬੈਕਐਂਡ, ਅੱਥਵਾ ਮੋਬਾਈਲ) ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਇੱਕ ਸਥਿਰ ਸਟੈਕ ਵਰਤੀਕ: React ਵੈੱਬ, Go ਬੈਕਐਂਡ ਨਾਲ PostgreSQL, ਅਤੇ ਮੋਬਾਈਲ ਲਈ Flutter। ਨਵੇਂ ਲਈ, ਵਰਤੋਂਕਾਰੀ ਲਾਭ opinionated framework ਵਰਗੇ ਹੀ ਹੁੰਦਾ ਹੈ: ਘੱਟ ਸੈਟਅੱਪ ਫੈਸਲੇ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ “happy path”, ਨਾਲ planning mode, snapshots, rollback, deployment/hosting, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਨਿਯੰਤਰਣ ਚਾਹੋ ਤਾਂ source code export ਦੀ ਸਮਰੱਥਾ।
ਆਪਣੇ ਪਹਿਲੇ ਨਿਰਮਾਣ ਲਈ "framework shopping" ਤੋਂ ਬਚੋ। ਇੱਕ ਢੰਗ ਦੀ ਚੋਣ ਕਰੋ, ਅਧਿਕਾਰਿਕ ਗਾਈਡ ਨੂੰ ਪੂਰਾ ਕਰਕੇ ਅੰਤ ਤੱਕ ਜਾਓ, ਅਤੇ ਉਸ ਤੇ ਟਿਕੋ। ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਪੂਰਾ ਕਰਨ ਨਾਲ ਤਿੰਨ ਨਹੀਂ, ਬਹੁਤੀ ਵਧੇਰੀ ਸਿਖਿਆ ਮਿਲਦੀ ਹੈ।
Opinionated frameworks ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਆਗੇ ਚਲਣ ਦਿਓ। ਉਦੇਸ਼ ਇੱਥੇ ਪਰਫੈਕਟ ਐਪ ਬਣਾਉਣਾ ਨਹੀਂ—ਇੱਕ ਛੋਟੀ, ਅਸਲ ਐਪ ਨੂੰ ਖ਼ਤਮ ਕਰਨਾ ਅਤੇ ਭੇਜ ਕੇ ਸਿੱਖਣਾ ਹੈ।
ਇੱਕ framework ਚੁਣੋ ਅਤੇ ਇੱਕ ਹਫ਼ਤੇ ਲਈ ਇਸ 'ਤੇ ਕਮੇਟ ਕਰੋ (Rails, Django, Laravel, Next.js—ਕੋਈ ਵੀ ठीक ਹੈ). ਫਿਰ ਅਧਿਕਾਰਿਕ ਟਿਊਟੋਰੀਅਲ ਨੂੰ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕਰੋ।
ਾਰ mid-way 'ਤੇ ਸੁਧਾਰ ਨਾ ਕਰੋ, ਡੇਟਾਬੇਸ ਨਾ ਬਦਲੋ, ਅਤੇ ਫੋਲਡਰ ਢਾਂਚਾ ਨਾਂ ਬਦਲੋ। ਉਦੱੱਸ਼ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਰਿਵਾਜ਼ਾਂ ਨੋਟ ਕਰਨ ਦੀ ਹੈ: ਕੋਡ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਰੂਟਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਡਾਟਾ ਕਿਵੇਂ ਫਲੋ ਕਰਦਾ ਹੈ, ਅਤੇ "ਨਾਰਮਲ" ਕੀ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਫਸੋ, errors ਨੂੰ ਖੋਜੋ ਅਤੇ ਜਾਰੀ ਰੱਖੋ—ਟਿਊਟੋਰੀਅਲ ਪੂਰਾ ਕਰਨਾ ਹਰ ਲਾਈਨ ਨੂੰ ਸਮਝਣੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਟਿਊਟੋਰੀਅਲ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਫੀਚਰ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਜੋੜੋ:
ਹਰ ਫੀਚਰ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸ਼ਿੱਪ ਕਰਨਯੋਗ ਰੱਖੋ। CRUD ਲਈ ਇੱਕ ਮਾਡਲ ਕਾਫ਼ੀ ਹੈ। Auth ਲਈ framework ਦੀ ਸਿਫਾਰਸ਼ੀ ਰਾਹ ਵਰਤੋ (starter kits, generators, ਜਾਂ built-in modules)।
ਆਗਿਆ: ਜੇ ਕੋਈ ਫੀਚਰ ਇਕ ਸ਼ਾਮ ਨੂੰ ਵੱਧ ਲਗਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਅੱਧਾ ਕਰੋ।
ਐਪ ਕੰਮ ਕਰਨ 'ਤੇ, ਇੱਕ ਸੁਰੱਖਿਆ ਪਰਤ ਜੋੜੋ:
ਇਹ ਥਾਂ opinionated ਡਿਫਾਲਟ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ: ਟੈਸਟਿੰਗ ਟੂਲ, ਕੰਵੈਨਸ਼ਨ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਗਾਈਡ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਨਕਸ਼ਾ ਕੀਤੇ ਹੁੰਦੇ ਹਨ।
ਤੁਹਾਡੀ ਐਪ "ਡਨ" ਤਾਂ ਹੋਵੇਗੀ ਜਦੋਂ ਇਹ ਡਿਪਲੋਇਡ ਹੋਵੇ, ਤੁਸੀਂ ਲਿੰਕ ਸਾਂਝਾ ਕਰ ਸਕੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ 3 ਲੋਕਾਂ ਤੋਂ feedback ਮਿਲ ਚੁੱਕੀ ਹੋਵੇ। ਜਦ ਇਹ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ iteration ਕਰ ਸਕਦੇ ਹੋ—ਜਾਂ ਦੂਜਾ ਐਪ ਸ਼ੁਰੂ ਕਰੋ ਜ਼ਿਆਦਾ ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ।
Opinionated frameworks ਨਾਲ ਤੇਜ਼ ਹੋਣਾ ਸਿਰਫ framework ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸਦੇ ਨਿਯਮਾਂ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹੋ। ਉਦੇਸ਼ ਹੈ ਖੁਸ਼ ਰਸਤੇ 'ਤੇ ਕਾਫ਼ੀ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰਹਿਣਾ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਕ ਅਸਲ ਚੀਜ਼ ਖਤਮ ਕਰੋ।
ਨਵੇਂ ਹੋਣ 'ਤੇ, ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ "ਇਹ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ?" ਲੱਭਣ ਵਿੱਚ ਲੱਗਦਾ ਹੈ। ਇਕ ਪੇਜ ਨੋਟ (ਜਾਂ repo ਵਿੱਚ README) ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਓਹ conventions ਲਿਖੀਆਂ ਹੋਣ: ਮੁੱਖ ਫੋਲਡਰ, ਨਾਮਕਰਨ ਨਿਯਮ, ਅਤੇ 5–10 ਕਮਾਂਡਾਂ ਜੋ ਤੁਸੀਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਚਲਾਉਂਦੇ ਹੋ।
ਉਦਾਹਰਣ:
ਇਸ ਨਾਲ ਦੁਹਰਾਈ ਵਾਲੀ Google ਖੋਜ muscle memory ਵਿੱਚ ਬਦਲ ਜਾਵੇਗੀ।
Opinionated frameworks ਤੁਹਾਨੂੰ ਕੰਮ ਕਰਨਯੋਗ ਬੇਸਲਾਈਨ ਦਿੰਦੇ ਹਨ—authentication ਪੈਟਰਨ, ਪ੍ਰੋਜੈਕਟ ਸਟਰੱਕਚਰ, build tools, ਇੱਥੇ ਤੱਕ ਕਿ error handling। ਡਿਫਾਲਟ ਨੂੰ “ਠੀਕ ਮੰਨੋ ਜਦ ਤਕ ਸਾਬਤ ਨਾ ਹੋਵੇ”।
ਕਿਸੇ library ਨੂੰ ਬਦਲਣ ਜਾਂ ਫੋਲਡਰ ਦੁਬਾਰਾ ਸੰਗਠਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ: ਕੀ ਇਹ ਬਦਲਾਅ ਮੈਨੂੰ ਅਗਲਾ ਫੀਚਰ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ? ਜੇ ਜਵਾਬ "ਕਦੇ ਭਵਿੱਖ ਵਿੱਚ ਹਾਂ", ਤਾਂ ਇਸਨੂੰ ਟਾਲੋ।
Formatting, linting, ਅਤੇ testing ਲਈ ਸਿਫਾਰਸ਼ ਕੀਤੇ ਸੈਟਅੱਪ ਵਰਤੋਂ। ਇਹ ਰਿਵਿਊ ਓਵਰਹੈਡ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਛੋਟੀ-ਛੋਟੀ ਸਟਾਈਲ ਮੁੱਦਿਆਂ ਨੂੰ ਘੰਟਿਆਂ ਦੇ ਡੀਟੇਰਾਂ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ।
ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਤੁਹਾਡੇ framework ਦੇ starter kit ਵਿੱਚ ਕੋਈ linter/formatter/test runner ਸੁਝਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਛੋਟਾ ਐਪ ਸ਼ਿਪ ਕਰਨ ਤੱਕ ਉਹੀ ਵਰਤੋਂ।
ਆਪਣੀ ਐਪ ਨੂੰ ਛੋਟੇ, ਦਰਸ਼ਨੀ ਚੈਕਪੌਇੰਟਾਂ ਵਿੱਚ ਤੋੜੋ (login ਕੰਮ ਕਰਦਾ, ਇੱਕ CRUD ਸਕ੍ਰੀਨ ਕੰਮ ਕਰਦੀ, payment flow ਕੰਮ ਕਰਦੀ)। ਹਰ ਚੈਕਪੌਇੰਟ ਤੋਂ ਬਾਅਦ ਡਿਪਲੋਏ ਕਰੋ—ਚਾਹੇ ਇਹ ਖਰਾਬ ਲੱਗੇ।
ਜਲਦੀ ਡਿਪਲੋਏਸ ਅਸਲ ਸਮੱਸਿਆਵਾਂ (config, env vars, DB ਸੈਟਅਪ) ਨੂੰ ਛੋਟੇ ਹੋਣ 'ਤੇ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ। ਇੱਕ ਰਨਿੰਗ "ਅਗਲਾ ਮਿਲਸਟੋਨ" ਦੀ ਸੂਚੀ ਰੱਖੋ ਅਤੇ ਮੌਜੂਦਾ ਮਿਲਸਟੋਨ ਲਾਈਵ ਹੋਣ ਤੱਕ ਸਕੋਪ ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਬਚੋ।
An opinionated framework ਤੁਹਾਡੇ ਲਈ ਬਹੁਤ ਸਾਰੇ ਫੈਸਲੇ ਪਹਿਲਾਂ ਹੀ ਕਰ ਦਿੰਦਾ ਹੈ — ਫੋਲਡਰ ਬਣਾਵਟ, ਰੂਟਿੰਗ ਦੇ ਨਿਯਮ, ਡੇਟਾਬੇਸ ਰਸਤੇ ਅਤੇ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਟੂਲ — ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਸ਼ੁਰੂ ਤੋਂ ਡਿਜ਼ਾਇਨ ਨਾ ਕਰੋ।
ਤੁਸੀਂ ਫਿਰ ਵੀ ਕਸਟਮਾਈਜ਼ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋਗੇ ਜੇ ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਦੀਆਂ ਸਹਿਮਤੀਆਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰੋਗੇ ਨਾ ਕਿ ਉਨ੍ਹਾਂ ਦੇ ਖਿਲਾਫ।
ਅਕਸਰ, ਸ਼ੁਰੂਆਤੀ ਲੋਕ وقت ਗੁਆ ਲੈਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ “ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ” ਫੈਸਲੇ ਕਰਨ ਵਿੱਚ ਫਸ ਜਾਂਦੇ ਹਨ: ਲਾਈਬ੍ਰੇਰੀਆਂ ਚੁਣਨਾ, ਢਾਂਚਾ ਸੋਚਣਾ, ਅਤੇ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਸ਼ੱਕ ਕਰਨਾ।
Opinionated frameworks ਇਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਘਟਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਇਹ ਦਿੰਦੇ ਹਨ:
ਇਸ ਕਰਕੇ ਨਵੇਂ ਸਿੱਖਣ ਵਾਲੇ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ।
“Unopinionated” ਜਾਂ DIY ਸਟੈਕ ਤੈਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਚਕੀਲਾਪਨ ਦਿੰਦੇ ਹਨ, ਪਰ ਉਹ ਹਰ ਹਿੱਸੇ ਨੂੰ ਖ਼ੁਦ ਚੁਣਨ ਅਤੇ ਜੋੜਨ ਦੀ ਲੋੜ ਪੈਦਾ ਕਰਦੇ ਹਨ (router, ORM, auth, testing, structure)।
Opinionated frameworks ਸ਼ੁਰੂਆਤੀ ਆਜ਼ਾਦੀ ਨੂੰ ਘਟਾ ਕੇ ਤੇਜ਼ੀ ਦਿੰਦੇ ਹਨ:
ਇਹ “ਰਾਇਆਂ” ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਥਾਵਾਂ ਤੇ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ:
Scaffolding ਨੂੰ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ end-to-end ਸਲਾਇਸ ਜਲਦੀ ਪ੍ਰਾਪਤ ਕਰ ਲਵੋ (ਡਾਟਾ → ਲਾਜਿਕ → UI), ਫਿਰ ਧੀਰੇ-ਧੀਰੇ ਸੋਧ ਕਰੋ।
ਪ੍ਰੈਕਟਿਕਲ ਤਰੀਕਾ:
Generated screens ਨੂੰ ਅਖੀਰਲਾ ਸਮਾਨ ਨਾ ਸਮਝੋ — ਇਹ ਇੱਕ ਸ਼ੁਰੂਆਤ ਹੈ, ਨਾਂ ਕਿ ਆਖਰੀ ਉਤਪਾਦ।
ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਦੇ ਨਾਲ ਲੜ ਰਹੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਇਕੋ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਨ ਲਈ ਕਈ ਸਥਾਨਾਂ 'ਤੇ ਕੋਰ ਪੈਟਰਨ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਰਹੇ ਹੋ।
ਇਸ ਦੀ ਥਾਂ ਇਸਨੂੰ ਪ੍ਰਯੋਗ ਕਰੋ:
ਜੇ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਇੱਕ ਸਾਫ਼ ਪੈਟਰਨ ਰੱਖੋ ਨਾ ਕਿ ਬਹੁਤ ਸਾਰੇ ਹੱਕ-ਹੱਕ ਦੇ ਹੈਕਸ।
Opinionated frameworks ਅਕਸਰ ਇੱਕ “pit of success” ਬਣਾਉਂਦੇ ਹਨ — ਡਿਫਾਲਟ ਰਾਹ ਅਕਸਰ ਸੁਰੱਖਿਅਤ ਰਾਹ ਹੁੰਦਾ ਹੈ।
ਆਮ ਸੁਰੱਖਿਆ-ਸਬੰਧੀ ਡਿਫਾਲਟ ਸ਼ਾਮਲ ਹਨ:
ਫਿਰ ਵੀ, ship ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਧਿਕਾਰਿਕ ਸੁਰੱਖਿਆ ਗਾਈਡ ਤੋਂ ਇੱਕ ਫਾਈਨਲ ਪਾਸ ਕਰੋ — ਡਿਫਾਲਟ ਮਦਦਗਾਰ ਹਨ ਪਰ ਗੈਰੰਟੀ ਨਹੀਂ।
ਪਹਿਲਾਂ ਦਿਖ਼ਾਈਆਂ ਦੇ ਤੌਰ 'ਤੇ ਡਿਫਾਲਟ ਹੇਠਾਂ ਰਹੋ, ਅਤੇ ਇਕ ਛੋਟਾ ਐਪ ਤਕ ਪਹੁੰਚਣ ਤੱਕ ਇਨ੍ਹਾਂ ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਚੋ।
ਅਚ੍ਹਾਂ ਨਿਯਮ: ਇਕ ਡਿਫਾਲਟ ਨੂੰ ਤਬਦੀਲ ਕਰੋ ਜਦੋਂ ਇਹ ਸਪੱਸ਼ਟ ਰਹੇ ਕਿ ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਅਗਲੇ ਫੀਚਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲੇਗੀ — ਨਾ ਕਿ “ਕਦੇ ਭਵਿੱਖ ਵਿੱਚ ਠੀਕ ਹੋ ਸਕਦਾ”।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਬਦਲਾਅ ਹੈ, ਤਾਂ ਛੋਟੇ commits ਵਿੱਚ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵਾਪਸ ਜਾ ਸਕੋ।
ਉਹ ਫਰੇਮਵਰਕ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਲਕੜੀ ਦੇ ਟੀਚੇ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ ਅਤੇ ਨਵੇਂ ਲੋਕਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋਵੇ:
ਫਿਰ ਇੱਕ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਇੱਕ ਵਿਕਲਪ ਚੁਣੋ ਅਤੇ ਉਸਤੇ ਟਿਕੇ ਰਹੋ। ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਪੂਰਾ ਕਰਨਾ ਨਵੇਂ ਪ੍ਰਾਜੈਕਟਾਂ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਿਖਾਉਂਦਾ ਹੈ।
ਇਕ ਸਧਾਰਨ ਯੋਜਨਾ:
“Done” ਦਾ ਅਰਥ: ਡਿਪਲੋਇਡ + ਸਾਂਝਾ ਕਰਨਯੋਗ ਲਿੰਕ + ਘੱਟੋ-ਘੱਟ 3 ਲੋਕਾਂ ਦੇ Feedback। ਇਹ ਪਰਿਭਾਸ਼ਾ ਅਨੰਤ ਸੁਧਾਰ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
