ਕਿਵੇਂ ਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਲੋੜ ਘਟਾਉਂਦੀਆਂ ਹਨ

ਜਦੋਂ ਰਿਵਾਇਤਾਂ ਦਸਤਾਵੇਜ਼ ਦੀ ਜਗ੍ਹਾ ਲੈ ਲੈਂਦੀ ਹਨ ਤਾਂ ਇਸਦਾ ਕੀ ਉਦੇਸ਼ ਹੁੰਦਾ ਹੈ\n\nਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਉਹ “ਡਿਫੌਲਟ ਤਰੀਕੇ” ਹਨ ਜੋ ਇਕ ਫਰੇਮਵਰਕ ਖਾਮੋਸ਼ੀ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ—ਜਾਂ ਖੁੱਲ ਕੇ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਹਰ ਟੀਮ ਨੂੰ ਆਪਣਾ ਫੋਲਡਰ ਲੇਆਊਟ, ਨਾਮਕਰਨ ਸਕੀਮ ਜਾਂ ਰਿਕਵੇਸਟ/ਰੇਸਪਾਂਸ ਫਲੋ ਖੁਦ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਥਾਂ, ਫਰੇਮਵਰਕ ਇਕ ਸਾਂਝਾ ਪੈਟਰਨ ਦਿੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਦਾ ਪਾਲਣ ਕਰਦੇ ਹੋ, ਤਾਂ ਹੋਰ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਲੰਮੇ ਵਰਨਾਂ ਦੇ ਪਤਾ ਲਗਾ ਲੈਂਦੇ ਹਨ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਹਨ ਅਤੇ ਕਿਵੇਂ ਵਰਤੋਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ।\n\n### ਟੀਮਾਂ ਡੌਕਮੈਂਟੇਸ਼ਨ क्यों ਲਿਖਦੀਆਂ ਹਨ\n\nਜਿਆਦਾਤਰ ਡੌਕਸ ਇਸ ਲਈ ਨਹੀਂ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਕਿਉਂਕਿ ਲੋਕ ਡੌਕਸ ਲਿਖਣਾ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਇਹ ਕੁਝ ਮੁੜ ਆਉਂਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ:\n\n- ਓਨਬੋਰਡਿੰਗ: ਨਵੇਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਮਝਾਉਣਾ ਕਿ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਸੰਗਠਿਤ ਹੈ\n- ਅਨੁਕੂਲਤਾ: ਹਰ ਕਿਸੇ ਨੂੰ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਤੋਂ ਰੋਕਣਾ\n- ਫੈਸਲੇ ਦਰਜ ਕਰਨਾ: ਇਹ ਦਰਸਾਉਣਾ ਕਿ ਕਿਸੇ ਖਾਸ ਦ੍ਰਿੜਤਾ ਨੂੰ ਕਿਉਂ ਚੁਣਿਆ ਗਿਆ (ਅਕਸਰ ਟਰੇਡ-ਆਫ਼ ਦਰਸਾਉਂਦੇ ਹੋਏ)\n\nਰਿਵਾਇਤਾਂ ਖਾਸ ਕਰਕੇ ਪਹਿਲੇ ਦੋ ਕੰਮਾਂ ਨੂੰ ਬਹੁਤ ਅਚਛੀ ਤਰ੍ਹਾਂ ਨਿਭਾਉਂਦੀਆਂ ਹਨ। ਜਦੋਂ “X ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ” ਅਤੇ “Y ਨੂੰ ਕੀ ਨਾਮ ਦੇਣਾ ਹੈ” ਪਹਿਲਾਂ ਹੀ ਫਰੇਮਵਰਕ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਮਝਾਉਣ ਲਈ ਘੱਟ ਕੁਝ ਰਹਿੰਦਾ ਅਤੇ ਬਹਿਸ ਕਰਨ ਲਈ ਵੀ ਘੱਟ।\n\n### ਰਿਵਾਇਤਾਂ ਦਸਤਾਵੇਜ਼ ਘਟਾਉਂਦੀਆਂ ਹਨ—ਪਰ ਖਤਮ ਨਹੀਂ ਕਰਦੀਆਂ\n\n“ਰਿਵਾਇਤਾਂ ਦਸਤਾਵੇਜ਼ ਦੀ ਜਗ੍ਹਾ ਲੈਂਦੀਆਂ ਹਨ” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਦਸਤਾਵੇਜ਼ ਅੰਤਰਭੂਤ ਹੋ ਜਾਵੇ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਬੁਨਿਆਦੀ ਮਾਰਗਬੀਨੀ ਗਾਈਡਲਾਈਨਾਂ ਲੇਖ ਦੀ ਬਜਾਇ ਇਕ ਪੇਸ਼ਗੋਈਯੋਗ ਸੰਰਚਨਾ ਵਿੱਚ ਚਲੀ ਜਾਂਦੀਆਂ ਹਨ। ਮਿਸਾਲ ਲਈ, controllers ਕਿੱਥੇ ਜਾਣਗੇ ਇਹ ਸਿੱਧਾ ਫਰੇਮਵਰਕ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲੱਗ ਸਕਦਾ ਹੈ (ਅਤੇ ਟੂਲ, ਜੈਨਰੇਟਰ ਅਤੇ ਉਦਾਹਰਣ ਇਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ)।\n\nਨਤੀਜਾ: ਜਿਆਦਾ ਡੌਕਸ ਉਹਨਾਂ obvious ਗੱਲਾਂ ਬਾਰੇ ਨਹੀਂ ਅਤੇ ਧਿਆਨ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਵੱਧਦਾ ਹੈ ਜੋ ਪ੍ਰੋਜੈਕਟ-ਖਾਸ ਹੁੰਦੀਆਂ ਹਨ: ਬਿਜ਼ਨਸ ਨਿਯਮ, ਅਸਧਾਰਣ ਆਰਕੀਟੈਕਚਰ ਚੋਣਾਂ, ਅਤੇ ਜਾਣ-ਬੂਝ ਕੇ ਕੀਤੀਆਂ ਛੂਟਾਂ।\n\n### ਤੁਹਾਨੂੰ ਇਸ ਲੇਖ ਤੋਂ ਕੀ ਮਿਲੇਗਾ\n\nਇਹ ਲੇਖ ਉਨ੍ਹਾਂ ਡਿਵੈਲਪਰਾਂ, ਟੈਕ ਲੀਡਾਂ ਅਤੇ ਪ੍ਰੋਡਕਟ-ਮਾਇੰਡਡ ਟੀਮਾਂ ਲਈ ਹੈ ਜੋ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਕੋਡਬੇਸ ਸਾਫ਼ ਹੋਣ ਅਤੇ ਓਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਹੋਵੇ ਬਿਨਾਂ ਕਿਸੇ ਵੱਡੇ ਡੌਕਮੈਂਟ ਸਾਈਟ ਨੂੰ ਰੱਖਣ ਦੇ।\n\nਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ “ਗੁਪਤ ਦਸਤਾਵੇਜ਼” ਕਿਵੇਂ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਰਿਵਾਇਤਾਂ ਆਮ ਤੌਰ ਤੇ ਮਿਆਰਬੱਧ ਕਰਦੀਆਂ ਹਨ, ਕਿੱਥੇ ਰਿਵਾਇਤਾਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਗੱਲਾਂ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ—ਤਾਂ ਜੋ ਸਪਸ਼ਟਤਾ ਵੱਧੇ ਜਿਵੇਂ ਡੌਕਸ ਘਟਣ।\n\n## ਕਿਉਂ ਰਿਵਾਇਤਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਸਾਂਝੇ ਡਿਫਾਲਟ ਲੰਬੀ ਵਿਆਖਿਆ ਤੋਂ ਬਿਹਤਰ\n\n“Convention over configuration” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਰੇਮਵਰਕ ਤੁਹਾਡੇ ਲਈ ਸਮਝਦਾਰ ਚੋਣਾਂ ਕਰ ਲੈਂਦਾ—ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਸਦੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋ। ਵੱਡੀ-ਵੱਡੀ ਸੈਟਅੱਪ ਦਿੱਸਣ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਸਾਂਝੇ ਡਿਫਾਲਟਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ ਜੋ ਹਰ ਕੋਈ ਪਛਾਣ ਲੈਂਦਾ ਹੈ।\n\n### ਇਕ ਸਧਾਰਣ ਤુલਨਾ\n\nਇਸਨੂੰ ਏਸੇ ਤਰ੍ਹਾਂ ਸੋਚੋ ਜਿਵੇਂ ਕਿਸੇ ਦੇਸ਼ ਵਿੱਚ ਸਭ ਲੋਕ ਸਹੀ ਪਾਸੇ ਡਰਾਇਵ ਕਰਦੇ ਹਨ, ਲਾਲ ਬੱਤੀ 'ਤੇ ਰੁਕਦੇ ਹਨ ਅਤੇ ਮਿਆਰੀ ਨਿਸ਼ਾਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ।\n\nਤੁਸੀਂ ਹਰ ਚੌਰਾਹੇ ਲਈ ਵਿਸਥਾਰਪੂਰਣ ਮੈਨੁਅਲ ਲਿਖ ਸਕਦੇ ਹੋ (“ਜੇ ਤੁਸੀਂ ਲਾਲ ਅੱਠਕੋਣ ਵੇਖੋ ਤਾਂ ਰੁਕੋ; ਜੇ ਹਰਾ ਹੈ ਤਾਂ ਚੱਲੋ…”), ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ—ਕਿਉਂਕਿ ਰਿਵਾਇਤਾ ਪਹਿਲਾਂ ਹੀ ਮਾਲੂਮ ਤੇ ਲਗਾਤਾਰ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।\n\nਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਉਹ “ਇਥੇ ਅਸੀਂ ਕੰਮ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ” ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਵਰਤਣਾ ਬਣਾਉਂਦੀਆਂ ਹਨ।\n\n### ਡਿਫਾਲਟ ਹਰ ਕਦਮ ਵਿਆਖਿਆ ਕਰਨ ਦੀ ਲੋੜ ਘਟਾਉਂਦੇ ਹਨ\n\nਜਦੋਂ ਫਰੇਮਵਰਕ ਡਿਫਾਲਟ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਹਰ ਛੋਟੀ-ਛੋਟੀ ਰਾਹ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ। ਫਰੇਮਵਰਕ (ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ) ਕੁਝ ਮਾਇਆਮਾਨ ਪੈਟਰਨ ਮੰਨ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ:\n\n- ਫਾਈਲਾਂ ਕਿੱਥੇ ਜਾਣ (controllers ਇੱਕ ਫੋਲਡਰ ਵਿੱਚ, ਟੈਮਪਲੇਟ ਹੋਰ ਵਿੱਚ)\n- ਚੀਜ਼ਾਂ ਨੂੰ ਕਿਵੇਂ ਨਾਮ ਦੇਣਾ (ਇਕ User ਮਾਡਲ users ਡੇਟਾ ਨਾਲ ਮੇਪ ਹੁੰਦਾ ਹੈ)\n- ਆਮ ਫੀਚਰ ਕਿਵੇਂ ਵਾਇਰ ਹੁੰਦੇ ਹਨ (ਰਾਊਟਿੰਗ, ਵੈਲੀਡੇਸ਼ਨ, ਪਰਿਵੇਸ਼ਾਂ ਦੀ ਸੈਟਿੰਗ)\n\nਇਹ ਸਾਂਝਾ ਬੇਸਲਾਈਨ ਡੌਕਸ ਨੂੰ ਇਸ ਕਹਾਣੀ ਤੱਕ ਘਟਾਉਂਦੀ ਹੈ: “ਅਸੀਂ ਫਰੇਮਵਰਕ ਡਿਫਾਲਟ ਫੋਲੋ ਕਰਦੇ ਹਾਂ, ਜਿੱਥੇ ਉਸੇ ਤੋਂ ਇਲਾਵਾ ਦੱਸਿਆ ਗਿਆ ਹੋਵੇ।” ਇਹ ਓਨਬੋਰਡਿੰਗ ਦੌਰਾਨ ਮੈਨਟਲ ਲੋਡ ਵੀ ਘਟਾਉਂਦਾ ਹੈ: ਨਵੇਂ ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਕੋਡ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।\n\n### ਟਰੇਡਆਫ਼: ਘੱਟ ਲਚੀਲਾਪਨ, ਜ਼ਿਆਦਾ ਇਕਸਾਰਤਾ\n\nਰਿਵਾਇਤਾਂ ਮੁਫ਼ਤ ਨਹੀਂ। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਈ ਵਾਰੀ ਅਸਧਾਰਣ ਫੋਲਡਰ ਢਾਂਚੇ, ਕਸਟਮ ਨਾਮਕਰਨ ਜਾਂ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਵਰਕਫਲੋਜ਼ ਛੱਡਦੇ ਹੋ।\n\nਫ਼ਾਇਦਾ ਹੈ ਇਕਸਾਰਤਾ: ਘੱਟ ਤਰਕ-ਵਟਾਂਦਰਾ, ਘੱਟ ਹੈਰਾਨੀ, ਘੱਟ "ਟ੍ਰਾਈਬਲ ਨੋਲੇਜ" ਨਿਯਮ ਜੋ ਸਿਰਫ ਲੰਬੇ ਸਮੇਂ ਵਾਲਿਆਂ ਨੂੰ ਯਾਦ ਰਹਿੰਦੇ ਹਨ। ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਵੇਰਵਾ ਕਰਨ ਦੀ ਥਾਂ ਬਣਾਉਣ 'ਤੇ ਘੱਟ ਸਮਾਂ ਖਰਚ ਕਰਦੀ ਹੈ।\n\n### ਜਦੋਂ ਰਿਵਾਇਤਾਂ ਵੱਧ-ਤੱਕ ਬਾਅਦਕਾਰ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਉਹ ਚੰਗੀਆਂ ਹੋਦੀਆਂ ਹਨ\n\nਇਕ ਰਿਵਾਇਤਾ ਤਦ ਹੀ ਡੌਕਸ ਬਚਾਉਂਦੀ ਹੈ ਜਦ ਲੋਕ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ ਜਾਣਦੇ ਹੋਣ—ਜਾਂ ਇੱਕ ਵਾਰੀ ਸਿੱਖ ਕੇ ਹਰ ਥਾਂ ਇਸਨੂੰ ਵਰਤ ਸਕਣ।\n\nਇਸੇ ਲਈ ਲੋਕਪ੍ਰਿਯ ਫਰੇਮਵਰਕ ਤਾਕਤਵਰ ਹਨ: ਉਨ੍ਹਾਂ ਦੀਆਂ ਰਿਵਾਇਤਾਂ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਿੱਖਾਈ ਜਾਂਦੀਆਂ, ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕੋਡਬੇਸ ਵਿੱਚ ਦੁਹਰਾਈ ਜਾਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਉਨ੍ਹਾਂ ਸਾਂਝੇ ਡਿਫਾਲਟਾਂ ਦੇ ਨੇੜੇ ਰਹਿੰਦਾ ਹੈ, ਤੁਹਾਡਾ ਕੋਡ "ਡੀਫਾਲਟ ਤੌਰ 'ਤੇ" ਸਮਝ ਆਉਣਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ, ਘੱਟ ਲਿਖਤੇ ਡੌਕਸ ਦੇ ਨਾਲ।\n\n## ਉਹ 5 ਚੀਜ਼ਾਂ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਸੰਮਾਨਿਤ ਕਰਦੀਆਂ ਹਨ\n\nਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਸਾਂਝੇ ਸ਼ਾਰਟਕੱਟ ਹਨ। ਉਹ ਹਰ ਨਵੇਂ ਸਾਥੀ ਦੇ ਦਿਨ-ਇੱਕ ਦੇ ਸਵਾਲਾਂ ਨੂੰ ਮਿਆਰਬੱਧ ਕਰਦੀਆਂ ਹਨ: “ਇਹ ਕਿੱਥੇ ਸਟੋਰ ਕਰੀਏ?” ਅਤੇ “ਇਸਨੂੰ ਕੀ ਨਾਮ ਦਿੱਤਾ ਜਾਵੇ?” ਜਦੋਂ ਇਹਨਾਂ ਦੇ ਜਵਾਬ ਪੇਸ਼ਗੋਈਯੋਗ ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਕਈ ਪੰਨਿਆਂ ਵਾਲੀ ਡੌਕੁਮੈਂਟੇਸ਼ਨ ਦੀ ਥਾਂ ਕੁਝ ਇਕਸਾਰ ਡਿਫਾਲਟ ਨਾਲ ਕੰਮ ਚਲਾ ਸਕਦੇ ਹੋ।\n\n### 1) ਫੋਲਡਰ ਅਤੇ ਫਾਇਲ ਸਟ੍ਰਕਚਰ\n\nਜ਼ਿਆਦਾਤਰ ਫਰੇਮਵਰਕ ਇੱਕ ਜਾਣ ਪਹਿਚਾਣ ਵਾਲਾ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ ਪੇਸ਼ ਕਰਦੇ ਹਨ: UI ਲਈ ਇੱਕ ਥਾਂ, ਰੂਟਾਂ ਲਈ ਇੱਕ ਥਾਂ, ਡੇਟਾ ਐਕਸੈੱਸ ਲਈ ਇੱਕ ਥਾਂ, ਟੈਸਟਾਂ ਲਈ ਇੱਕ ਥਾਂ। ਇਹ ਇਕਸਾਰਤਾ ਮਹੱਤਵਪੂਰਕ ਹੈ ਕਿਉਂਕਿ ਲੋਕਾਂ ਨੂੰ "ਉਹ ਹਿੱਸਾ ਜੋ ਪੇਜ਼ ਰੈਂਡਰ ਕਰਦਾ ਹੈ" ਤੇ "ਉਹ ਹਿੱਸਾ ਜੋ ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ" ਲੱਭਣ ਲਈ ਗਾਈਡ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ।\n\nਸਰਬੋਤਮ ਰੇਖਾ: ਚੰਗੀਆਂ ਰਿਵਾਇਤਾਂ ਆਮ ਕੰਮਾਂ ਨੂੰ ਮਸ਼ੀਨ-ਮੇਮੋਰੀ ਵਾਂਗ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਨਵਾਂ ਸਕ੍ਰੀਨ ਜੋੜੋ—ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ ਕਿ ਉਹ ਕਿਸ ਫੋਲਡਰ ਵਿੱਚ ਹੋਵੇਗਾ।\n\n### 2) ਨਾਮਕਰਨ ਰਿਵਾਇਤਾਂ\n\nਨਾਮਕਰਨ ਨਿਯਮ ਇਸ ਗੱਲ ਦੀ ਲੋੜ ਘਟਾਉਂਦੇ ਹਨ ਕਿ “ਸਾਡੇ controllers X ਵਿੱਚ ਹਨ ਅਤੇ Y ਵਿੱਚ ਵਾਇਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ” ਵਰਗੀਆਂ ਵਿਆਖਿਆਵਾਂ ਕਰਨ ਦੀ। ਇਸ ਤਰ੍ਹਾਂ ਨਾਮ ਹੀ ਰੋਲ ਦਰਸਾਉਂਦੇ ਹਨ।\n\nਆਮ ਉਦਾਹਰਨਾਂ:\n\n- ਪੇਜ/ਕੰਪੋਨੈਂਟ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਦੇ ਨਾਮ ਉੱਤੇ ਜੋ ਉਹ ਰੈਂਡਰ ਕਰਦੇ ਹਨ (ਸਹੀ ਕੇਸਿੰਗ ਨਾਲ)\n- ਟੈਸਟ ਉਹ ਯੂਨਿਟ ਦੇ ਨਾਮ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਹੁੰਦੇ ਹਨ\n- ਫਾਈਲਾਂ ਨੂੰ ਐਕਸਪੋਰਟਾਂ ਨਾਲ ਮੈਚ ਕਰਨਾ ਤਾਂ ਜੋ سرچ ਉਮੀਦ ਮੁਤਾਬਕ ਕੰਮ ਕਰੇ\n\n### 3) ਰਾਊਟਿੰਗ ਅਤੇ URLs\n\nਬਹੁਤ ਸਾਰੇ ਵੈੱਬ ਫਰੇਮਵਰਕ ਫਾਈਲਾਂ ਨੂੰ ਰਾਊਟਾਂ ਨਾਲ ਮੈਪ ਕਰਦੇ ਹਨ (ਜਾਂ ਰਾਊਟਾਂ ਅਨੁਮਾਨ ਲਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ)। ਜੇ ਤੁਸੀਂ ਫਾਇਲਨਾਮ ਤੋਂ URL ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ — ਜਾਂ ਉਲਟ — ਤਾਂ ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਵੱਖਰੀ ਰਾਊਟਿੰਗ ਡੌਕ ਨਹੀਂ ਲਿਖਣ ਦੀ ਲੋੜ ਰਹਿੰਦੀ।\n\nਰਿਵਾਇਤਾ ਡਾਇਨਾਮਿਕ ਰਾਊਟ, ਨੇਸਟਡ ਰਾਊਟ ਅਤੇ 404 ਹੈਂਡਲਿੰਗ ਬਾਰੇ ਉਮੀਦਾਂ ਵੀ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ “ਨਵਾਂ ਐਂਡਪੌਇੰਟ ਕਿਵੇਂ ਜੋੜੀਏ?” ਦਾ ਇੱਕ ਮਿਆਰੀ ਜਵਾਬ ਹੁੰਦਾ ਹੈ।\n\n### 4) ਡੇਟਾ ਐਕਸੈੱਸ ਪੈਟਰਨ\n\nਰਿਵਾਇਤਾਂ ਅਕਸਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ ਕਿ "ਡੇਟਾ ਕੋਡ" ਕਿੱਥੇ ਰਹੇਗਾ: ਮਾਡਲ, ਰਿਪੋਜ਼ਟਰੀ, ਸੇਵਾ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਸਕੀਮਾ ਫਾਇਲਾਂ। ਭਾਵੇਂ ਐਪ ਛੋਟੀ ਹੋਵੇ, ਡੇਟਾ ਐਕਸੈੱਸ ਲਈ ਇਕ ਮਨਜ਼ੂਰ ਕੀਤਾ ਘਰ ਹੋਣ ਨਾਲ UI ਕੋਡ ਵਿੱਚ ਬੇ-ਤਰਤੀਬ ਡੀਟਾਬੇਸ ਕਾਲਾਂ ਫੈਲਣ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ।\n\n### 5) ਆਮ ਸਕ੍ਰਿਪਟ ਅਤੇ ਕਮਾਂਡ\n\nਸਟੈਂਡਰਡ ਕਮਾਂਡ (run, test, build, lint, format) ਭੁੱਲਣ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਨਵਾਂ ਡਿਵੈਲਪਰ ਇੱਕ ਵਿਕੀ ਪੇਜ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਚਲਾਉਣ ਲਈ obvious ਕਦਮ ਲੈ ਸਕੇ—npm test (ਜਾਂ ਸਮਾਨ) ਹੀ ਆਮ ਤੌਰ ਤੇ ਸਪੱਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।\n\nਜਦੋਂ ਇਹ ਪੰਜ ਖੇਤਰ ਇਕਸਾਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕੋਡਬੇਸ ਖੁਦ ਵੱਧਤਰ "ਇਥੇ ਕੰਮ ਕਿਵੇਂ ਹੁੰਦਾ" ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਦਿੰਦਾ ਹੈ।\n\n## ਰਿਵਾਇਤਾਂ ਕਿਵੇਂ ਕੋਡਬੇਸ ਨੂੰ ਇੱਕ ਨਕਸ਼ੇ ਵਾਂਗ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ\n\n"ਹਰ ਚੀਜ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ" ਵਾਲੀ ਵਿਕੀ ਆਮ ਤੌਰ 'ਤੇ ਸਮੂਹ ਨੂੰ ਪ੍ਰੋਜ਼ ਵਿੱਚ ਵੇਰਵਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਇਹ ਅਕਸਰ ਸ਼ੁਰੂ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ, ਫਿਰ ਫੋਲਡਰਾਂ ਦੇ ਛੱਲਣ, ਨਾਮਾਂ ਦੇ ਬਦਲਣ ਅਤੇ ਨਵੇਂ ਫੀਚਰਾਂ ਦੇ ਆਉਣ ਨਾਲ out-of-date ਹੋ ਜਾਂਦੀ ਹੈ। ਰਿਵਾਇਤਾਂ ਇਸ ਵਿਚਾਰ ਨੂੰ ਉਲਟ ਕਰਦੀਆਂ ਹਨ: ਲੰਮੇ ਵੇਰਵੇ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਬਜਾਇ ਤੁਸੀਂ ਢਾਂਚੇ ਨੂੰ ਪੜ੍ਹਦੇ ਹੋ।\n\n### ਪੇਸ਼ਗੋਈਯੋਗ ਥਾਵਾਂ ਦਿਸ਼ਾ ਜਾਣਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ\n\nਜਦੋਂ ਫਰੇਮਵਰਕ (ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ) ਇਹ ਤੈਅ ਕਰ ਲੈਂਦੀ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਰੈਪੋਜ਼ਟਰੀ ਇੱਕ ਸਿਟੀ ਗ੍ਰਿਡ ਵਾਂਗ ਨੈਵੀਗੇਬਲ ਬਣ ਜਾਂਦਾ ਹੈ।\n\nਜੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ UI ਕੰਪੋਨੈਂਟ components/ ਵਿੱਚ ਜਾਂਦੇ ਹਨ, ਪੇਜ-ਲੇਵਲ ਵਿਊ pages/ ਵਿੱਚ ਜਾਂਦੇ ਹਨ, ਅਤੇ API ਹੈਂਡਲਰ api/ ਵਿੱਚ ਹਨ, ਤਾਂ ਤੁਸੀਂ “X ਕਿੱਥੇ ਹੈ?” ਦਾ ਸਵਾਲ ਪੁੱਛਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਕਿਉਂਕਿ ਪਹਿਲਾ ਅਨੁਮਾਨ ਅਕਸਰ ਸਹੀ ਹੋਵੇਗਾ। ਹੋਰ ਵਾਰੀ ਜਦੋ ਇਹ ਸਹੀ ਨਹੀਂ ਵੀ ਹੁੰਦਾ, ਤੁਹਾਡੀ ਖੋਜ ਸੰਕੁਚਿਤ ਰਹਿੰਦੀ ਹੈ: ਇਹ ਕਿਸੇ ਵੀ ਜਗ੍ਹਾ ਨਹੀਂ—ਇਹ ਕੁਝ ਉਮੀਦ ਕੀਤੀਆਂ ਥਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।\n\n### ਨਾਮ ਸਾਈਨਪੋਸਟ ਵਾਂਗ ਹਨ\n\nਰਿਵਾਇਤਾਂ ਫਾਇਲਨਾਂ ਅਤੇ ਪ੍ਰਤੀਕਾਂ ਨੂੰ ਮਤਲਬ ਭਰ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਨਵਾਂ ਆਇਆ ਵਿਅਕਤੀ ਸਥਿਤੀ ਅਤੇ ਨਾਮ ਤੋਂ ਕੰਮ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾ ਸਕਦਾ ਹੈ:\n\n- user.controller ਵਾਲੀ ਫਾਇਲ ਸੰਭਵਤ: ਰਿਕਵੇਸਟ ਲੋਜਿਕ ਸੰਭਾਲਦੀ ਹੈ\n- UserService ਕਲਾਸ ਸੰਭਵਤ: ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਨੂੰ ਰੱਖਦੀ ਹੈ\n- migrations/ ਫੋਲਡਰ ਸੰਭਵਤ: ਆਰਡਰਡ, ਇੱਕ-ਵਾਰੀ ਚਲਾਉਣ ਵਾਲੀਆਂ ਡੇਟਾਬੇਸ ਤਬਦੀਲੀਆਂ ਰੱਖਦਾ ਹੈ\n\nਇਹ ਅਨੁਮਾਨ "ਆਰਕੀਟੈਕਚਰ ਸਮਝਾਓ" ਦੇ ਸਵਾਲਾਂ ਨੂੰ ਛੋਟੇ, ਜਵਾਬਯੋਗ ਸਵਾਲਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ("ਕੀ ਇਹ ਸੇਵਾ ਡਾਇਰੈਕਟ ਡੀਬੀ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੀ ਹੈ?"), ਜੋ ਕਿ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਲਈ ਆਸਾਨ ਹਨ।\n\n### ਟੈਮਪਲੇਟ ਨਕਸ਼ਾ ਨੂੰ ਇਕਸਾਰ ਰੱਖਦੇ ਹਨ\n\nਨਕਸ਼ੇ ਨੂੰ ਜ਼ੋਰਦਾਰ ਬਣਾਉਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਸਕੈਫੋਲਡਿੰਗ ਹੈ। ਸਟਾਰਟਰ ਟੈਮਪਲੇਟ ਅਤੇ ਜੈਨਰੇਟਰ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ “ਸਹੀ” ਆਕਾਰ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹਨ—ਫੋਲਡਰ, ਫਾਇਲਨਾਮ, ਬੋਇਲਰਪਲੇਟ ਵਾਇਰਿੰਗ ਅਤੇ ਅਕਸਰ ਟੈਸਟ ਵੀ।\n\nਇਹ ਮਾਮਲਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਰਿਵਾਇਤਾਂ ਸਿਰਫ਼ ਤਦ ਹੀ ਮਦਦ ਕਰਦੀਆਂ ਹਨ ਜਦ ਉਹ ਲਗਾਤਾਰ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਟੈਮਪਲੇਟ ਇੱਕ ਗਾਰਡਰੇਲ ਹੈ: ਇਹ ਹਰ ਨਵੀਂ ਰੂਟ, ਕੰਪੋਨੈਂਟ ਜਾਂ ਮੋਡੀਊਲ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਸੰਰਚਨਾ ਵਿੱਚ ਧੱਕਦਾ ਹੈ, ਤਾਂ ਜੋ ਕੋਡਬੇਸ ਰੀਡੇਬਲ ਰਹੇ ਬਿਨਾਂ ਵਾਧੂ ਵਿਕੀ ਪੰਨਿਆਂ ਦੇ।\n\nਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਸਕੈਫੋਲਡਸ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਓਨਬੋਰਡਿੰਗ ਪੇਜ ਤੋਂ ਲਿੰਕ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, /docs/getting-started) ਤੇ ਫੋਲਡਰ ਟ੍ਰੀ ਨੂੰ ਬਾਕੀ ਕੰਮ ਕਰਨ ਦਿਓ।\n\n## “ਗੁਪਤ ਦਸਤਾਵੇਜ਼” ਦੇ ਅਸਲੀ ਦੁਨੀਆ ਉਦਾਹਰਨ\n\nਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਅਕਸਰ ਚੁੱਪ-ਚਾਪ, ਅੰਦਰੂਨੀ ਹਦਾਇਤਾਂ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। "ਕਿੱਥੇ ਚੀਜ਼ਾਂ ਰੱਖਣੀਆਂ ਹਨ" ਜਾਂ "ਇਸਨੂੰ ਕਿਵੇਂ ਵਾਇਰ ਕਰਨਾ ਹੈ" ਬਾਰੇ ਵੱਖਰਾ ਪੰਨਾ ਲਿਖਣ ਦੀ ਥਾਂ, ਫਰੇਮਵਰਕ ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰ ਚੁੱਕਿਆ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਤੁਸੀਂ ਸੰਰਚਨਾ ਨੂੰ ਪੜ੍ਹ ਕੇ ਸਿੱਖ ਲੈਂਦੇ ਹੋ।\n\n### Ruby on Rails: “ਇਥੇ ਰੱਖੋ ਤੇ ਕੰਮ ਕਰੇਗਾ”\n\nRails "convention over configuration" ਲਈ ਮਸ਼ਹੂਰ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ OrdersController ਨਾਮ ਦਾ controller ਬਣਾਉਂਦੇ ਹੋ, Rails ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਮਿਲਦਾ-ਜੁਲਦਾ view ਫੋਲਡਰ app/views/orders/ ਤੇ ਹੋਵੇਗਾ।\n\nਇਹ ਇਕ convention ਉਹਨਾਂ ਡੌਕਸ ਦੇ ਟੁਕੜਿਆਂ ਦੀ ਥਾਂ ਲੈ ਸਕਦੀ ਹੈ ਜੋ ਬਿਆਨ ਕਰਦੀਆਂ ਕਿ:\n\n- HTML ਟੈਮਪਲੇਟ ਕਿੱਥੇ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ\n- ਕਿਸ URL ਤੇ ਕਿਹੜਾ controller action ਮਿਲਦਾ ਹੈ\n- controller ਕਿਵੇਂ ਮਿਲਦੇ template ਨੂੰ ਚੁਣਦਾ ਹੈ\n\nਨਤੀਜਾ: ਨਵੇਂ ਸਾਥੀ ਫੋਲਡਰ ਪੈਟਰਨ ਨੂੰ ਫਾਲੋ ਕਰਕੇ ਇੱਕ ਪੇਜ਼ ਜੋੜ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਪੁੱਛੇ "ਇਹ ਫਾਇਲ ਕਿੱਥੇ ਰੱਖਨੀ ਹੈ?"\n\n### Django: ਆਮ ਕੰਮਾਂ ਲਈ ਪੇਸ਼ਗੋਈਯੋਗ ਢਾਂਚਾ\n\nDjango ਇੱਕ ਇਕਸਾਰ "app" ਢਾਂਚਾ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ Django app ਵੇਖਦਾ ਹੈ, ਉਹ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ models.py ਡੇਟਾ ਰੂਪ ਦੇ ਲਈ ਹੋਵੇਗਾ, views.py ਰਿਕQUEST ਹੈਂਡਲਿੰਗ ਲਈ, ਅਤੇ templates/ HTML ਲਈ।\n\nਤੁਸੀਂ ਲੰਬਾ ਗਾਈਡ ਲਿਖ ਸਕਦੇ ਹੋ ਜੋ ਪ੍ਰੋਜੈਕਟ ਦੀ ਬਨਾਵਟ ਬਾਰੇ ਦੱਸੇ, ਪਰ Django ਦੇ ਡਿਫਾਲਟ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਿਖਾਉਂਦੇ ਹਨ। ਜਦ ਕੋਈ ਸਾਥੀ ਪੇਜ਼ ਦੇ ਰੂਪ ਨੂੰ ਬਦਲਣਾ ਚਾਹੇ, ਉਹ templates/ ਵਿੱਚ ਵੇਖਣਗੇ। ਜਦ ਉਹ ਸਟੋਰਡ ਡੇਟਾ ਨੂੰ ਸੋਧਣਾ ਚਾਹੇ, ਉਹ models.py ਨੂੰ ਦੇਖਦੇ ਹਨ।\n\nਨਤੀਜਾ: ਤੇਜ਼ ਫਿਕਸ, ਘੱਟ ਖੋਜ ਦਾ ਸਮਾਂ, ਘੱਟ "ਕਿਹੜੀ ਫਾਇਲ ਇਸਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ?" ਵਾਲੀਆਂ ਪੁੱਛਗੀਆਂ।\n\n### Next.js: ਰਾਊਟਿੰਗ ਬਿਨਾਂ ਰਾਊਟਿੰਗ ਮੈਨੁਅਲ ਦੇ\n\nNext.js ਡੌਕਸ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਰਾਊਟਿੰਗ ਤੁਹਾਡੇ ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ ਦੀ ਸਿੱਧੀ ਪ੍ਰਤੀਬਿੰਬ ਹੋ ਜਾਂਦੀ ਹੈ। app/about/page.tsx (ਜਾਂ ਪੁਰਾਣੇ ਸੈਟਅਪ ਵਿੱਚ pages/about.tsx) ਵਿੱਚ ਫਾਇਲ ਬਣਾਉ—ਅਤੇ ਤੁਹਾਨੂੰ ਆਪਣੀ ਆਪ /about ਪੇਜ ਮਿਲ ਜਾਂਦੀ ਹੈ।\n\nਇਸ ਨਾਲ ਉਹ ਸਭ ਡੌਕਸ ਲੋੜੀਂਦੇ ਨਹੀਂ ਰਹਿੰਦੇ ਜੋ ਸਮਝਾਉਂਦੇ ਹਨ:\n\n- ਰਾਊਟਾਂ ਨੂੰ ਕਿਵੇਂ ਰਜਿਸਟਰ ਕਰਨਾ ਹੈ\n- ਰਾਊਟਾਂ ਨੂੰ ਲਗਾਤਾਰ ਕਿਵੇਂ ਨਾਮ ਦੇਣਾ ਹੈ\n- ਨਵਾਂ ਪੇਜ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ ਬਿਨਾਂ ਨੈਵੀਗੇਸ਼ਨ ਖਰਾਬ ਕੀਤੇ\n\nਨਤੀਜਾ: ਓਨਬੋਰਡਿੰਗ ਸਧਾਰਨ—ਲੋਕ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਸਕੈਨ ਕਰਕੇ ਵੈਬਸਾਇਟ ਦੀ ਰੂਪ-ਰੇਖਾ ਪਤਾ ਲਗਾ ਲੈਂਦੇ ਹਨ।\n\n### ਅਲੱਗ-ਅਲੱਗ ਇਕੋ ਖਿਆਲ, ਵੱਖ-ਵੱਖ ਪਰਿਬੇਸ਼\n\nRails, Django ਅਤੇ Next.js ਵੱਖਰੇ ਲਗਦੇ ਹਨ, ਪਰ ਮੂਲ ਸਿਧਾਂਤ ਇਕੋ ਹੀ ਹੈ: ਸਾਂਝੇ ਡਿਫਾਲਟ ਪ੍ਰੋਜੈਕਟ ਸੰਰਚਨਾ ਨੂੰ ਹਦਾਇਤਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਹਰ ਕੋਈ ਇੱਕੋ ਹੀ ਰਿਵਾਇਤ ਵਿੱਚ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਕੋਡਬੇਸ ਅਕਸਰ "ਕਿਵੇਂ ਅਸੀਂ ਇਹ ਇੱਥੇ ਕਰਦੇ ਹਾਂ" ਵਾਲੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਦਿੰਦਾ ਹੈ—ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ ਦਸਤਾਵੇਜ਼ ਦੇ।\n\n## ਜਦੋਂ ਰਿਵਾਇਤਾਂ ਟੁੱਟਦੀਆਂ ਹਨ (ਅਤੇ ਮੁੜ ਤੋਂ ਗੜਬੜ ਆਉਂਦੀ ਹੈ)\n\nਜਦੋਂ ਰਿਵਾਇਤਾਂ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਉਹ "ਅਦਿੱਖ" ਦੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਫਾਇਲਾਂ ਕਿੱਥੇ ਹਨ, ਚੀਜ਼ਾਂ ਨੂੰ ਕੀ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਗੁਜ਼ਾਰਸ਼ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ। ਗੜਬੜ ਉਹਦੋਂ ਵਾਪਸ ਆਉਂਦੀ ਹੈ ਜਦੋ ਕੋਡਬੇਸ ਉਹਨਾਂ ਸਾਂਝੇ ਡਿਫਾਲਟਾਂ ਤੋਂ ਹੱਟ ਜਾਂਦਾ ਹੈ।\n\n### ਤੁਹਾਡੇ ਰਿਵਾਇਤਾਂ ਘਟ ਰਹੇ ਹਨ ਇਹਦੇ ਨਿਸ਼ਾਨ\n\nਕਈ ਪੈਟਰਨ ਸ਼ੁਰੂ ਵਿੱਚ ਉੱਥੇ ਆਉਂਦੇ ਹਨ:\n\n- ਬਹੁਤ ਸਾਰੇ ਕਸਟਮ ਫੋਲਡਰ ਜੋ ਫਰੇਮਵਰਕ ਦੀ ਆਮ ਸੰਰਚਨਾ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ (ਉਦਾਹਰਨ ਲਈ, ਹਰ ਫੀਚਰ ਲਈ ਨਵੇਂ ਟੌਪ-ਲੈਵਲ ਡਾਇਰੈਕਟਰੀਆਂ)\n- ਅਸੰਕਲਿਸ਼ਟ ਨਾਮਕਰਨ: ਇੱਕ ਹਿੱਸਾ UserService ਵਰਤਦਾ, ਦੂਜਾ UsersManager, ਤੀਜਾ user_service\n- ਐਡ-ਹੌਕ ਪੈਟਰਨ ਜੋ ਸਕ੍ਰੀਨ ਤੋਂ ਸਕ੍ਰੀਨ ਜਾਂ ਐਂਡਪੌਇੰਟ ਤੋਂ ਐਂਡਪੌਇੰਟ ਬਦਲ ਰਹੇ ਹਨ ("ਅਸੀਂ ਇੱਥੇ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕੀਤਾ ਕਿਉਂਕਿ…") ਬਿਨਾਂ ਕਿਸੇ ਸਥਿਰ ਗਾਈਡਲਾਈਨ ਦੇ\n\nਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਆਪਣੇ ਆਪ ਗਲਤ ਨਹੀਂ—ਪਰ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਨਵਾਂ ਸਾਥੀ ਹੁਣ ਫਰੇਮਵਰਕ ਦੇ "ਨਕਸ਼ੇ" 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।\n\n### ਕਿਵੇਂ "ਸਿਰਫ ਇੱਕ ਛੂਟ" ਬਹੁਤ ਸਾਰੀਆਂ ਬਣ ਜਾਂਦੀ ਹੈ\n\nਜ਼ਿਆਦਾਤਰ ਰਿਵਾਇਤ ਟੁੱਟਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਇੱਕ ਵਾਜਬ ਸਥਾਨਕ ਅਨੁਕੂਲਤਾ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: "ਇਹ ਫੀਚਰ ਖਾਸ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਇੱਥੇ ਰੱਖਾਂਗੇ" ਜਾਂ "ਇਹ ਨਾਮ ਵਧੀਆ ਲੱਗਦਾ ਹੈ"। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਛੂਟ ਸੰਕਰਮਕ ਹੁੰਦੀਆਂ ਹਨ। ਜਿਵੇਂ-ਜਿਵੇਂ ਪਹਿਲੀ ਛੂਟ ਚੱਲਦੀ ਹੈ, ਅਗਲਾ ਡਿਵੈਲਪਰ ਇਸਨੂੰ ਪ੍ਰੇਸਿਡੈਂਟ ਵਜੋਂ ਵਰਤਦਾ ਹੈ:\n\n- ਦੂਜਾ ਫੀਚਰ ਕਸਟਮ ਫੋਲਡਰ ਨੂੰ ਕਾਪੀ ਕਰ ਲੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਹੈ\n- ਤੀਜਾ ਫੀਚਰ ਇਸਨੂੰ ਥੋੜ੍ਹਾ ਬਦਲ ਕੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੂਜੇ ਨਾਲ ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਹੋਇਆ\n- ਜਲਦੀ ਹੀ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕੋ ਹੀ ਕੰਮ ਦੇ ਤਿੰਨ “ਕਬੂਲਯੋਗ” ਤਰੀਕੇ ਹੋ ਜਾਂਦੇ ਹਨ\n\nਉਸ ਸਮੇਂ, ਰਿਵਾਇਤ ਰਿਵਾਇਤ ਨਹੀਂ ਰਹਿੰਦੀ—ਇਹ ਟ੍ਰਾਈਬਲ ਨੋਲੇਜ ਬਣ ਜਾਂਦੀ ਹੈ।\n\n### ਅਸਲੀ ਲਾਗਤ: ਸਮਾਂ, ਗਲਤੀਆਂ, ਤੇ ਬੈਠਕਾਂ\n\nਜਦੋਂ ਰਿਵਾਇਤਾਂ ਧੁੰਦਲੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਓਨਬੋਰਡਿੰਗ ਸਲੋ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਕੰਮ ਲੰਬੇ ਹੋ ਜਾਂਦੇ ਹਨ ("ਇਨ੍ਹਾਂ ਫੋਲਡਰਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਅਸਲ ਵਾਲਾ ਹੈ?"), ਅਤੇ ਗਲਤੀਆਂ ਵੱਧਦੀਆਂ ਹਨ (ਗਲਤ ਮੋਡੀਊਲ ਵਾਇਰ ਕਰਨਾ, ਗਲਤ ਨਾਮਕਰਨ ਵਰਤਣਾ, ਲਾਜਿਕ ਡੁਪਲੀਕੇਟ ਕਰਨਾ)। ਟੀਮ ਇਸਦਾ ਮੁਕਾਬਲਾ ਵੱਧ syncs, ਲੰਬੇ PR ਵਰਨਣਾਂ, ਅਤੇ "ਕੁਇੱਕ ਡੌਕਸ" ਜੋ ਠੰਢੇ ਹੋ ਜਾਂਦੇ ਹਨ ਲਿਖਣ ਦੁਆਰਾ ਕਰਦੀ ਹੈ।\n\n### ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਸਪਸ਼ਟਤਾ ਰੱਖਣ ਲਈ\n\nਕੇਵਲ ਉਸ ਸਮੇਂ ਕਸਟਮਾਈਜ਼ ਕਰੋ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਪੱਸ਼ਟ ਕਾਰਨ ਹੋ—ਅਤੇ ਬਦਲੇ ਹੋਏ ਨਿਰਦੇਸ਼ ਦੀ ਇਕ ਲਿਖਤੀ ਨੋਟ ਛੱਡੋ।\n\nਉਹ ਨੋਟ ਹਲਕੀ ਹੋ ਸਕਦੀ ਹੈ: ਅਸਧਾਰਣ ਸੰਰਚਨਾ ਨਜ਼ਦੀਕ ਇੱਕ ਛੋਟਾ ਟਿੱਪਣੀ, ਜਾਂ /docs/decisions ਪੇਜ ਵਿੱਚ ਇੱਕ ਸੰਖੇਪ ਦਰਜ।\n\n## ਤੁਹਾਨੂੰ ਹਾਲੇ ਵੀ ਕੀ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਛੂਟਾਂ\n\nਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਕਈ ਪੰਨੇ ਦੀ ਵਿਆਖਿਆ ਹਟਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ। ਜੋ ਹਿੱਸੇ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ जान-ਬੂਝ ਕੇ ਫਰੇਮਵਰਕ ਦੀ ਉਮੀਦ ਤੋਂ ਵੱਖ ਹਨ, ਉਹ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਯੋਗ ਹਨ।\n\n### ਫੈਸਲੇ ਦਰਜ ਕਰੋ, ਬੁਨਿਆਦੀਆਂ ਨਹੀਂ\n\nਸਟੈਂਡਰਡ ਫਰੇਮਵਰਕ ਵਿਹਾਰ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਸ ਦੀ ਥਾਂ, ਉਹ ਫੈਸਲੇ ਸੰਭਾਲੋ ਜੋ ਦਿਨ-ਬ-ਦਿਨ ਕੰਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ:\n\n- ਤੁਸੀਂ ਕੀ ਚੁਣਿਆ (ਅਤੇ ਕੀ ਨਹੀਂ)\n- ਕੀ ਬਦਲਿਆ (ਅਤੇ ਕਦੋਂ)\n- ਕਿਉਂ ਬਦਲਿਆ (ਟਰੇਡ-ਆਫ਼, ਪਾਬੰਦੀਆਂ, ਘਟਨਾ-ਜਾਂਚੀ ਮੰਗਾਂ)

