DHH ਅਤੇ Rails: ਕਿਵੇਂ ਰਿਵਾਜਾਂ ਨੇ ਵੈੱਬ ਐਪਸ ਨੂੰ ਤੇਜ਼ ਸ਼ਿਪ ਕਰਵਾਇਆ

ਕਿਉਂ Rails ਪਹਿਲਾਂ ਆਏ ਹੱਲਾਂ ਨਾਲੋਂ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ

Rails ਤੋਂ ਪਹਿਲਾਂ, ਵੈੱਬ ਐਪ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਲੰਬੀ “ਸੈਟਅੱਪ ਟੈਕਸ” ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਸੀ। ਤੁਸੀਂ ਫੋਲਡਰ ਸਟਰਕਚਰ ਚੁਣਦੇ (ਜਾਂ ਬਣਾਉਂਦੇ) ਸੀ, URL ਨੂੰ ਕੋਡ ਨਾਲ ਕਿਵੇਂ ਮੈਪ ਕਰਨਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਹੱਥੋਂ ਵਾਇਰ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਅਤੇ ਉਹੀ ਗਲੂ ਕੋਡ ਵਾਰੀ-ਵਾਰੀ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ। ਇਹ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦਾ—ਪਰ ਫਿਰ ਵੀ ਦਿਨ ਖਤਮ ਹੋ ਜਾਂਦੇ।

ਇਸ ਤੋਂ ਦੂਜਾ ਟੁਰਾਂDecision fatigue ਸੀ। ਛੋਟੇ ਫੈਸਲੇ—ਫਾਈਲ ਨਾਮ, ਬਿਜ਼ਨਸ ਲੋਜਿਕ ਕਿੱਥੇ ਰੱਖਣੀ ਹੈ, ਟੈਸਟ ਕਿਵੇਂ ਠੀਕ ਕਰਣੇ—ਬਾਰ-ਬਾਰ ਫਿਰ ਤੋਂ ਨਿਗੋਸ਼ੀਏਟ ਹੋਣੇ ਪੈਂਦੇ। ਟੀਮ ਅਤੇ ਵਧ ਰਹੇ ਕੋਡਬੇਸ ਨਾਲ ਇਹ ਸਭ ਮੀਟਿੰਗਾਂ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਅਤੇ ਅਸਮਾਨਤ ਪੈਟਰਨਾਂ ਵਿੱਚ ਗੁਮ ਹੋ ਜਾਂਦਾ।

ਵਿਚਾਰ: ਘੱਟ ਚੋਇਸਾਂ, ਵੱਧ ਪ੍ਰਗਤੀ

Rails ਇੱਕ ਸਧਾਰਨ ਵਾਅਦਾ ਫੈਲਾਇਆ: ਜੇ ਤੁਸੀਂ ਆਮ ਤਰੀਕੇ ਨੂੰ ਫੋਲੋ ਕਰੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਨੂਂ ਕਨਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਏਗੀ। ਇਹੀ “convention over configuration” ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਹੈ।

ਰੇਲਜ਼ ਤੁਹਾਡੇ ਬਦਲੇ ਹਰ ਸੈਟਿੰਗ ਮੰਗਣ ਦੀ ਥਾਂ ਤਰਕਸ਼ੀਲ ਡਿਫੌਲਟ ਮੰਨ ਲੈਂਦਾ ਹੈ:

• ਮਾਡਲ, ਵਿਊਜ਼ ਅਤੇ ਕੰਟਰੋਲਰ ਲਈ ਇੱਕ ਅਨੁਮਾਨਤ ਥਾਂ
• ਆਮ ਨੈਮਿੰਗ ਜੋ ਆਪਣੇ-ਆਪ ਨੂੰ ਡੇਟਾਬੇਸ ਟੇਬਲਾਂ ਨਾਲ ਜੋੜਦੀ ਹੈ
• ਆਮ URL ਪੈਟਰਨ ਜੋ ਮੈਨੂਅਲ ਵਾਇਰਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ

ਜਦੋਂ ਫਰੇਮਵਰਕ ਪਹਿਲਾਂ ਹੀ “ਜਾਣਦਾ” ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਮੁਰਾਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਘੱਟ ਬੋਇਲਰਪਲੇਟ ਲਿਖਦੇ ਹੋ ਅਤੇ ਪਹਿਲੇ ਸਕ੍ਰੀਨਾਂ ਤੇ ਜਲਦੀ ਪਹੁੰਚਦੇ ਹੋ।

ਪ੍ਰਯੋਗ ਵਿੱਚ ਇਹ ਕਿਉਂ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ

ਤੇਜ਼ੀ ਸਿਰਫ ਨਾ ਲਾਈਨਾਂ ਘੱਟ ਲਿਖਣ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਰਿਵਾਜਾਂ ਇਸ ਗੱਲ ਨੂੰ ਬਦਲ ਦਿਤਾ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ:

• ਜ਼ਿਆਦਾ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ: ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਫੀਚਰ ਉਹਙ੍ਹੀ ਰਚਨਾ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਹੋਦੀ ਹੈ।
• ਸੁਚਾਰੂ ਟੀਮਵਰਕ: ਡਿਵੈਲਪਰ ਅਣਜਾਣੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੀ ਆਸਾਨੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਜਾਣਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ।
• ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਲੂਪ: ਬਦਲਾਵ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਐਪ ਇੱਕ ਜਾਣਪਹਚਾਣ ਵਾਲੇ ਢੰਗ ਵਿੱਚ ਸੰਗਠਿਤ ਰਹਿੰਦੀ ਹੈ।

ਇਸ ਲੇਖ ਦਾ ਕੇਂਦਰ ਇਹ ਹੈ ਕਿ Rails ਰਿਵਾਜਾਂ ਵਿਚਾਰ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੋਂ ਵਿੱਚ ਕਿਵੇਂ ਰਾਹ ਘਟਾਉਂਦੇ ਹਨ—ਖ਼ਿਆਲ ਤੋਂ ਚਲ ਰਹੀ ਫੀਚਰ ਤੱਕ ਦੇ ਰਾਹ ਨੂੰ ਛੋਟਾ ਕਰਦੇ ਹਨ—ਬਿਨਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਜਾਂ ਫਰੇਮਵਰਕ ਦੀ ਪੂਜਾ ਕਰਨ ਦੇ। ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਕੋਈ ਇੱਕ ਵਿਅਕਤੀ ਜਾਂ ਫਰੇਮਵਰਕ “ਜਾਦੂਈ” ਹੈ, ਬਲਕਿ ਚੰਗੇ ਡਿਫੌਲਟ ਨਿਰਧਾਰਨਤੱਕ ਦੀ ਘਟਨਾ ਨੂੰ ਦੂਰ ਕਰਦੇ ਹਨ।

DHH ਅਤੇ Ruby on Rails ਦਾ ਆਰੰਭ

David Heinemeier Hansson—ਆਮ ਤੌਰ 'ਤੇ DHH—Ruby on Rails ਦੇ ਬਣਾਉਣ ਵਾਲੇ ਹਨ। ਉਹ Rails ਨੂੰ 37signals (ਹੁਣ Basecamp) 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋਏ ਬਣਾਇਆ ਅਤੇ 2004 ਵਿੱਚ ਇਸਨੂੰ open source ਵਜੋਂ ਜਨਤਾ ਲਈ ਰਿਲੀਜ਼ ਕੀਤਾ। ਇਹ ਸਮਾਂ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ Rails ਕਿਸੇ ਖਾਲੀ ਕਮਰੇ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੋਇਆ: ਇਹ ਇੱਕ ਅਸਲ ਉਤਪਾਦ ਸਪਰੈਸ਼ਰ ਤੋਂ ਰੁੱਬ ਹੋ ਕੇ ਬਣਿਆ।

ਸਫੇ 'ਤੇ ਨਹੀਂ, ਅਸਲ ਐਪ ਤੋਂ ਕੱਢਿਆ ਗਿਆ

Rails Basecamp ਦੇ ਇਕ ਅੰਦਰੂਨੀ ਫਰੇਮਵਰਕ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ। ਕਿਸੇ ਵੱਡੇ ਸਿਧਾਂਤ ਨਾਲ ਨਹੀਂ ਕਿ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ, DHH ਨੇ ਉਹ ਹਿੱਸੇ ਬਾਹਰ ਕੱਢੇ ਜੋ بار بار ਲੋੜੀਂਦੇ ਸਨ: ਰाउंटਿੰਗ, ਕੋਡ ਦਾ ਆਯੋਜਨ, ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲਬਾਤ, HTML ਰੇਂਡਰ ਕਰਨਾ, ਅਤੇ ਆਮ ਵੈੱਬ ਪੈਟਰਨ ਸਾਂਭਣਾ।

ਕਿਉਂਕਿ ਇਹ ਉਤਪਾਦੀ ਲੋੜਾਂ ਤੋਂ ਆਇਆ, Rails ਰੋਟੀਨ ਕੰਮਾਂ ਤੋਂ ਰੁਕਾਵਟ ਹਟਾਉਣ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ। ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਸਭ ਕੁਝ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ—ਇਹ ਆਮ ਹਾਲਤ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ।

"opinionated framework" ਦਾ ਮਤਲਬ ਕੀ ਹੈ

Rails ਨੂੰ ਅਕਸਰ "opinionated" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਸਧਾਰਨ ਲਫ਼ਜ਼ਾਂ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ Rails ਤੁਹਾਡੇ ਲਈ ਫੈਸਲੇ ਲੈਂਦਾ—ਖਾਸ ਕਰਕੇ ਸਟਰਕਚਰ ਅਤੇ ਡਿਫੌਲਟ ਬਾਰੇ—ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਨਾ ਕਰਨੀਆਂ ਪੈਣ।

ਉਦਾਹਰਨ ਲਈ, ਇਹ ਟੀਮਾਂ ਨੂੰ ਇਸ ਵੱਲ ਧੱਕ ਦੇਂਦਾ:

• ਇੱਕ ਮਿਆਰੀ ਫੋਲਡਰ ਲੇਆਊਟ ਅਤੇ ਨੈਮਿੰਗ ਕਨਵੇਂਸ਼ਨ
• ਡੇਟਾ ਅਤੇ ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਮਾਡਲ ਕਰਨ ਦਾ ਇੱਕ ਸਥਿਰ ਤਰੀਕਾ
• ਕੰਟਰੋਲਰ, ਵਿਊਜ਼ ਅਤੇ ਰੂਟਸ ਲਈ ਅਨੁਮਾਨਤ ਪੈਟਰਨ

ਇਹ ਰਾਏਆਂ ਤੁਹਾਡੇ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣੀ ਹੁੰਦੀਆਂ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਘੱਟ ਫੈਸਲੇ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੀ ਵਰਜਨ ਤੇਜ਼ ਅਤੇ ਇਟਰੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਕਮਿਊਨਿਟੀ ਪ੍ਰਭਾਵ: ਸਾਂਝੇ ਡਿਫੌਲਟ, ਸਾਂਝੀ ਵੋਕੈਬੁਲੇਰੀ

Rails ਸਿਰਫ ਕੋਡ ਨਹੀਂ ਦਿੱਤਾ; ਇਸ ਨੇ ਵੈੱਬ ਐਪਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਇੱਕ ਸਾਂਝਾ ਢੰਗ ਬਣਾਇਆ। ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਟੀਮਾਂ ਇੱਕੋ ਹੀ ਕਨਵੇਂਸ਼ਨਾਂ ਫੋਲੋ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਾਂਝਾ ਸ਼ਬਦਾਵਲੀ ਬਣ ਜਾਂਦੀ ਹੈ ("models", "migrations", "scaffolds", "RESTful routes") ਅਤੇ ਟ੍ਰਾਂਸਫਰੇਬਲ ਹੁਨਰ। ਇਹ ਔਨਬੋਰਡਿੰਗ ਦਾ ਸਮਾਂ ਘੱਟ ਕਰਦਾ, ਮਦਦ ਲੱਭਣਾ ਆਸਾਨ ਬਣਾਂਦਾ ਅਤੇ "ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਕਰੀਏ?" ਨੂੰ "Rails ਲਈ ਇਸਦਾ ਮਿਆਰ ਪਹਿਲਾਂ ਹੀ ਹੈ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ।

Convention Over Configuration, ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਸਮਝਾਈਆ

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

ਮੁੱਖ ਵਿਚਾਰ: ਪਹਿਲਾਂ ਡਿਫੌਲਟ, ਫਿਰ ਖਾਸ ਮਾਮਲੇ

"Convention over configuration" ਦਾ ਮਤਲਬ ਹੈ ਕਿ Rails ਮੰਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਆਮ ਵੈੱਬ ਐਪ ਬਣਾ ਰਹੇ ਹੋ—ਯੂਜ਼ਰ, ਪੰਨੇ, ਫਾਰਮ, ਡੇਟਾਬੇਸ ਟੇਬਲ—ਅਤੇ ਇਹ ਹਰ ਇੱਕ ਚੀਜ਼ ਲਈ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਦਿੰਦਾ। ਜੇ ਤੁਸੀਂ ਕਨਵੇਂਸ਼ਨਾਂ ਦਾ ਪਾਲਣ ਕਰੋਗੇ, ਤਾਂ ਹਿੱਸੇ ਘੱਟ ਸੈਟਅੱਪ ਨਾਲ "ਸਿੱਧੇ ਜੁੜ ਜਾਂਦੇ" ਹਨ।

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

Rails ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਫੈਸਲਾ ਕਰਨ ਦਾ ਸਧਾਰਨ ਉਦਾਹਰਨ

Rails ਨਾਮਕ ਨੈਮਿੰਗ ਅਤੇ ਸਥਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਿੱਸਿਆਂ ਨੂੰ ਆਪੋ-ਆਪ ਬੰਨ੍ਹਦਾ ਹੈ:

• ਜੇ ਤੁਹਾਡੇ ਕੋਲ Article ਨਾਂ ਦਾ ਮਾਡਲ ਹੈ, Rails articles ਨਾਂ ਦੀ ਡੇਟਾਬੇਸ ਟੇਬਲ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।
• ArticlesController ਨਾਂ ਦਾ ਇੱਕ ਕੰਟਰੋਲਰ ਆਰਟਿਕਲਾਂ ਨਾਲ ਜੁੜੇ URL ਅਤੇ ਐਕਸ਼ਨਾਂ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ।
• ਫਾਈਲਾਂ ਆਮ ਥਾਵਾਂ app/models/article.rb ਅਤੇ app/controllers/articles_controller.rb ਵਿੱਚ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਕਿਉਂਕਿ Rails ਜਾਣਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਕਿਵੇਂ ਕਾਲ ਕਰਨਾ ਹੈ, ਤੁਸੀਂ ਦੁਹਰਾਉਂਦੇ ਵਾਇਰਿੰਗ ਤੋਂ ਬਚਦੇ ਹੋ। ਤੁਸੀਂ ਫੀਚਰ ਲਿਖਦੇ ਹੋ, ਗਲੂ ਨਹੀਂ।

ਟਰੇਡ-ਅਫ

ਕੀਮਤ ਪਹਿਲਾਂ ਘੱਟ ਆਜ਼ਾਦੀ ਹੈ: ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਸਟਮ ਸਟਰਕਚਰ ਜਾਂ ਅਸੰਪਰਤੀ ਨੈਮਿੰਗ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਵੱਧ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਪਏ (ਅਤੇ ਤੁਸੀਂ ਉਮੀਦਾਂ ਦੇ ਵਿਰੁੱਧ ਤੈਰ ਰਹੇ ਹੋ)। ਲਾਭ ਤੇਜ਼ੀ ਅਤੇ ਇਕਸਾਰਤਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਕਈ ਲੋਕ ਇਕੋ ਹੀ ਕੋਡਬੇਸ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਸਾਂਝੇ ਪੈਟਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

Rails MVC ਅਤੇ ਅਨੁਮਾਨਤ ਢਾਂਚੇ ਦੀ ਤਾਕਤ

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

• Models: ਤੁਹਾਡੀ ਐਪ ਦੇ "ਬਿਜ਼ਨਸ ਓਬਜੈਕਟ"। ਇਹ ਡੇਟਾ ਸਟੋਰ ਕਰਦੇ ਹਨ (ਅਕਸਰ ਡੇਟਾਬੇਸ ਰਾਹੀਂ) ਅਤੇ ਐਸੀ ਰੂਲਾਂ ਰੱਖਦੇ ਹਨ ਜਿਵੇਂ ਵੈਲਿਡੇਸ਼ਨ, ਕੀਮਤ ਲਾਜਿਕ, ਅਤੇ ਅਵਸਥਾ ਬਦਲਾਅ।
• Views: ਜੋ ਲੋਕ ਵੇਖਦੇ ਹਨ। ਟੈਂਪਲੇਟ ਜੋ ਡੇਟਾ ਨੂੰ HTML (ਜਾਂ JSON) ਵਿੱਚ ਬਦਲਦੇ ਹਨ, ਪ੍ਰੇਜ਼ੈਂਟੇਸ਼ਨ 'ਤੇ ਕੇਂਦਰਤ ਰਹਿੰਦੇ ਹਨ ਨਾ ਕਿ ਫੈਸਲੇ ਕਰਨ 'ਤੇ।
• Controllers: ਟ੍ਰੈਫਿਕ ਡਾਇਰੈਕਟਰ। ਇਹ ਰਿਕਵੇਸਟ ਲੈਂਦੇ ਹਨ, ਮਾਡਲ ਤੋਂ ਲੋੜੀਂਦਾ ਡੇਟਾ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੀ ਵਿਊ (ਜਾਂ ਰਿਸਪਾਂਸ) ਵਾਪਸ ਕਰਨੀ ਹੈ।

Rails ਇਹਨਾਂ ਨੂੰ ਘੱਟ ਸੈਟਅੱਪ ਨਾਲ ਕਿਵੇਂ ਜੋੜਦਾ ਹੈ

ਤੇਜ਼ੀ ਦਾ ਫਾਇਦਾ Rails ਦੀਆਂ ਰਿਵਾਜਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜੋ ਇਹਨਾਂ ਪਰਤਾਂ ਨੂੰ ਆਪੋ-ਆਪ ਜੋੜ ਦਿੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ PostsController ਬਣਾਉਂਦੇ ਹੋ, Rails app/controllers/posts_controller.rb ਵਿੱਚ ਇਸਦੀ ਉਮੀਦ ਕਰੇਗਾ। ਇੱਕ Post ਮਾਡਲ app/models/post.rb ਵਿੱਚ ਰਹੇਗਾ। ਉਸ ਕੰਟਰੋਲਰ ਲਈ ਵਿਊਜ਼ ਕੁਦਰਤੀ ਤੌਰ app/views/posts/ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ।

ਜਿਵੇਂ ਕਿ ਨਾਂ ਅਤੇ ਥਾਵਾਂ ਅਨੁਮਾਨਤ ਹਨ, Rails ਬਹੁਤ ਕੁਝ ਅਨੁਮਾਨ ਲਾ ਸਕਦਾ ਹੈ: ਰੂਟਸ controller ਐਕਸ਼ਨਾਂ ਨੂੰ ਮੈਪ ਕਰਦੇ ਹਨ, controller ਐਕਸ਼ਨ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਮੇਚਿੰਗ ਵਿਊ ਟੈਮਪਲੇਟ ਰੇਂਡਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਮਾਡਲ ਆਪਣਾ ਨਾਂ ਡੇਟਾਬੇਸ ਟੇਬਲ ਨਾਲ ਮਿਲਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਵਿਹਵਾਰ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹੋ—ਪਰ ਤੁਹਾਨੂੰ ਹਰ ਫੈਸਲੇ 'ਤੇ ਪਹਿਲਾਂ ਨਾ ਸੋਚਣਾ ਪਏ।

ਪੈਟਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਟੀਮ ਲਈ ਗੁਣਾ ਦੋਗੁਣਾ ਕਰਦੀ ਹੈ

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

"Fat model, skinny controller" (ਅਤੇ ਜਿੱਥੇ ਇਹ ਟੁੱਟਦਾ ਹੈ)

ਇੱਕ ਆਮ ਰਾਹਦਾਰੀ ਹੈ fat model, skinny controller: controllers ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਰੀਯੂਜ਼ਬਲ ਨਿਯਮ models ਵਿੱਚ ਰੱਖੋ। ਇਹ endpoints ਵਿੱਚ ਨਕਲ ਕੀਤੀ ਲਾਜਿਕ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਹੱਦ: ਤੁਹਾਡੇ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਵਰਕਫਲੋ ਇੱਕ Active Record ਮਾਡਲ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ। ਜਿਵੇਂ-ਜਿਵੇਂ ਐਪ ਵੱਧਦਾ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ service objects ਜਾਂ form objects ਲਿਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ models ਹੋਰ ਚੀਜ਼ਾਂ ਲਈ ਡੰਪਿੰਗ ਗ੍ਰਾਊਂਡ ਨਾ ਬਣ ਜਾਣ—ਫਿਰ ਵੀ controllers ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ।

Scaffolding: ਵਿਚਾਰ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲੇ CRUD ਤੱਕ ਮਿੰਟਾਂ ਵਿੱਚ

Rails scaffolding ਇੱਕ ਸ਼ਾਰਟਕਟ ਹੈ ਜੋ ਇੱਕ ਫੀਚਰ ਦੀ ਕੰਮ ਕਰਨ ਵਾਲੀ ਬੇਸਲਾਈਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਕਮਾਂਡ ਨਾਲ, Rails ਇੱਕ ਮਾਡਲ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕੰਟਰੋਲਰ ਐਕਸ਼ਨ, ਰੂਟਸ, ਅਤੇ ਬੁਨਿਆਦੀ ਵਿਊਜ਼ Create/Read/Update/Delete (CRUD) ਲਈ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਸਲਾਈਡ ਡੈੱਕ ਜਾਂ ਮੌਕਅੱਪ ਨਹੀਂ—ਇਹ ਐਪ ਦਾ ਇੱਕ ਚਲਣ ਵਾਲਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕਲਿਕ ਕਰ ਸਕਦੇ ਹੋ।

Scaffolding ਤੁਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ

ਇੱਕ scaffold "ਬੋਰੀਂਗ ਪਰ ਜ਼ਰੂਰੀ" ਹਿੱਸਿਆਂ ਨੂੰ ਵਾਇਰ ਕਰ ਦਿੰਦਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਵਿਚਾਰ ਨੂੰ ਪ੍ਰੂਵ ਕਰ ਸਕੋ:

• ਇੱਕ ਡੇਟਾਬੇਸ-ਬੈਕਡ ਰਿਸੋਰਸ (ਆਪਣੇ ਚੁਣੇ ਫੀਲਡਾਂ ਨਾਲ)
• ਰਿਕਾਰਡ ਬਣਾਉਣ ਅਤੇ ਸੰਪਾਦਨ ਲਈ ਫਾਰਮ
• ਰਿਕਾਰਡਾਂ ਦੀ ਲਿਸਟ ਅਤੇ ਵੇਖਣ ਲਈ ਪੰਨੇ
• ਮਿਆਰੀ ਰੂਟਸ ਅਤੇ ਕੰਟਰੋਲਰ ਐਕਸ਼ਨ

ਇਹ ਮੁੱਦਾ ਇਸ ਲਈ ਵੱਡਾ ਹੈ ਕਿਉਂਕਿ ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ ਅਕਸਰ ਸੈੱਟਅੱਪ ਕੰਮ 'ਤੇ ਟਿਕ ਜਾਂਦੀ ਹੈ। Scaffolding ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਬਾਇਪਾਸ ਕਰਨ ਅਤੇ ਇੱਕ ਅਸਲ ਚੀਜ਼ ਤੋਂ ਸਿੱਖਣ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

Scaffolds ਸਿੱਖਣ ਲਈ ਹਨ, ਖਤਮ ਕਰਨ ਲਈ ਨਹੀਂ

Scaffolding ਨੂੰ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਜਨਰੇਟਰ ਵਜੋਂ ਵੇਖਣਾ ਵਧੀਆ ਹੈ। ਡਿਫੌਲਟ ਵਿਊਜ਼ ਸਧਾਰਨ ਹੁੰਦੀਆਂ ਹਨ, UX ਘੱਟ-ਸੁੰਦਰ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕੋਡ ਸਧਾਰਨ ਅਨੁਮਾਨ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਫੀਚਰ ਹੈ, ਨਾ ਕਿ ਖਾਟ;

ਇਹ ਤੁਹਾਨੂੰ scaffolds ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਜੋਂ ਦੇਖਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ "ਅਖੀਰ ਦਾ ਡਿਜ਼ਾਇਨ"।

ਅਕਸਰ ਸਿਹਤਮੰਦ ਵਰਕਫਲੋ ਇਹ ਹੁੰਦੀ ਹੈ:

1. ਇੱਕ ਰਿਸੋਰਸ ਨੂੰ scaffold ਕਰੋ ਤਾਂ ਕਿ end-to-end ਲੂਪ ਕੰਮ ਕਰੇ।
2. ਕਿਸੇ ਨੂੰ (ਇੰਟਰਨਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ) ਦਿਖਾਓ ਤਾਂ ਕਿ ਫਲੋ ਵੈਲਿਡੇਟ ਹੋ ਜਾਏ।
3. ਰੀਫੈਕਟਰ ਕਰੋ: ਵੈਲਿਡੇਸ਼ਨ, ਪਰਮਿਸ਼ਨ, UI, ਅਤੇ ਬਿਜ਼ਨਸ ਰੂਲ ਅਨੁਸਾਰ ਢਾਲੋ।

ਸਾਵਧਾਨੀਆਂ: ਤੇਜ਼ੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਹਟਾਉਂਦੀ ਨਹੀਂ

ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਫਿਰ ਵੀ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੋਗੇ, ਆਥਰਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਕਸਨਾ ਪਏਗਾ, ਅਤੇ ਏਰਰ ਹੈਂਡਲਿੰਗ ਨੂੰ ਸੁਧਾਰਨਾ ਪਏਗਾ। ਅਤੇ ਕਿਉਂਕਿ scaffold ਕੀਤੀਆਂ ਪੇਜ਼ ਯੂਟਿਲਿਟੇਰੀ ਹੁੰਦੀਆਂ ਹਨ, ਅਸਲ UX ਕੰਮ—ਕਾਪੀ, ਲੇਆਊਟ, ਪਹੁੰਚਯੋਗਤਾ, ਅਤੇ ਐਜ਼-ਕੇਸਾਂ—ਲਈ ਸਮਾਂ ਰੱਖੋ। Scaffolding ਪਹਿਲਾ ਡਰਾਫਟ ਤੇਜ਼ ਕਰਦਾ ਹੈ; ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।

ਜਨਰੇਟਰ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ: ਵਰਕਫਲੋ ਵਿੱਚ ਇਟਰੇਸ਼ਨ ਬੁਨੀادی

Rails ਸਿਰਫ਼ ਕਨਵੇਂਸ਼ਨਾਂ ਨੂੰ ਸਿਧਾਂਤ ਵਿੱਚ ਨਹੀਂ ਲਿਆਇਆ—ਇਸ ਨੇ ਉਹਨਾਂ ਨੂਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਿੱਚ ਜਨਰੇਟਰ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਨੈਮਿੰਗ ਨਿਯਮਾਂ ਰਾਹੀਂ ਜੋੜ ਦਿੱਤਾ। ਇਹ ਏਕਤਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਕੋਡਬੇਸ ਇਕ-ਆਫ਼ ਫੈਸਲਿਆਂ ਦੇ ਢੇਰ ਵਿੱਚ ਬਦਲ ਜਾਣ ਦੇ।

ਜਨਰੇਟਰ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਰਿਵਾਜ ਇਕ ਸਿਸਟਮ ਵਜੋਂ

Rails ਜਨਰੇਟਰ ਸਿਰਫ "ਫਾਈਲਾਂ ਬਣਾਉਂਦਾ" ਨਹੀਂ। ਇਹ ਉਮੀਦ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਉਮੀਦ ਕੀਤੀਆਂ ਥਾਵਾਂ 'ਚ ਉਮੀਦ ਕੀਤਿਆਂ ਨਾਮਾਂ ਨਾਲ ਬਣਾਉਂਦਾ—ਮਾਡਲ app/models ਵਿੱਚ, ਕੰਟਰੋਲਰ app/controllers ਵਿੱਚ, ਟੈਸਟ ਸਹੀ ਫੋਲਡਰ ਵਿੱਚ, ਅਤੇ ਅਹਿਮ ਗੱਲ: ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜੋ ਡੇਟਾਬੇਸ ਰਚਨਾ ਨੂੰ ਅਪਡੇਟ ਕਰਦੀ ਹੈ।

ਕਿਉਂਕਿ Rails ਨੈਮਿੰਗ (User -> users ਟੇਬਲ ਵਰਗੀਆਂ) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਜਨਰੇਟ ਕੀਤੀਆਂ ਚੀਜ਼ਾਂ ਘੱਟ ਵਾਇਰਿੰਗ ਨਾਲ ਜੁੜ ਜਾਦੀਆਂ ਹਨ। ਘੱਟ ਸਮਾਂ ਇਸ ਗੱਲ 'ਤੇ ਲੱਗਦਾ ਕਿ ਕੁਝ ਕਿੱਥੇ ਜਾਂ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ, ਅਤੇ ਵੱਧ ਸਮਾਂ ਫੀਚਰ ਨੂੰ ਸੂਰਤ ਦੇਣ 'ਤੇ ਲੱਗਦਾ ਹੈ।

ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੇਕ ਚੇਨਜ ਪ੍ਰੋਡਕਟ ਦਾ ਹਿੱਸਾ

Migrations ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਐਸਾ ਕੁਝ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਐਪ ਦੇ ਨਾਲ-ਨਾਲ ਵਿਕਸਤ ਹੁੰਦਾ। "ਡੇਟਾਬੇਸ ਹੋ ਗਿਆ, ਹੁਣ ਅਸੀਂ ਕੋਡ ਕਰੀਏ" ਦੀ ਬਜੇ, Rails ਇੱਕ ਸਥਿਰੀ ਰਿਥਮ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ: ਫੀਚਰ ਬਣਾਓ, ਸਕੀਮਾ ਸੁਧਾਰੋ, ਅਸਲ ਉਪਭੋਗ ਤੋਂ ਸਿੱਖੋ, ਫਿਰ ਸੁਧਾਰੋ।

ਹਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਇੱਕ ਛੋਟਾ, ਟਾਈਮਸਟੈਂਪਡ ਕਦਮ ਹੁੰਦਾ ਜੋ ਸਮੀਖਿਆ, ਵਰਜਨ ਕੰਟਰੋਲ, ਅਤੇ ਵਾਤਾਵਰਣਾਂ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਟਰੇਟਿਵ ਉਤਪਾਦ ਬਦਲਾਵ—ਫੀਲਡ ਜੋੜਨ, ਪਾਬੰਦੀਆਂ ਠੀਕ ਕਰਨ, ਨਵੀਂ ਟੇਬਲਾਂ ਲਿਆਂਦੇ—ਟਾਈਮ ਨਾਲ ਘੱਟ ਖ਼ਤਰਨਾਕ ਹੁੰਦੇ ਹਨ।

ਉਦਾਹਰਣ ਵਰਕਫਲੋ: ਇੱਕ ਫੀਲਡ ਜੋੜੋ, ਵੈਲਿਡੇਟ ਕਰੋ, ਸ਼ਿਪ ਕਰੋ

ਕਹੋ ਤੁਸੀਂ ਉਪਭੋਗੀਆਂ ਵਿੱਚ role ਜ਼ੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ:

1. ਬਦਲਾਅ ਬਣਾਓ: rails g migration AddRoleToUsers role:string
2. ਚਲਾਓ: rails db:migrate
3. ਮਾਡਲ ਅਪਡੇਟ ਕਰੋ: User ਵਿੱਚ ਵੈਲਿਡੇਸ਼ਨ ਜੋੜੋ (ਅਤੇ ਸ਼ਾਇਦ enum)
4. ਫਾਰਮ ਅਤੇ ਵਿਊਜ਼ ਠੀਕ ਕਰੋ, ਟੈਸਟ ਅਪਡੇਟ ਕਰੋ, ਡਿਪਲੌਇ ਕਰੋ।

ਇਹ ਇਕ ਤੰਗ ਲੂਪ ਹੈ: ਸਕੀਮਾ ਬਦਲਾਅ ਅਤੇ ਐਪ ਬਦਲਾਅ ਇਕੱਠੇ ਚਲਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ "ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਨਹੀਂ" ਵਾਲੇ ਕੋਲਮ ਜਾਂ ਐਸੀ ਕੋਡ ਨਾ ਰਹਿ ਜਾਵੇ ਜੋ ਡੇਟਾ ਮੌਜੂਦ ਹੋਣ ਦਾ ਅਸਥਿਰ ਅਨੁਮਾਨ ਕਰਦਾ ਹੋਵੇ।

ਅਨੁਸ਼ਾਸਨ ਮਹੱਤਵਪੂਰਣ ਹੈ

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

ਡੀਆਰੀ ਵੱਲੋਂ ਮੁਲਾ: ਘੱਟ ਬੋਇਲਰਪਲੇਟ, ਫੀਚਰਾਂ 'ਤੇ ਵੱਧ ਧਿਆਨ

"Don't repeat yourself" (DRY) ਦਾ ਸਧਾਰਨ ਵਿਚਾਰ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਹਰ ਗਿਆਨ ਦਾ ਇੱਕ ਸਾਫ਼ ਸਰੋਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵੈੱਬ ਐਪ ਵਿੱਚ, ਦੁਹਰਾਉ ਅਕਸਰ ਅੱਚਾਨਕ ਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹੀ ਧਾਰਨਾ ਕਈ ਥਾਵਾਂ 'ਤੇ ਲਿਖੀ ਜਾਂਦੀ ਹੈ—ਰੂਟਸ, ਕੰਟਰੋਲਰ ਲਾਜਿਕ, ਵਿਊ ਟੈਂਪਲੇਟ, ਅਤੇ ਖ਼ਤੋ-ਖ਼ਤੋ ਡੇਟਾਬੇਸ ਕਵੇਰੀज़ ਵਿੱਚ।

ਇੱਕ ਠੋਸ DRY ਉਦਾਹਰਨ: Posts ਫੀਚਰ

ਕਲਪਨਾ ਕਰੋ ਤੁਸੀਂ Post ਰਿਕਾਰਡਾਂ ਵਾਲਾ ਇੱਕ ਮੂਲ ਬਲੌਗ ਬਣਾਉਂਦੇ ਹੋ। DRY ਆਦਤਾਂ ਦੇ ਬਿਨਾਂ, ਤੁਸੀਂ "ID ਨਾਲ ਪੋਸਟ ਲੱਭੋ" ਵਰਗੀ ਕੋਡ ਨੂੰ show, edit, update, ਅਤੇ destroy ਵਿੱਚ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ। Rails ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਂਝਾ ਮੈਥਡ ਵੱਲ ਧੱਕਦਾ:

before_action :set_post, only: %i[show edit update destroy]

def set_post
  @post = Post.find(params[:id])
end

ਇਹ DRY ਦੀ ਮਿਸਾਲ ਹੈ: ਇੱਕ ਬਦਲਾਅ (ਜਿਵੇਂ Post.friendly.find 'ਤੇ ਬਦਲਣਾ) ਹਰ ਐਕਸ਼ਨ ਨੂੰ ਅਪਡੇਟ ਕਰ ਦੇਵੇਗਾ।

Rails ਰਿਵਾਜ ਕਿਵੇਂ ਰੂਟਸ, ਕੰਟਰੋਲਰ ਅਤੇ ਵਿਊਜ਼ 'ਚੋਂ ਦੁਹਰਾਉ ਘਟਾਉਂਦੇ ਹਨ

Rails ਰਿਵਾਜ DRY ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਨਾਂ ਅਤੇ ਸਟਰਕਚਰ 'ਤੇ "ਸਹਿਮਤ" ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ RESTful ਰੂਟਸ (resources :posts) ਵਰਤਦੇ ਹੋ, Rails PostsController ਵਿੱਚ ਮਿਆਰੀ ਐਕਸ਼ਨਾਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ app/views/posts/show.html.erb ਵਰਗੀਆਂ ਪਾਥਾਂ 'ਤੇ ਵਿਊਜ਼ ਲਭਦਾ ਹੈ।

ਇਨ੍ਹਾਂ ਟੁਕੜਿਆਂ ਦੇ ਲਾਈਨ-ਅਪ ਹੋਣ ਕਾਰਨ, ਤੁਸੀਂ ਘੱਟ ਗਲੂ ਕੋਡ ਲਿਖਦੇ ਹੋ। ਇੱਕ ਲਿੰਕ ਹੈਲਪਰ ਜਿਵੇਂ link_to @post.title, @post ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ Rails ਮਾਡਲ ਇੰਸਟੈਂਸ ਤੋਂ ਸਹੀ ਰੂਟ ਅਨੁਮਾਨ ਲਾ ਸਕਦਾ ਹੈ। ਪਾਰਸ਼ਲ ਨੈਮਿੰਗ ਕਨਵੇਂਸ਼ਨ (render @posts) ਹਰ ਆਈਟਮ ਲਈ posts/_post ਆਟੋਮੈਟਿਕ ਚੁਣ ਸਕਦਾ ਹੈ।

DRY ਦਾ ਜ਼ਿਆਦਾ ਕਰਨਾ ਨੁਕਸਾਨਦਾਇਕ ਵੀ ਹੋ ਸਕਦਾ ਹੈ

DRY ਨੂੰ ਬਹੁਤ ਅਗੇ ਵਧਾਉਣਾ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ: ਬਹੁਤ ਹੀ ਛੋਟੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨ, ਮੈਟਾ-ਪ੍ਰੋਗਰਾਮਿੰਗ, ਜਾਂ "ਇੱਕ ਮੈਥਡ ਜੋ ਸਭ ਕੁਝ ਸੰਭਾਲੇ" ਲਾਈਨਾਂ ਬਚਾ ਸਕਦਾ ਹੈ ਪਰ ਸਮਝ ਦੀ ਕੀਮਤ ਤੇ। ਕੁਝ ਦਾਹਰ-ਦੁਹਰਾਅ ਕਈ ਵਾਰ ਸਪਸ਼ਟ ਰਹਿਣ ਲਈ ਠੀਕ ਹੁੰਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਵਿਊਜ਼ ਅਤੇ ਬਿਜ਼ਨਸ ਲੋਜਿਕ ਵਿੱਚ। ਲਕਸ਼ ਹੈ ਰੱਖਠਣਯੋਗਤਾ, ਨਾ ਕਿ ਘੱਟ ਤੋਂ ਘੱਟ ਚਰित्र ਗਿਣਤੀ।

ਖੁਸ਼ੀ ਦਾ ਰਸਤਾ: ਕਿਉਂ ਡਿਫੌਲਟ ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ

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

ਖੁਸ਼ੀ ਰਸਤੇ ਦੀ ਵਿਕਾਸ, ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ

ਖੁਸ਼ੀ ਰਸਤੇ ਦੀ ਵਿਕਾਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਜਿਆਦਾਤਰ ਸਮਾਂ "ਸਧਾਰਨ" ਚੀਜ਼ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਫਰੇਮਵਰਕ ਨਾਲ ਜੂੰਝਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਮਾਡਲ Order ਨਾਮ ਰੱਖਦੇ ਹੋ, Rails orders ਟੇਬਲ ਦੀ ਉਮੀਦ ਕਰਦਾ, ਜਾਣਦਾ ਹੈ ਕਿ ਫਾਈਲ ਕਿੱਥੇ ਰਹੇਗੀ, ਅਤੇ ਕੰਟਰੋਲਰ, ਵਿਊਜ਼, ਅਤੇ ਰੂਟਸ ਕਿਵੇਂ ਮਿਲਣੇ ਚਾਹੀਦੇ—ਤਾਂ ਕਿ ਤੁਸੀਂ ਹਰ ਚੋਣ ਨੂੰ ਸਬੂਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਮਹਿਸੂਸ ਕਰੋ।

ਫੈਸਲੇ ਘਟਾਉਣ ਵਾਲੇ ਡਿਫੌਲਟ

ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਕੋਲ ਬੇਅੰਤ ਪਹਿਲੇ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ: ਫੋਲਡਰ ਸਟਰਕਚਰ, ਨੈਮਿੰਗ, ਕਨਫਿਗਰੇਸ਼ਨ ਸਟਾਈਲ, ਟੈਸਟ ਸੈਟਅੱਪ, ਫਾਰਮਸ ਨੂੰ ਸੰਭਾਲਣਾ, ਬਿਜ਼ਨਸ ਲੋਜਿਕ ਕਿੱਥੇ ਰੱਖਣਾ। Rails ਜ਼ਰੂਰੀ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਦਿੰਦਾ।

ਇਹ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ ਫੈਸਲੇ ਦੀ ਥਕਾਵਟ ਅਸਲੀ ਹੈ: ਜਿਹਨੇ ਵੱਧ ਛੋਟੇ-ਛੋਟੇ ਚੋਇਸ ਤੁਸੀਂ ਲੈਂਦੇ ਹੋ, ਉਹਨੀ ਦੇ ਨਾਲ ਤੁਸੀਂ ਢੀਰੇ ਹੋ ਜਾਂਦੇ ਹੋ—ਅਤੇ ਟੀਮ ਮੈਂਬਰਾਂ ਲਈ ਪਤਾ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਕੀਤਾ। Rails ਡਿਫੌਲਟ ਇੱਕ "ਠੀਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ" ਬਣਾਉਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੁਰੰਤ ਫੀਚਰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕੋ ਅਤੇ ਸਿਰਫ਼ ਜਦੋਂ ਜ਼ਰੂਰਤ ਹੋਵੇ ਅਨੁਕੂਲਤਾ ਕਰੋ।

ਤੇਜ਼ ਪ੍ਰਯੋਗ, ਘੱਟ ਫੀਡਬੈਕ ਲੂਪ

ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ ਦਾ ਮਕਸਦ ਵੱਧ (ਅਤੇ ਵਧੀਆ) ਪ੍ਰਯੋਗ ਚਲਾਉਣਾ ਹੈ: ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ, ਦੇਖੋ ਉਪਭੋਗੀ ਕੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਢਾਲੋ। Rails ਇਸ ਰਿਥਮ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ:

• ਇੱਕ ਨਵੀਂ ਧਾਰਨਾ ਨੂੰ ਮਾਡਲ ਕਰਨਾ ਅਤੇ ਜਲਦੀ ਢੰਗ ਨਾਲ ਐਪ ਵਿੱਚ ਵਾਇਰ ਕਰਨਾ
• ਵੈਲਿਡੇਸ਼ਨ ਅਤੇ ਏਰਰ ਸੁਨੇਹੇ ਬਿਨਾਂ ਵੱਧ ਪਲੰਬਿੰਗ ਦੇ ਜੋੜਨਾ
• ਕੰਮ ਕਰਨ ਵਾਲੇ endpoints ਅਤੇ ਪੰਨੇ ਤਿਆਰ ਕਰਨਾ ਜੋ ਬਾਕੀ ਕੋਡ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਹਨ

ਛੋਟੇ ਨਿਰਮਾਣ ਸਮੇਂ ਦਾ ਨਤੀਜਾ ਛੋਟੇ ਫੀਡਬੈਕ ਲੂਪ ਹਨ—ਅਤੇ ਇੱਥੇ ਤੇਜ਼ੀ ਸਿੱਖਣ ਵਿੱਚ ਬਦਲਦੀ ਹੈ।

ਜਦੋਂ ਖੁਸ਼ੀ ਰਸਤਾ ਟੁੱਟਦਾ ਹੈ

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

ਟੀਮ ਦੀ ਤੇਜ਼ੀ: ਸਾਂਝੇ ਰਿਵਾਜ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਾਗਤ ਘਟਾਉਂਦੇ ਹਨ

Rails ਸਿਰਫ਼ ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕੀਤਾ—ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ। "Rails way" ਅਸਲ ਵਿੱਚ ਸਾਂਝੀਆਂ ਉਮੀਦਾਂ ਦਾ ਇਕ ਸੈੱਟ ਹੈ: ਫਾਈਲਾਂ ਕਿੱਥੇ ਰਹਿੰਦੀਆਂ ਹਨ, ਕਲਾਸਾਂ ਦਾ ਨਾਂ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਰਿਕਵੈਸਟ ਕੰਟਰੋਲਰ ਤੋਂ ਵਿਊਜ਼ ਤੱਕ ਕਿਵੇਂ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਕਿਵੇਂ ਮਾਡਲ ਹੁੰਦਾ। ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਜੈਕਟ ਇੱਕੋ ਜਿਹੇ ਪੈਟਰਨ ਫੋਲੋ ਕਰਦੇ ਹਨ, ਤਾਂ ਟੀਮ-ਮੇਟਾਂ ਨੂੰ ਸਟਰੱਕਚਰ ਡਿਕੋਡ ਕਰਨ 'ਚ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਅਤੇ ਫੀਚਰ ਸ਼ਿਪ ਕਰਨ 'ਤੇ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ।

ਦਿਨ-ਪਰ-ਦਿਨ "Rails way" ਕਿਵੇਂ ਦਿੱਸਦੀ ਹੈ

ਰਿਵਾਜ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਰਹੇ ਫੈਸਲਿਆਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:

• ਮਾਡਲ app/models, ਕੰਟਰੋਲਰ app/controllers, ਵਿਊਜ਼ app/views ਵਿੱਚ
• ਪੇਸ਼ਗੋਈ ਨੈਮਿੰਗ (PostsController Post ਨੂੰ ਮੈਨੇਜ ਕਰਦਾ)
• ਆਮ RESTful ਰੂਟਸ (index, show, create, ਆਦਿ)
• ਫਾਰਮ, ਵੈਲਿਡੇਸ਼ਨ ਅਤੇ ਪਾਰਸ਼ਲ ਲਈ ਜਾਣਪਹਚਾਣੀ ਰਵਾਇਤ

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਜਾਦੂਈ ਨਹੀਂ। ਇਕੱਠੇ ਇਹ "ਅਸੀਂ ਇੱਥੇ ਇਹੀ ਕਰੇਗੇ" ਵਾਲੇ ਗੱਲ-ਬਾਤਾਂ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ।

ਤੇਜ਼ ਔਨਬੋਰਡਿੰਗ ਅਤੇ ਘੱਟ ਹੈਂਡਆਫ

ਜਦੋਂ ਨਵਾਂ ਡਿਵੈਲਪਰ ਜੁੜਦਾ ਹੈ, Rails ਰਿਵਾਜ ਇਮਾਰਤ ਦੇ ਨਿਸ਼ਾਨਾਂ ਵਰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਤੁਸੀਂ ਬਿਨਾਂ ਗਾਈਡ ਟੂਰ ਦੇ ਜ਼ਰੂਰਤ ਆਸਾਨੀ ਨਾਲ ਲੋੜੀਂਦੀ ਚੀਜ਼ ਲੱਭ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਔਨਬੋਰਡਿੰਗ ਸਮਾਂ ਘਟਦਾ ਅਤੇ ਗਿਆਨ ਇਕ ਵਿਅਕਤੀ ਦੇ ਸਿਰ 'ਤੇ ਫੈਸਲਿਆ ਰਹਿਣ ਦਾ ਖਤਰਾ ਘਟਦਾ ਹੈ।

ਚੰਗੇ ਕੋਡ ਰਿਵਿਊ, ਘੱਟ ਬਾਇਕਸ਼ੇਡਿੰਗ

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

ਟਰੇਡ-ਅਫ: ਅਨੁਕੂਲਤਾ ਹਮੇਸ਼ਾਂ ਸਹੀ ਨਹੀਂ ਹੁੰਦੀ

ਉਲਟ ਪਾਸਾ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਪੈਰੋਕਾਰਤਾ ਵਜੋਂ ਰਿਵਾਜ ਫੋਲੋ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਸਿਹਤਮੰਦ ਹੈ ਕਿ ਅਪਵਾਦਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਤਰਕਸ਼ੀਲ ਕੀਤਾ ਜਾਵੇ—ਖ਼ਾਸ ਕਰਕੇ ਅਜਿਹੇ ਡੋਮੇਨ, ਸਕੇਲਿੰਗ ਪਾਬੰਦੀਆਂ, ਜਾਂ ਸੁਰੱਖਿਆ ਦੀਆਂ ਲੋੜਾਂ ਲਈ—ਫਿਰ ਵੀ Rails ਡਿਫੌਲਟਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇ।

ਬੈਟਰੀਜ਼ ਇੰਕਲੂਡਿਡ: ਇਕਠੇ ਟੂਲਸ ਜੋ ਉਤਪਾਦ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਵਾਉਂਦੇ ਹਨ

Rails ਨੇ ਆਪਣੀ "batteries included" ਖੁਬੀ ਨਾਲ ਇਕ ਵੈੱਬ ਐਪ ਨੂੰ ਇਕ ਸੰਪੂਰਨ ਉਤਪਾਦ ਵਜੋਂ ਵੇਖਿਆ, ਨਾ ਕਿ ਅਲੱਗ-ਅਲੱਗ ਭਾਗਾਂ ਦਾ ਪਜ਼ਲ। ਰਾਉਟਿੰਗ, ਟੈਂਪਲੇਟਿੰਗ, ਬੈਕਗ੍ਰਾਉਂਡ ਵਰਕ, ਈਮੇਲ, ਫ਼ਾਇਲ ਅੱਪਲੋਡ, ਸੁਰੱਖਿਆ ਡਿਫੌਲਟ, ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਸਟੈਕ ਨੂੰ ਜੋੜਨ ਦੀ ਬਜਾਏ, Rails ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੰਨ੍ਹਾ ਦੇਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਆਉਂਦਾ।

ਆਮ ਲੋੜਾਂ ਲਈ ਮਿਆਰੀ ਹੱਲ

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

ਜਦੋਂ "ਮਿਆਰੀ" ਰਸਤਾ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਹੋਵੇ, ਤਾਂ ਸ਼ਿਪ ਕਰਨਾ ਅਰਥ ਹੈ ਕਿ ਐਪ-ਵੱਖ-ਵੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਭਰਨਾ—ਮਾਡਲ, ਨੀyam, ਅਤੇ UI—ਨਹੀਂ ਕਿ ਹਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਲਈ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣ।

ਘੱਟ ਸੀਮਾਂ, ਘੱਟ ਗਲੂ ਕੋਡ

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

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

ਟਰੇਡ-ਅਫ: ਫਰੇਮਵਰਕ-ਵਿਆਪੀ ਬਦਲਾਅ

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

ਜਿੱਥੇ Convention Over Configuration ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ

Rails ਰਿਵਾਜਾਂ ਇੱਕ ਗਤੀ ਵਧਾਉਣ ਵਾਲਾ ਕਾਰਨ ਬਣਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੇ ਨੇੜੇ ਰਹਿੰਦੇ ਹੋ। ਪਰ ਉਹੀ ਰਿਵਾਜਾਂ ਤੁਹਾਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਫਰੇਮਵਰਕ ਨੂੰ ਉਸ ਰੂਪ ਵਿੱਚ ਮੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ Rails ਸੁਗਮ ਬਣਾਉਣ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ।

ਸੰਕੇਤ ਜੇ ਤੁਸੀਂ ਰਿਵਾਜਾਂ ਨਾਲ ਜੰਗ ਕਰ ਰਹੇ ਹੋ

ਕੁਝ ਪ੍ਰਯੋਗਿਕ "ਸਮਾਰਕ ਸਿਗਨਲ" ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਦਿੱਖਾਈ ਦੇਂਦੇ ਹਨ:

• ਤੁਸੀਂ ਮੁੜ ਮੁੜ ਡਿਫੌਲਟ ਓਵਰਰਾਈਡ ਕਰ ਰਹੇ ਹੋ (autoloading, inflections, routing patterns) ਤਾਂ ਕਿ ਚੀਜ਼ਾਂ "ਠੀਕ ਦੇ。
• ਤੁਸੀਂ ਕਸਟਮ ਡਾਈਰੈਕਟਰੀ ਨਿਯਮ ਲਿਆਉਂਦੇ ਹੋ ਜੋ ਨਵੇਂ ਟੀਮ ਮੈਂਬਰਾਂ ਲਈ ਬਿਨਾਂ ਨਕਸ਼ੇ ਦੇ ਅਨੁਮਾਨ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ।
• ਭਾਰੀ ਮੈਟਾ-ਪ੍ਰੋਗਰਾਮਿੰਗ ਮੂਲ ਵਿਹਾਰ ਨੂੰ ਟਰੇਸ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀ ("ਇਹ ਮੈਥਡ ਕਿੱਥੇ ਪਰਿਭਾਸ਼ਿਤ ਹੈ?" ਰੋਜ਼ਾਨਾ ਸਵਾਲ ਬਣ ਜਾਂਦਾ)।
• ਬੁਨਿਆਦੀ ਕੰਮ ਪ੍ਰੋਜੈਕਟ-ਨਿਰਧਾਰਤ ਰਿਵਾਜਾਂ ਦੀ ਯਾਦ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਨਾ ਕਿ ਮਿਆਰੀ Rails ਪੈਟਰਨ ਨਾਲ।

ਜਦੋਂ ਇਹ ਹੁੰਦਾ ਹੈ, ਉਹ ਸਮਾਂ ਜੋ ਤੁਸੀਂ ਰਿਵਾਜਾਂ ਨਾਲ ਬਚਾਇਆ ਸੀ ਆਖਰਕਾਰ onboarding, debugging, ਅਤੇ code review ਵਿੱਚ ਵਾਪਸ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਕੇਲਿੰਗ: ਅਸਲ ਟਰੇਡ-ਅਫ

Rails ਸਕੇਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਨੂੰ ਜਾਦੂ ਨਾਲ ਹਟਾਉਂਦਾ ਨਹੀਂ। convention-friendly ਕੋਡ ਵੀ ਢੀਲਾ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ queries, caching, background jobs, ਅਤੇ object allocations 'ਤੇ ਨਜ਼ਰ ਨਾ ਰੱਖੋ।

ਜਿੱਥੇ ਰਿਵਾਜ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ, ਉਹ ਹੈ ਜਦੋਂ ਤੁਸੀਂ assume ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ ਡਿਫੌਲਟ "ਹਮੇਸ਼ਾਂ ਆਪਟੀਮਲ" ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਨਾਈਵ Active Record ਵਰਤੋਂ N+1 queries ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਡਿਫੌਲਟ ਕੈਸ਼ਿੰਗ ਫੈਸਲੇ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਹੌਟ endpoint ਲਈ ਬਹੁਤ ਜਨਰਿਕ ਹੋ ਸਕਦੇ ਹਨ। ਸਕੇਲਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਮਾਪਣ, ਫਿਰ ਸੋਚ-ਵਿਚਾਰਕੇ ਸਥਿਰ ਕਰਨ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ।

ਤੇਜ਼ ਇਟਰੇਸ਼ਨ "ਕੋਈ ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਨਹੀਂ" ਨਹੀਂ ਹੈ

Rails ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਅਤੇ ਸਿੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ—ਪਰ ਤੇਜ਼ ਬਦਲਾਵ ਅਕਸਰ ਅਸਹਿਮਤਾ ਜਨਦਾ: model bloat, callback chains, ਜਾਂ business logic ਦਾ controllers ਵਿੱਚ ਵਿਖੇ ਖਿਸਕਣਾ। ਰਿਵਾਜ ਰੁਕਾਵਟ ਘਟਾਉਂਦੇ ਹਨ; ਉਹ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਹੱਦਾਂ ਨਹੀਂ ਲਗਾਉਂਦੇ।

ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ ਕਿਵੇਂ ਅਨੁਕੂਲ ਕਰੋ

ਇਰਾਦੇ ਨਾਲ ਕਸਟਮਾਈਜ਼ ਕਰੋ:

• ਪਹਿਲਾਂ ਛੋਟੇ, ਵਾਪਸ ਕਰਨਯੋਗ ਬਦਲਾਅ ਕਰੋ; ਸ਼ੁਰੂ ਵਿੱਚ ਮੂਲ ਰਿਵਾਜ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਬਚੋ।
• ਇੱਕ ਛੋਟੀ "ਸਾਡਾ Rails ਐਪ ਕਿਵੇਂ ਵੱਖਰੇ ਹੈ" ਨੋਟ ਵਿੱਚ ਅਪਵਾਦਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
• ਹੱਦਾਂ ਸਾਫ਼ ਰੱਖੋ (service objects, concerns, jobs) ਤਾਂ ਕਿ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਹਰ ਥਾਂ ਨਾਂ ਫੈਲੇ।

ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਲਚਕੀਲਾਪਨ ਕਮਾਉ ਜਾਵੇ ਬਿਨਾਂ "convention over configuration" ਨੂੰ "ਹਰ ਜਗ੍ਹਾ configuration" ਵਿੱਚ ਬਦਲਣ ਦੇ।

ਇੱਕ ਆਧੁਨਿਕ ਸਮਾਂਨੀ: ਰਿਵਾਜਾਂ vs "Vibe-Coding" ਡਿਫੌਲਟ

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

Koder.ai ਉਹੀ ਨਤੀਜਾ ਟਾਰਗਟ ਕਰਦਾ ਜੋ Rails ਪਹਿਲਾਂ ਆਪਟਿਮਾਈਜ਼ ਕਰਦਾ: ਖਿਆਲ ਤੋਂ ਚਲ ਰਹੀ ਫੀਚਰ ਤੱਕ ਛੋਟਾ ਰਾਹ। ਹੱਥੋਂ-ਵਾਇਰਿੰਗ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਗੱਲਬਾਤ ਵਿੱਚ ਆਪਣੀ ਮੁਰਾਦ ਦੱਸਦੇ ਹੋ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਇੱਕ ਅਸਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਉਸ 'ਤੇ ਇਟਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਫਿਰ Rails scaffold ਦੇ ਬਾਅਦ ਵਾਂਗ—ਵਹਿਵਾਰ, ਪਰਮਿਸ਼ਨ, ਅਤੇ UX ਨੂੰ ਸੰਵਾਰਦੇ ਹੋ—ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋ।

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

Rails ਨਾਲ ਬਣਾਉਣ ਅਤੇ ਇਟਰੇਟ ਕਰਨ ਲਈ ਪ੍ਰਯੋਗਿਕ ਨਿਸ਼ਾਨੇ

Rails ਸਭ ਤੋਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਦੀਆਂ ਰਿਵਾਜਾਂ ਨੂੰ ਆਪਣੀ ਉਤਪਾਦ ਟੀਮ ਲਈ ਡਿਫੌਲਟ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਜੋਂ ਸੁਵੀਕਾਰ ਕਰਦੇ ਹੋ—ਨਾ ਕਿ ਹਰ ਟਿਕਟ ਤੇ ਚਰਚਾ ਕਰਨ ਵਾਲਾ ਸੁਝਾਅ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਗਤੀ ਬਣੀ ਰਹੇ ਪਰ ਮਨਮਾਨੀ ਅਪਵਾਦਾਂ ਲਈ ਜਗ੍ਹਾ ਬਖ਼ਸ਼ੀ ਜਾਵੇ।

ਰਿਵਾਜਾਂ ਨੂੰ ਚੰਗਾ ਵਰਤਣ ਲਈ ਨਿਯਮ

Rails ਦੇ "ਉਮੀਦ ਕੀਤੀਆਂ" ਚੋਣਾਂ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ: ਅਨੁਮਾਨਤ ਨੈਮਿੰਗ, ਮਿਆਰੀ ਫੋਲਡਰ ਸਟਰਕਚਰ, RESTful ਰੂਟਸ, ਅਤੇ ਫਾਰਮ, ਵੈਲਿਡੇਸ਼ਨ, ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਅੰਦਰੂਨੀ ਤਰੀਕਾ।

ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਵਜੋਂ, ਪੁੱਛੋ: "ਕੀ ਨਵਾਂ ਟੀਮ-ਮੈਂਬਰ ਅਨੁਮਾਨਤ ਤੌਰ 'ਤੇ ਪਤਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਕੋਡ ਕਿੱਥੇ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ?" ਜੇ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਰਿਵਾਜ ਦੇ ਨੇੜੇ ਰਹਿ ਰਹੇ ਹੋ—ਅਤੇ ਭਵਿੱਖ ਦੇ ਬਦਲਾਅ ਸਾਸਤੇ ਰਹਿਣਗੇ।

ਇੱਕ ਹਲਕਾ ਫੈਸਲਾ ਢਾਂਚਾ

ਜਦੋਂ ਤਕ ਕੋਈ ਮਾਪਯੋਗ ਲੋੜ ਨਾ ਹੋਵੇ, ਰਿਵਾਜਾਂ ਦਾ ਪਾਲਣ ਕਰੋ। "ਮਾਪਯੋਗ" ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:

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

ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਦਰਸ਼ਾ ਸਕਦੇ, ਤਾਂ Rails ਤਰੀਕੇ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਇਹ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਦਾ ਅਤੇ ਇਟਰੇਸ਼ਨ ਨੂੰ ਸੁਗਮ ਬਣਾਉਂਦਾ।

ਅਪਵਾਦ ਛੋਟੇ ਅਤੇ ਲਿਖੇ ਹੋਏ ਰੱਖੋ

ਹਰ ਟੀਮ ਆਖ਼ਿਰਕਾਰ ਕੁਝ ਸੋਚ-ਸਮਝ ਕੇ ਵੱਖ-ਵੱਖ ਹੋਣਗੀਆਂ—service objects, ਅਲਟਰਨੇਟ ਫਾਰਮ ਪੈਟਰਨ, ਖਾਸ ਰੂਟਿੰਗ ਨਿਯਮ, ਜਾਂ ਕਸਤਮ ਕਵੇਰੀ ਰੂਟੀਨ।

ਇਨ੍ਹਾਂ ਨੂੰ ਆਪਣੀ ਰੇਪੋ ਵਿੱਚ ਇੱਕ ਛੋਟੀ "ਟੀਮ ਪਲੇਪੁੱਕ" (ਇੱਕ ਸਫ਼ਾ) ਵਿੱਚ ਰੱਖੋ। ਸ਼ਾਮਲ ਕਰੋ:

• ਅਪਵਾਦ ਕੀ ਹੈ
• ਇਸਨੂੰ ਕਦੋਂ ਵਰਤਣਾ ਹੈ (ਤੇ ਕਦੋਂ ਨਹੀਂ)
• ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਤੋਂ ਇਕ ٹھੋਸ ਉਦਾਹਰਨ

ਇਹ ਅਪਵਾਦ ਕ੍ਰੀਪ ਨੂੰ ਰੋਕਦਾ ਅਤੇ ਨਵਿਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸ਼ਿਪ ਕਰਣ ਯੋਗ ਬਣਾਂਦਾ।

ਅਸਲ ਸਿੱਖਿਆ

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