ਉਦਾਹਰਨ: “ਅਸੀਂ /src/features ਹੇਠਾਂ ਫੀਚਰ ਫੋਲਡਰ ਵਰਤਦੇ ਹਾਂ ਬਜਾਏ ਲੇਅਰ ਫੋਲਡਰਾਂ (/src/components, /src/services) ਦੇ—ਕਿਉਂਕਿ ਇਸ ਨਾਲ ownership ਟੀਮਾਂ ਨੂੰ ਨਕਸ਼ੇ ਵਿੱਚ ਮੈਪ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕ੍ਰਾਸ-ਟੀਮ coupling ਘਟਦਾ ਹੈ।” ਇਹ ਇਕ ਸਟੇਟਮੈਂਟ ਹਫ਼ਤਿਆਂ ਦੀ ਧੀਮੀ ਪ੍ਰਗਤੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।\n\n### ਕੋਡ ਦੇ ਨੇੜੇ ਛੋਟੀ “Exception Notes” ਛੱਡੋ\n\nਜਦ ਕੋਈ ਛੂਟ ਲੋਕਲ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਕ ਹੋਵੇ, ਨੋਟ ਨੂੰ ਉਥੇ ਰੱਖੋ। ਫੋਲਡਰ ਦੇ ਅੰਦਰ ਇੱਕ ਛੋਟਾ ਜਾਂ ਫਾਇਲ ਦੀ ਸ਼ੀਰਸ਼ਕ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਟਿੱਪਣੀ ਅਕਸਰ ਕੇਂਦਰੀ ਵਿਕੀ ਨਾਲੋਂ ਵਧੀਆ ਹੈ।\n\nਚੰਗੇ ਉਮੀਦਵਾਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:\n\n- ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਜੋ ਤਰਤੀਬ ਨੂੰ ਤੋੜਦੀ ਹੈ ਅਤੇ ਜਿਸਦਾ ਕਾਰਨ ਹੈ\n- ਇੱਕ ਮੋਡੀਊਲ ਜੋ ਅਸਧਾਰਣ ਕਰਮ-ਕ੍ਰਮ ਵਿੱਚ ਇਨਿਸ਼ੀਅਲਾਈਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ\n- ਇੱਕ ਨਾਮਕਰਨ ਨਿਯਮ ਜੋ ਬਿਨਾਂ ਸੀਮਾ ਜਾਣੇ "ਗਲਤ" ਲੱਗਦਾ ਹੈ\n\nਇਨ੍ਹਾਂ ਨੋਟਾਂ ਨੂੰ ਛੋଟੇ ਅਤੇ ਕਾਰਵਾਈ ਯੋਗ ਰੱਖੋ: ਕੀ ਵੱਖਰਾ ਹੈ, ਕਿਉਂ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ।\n\n### ਇਕ ਛੋਟਾ “Project Rules” ਪੇਜ ਬਣਾਓ\n\nਇਕ ਹਲਕੀ ਸਰਦਾਰ ਪੇਜ ਰੱਖੋ (ਅਕਸਰ ਜਾਂ ਰੂਟ ) ਜਿਸ ਵਿੱਚ ਸਿਰਫ ਉਹ 5–10 ਮੁੱਖ ਚੋਣਾਂ ਦੀ ਸੂਚੀ ਹੋਵੇ ਜਿਹੜੀਆਂ ਲੋਕਾਂ ਨੂੰ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ:\n\n- ਉਹ ਨਾਮਕਰਨ ਰਿਵਾਇਤਾਂ ਜੋ ਫਰੇਮਵਰਕ ਡਿਫਾਲਟ ਤੋਂ ਵੱਖ ਹਨ\n- ਉਮੀਦ ਕੀਤਾ ਪ੍ਰੋਜੈਕਟ ਸਟ੍ਰਕਚਰ (ਸਿਰਫ ਜਿੱਥੇ ਵੱਖਰਾ ਹੋਵੇ)\n- ਨਵੀਂ ਫੀਚਰ ਜਾਂ ਐਂਡਪੌਇੰਟ ਜੋੜਨ ਲਈ "ਗੋਲਡਨ ਪਾਥ"

ਇਹ ਕੋਈ ਪੂਰਾ ਮੈਨੂਅਲ ਨਹੀਂ—ਸਿਰਫ ਸਾਂਝੇ ਗਾਰਡਰੇਲਜ਼।\n\n### ਕਿਵੇਂ ਚਲਾਉਣ ਅਤੇ ਟੈਸਟ ਕਰਨ ਲਈ Quickstart\n\nਰਿਵਾਇਤਾਂ ਦੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਓਨਬੋਰਡਿੰਗ ਰੁਕ ਜਾਂਦੀ ਹੈ ਜਦ ਲੋਕ ਐਪ ਨੂੰ ਚਲਾ ਨਹੀਂ ਸਕਦੇ। ਇੱਕ ਛੋਟਾ "How to run/test" ਸੈਕਸ਼ਨ ਜੋ ਸਟੈਂਡਰਡ ਕਮਾਂਡਾਂ ਅਤੇ ਤੁਹਾਡੇ ਅਸਲ ਸੈਟਅਪ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ ਸ਼ਾਮਲ ਕਰੋ।\n\nਜੇਕਰ ਕਨਵੈਂਸ਼ਨਲ ਕਮਾਂਡ ਹੈ ਪਰ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਇਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ।\n\n### ਕੋਡ ਰਿਵਿਊਜ਼ ਰਾਹੀਂ ਡੌਕਸ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖੋ\n\nਜਦੋਂ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਬਦਲਣਾ ਹੋਵੇ ਤਾਂ ਇਹ ਅਮਲ ਰਿਵਿਊ ਦਾ ਹਿੱਸਾ ਬਣਾਓ। ਪ੍ਰੀ-ਰਿਵਿਊ ਵਿੱਚ ਪੁੱਛੋ: "ਕੀ ਇਸ ਨੇ ਨਵੀਂ ਛੂਟ ਪੈਦਾ ਕੀਤੀ?" ਜੇ ਹਾਂ, ਤਾਂ ਇੱਕ ਲੋکل README, Project Rules, ਜਾਂ ਰੂਟ Quickstart ਵਿੱਚ ਹੀ ਉਹ ਨੋਟ ਲਗਾਓ ਅਤੇ ਇਹ ਬਦਲਾਅ ਉਸੇ PR ਵਿੱਚ ਮੰਗੋ।\n\n## ਡੌਕਸ ਘਟਾਉਣ ਲਈ ਆਟੋਮੇਸ਼ਨ ਨਾਲ ਰਿਵਾਇਤਾਂ ਲਾਗੂ ਕਰੋ\n\nਜੇ ਰਿਵਾਇਤਾਂ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਦੇ "ਡਿਫਾਲਟ" ਹਨ, ਤਾਂ ਆਟੋਮੇਸ਼ਨ ਉਹਨਾਂ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦੀ ਹੈ। ਵੀਕਿ ਯਾਦ ਰਹਿਣ ਦੀ ਬਜਾਇ, ਨਿਯਮਾਂ ਨੂੰ ਏਕਜ਼ੀਕਿਊਟੇਬਲ ਬਣਾਉ ਤਾਂ ਟੀਮ ਆਪਣੀ-ਆਪ ਹੀ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲੱਗਦੀ ਹੈ।\n\n### ਆਟੋਮੈਟਿਕ ਚੈੱਕ ਜੋ ਟੀਮਾਂ ਨੂੰ ਇਕਸਾਰ ਰੱਖਦੇ ਹਨ\n\nਚੰਗੀ ਸੈਟਅੱਪ ਮੁੜ-ਡ੍ਰਿਫਟ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਅਤੇ ਸ਼ਾਂਤ ਤਰੀਕੇ ਨਾਲ ਫੜ ਲੈਂਦੀ ਹੈ:\n\n- ਸੇਵ 'ਤੇ ਆਟੋ-ਫਾਰਮੈਟ ਅਤੇ CI ਵਿੱਚ (ਉਦਾਹਰਨ: Prettier, gofmt, black) ਤਾਂ ਜੋ ਸਟਾਇਲ ਦੀਆਂ ਚਰਚਾਵਾਂ ਖਤਮ ਹੋ ਜਾਣ\n- ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਨਾਮਕਰਨ ਰਿਵਾਇਤਾਂ ਰੋਕਣ ਲਈ (ਉਦਾਹਰਨ: React hooks rules, unused imports, “no default export” ਜੇ ਇਹ ਤੁਹਾਡਾ ਮਿਆਰ ਹੈ)\n- , ਵਰਗੇ ਪੈਟਰਨ ਲਾਗੂ ਕਰਨ ਲਈ ਤਾਂ ਕਿ ਟੈਸਟ ਇੱਕਸਾਰ ਪੜ੍ਹੇ ਜਾਣ\n- ਇੰਪੋਰਟਾਂ ਨੂੰ ਰੋਕੋ ਜੋ ਤੁਹਾਡੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਉੱਲੰਘਣਾ ਕਰਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ: "features ਹੋਰ features ਤੋਂ import ਨਹੀਂ ਕਰ ਸਕਦੇ", ਜਾਂ "UI server ਕੋਡ import ਨਾ ਕਰੇ")। ESLint ਨਿਯਮ, TypeScript ਪਾਥ ਰਿਸਟ੍ਰਿਕਸ਼ਨ ਜਾਂ ਕਸਟਮ ਸਕ੍ਰਿਪਟ ਇਹ ਕਰ ਸਕਦੇ ਹਨ।\n\nਇਹ ਚੈੱਕ ਪੈਰਾਗ੍ਰਾਫ "ਕਿਰਪਾ ਕਰਕੇ ਯਾਦ ਰੱਖੋ" ਦੀ ਥਾਂ ਨਤੀਜਾ ਦਿੰਦੇ ਹਨ: ਕੋਡ ਜਾਂ ਤਾਂ ਰਿਵਾਇਤ ਨੂੰ ਮੰਨਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।\n\n### ਫੇਲਿੰਗ ਫੈਸਟ: ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਦੇ پکੜੋ\n\nਆਟੋਮੇਸ਼ਨ ਚਮਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਫੇਲ ਤੁਰੰਤ ਕਰਦਾ ਹੈ:\n\n- ਸਮੱਸਿਆਵਾਂ ਜਾਂ ਭਿੱਟੀਆਂ ਵੇਲੇ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਹਫ਼ਤਿਆਂ ਬਾਅਦ\n- ਰਿਵਿਊਅਰਾਂ ਦਾ ਸਮਾਂ ਸਟਾਇਲ ਨੂੰ ਤੁਰੰਤ ਠੀਕ ਕਰਨ ਨਾਲ ਘਟਦਾ ਹੈ ਅਤੇ ਉਹ ਪ੍ਰੋਡਕਟ ਲੌਜਿਕ ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ\n- ਨਵੇਂ ਭਰਤੀ ਹੋਏ ਲੋਕ ਨਿਯਮਾਂ ਨੂੰ ਸਪਸ਼ਟ, ਇਕਸਾਰ errors ਦੇਖ ਕੇ ਸਿੱਖਦੇ ਹਨ\n\n### ਨਿਯਮਾਂ ਨੂੰ ਘੱਟ-ਅਤੇ-ਮਤਦਾਰ ਰੱਖੋ—ਅਤੇ ਫਰੇਮਵਰਕ ਨਾਲ ਨਾਲ\n\nਚੰਗੇ ਨਿਯਮ ਛੋਟੇ ਅਤੇ ਸੁਸਤ ਹੁੰਦੇ ਹਨ। ਫਰੇਮਵਰਕ ਦੇ ਡਿਫਾਲਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਕੇਵਲ ਉਹ ਜੋ ਸਪਸ਼ਟਤਾ ਬਚਾਉਂਦੇ ਹਨ (ਨਾਮਕਰਨ, ਢਾਂਚਾ, ਬਾਉਂਡਰੀਜ਼) ਸ਼ਾਮਲ ਕਰੋ। ਹਰ ਨਵਾਂ ਨਿਯਮ ਇੱਕ ਹੋਰ ਚੀਜ਼ ਹੁੰਦੀ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਸਮਝਣੀ ਪਏਗੀ—ਇਸ ਲਈ ਨਵੀਂ ਜਾਂਚਨੂੰ ਇਕ ਕੋਡ ਲਾਈਨ ਵਾਂਗ treat ਕਰੋ: ਜਦੋਂ ਇਹ ਕਿਸੇ ਮੁੜ-ਆਉਣ ਵਾਲੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰੇ ਤਾਂ ਜੋੜੋ, ਅਤੇ ਜਦੋਂ ਇਹ ਮਦਦ ਨਹੀਂ ਕਰਦੀ ਤਾਂ ਹਟਾਓ।\n\n## ਮਨੁੱਖ-ਪੜ੍ਹਨ ਯੋਗ ਟੈਸਟ: ਜਿਉਂਦਾ ਦਸਤਾਵੇਜ਼\n\nਜਦੋਂ ਕੋਡਬੇਸ ਫਰੇਮਵਰਕ ਰਿਵਾਇਤਾਂ ਦਾ ਪਾਲਣ ਕਰਦਾ ਹੈ, ਟੈਸਟ ਸਿਰਫ਼ "ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ" ਤੋਂ ਵੱਧ ਹੋ ਸਕਦੇ ਹਨ। ਉਹ ਸਾਨੂੰ ਸਿਸਟਮ ਦਾ ਉਦੇਸ਼ ਸਪਸ਼ਟ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੱਸ ਸਕਦੇ ਹਨ, ਰੂਪ ਵਿੱਚ, ਸਮਝਾਉਂਦੇ ਹੋਏ ਕਿ ਸਿਸਟਮ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਬਿਲਕੁਲ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਕੋਲ।\n\n### ਐਸਾ ਟੈਸਟ ਲਿਖੋ ਜੋ ਇਕ ਕਹਾਣੀ ਪੜ੍ਹੇ ਜਿਵੇਂ\n\nਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ: । ਜੇ ਕੋਈ ਟੈਸਟ ਨਾਮ ਸਕਿੰਨ ਕਰਕੇ ਸਮਝ ਆ ਸਕੇ ਕਿ ਸਿਸਟਮ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਦਸਤਾਵੇਜ਼ ਦੀ ਲੋੜ ਘਟਾ ਰਹੇ ਹੋ।\n\nਚੰਗੇ ਟੈਸਟ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਰਿਦਮ ਫੋਲੋ ਕਰਦੇ ਹਨ:\n\n- ਇੱਕ ਵਾਸਤਵਿਕ ਸ਼ੁਰੂਆਤੀ ਹਾਲਤ ਸੈਟ ਕਰੋ\n- ਇੱਕ ਕੰਮ ਕਰੋ\n- ਉਹ ਨਤੀਜਾ ਚੈੱਕ ਕਰੋ ਜੋ ਮਹੱਤਵਪੂਰਕ ਹੈ\n\nਹੋਰ ਵਧੀਆ ਗੱਲ ਇਹ ਹੈ ਕਿ ਨਾਮਕਰਨ user intent ਨੂੰ ਮਿਰਰ ਕਰਦਾ ਹੋਵੇ:\n\n- \n- \n\nਇਹ ਨਾਮ "ਡੌਕਸ" ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਭੁੱਲਣਾ ਮੁੰਕਿਨ ਨਹੀਂ—ਕਿਉਂਕਿ ਫੇਲ ਹੁੰਦੇ ਟੈਸਟ ਗੱਲ ਚੁੱਕਦੇ ਹਨ।\n\n### ਯੂਜ਼ਰ ਫਲੋ ਲਈ ਐਕਸੈਪਟੈਂਸ ਟੈਸਟ\n\nਐਕਸੈਪਟੈਂਸ (ਅਥਵਾ ਫੀਚਰ) ਟੈਸਟ ਉਪਭੋਗਤਾ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਪ੍ਰੋਡਕਟ ਦਾ ਵਰਤਾਰਾ ਦਰਸਾਉਂਦੇ ਹਨ।\n\nਉਦਾਹਰਨ ਬਿਹੇਵੀਅਰ ਜੋ ਇਹ ਟੈਸਟ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹਨ:\n\n- ਇੱਕ ਯੂਜ਼ਰ ਸਾਈਨ ਅੱਪ ਕਰਦਾ, ਈਮੇਲ ਪੁਸ਼ਟੀ ਕਰਦਾ, ਅਤੇ welcome ਪੇਜ 'ਤੇ ਆਉਂਦਾ\n- ਇੱਕ ਐਡਮਿਨ ਛੂਟ ਕੋਡ ਬਣਾਉਂਦਾ ਅਤੇ checkout 'ਤੇ ਉਹ ਲਾਗੂ ਹੁੰਦਾ ਹੈ\n\nਇਹ ਟੈਸਟ ਸਵਾਲ "ਜਦ ਮੈਂ X ਕਰਦਾ/ਕਰਦੀ ਹਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?" ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ—ਅਕਸਰ ਨਵੇਂ ਸਾਥੀ ਲਈ ਪਹਿਲਾ ਪ੍ਰਸ਼ਨ।\n\n### ਯੂਨੀਟ ਟੈਸਟ ਛੋਟੇ ਪਰ ਮਹੱਤਵਪੂਰਨ ਨਿਯਮਾਂ ਲਈ\n\nਯੂਨੀਟ ਟੈਸਟ ਉਨ੍ਹਾਂ ਗੱਲਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਵਿੱਚ ਚਮਕਦੇ ਹਨ ਜੋ “ਛੋਟੇ ਪਰ ਮਹੱਤਵਪੂਰਨ” ਹੁੰਦੀਆਂ ਹਨ:

• rounding ਵਿਹਾਰ
• ਵੈਲੀਡੇਸ਼ਨ ਨਿਯਮ
• ਅਧਿਕਾਰ ਚੈੱਕ
• ਪੇਚੀਦਾ ਐਜ ਕੇਸ (ਟਾਈਮਜ਼ੋਨ, ਲਿਮਿਟ, ਖਾਲੀ ਹਾਲਤ)

ਜਦ ਰਿਵਾਇਤਾਂ ਤੋਂ ਇਹ ਨਿਯਮ ਸਪੱਝ ਨਹੀਂ ਹੁੰਦੇ, ਤਾਂ ਯੂਨੀਟ ਟੈਸਟ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਕੀਮਤੀ ਹਨ।\n\n### ਫਿਕਸਚਰਜ਼ ਅਤੇ ਉਦਾਹਰਣ ਡੇਟਾ ਛੋਟੇ ਅਤੇ ਮਾਇਨੇਿੰਗਫੁਲ ਰੱਖੋ\n\nਸੈਂਪਲ ਡੇਟਾ ਵੀ ਜੀਉਂਦਾ ਦਸਤਾਵੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਛੋਟਾ, ਅਚਛੀ ਤਰ੍ਹਾਂ ਨਾਮਕ ਫਿਕਸਚਰ (ਉਦਾਹਰਨ: ) ਡੋਮੇਨ ਨੂੰ ਇਕ ਪੈਰਾਗ੍ਰਾਫ ਨਾਲੋਂ ਤੇਜ਼ ਸਿਖਾਉਂਦਾ ਹੈ।\n\nਚਾਬੀ ਹੈ ਸੰਯਮ: ਫਿਕਸਚਰ ਨੂੰ ਨਿਊਨਤਮ, ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਇੱਕ գաղափਰ ਨਾਲ ਜੁੜਿਆ ਰੱਖੋ ਤਾਂ ਜੋ ਉਹ ਇਕ ਹੋਰ ਸਿਸਟਮ ਬਣ ਕੇ ਬਣਨ ਨਾ ਪੈਣ।\n\n## ਸਟਾਰਟਰ ਟੈਮਪਲੇਟ: ਰਿਵਾਇਤਾਂ ਫੈਲਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ\n\nਸਟਾਰਟਰ ਟੈਮਪਲੇਟ (ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਪਿੱਛੇ ਜੈਨਰੇਟਰ) "ਇਥੇ ਅਸੀਂ ਕੰਮ ਕਿਵੇ ਕਰਦੇ ਹਾਂ" ਨੂੰ ਅਸਲ ਵਿੱਚ ਲਿਆਂਦੇ ਦੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕੇ ਹਨ। ਹਰ ਟੀਮ ਮੈਂਬਰ ਤੋਂ ਇਹ ਉਮੀਦ ਨਾ ਰੱਖੋ ਕਿ ਉਹ ਸਹੀ ਫੋਲਡਰ, ਸਕ੍ਰਿਪਟ ਅਤੇ ਟੂਲਿੰਗ ਯਾਦ ਰੱਖੇ—ਤੁਸੀਂ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਇੱਕ ਰੈਪੋ ਵਿੱਚ encode ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਸਹੀ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।\n\n### ਟੈਮਪਲੇਟ, ਜੈਨਰੇਟਰ, ਸਟਾਰਟਰ ਕਿੱਟ: ਵੱਖਰੇ ਤੇਜ਼ੀਆਂ, ਇਕੋ ਮਕਸਦ\n\n- ਤੁਹਾਨੂੰ ਨਕਲਯੋਗ ਬੇਸਲਾਈਨ ਦਿੰਦੇ ਹਨ (ਉਦਾਹਰਨ: "ਨਵੀਂ ਸਰਵਿਸ", "ਨਵਾਂ ਫਰੰਟਐਂਡ ਐਪ")।\n- (CLI ਟੂਲ) ਕੁਝ ਸਵਾਲ ਪੁੱਛ ਕੇ ਇਕਸਾਰ ਫਾਇਲਾਂ, ਨਾਮਕਰਨ, ਅਤੇ ਵਾਇਰਿੰਗ ਬਣਾਉਂਦੇ ਹਨ।\n- ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਢਾਂਚੇ ਦੇ ਨਾਲ-ਨਾਲ CI, ਲਿੰਟਿੰਗ, ਟੈਸਟਿੰਗ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਡਿਫਾਲਟ ਵੀ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ।\n\nਤਿੰਨੋ ਡੌਕਮੈਂਟੇਸ਼ਨ ਦੇ ਬਹੁਤ ਰਿਨੇ ਵਾਲੇ ਰਿਸ਼ਤੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਰਿਵਾਇਤਾਂ ਸ਼ੁਰੂਆਤ ਤੋਂ ਹੀ ਕੋਡ ਵਿੱਚ encode ਹੁੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਕਿਸੇ ਵਿਕੀ ਵਿੱਚ ਜੋ drifting ਹੋ ਸਕਦੀ ਹੈ।\n\nਆਮ ਤੌਰ 'ਤੇ ਇੱਥੇ ਉਹ ਟੂਲਜ਼ ਵਰਗੇ ਹਨ ਜੋ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ: — ਜਦੋਂ ਤੁਸੀਂ ਨਵਾਂ React app, Go ਬੈਕਐਂਡ, PostgreSQL ਸਕੀਮਾ ਜਾਂ Flutter 클ਾਇੰਟ generate ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਡਿਫਾਲਟ ਆਉਟਪੁੱਟ ਨੂੰ ਆਪਣੇ ਰਿਵਾਇਤਾਂ ਨਾਲ ਮਿਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਸੋਰਸ ਕੋਡ ਨੂੰ ਆਪਣੇ ਰੈਪੋ ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।\n\n### ਸੈਟਅੱਪ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ ਤਾਂ ਕਿ "ਹਰ ਰੈਪੋ ਵੱਖਰਾ ਨਾ ਹੋਵੇ"\n\nਓਨਬੋਰਡਿੰਗ ਦੌਰਾਨ ਹੋਣ ਵਾਲੀ ਜ਼ਿਆਦਾਤਰ ਗੜਬੜ ਕਾਰੋਬਾਰੀ ਲੌਜਿਕ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇਸ ਬਾਰੇ ਹੁੰਦੀ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ। ਇੱਕ ਚੰਗਾ ਟੈਮਪਲੇਟ ਆਮ ਕੰਮਾਂ ਨੂੰ ਹਰ ਰੈਪੋ ਵਿੱਚ ਇਕੋ ਜਿਹਾ ਬਣਾਉਂਦਾ ਹੈ: ਉਹੀ ਸਕ੍ਰਿਪਟ, ਉਹੀ ਫੋਲਡਰ ਨਾਮ, ਉਹੀ ਚੈੱਕ ਕਮਾਂਡ, ਉਹੀ PR ਉਮੀਦਾਂ।\n\nਜੇ ਤੁਸੀਂ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰੋ, ਤਾਂ ਇਸ 'ਤੇ ਮਿਲੋ:\n\n- ਪੇਸ਼ਗੋਈਯੋਗ ਫੋਲਡਰ (ਉਦਾਹਰਨ: , , ਸਿਰਫ਼ ਛੂਟਾਂ ਲਈ)\n- ਇੱਕ-ਕਮਾਂਡ ਸੈਟਅੱਪ (ਉਦਾਹਰਨ: + )\n- , , ਅਤੇ ਸਕ੍ਰਿਪਟ\n- PR 'ਤੇ ਚੱਲਣ ਵਾਲੀ ਡਿਫਾਲਟ CI ਪਾਈਪਲਾਈਨ\n\n### ਇਕ ਹਲਕਾ "ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ" ਚੈਕਲਿਸਟ\n\nਇਸਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਟੀਮਾਂ ਇਸਨੂੰ ਸਕਿਪ ਨਾ ਕਰਨ:\n\n1. ਫੋਲਡਰ ਢਾਂਚਾ ਅਤੇ ਨਾਮਕਰਨ ਨਿਯਮ\n2. ਇੱਕ-ਕਮਾਂਡ ਸੈਟਅੱਪ (ਉਦਾਹਰਨ: + )\n3. , , ਅਤੇ ਸਕ੍ਰਿਪਟ\n4. PR 'ਤੇ ਚਲਣ ਵਾਲੀ CI\n5. ਬੁਨਿਆਦੀ README: ਮਕਸਦ, prerequisite, ਅਤੇ 3–5 ਕਮਾਂਡ ਜਿਹੜੀਆਂ ਲੋਕਾਂ ਨੂੰ ਚਾਹੀਦੀਆਂ ਹਨ\n\n### ਟੈਮਪਲੇਟ ਨੂੰ ਜਿਵੇਂ-ਉਤਾਰਣਾ: ਉਹ ਸਮੱਸਿਆ ਬਣ ਸਕਦਾ ਹੈ\n\nਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਹੈ ਕਿ ਪੁਰਾਣੇ ਟੈਮਪਲੇਟ ਨੂੰ "ਕਿਉਂਕਿ ਇਹ ਪਿਛਲੇ ਸਾਲ ਚੰਗਾ ਸੀ" ਕਰਕੇ ਨਕਲ ਕੀਤਾ ਜਾਵੇ। ਅਪ-ਟੂ-ਡੇਟ ਨ ਹੋਣ ਵਾਲੇ ਡੀਪੈਂਡੈਂਸੀ, ਲੈਗੇਸੀ ਸਕ੍ਰਿਪਟ, ਜਾਂ ਅਭਿਆਸ ਜਦੋਂ ਸਟਾਰਟਰ ਵਿੱਚ ਹਨ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਦੇ ਹਨ।\n\nਟੈਮਪਲੇਟ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਾਂਗ treat ਕਰੋ: ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਰਿਵਾਇਤਾਂ ਬਦਲਦੀਆਂ ਹਨ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ। (ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ rollback ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ—Koder.ai ਕਰਦਾ ਹੈ—ਤਾਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ starters 'ਤੇ iteration ਲਈ ਵਰਤੋ)।\n\n## ਡੌਕਸ ਘਟਾਉਣ ਬਿਨਾਂ ਸਪਸ਼ਟਤਾ ਘਟਾਏ: ਇੱਕ ਕਾਰਜਕ ਚੈੱਕਲਿਸਟ\n\nਦਸਤਾਵੇਜ਼ ਘਟਾਉਣਾ ਲੋਕਾਂ ਨੂੰ ਅਨੁਮਾਨ ਕਰਨ ਲਈ ਛੱਡਣਾ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਅਰਥ ਹੈ "ਹੈਪੀ ਪਾਥ" ਨੂੰ ਇੰਨਾ ਇਕਸਾਰ ਬਣਾ ਦੇਣਾ ਕਿ ਜਿਆਦਾਤਰ ਸਵਾਲ ਆਪਣੇ-ਆਪ ਹੀ ਹੱਲ ਹੋ ਜਾਣ, ਅਤੇ ਸਿਰਫ਼ ਵਾਕਈ ਅਸਧਾਰਣ ਹਿੱਸੇ ਲਿਖੇ ਜਾਣ।\n\n### 1) ਇੱਕ ਛੋਟੀ ਸਵੈ-ਆਡਿਟ ਕਰੋ (ਅਸਲ ਘਰਾਂਢੀ ਲੱਭੋ)\n\nਉਹ ਥਾਵਾਂ ਲੱਭੋ ਜਿੱਥੇ ਲੋਕ ਲਗਾਤਾਰ ਇੱਕੋ ਹੀ ਸਵਾਲ ਪੁੱਛ ਰਹੇ ਹਨ Slack, PR comments, standups, ਜਾਂ ਓਨਬੋਰਡਿੰਗ ਸੈਸ਼ਨਾਂ ਵਿੱਚ। ਕੁਝ ਪ੍ਰਾਂਪਟ:\n\n- "ਇਹ ਫਾਇਲ ਕਿੱਥੇ ਰਹੇਗੀ?"\n- "ਇਸਨੂੰ ਅਸੀਂ ਕੀ ਨਾਮ ਦਈਏ?"\n- "ਨਵਾਂ ਪੇਜ/ਜੌਬ/ਐਂਡਪੌਇੰਟ ਕਿਵੇਂ ਜੋੜੀਏ?"\n- "ਇਸ ਮੋਡੀਊਲ ਵਿੱਚ ਇਹ ਕੰਮ ਕਿਉਂ ਵੱਖਰਾ ਹੈ?"\n\nਜੇ ਤੁਸੀਂ ਇੱਕੋ ਸਵਾਲ ਦੋ ਵਾਰੀ ਸੁਣਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸੰਭਵਤ: ਨਵੀਂ ਲਿਖਾਈ ਨਹੀਂ—ਇੱਕ ਰਿਵਾਇਤਾ ਦੀ ਲੋੜ ਹੈ।\n\n### 2) ਫੈਸਲਾ ਕਰੋ: ਫਰੇਮਵਰਕ ਡਿਫਾਲਟ ਅਪਣਾਓ, ਜਾਂ ਏਕ ਨਿਰਣਾ16ਹ ਦਸਤਾਵੇਜ਼ ਕਰੋ\n\nਹਰ ਦੋਹਰੇ ਸਵਾਲ ਲਈ ਇਹ ਨਿਰਣਾ ਕਰੋ:

• ਅਸੀਂ ਫਰੇਮਵਰਕ ਨਾਲ ਲੜ ਰਹੇ ਹਾਂ: ਫਰੇਮਵਰਕ ਦੇ ਡਿਫਾਲਟ ਰਿਵਾਇਤਾਂ ਨੂੰ ਵਾਪਸ ਲੈ ਆਓ (ਰਾਊਟਿੰਗ, ਫੋਲਡਰ ਲੇਆਊਟ, ਨਾਮਕਰਨ, ਐਰਰ ਹੈਂਡਲਿੰਗ)। ਡਿਫਾਲਟ ਪਹਿਲਾਂ ਹੀ ecosystem ਦੁਆਰਾ "ਦਸਤਾਵੇਜ਼" ਹੈ।
• ਸਾਡੇ ਕੋਲ ਵੱਖਰਨ ਲਈ ਚੰਗਾ ਕਾਰਨ ਹੈ: ਡੀਵੀਏਸ਼ਨ ਰੱਖੋ, ਪਰ ਇਸਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਵੇਖਣਯੋਗ ਬਣਾਓ।

ਇਕ ਉਪਯੋਗੀ ਨਿਯਮ: ਜੇ ਡੀਵੀਏਸ਼ਨ ਅਸਲ ਸਮਾਂ ਬਚਾਉਂਦੀ ਜਾਂ ਅਸਲ ਜੋਖਮ ਰੋਕਦੀ ਨਹੀਂ, ਤਾਂ ਉਹ ਲਗਾਤਾਰ ਗਲਤਫ਼ੈਰਮੀ ਲਈ ਯੋਗ ਨਹੀਂ ਰਹੇਗੀ।\n\n### 3) ਇਕ ਛੋਟਾ "Conventions & Exceptions" ਪੇਜ ਬਣਾਓ\n\nਇੱਕ ਸਿੰਗਲ ਛੋਟਾ ਪੇਜ ਰੱਖੋ (ਉਦਾਹਰਨ /docs/conventions) ਜਿਸ ਵਿੱਚ ਲਿਖਿਆ ਹੋਵੇ:\n\n- ਉਹ 5–10 ਰਿਵਾਇਤਾਂ ਜੋ ਹਰ ਕੋਈ ਮੰਨੇ\n- ਛੂਟਾਂ ਦੀ ਛੋਟੀ ਸੂਚੀ (ਕਾਰਨ ਅਤੇ ਇਕ ਉਦਾਹਰਨ ਨਾਲ)\n\nਇਸਨੂੰ ਲੋਕਾਂ ਦੇ ਪਹਿਲੇ ਹਫ਼ਤੇ ਵਿਚ ਲੋੜੀਦੇ ਚੀਜ਼ਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖੋ। ਜੇ ਇਹ ਵਧਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇ, ਤਾਂ ਅਕਸਰ ਇਹ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਨੂੰ ਸਧਾਰਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।\n\n### 4) ਕੈਡੈਂਸ ਸੈੱਟ ਕਰੋ: ਰਿਵਾਇਤਾਂ ਨੂੰ ਤਿਮਾਹੀ ਵਿਆਖਿਆ ਕਰੋ\n\nਐਪ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ। ਹਲਕੀ ਤਰ੍ਹਾਂ ਤਿਮਾਹੀ ਸਮੀਖਿਆ ਨਿਰਧਾਰਤ ਕਰੋ:

• ਕਿਹੜੇ ਨਵੇਂ ਪੈਟਰਨ ਆਏ?\n- ਕਿਹੜੀਆਂ ਛੂਟਾਂ "ਨਾਰਮਲ" ਬਣ ਚੁੱਕੀਆਂ ਹਨ (ਅਤੇ ਰਿਵਾਇਤ ਬਣਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ)?\n- ਕਿਹੜੀਆਂ ਰਿਵਾਇਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ (ਅਤੇ ਕਿਉਂ)?\n\n### ਨਤੀਜਾ\n\nਸਥਾਪਿਤ ਡਿਫਾਲਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ, ਅਤੇ ਸਿਰਫ਼ ਜੋ ਵੱਖ ਹੈ ਉਸਨੂੰ ਸਪਸ਼ਟ, ਸੰਖੇਪ ਅਤੇ ਇੱਕ ਹੀ ਜਗ੍ਹਾ ਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ।