ਇਸ ਦੇਖੋ ਕਿ DHH ਅਤੇ Ruby on Rails ਨੇ "convention over configuration" ਨੂੰ ਕਿਵੇਂ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਵੈੱਬ ਐਪ ਤੇਜ਼ ਬਣੀਆਂ, ਬੋਇਲਰਪਲੇਟ ਘੱਟ ਹੋਇਆ ਅਤੇ ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ ਤੇਜ਼ ਹੋਈ।

Rails ਤੋਂ ਪਹਿਲਾਂ, ਵੈੱਬ ਐਪ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਲੰਬੀ “ਸੈਟਅੱਪ ਟੈਕਸ” ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਸੀ। ਤੁਸੀਂ ਫੋਲਡਰ ਸਟਰਕਚਰ ਚੁਣਦੇ (ਜਾਂ ਬਣਾਉਂਦੇ) ਸੀ, URL ਨੂੰ ਕੋਡ ਨਾਲ ਕਿਵੇਂ ਮੈਪ ਕਰਨਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਹੱਥੋਂ ਵਾਇਰ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਅਤੇ ਉਹੀ ਗਲੂ ਕੋਡ ਵਾਰੀ-ਵਾਰੀ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ। ਇਹ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦਾ—ਪਰ ਫਿਰ ਵੀ ਦਿਨ ਖਤਮ ਹੋ ਜਾਂਦੇ।
ਇਸ ਤੋਂ ਦੂਜਾ ਟੁਰਾਂDecision fatigue ਸੀ। ਛੋਟੇ ਫੈਸਲੇ—ਫਾਈਲ ਨਾਮ, ਬਿਜ਼ਨਸ ਲੋਜਿਕ ਕਿੱਥੇ ਰੱਖਣੀ ਹੈ, ਟੈਸਟ ਕਿਵੇਂ ਠੀਕ ਕਰਣੇ—ਬਾਰ-ਬਾਰ ਫਿਰ ਤੋਂ ਨਿਗੋਸ਼ੀਏਟ ਹੋਣੇ ਪੈਂਦੇ। ਟੀਮ ਅਤੇ ਵਧ ਰਹੇ ਕੋਡਬੇਸ ਨਾਲ ਇਹ ਸਭ ਮੀਟਿੰਗਾਂ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਅਤੇ ਅਸਮਾਨਤ ਪੈਟਰਨਾਂ ਵਿੱਚ ਗੁਮ ਹੋ ਜਾਂਦਾ।
Rails ਇੱਕ ਸਧਾਰਨ ਵਾਅਦਾ ਫੈਲਾਇਆ: ਜੇ ਤੁਸੀਂ ਆਮ ਤਰੀਕੇ ਨੂੰ ਫੋਲੋ ਕਰੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਨੂਂ ਕਨਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਏਗੀ। ਇਹੀ “convention over configuration” ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਹੈ।
ਰੇਲਜ਼ ਤੁਹਾਡੇ ਬਦਲੇ ਹਰ ਸੈਟਿੰਗ ਮੰਗਣ ਦੀ ਥਾਂ ਤਰਕਸ਼ੀਲ ਡਿਫੌਲਟ ਮੰਨ ਲੈਂਦਾ ਹੈ:
ਜਦੋਂ ਫਰੇਮਵਰਕ ਪਹਿਲਾਂ ਹੀ “ਜਾਣਦਾ” ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਮੁਰਾਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਘੱਟ ਬੋਇਲਰਪਲੇਟ ਲਿਖਦੇ ਹੋ ਅਤੇ ਪਹਿਲੇ ਸਕ੍ਰੀਨਾਂ ਤੇ ਜਲਦੀ ਪਹੁੰਚਦੇ ਹੋ।
ਤੇਜ਼ੀ ਸਿਰਫ ਨਾ ਲਾਈਨਾਂ ਘੱਟ ਲਿਖਣ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਰਿਵਾਜਾਂ ਇਸ ਗੱਲ ਨੂੰ ਬਦਲ ਦਿਤਾ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ:
ਇਸ ਲੇਖ ਦਾ ਕੇਂਦਰ ਇਹ ਹੈ ਕਿ Rails ਰਿਵਾਜਾਂ ਵਿਚਾਰ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੋਂ ਵਿੱਚ ਕਿਵੇਂ ਰਾਹ ਘਟਾਉਂਦੇ ਹਨ—ਖ਼ਿਆਲ ਤੋਂ ਚਲ ਰਹੀ ਫੀਚਰ ਤੱਕ ਦੇ ਰਾਹ ਨੂੰ ਛੋਟਾ ਕਰਦੇ ਹਨ—ਬਿਨਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਜਾਂ ਫਰੇਮਵਰਕ ਦੀ ਪੂਜਾ ਕਰਨ ਦੇ। ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਕੋਈ ਇੱਕ ਵਿਅਕਤੀ ਜਾਂ ਫਰੇਮਵਰਕ “ਜਾਦੂਈ” ਹੈ, ਬਲਕਿ ਚੰਗੇ ਡਿਫੌਲਟ ਨਿਰਧਾਰਨਤੱਕ ਦੀ ਘਟਨਾ ਨੂੰ ਦੂਰ ਕਰਦੇ ਹਨ।
David Heinemeier Hansson—ਆਮ ਤੌਰ 'ਤੇ DHH—Ruby on Rails ਦੇ ਬਣਾਉਣ ਵਾਲੇ ਹਨ। ਉਹ Rails ਨੂੰ 37signals (ਹੁਣ Basecamp) 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋਏ ਬਣਾਇਆ ਅਤੇ 2004 ਵਿੱਚ ਇਸਨੂੰ open source ਵਜੋਂ ਜਨਤਾ ਲਈ ਰਿਲੀਜ਼ ਕੀਤਾ। ਇਹ ਸਮਾਂ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ Rails ਕਿਸੇ ਖਾਲੀ ਕਮਰੇ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੋਇਆ: ਇਹ ਇੱਕ ਅਸਲ ਉਤਪਾਦ ਸਪਰੈਸ਼ਰ ਤੋਂ ਰੁੱਬ ਹੋ ਕੇ ਬਣਿਆ।
Rails Basecamp ਦੇ ਇਕ ਅੰਦਰੂਨੀ ਫਰੇਮਵਰਕ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ। ਕਿਸੇ ਵੱਡੇ ਸਿਧਾਂਤ ਨਾਲ ਨਹੀਂ ਕਿ ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ, DHH ਨੇ ਉਹ ਹਿੱਸੇ ਬਾਹਰ ਕੱਢੇ ਜੋ بار بار ਲੋੜੀਂਦੇ ਸਨ: ਰाउंटਿੰਗ, ਕੋਡ ਦਾ ਆਯੋਜਨ, ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲਬਾਤ, HTML ਰੇਂਡਰ ਕਰਨਾ, ਅਤੇ ਆਮ ਵੈੱਬ ਪੈਟਰਨ ਸਾਂਭਣਾ।
ਕਿਉਂਕਿ ਇਹ ਉਤਪਾਦੀ ਲੋੜਾਂ ਤੋਂ ਆਇਆ, Rails ਰੋਟੀਨ ਕੰਮਾਂ ਤੋਂ ਰੁਕਾਵਟ ਹਟਾਉਣ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ। ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਸਭ ਕੁਝ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ—ਇਹ ਆਮ ਹਾਲਤ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ।
Rails ਨੂੰ ਅਕਸਰ "opinionated" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਸਧਾਰਨ ਲਫ਼ਜ਼ਾਂ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ Rails ਤੁਹਾਡੇ ਲਈ ਫੈਸਲੇ ਲੈਂਦਾ—ਖਾਸ ਕਰਕੇ ਸਟਰਕਚਰ ਅਤੇ ਡਿਫੌਲਟ ਬਾਰੇ—ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਨਾ ਕਰਨੀਆਂ ਪੈਣ।
ਉਦਾਹਰਨ ਲਈ, ਇਹ ਟੀਮਾਂ ਨੂੰ ਇਸ ਵੱਲ ਧੱਕ ਦੇਂਦਾ:
ਇਹ ਰਾਏਆਂ ਤੁਹਾਡੇ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣੀ ਹੁੰਦੀਆਂ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਘੱਟ ਫੈਸਲੇ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੀ ਵਰਜਨ ਤੇਜ਼ ਅਤੇ ਇਟਰੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
Rails ਸਿਰਫ ਕੋਡ ਨਹੀਂ ਦਿੱਤਾ; ਇਸ ਨੇ ਵੈੱਬ ਐਪਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਇੱਕ ਸਾਂਝਾ ਢੰਗ ਬਣਾਇਆ। ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਟੀਮਾਂ ਇੱਕੋ ਹੀ ਕਨਵੇਂਸ਼ਨਾਂ ਫੋਲੋ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਾਂਝਾ ਸ਼ਬਦਾਵਲੀ ਬਣ ਜਾਂਦੀ ਹੈ ("models", "migrations", "scaffolds", "RESTful routes") ਅਤੇ ਟ੍ਰਾਂਸਫਰੇਬਲ ਹੁਨਰ। ਇਹ ਔਨਬੋਰਡਿੰਗ ਦਾ ਸਮਾਂ ਘੱਟ ਕਰਦਾ, ਮਦਦ ਲੱਭਣਾ ਆਸਾਨ ਬਣਾਂਦਾ ਅਤੇ "ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਕਰੀਏ?" ਨੂੰ "Rails ਲਈ ਇਸਦਾ ਮਿਆਰ ਪਹਿਲਾਂ ਹੀ ਹੈ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ।
Rails ਨੇ ਇੱਕ ਸਿੱਧੀ ਗੱਲ ਪ੍ਰਸਿੱਧ ਕੀਤੀ: ਆਮ ਹਾਲਤ ਲਈ, ਫਰੇਮਵਰਕ ਨੂੰ sahi ਅਨ ਦਰਸਾ ਲੈਣਾ ਚਾਹੀਦਾ ਤਾਂ ਕਿ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਖੁੱਲ ਕੇ ਨਹੀਂ ਦੱਸਣੀ ਪਏ। ਤੁਹਾਨੂੰ ਕੋਡ ਕਿਵੇਂ ਆਯੋਜਿਤ ਹੈ, ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ, ਅਤੇ ਡੇਟਾ ਡੇਟਾਬੇਸ ਨਾਲ ਕਿਵੇਂ ਮੈਪ ਹੁੰਦਾ—ਇਹਨਾਂ ਲਈ ਬੇਹਤਰ ਡਿਫੌਲਟ ਮਿਲਦੇ ਹਨ। ਤੁਸੀਂ ਸਿਰਫ਼ ਉਹੀ ਚੀਜ਼ ਕਨਫਿਗਰ ਕਰੋ ਜੋ ਵੀਖਤੀ ਹੈ।
"Convention over configuration" ਦਾ ਮਤਲਬ ਹੈ ਕਿ Rails ਮੰਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਆਮ ਵੈੱਬ ਐਪ ਬਣਾ ਰਹੇ ਹੋ—ਯੂਜ਼ਰ, ਪੰਨੇ, ਫਾਰਮ, ਡੇਟਾਬੇਸ ਟੇਬਲ—ਅਤੇ ਇਹ ਹਰ ਇੱਕ ਚੀਜ਼ ਲਈ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਦਿੰਦਾ। ਜੇ ਤੁਸੀਂ ਕਨਵੇਂਸ਼ਨਾਂ ਦਾ ਪਾਲਣ ਕਰੋਗੇ, ਤਾਂ ਹਿੱਸੇ ਘੱਟ ਸੈਟਅੱਪ ਨਾਲ "ਸਿੱਧੇ ਜੁੜ ਜਾਂਦੇ" ਹਨ।
ਇਹ ਉਸ ਤਰ੍ਹਾਂ ਦੇ ਅਪ੍ਰੋਚ ਤੋਂ ਵੱਖਰਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੇ ਪਹਿਲੇ ਕਦਮ ਅਕਸਰ ਸੈਟਿੰਗਾਂ ਬਣਾਉਣ ਅਤੇ ਸੰਭਾਲਣ ਤੇ ਲੰਘਦੇ ਹਨ: ਵਾਧੂ ਫਾਈਲਾਂ, ਮੈਨਿਫੈਸਟ, ਜਾਂ ਬੇਅੰਤ ਫਲੈਗ ਜੋ ਤੁਹਾਡੇ ਐਪ ਦੀਆਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਗੱਲਾਂ ਨੂੰ ਵਰਣਨ ਕਰਦੇ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਨੂੰ ਦੱਸਣ ਵਿੱਚ ਸਮਾਂ ਗੁਜ਼ਾਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ, ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।
Rails ਨਾਮਕ ਨੈਮਿੰਗ ਅਤੇ ਸਥਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਿੱਸਿਆਂ ਨੂੰ ਆਪੋ-ਆਪ ਬੰਨ੍ਹਦਾ ਹੈ:
Article ਨਾਂ ਦਾ ਮਾਡਲ ਹੈ, Rails articles ਨਾਂ ਦੀ ਡੇਟਾਬੇਸ ਟੇਬਲ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।ArticlesController ਨਾਂ ਦਾ ਇੱਕ ਕੰਟਰੋਲਰ ਆਰਟਿਕਲਾਂ ਨਾਲ ਜੁੜੇ URL ਅਤੇ ਐਕਸ਼ਨਾਂ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ।app/models/article.rb ਅਤੇ app/controllers/articles_controller.rb ਵਿੱਚ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।ਕਿਉਂਕਿ Rails ਜਾਣਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਕਿਵੇਂ ਕਾਲ ਕਰਨਾ ਹੈ, ਤੁਸੀਂ ਦੁਹਰਾਉਂਦੇ ਵਾਇਰਿੰਗ ਤੋਂ ਬਚਦੇ ਹੋ। ਤੁਸੀਂ ਫੀਚਰ ਲਿਖਦੇ ਹੋ, ਗਲੂ ਨਹੀਂ।
ਕੀਮਤ ਪਹਿਲਾਂ ਘੱਟ ਆਜ਼ਾਦੀ ਹੈ: ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਸਟਮ ਸਟਰਕਚਰ ਜਾਂ ਅਸੰਪਰਤੀ ਨੈਮਿੰਗ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਵੱਧ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਪਏ (ਅਤੇ ਤੁਸੀਂ ਉਮੀਦਾਂ ਦੇ ਵਿਰੁੱਧ ਤੈਰ ਰਹੇ ਹੋ)। ਲਾਭ ਤੇਜ਼ੀ ਅਤੇ ਇਕਸਾਰਤਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਕਈ ਲੋਕ ਇਕੋ ਹੀ ਕੋਡਬੇਸ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਸਾਂਝੇ ਪੈਟਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
Rails ਨੇ MVC ਨੂੰ ਵਿਆਪਕ ਦਰਸ਼ਕਾਂ ਲਈ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਨਾ ਕਿ ਇਸਨੂੰ ਖੋਜ ਕੇ, ਬਲਕਿ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਕੇ। MVC ਸਭ ਤੋਂ ਆਸਾਨ ਤਰ੍ਹਾਂ ਸਮਝ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਤਿੰਨ ਜਿੰਮੇਵਾਰੀਆਂ ਵਜੋਂ ਸੋਚੋ:
ਤੇਜ਼ੀ ਦਾ ਫਾਇਦਾ Rails ਦੀਆਂ ਰਿਵਾਜਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜੋ ਇਹਨਾਂ ਪਰਤਾਂ ਨੂੰ ਆਪੋ-ਆਪ ਜੋੜ ਦਿੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ PostsController ਬਣਾਉਂਦੇ ਹੋ, Rails app/controllers/posts_controller.rb ਵਿੱਚ ਇਸਦੀ ਉਮੀਦ ਕਰੇਗਾ। ਇੱਕ Post ਮਾਡਲ app/models/post.rb ਵਿੱਚ ਰਹੇਗਾ। ਉਸ ਕੰਟਰੋਲਰ ਲਈ ਵਿਊਜ਼ ਕੁਦਰਤੀ ਤੌਰ app/views/posts/ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ।
ਜਿਵੇਂ ਕਿ ਨਾਂ ਅਤੇ ਥਾਵਾਂ ਅਨੁਮਾਨਤ ਹਨ, Rails ਬਹੁਤ ਕੁਝ ਅਨੁਮਾਨ ਲਾ ਸਕਦਾ ਹੈ: ਰੂਟਸ controller ਐਕਸ਼ਨਾਂ ਨੂੰ ਮੈਪ ਕਰਦੇ ਹਨ, controller ਐਕਸ਼ਨ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਮੇਚਿੰਗ ਵਿਊ ਟੈਮਪਲੇਟ ਰੇਂਡਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਮਾਡਲ ਆਪਣਾ ਨਾਂ ਡੇਟਾਬੇਸ ਟੇਬਲ ਨਾਲ ਮਿਲਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਵਿਹਵਾਰ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹੋ—ਪਰ ਤੁਹਾਨੂੰ ਹਰ ਫੈਸਲੇ 'ਤੇ ਪਹਿਲਾਂ ਨਾ ਸੋਚਣਾ ਪਏ।
ਜਦੋਂ ਹਰ Rails ਐਪ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਆਯੋਜਿਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਔਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ। ਟੀਮ-ਮੇਟ ਪਤਾ ਕਰ ਲੈਂਦੇ ਹਨ ਕਿ ਵੈਲਿਡੇਸ਼ਨ ਕਿੱਥੇ ਮਿਲੇਗੀ, ਟੈਂਪਲੇਟ ਕਿੱਥੇ ਰਹੇਗੀ, ਅਤੇ ਇਕ ਫੀਚਰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਬਣਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ "ਕੋਡ ਕਿੱਥੇ ਹੈ?" ਸਮੇਂ ਨੂੰ ਘੱਟ ਕਰਦਾ ਅਤੇ "ਚੇਜ਼ ਨੂੰ ਸ਼ਿਪ ਕਰੋ" ਸਮੇਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।
ਇੱਕ ਆਮ ਰਾਹਦਾਰੀ ਹੈ fat model, skinny controller: controllers ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਰੀਯੂਜ਼ਬਲ ਨਿਯਮ models ਵਿੱਚ ਰੱਖੋ। ਇਹ endpoints ਵਿੱਚ ਨਕਲ ਕੀਤੀ ਲਾਜਿਕ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਹੱਦ: ਤੁਹਾਡੇ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਵਰਕਫਲੋ ਇੱਕ Active Record ਮਾਡਲ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ। ਜਿਵੇਂ-ਜਿਵੇਂ ਐਪ ਵੱਧਦਾ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ service objects ਜਾਂ form objects ਲਿਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ models ਹੋਰ ਚੀਜ਼ਾਂ ਲਈ ਡੰਪਿੰਗ ਗ੍ਰਾਊਂਡ ਨਾ ਬਣ ਜਾਣ—ਫਿਰ ਵੀ controllers ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ।
Rails scaffolding ਇੱਕ ਸ਼ਾਰਟਕਟ ਹੈ ਜੋ ਇੱਕ ਫੀਚਰ ਦੀ ਕੰਮ ਕਰਨ ਵਾਲੀ ਬੇਸਲਾਈਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਕਮਾਂਡ ਨਾਲ, Rails ਇੱਕ ਮਾਡਲ, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਕੰਟਰੋਲਰ ਐਕਸ਼ਨ, ਰੂਟਸ, ਅਤੇ ਬੁਨਿਆਦੀ ਵਿਊਜ਼ Create/Read/Update/Delete (CRUD) ਲਈ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਸਲਾਈਡ ਡੈੱਕ ਜਾਂ ਮੌਕਅੱਪ ਨਹੀਂ—ਇਹ ਐਪ ਦਾ ਇੱਕ ਚਲਣ ਵਾਲਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕਲਿਕ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ scaffold "ਬੋਰੀਂਗ ਪਰ ਜ਼ਰੂਰੀ" ਹਿੱਸਿਆਂ ਨੂੰ ਵਾਇਰ ਕਰ ਦਿੰਦਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਵਿਚਾਰ ਨੂੰ ਪ੍ਰੂਵ ਕਰ ਸਕੋ:
ਇਹ ਮੁੱਦਾ ਇਸ ਲਈ ਵੱਡਾ ਹੈ ਕਿਉਂਕਿ ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ ਅਕਸਰ ਸੈੱਟਅੱਪ ਕੰਮ 'ਤੇ ਟਿਕ ਜਾਂਦੀ ਹੈ। Scaffolding ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਬਾਇਪਾਸ ਕਰਨ ਅਤੇ ਇੱਕ ਅਸਲ ਚੀਜ਼ ਤੋਂ ਸਿੱਖਣ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
Scaffolding ਨੂੰ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਜਨਰੇਟਰ ਵਜੋਂ ਵੇਖਣਾ ਵਧੀਆ ਹੈ। ਡਿਫੌਲਟ ਵਿਊਜ਼ ਸਧਾਰਨ ਹੁੰਦੀਆਂ ਹਨ, UX ਘੱਟ-ਸੁੰਦਰ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕੋਡ ਸਧਾਰਨ ਅਨੁਮਾਨ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਫੀਚਰ ਹੈ, ਨਾ ਕਿ ਖਾਟ;
ਇਹ ਤੁਹਾਨੂੰ scaffolds ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਜੋਂ ਦੇਖਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ "ਅਖੀਰ ਦਾ ਡਿਜ਼ਾਇਨ"।
ਅਕਸਰ ਸਿਹਤਮੰਦ ਵਰਕਫਲੋ ਇਹ ਹੁੰਦੀ ਹੈ:
ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਫਿਰ ਵੀ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਤੁਸੀਂ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੋਗੇ, ਆਥਰਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਕਸਨਾ ਪਏਗਾ, ਅਤੇ ਏਰਰ ਹੈਂਡਲਿੰਗ ਨੂੰ ਸੁਧਾਰਨਾ ਪਏਗਾ। ਅਤੇ ਕਿਉਂਕਿ scaffold ਕੀਤੀਆਂ ਪੇਜ਼ ਯੂਟਿਲਿਟੇਰੀ ਹੁੰਦੀਆਂ ਹਨ, ਅਸਲ UX ਕੰਮ—ਕਾਪੀ, ਲੇਆਊਟ, ਪਹੁੰਚਯੋਗਤਾ, ਅਤੇ ਐਜ਼-ਕੇਸਾਂ—ਲਈ ਸਮਾਂ ਰੱਖੋ। Scaffolding ਪਹਿਲਾ ਡਰਾਫਟ ਤੇਜ਼ ਕਰਦਾ ਹੈ; ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।
Rails ਸਿਰਫ਼ ਕਨਵੇਂਸ਼ਨਾਂ ਨੂੰ ਸਿਧਾਂਤ ਵਿੱਚ ਨਹੀਂ ਲਿਆਇਆ—ਇਸ ਨੇ ਉਹਨਾਂ ਨੂਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਿੱਚ ਜਨਰੇਟਰ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਨੈਮਿੰਗ ਨਿਯਮਾਂ ਰਾਹੀਂ ਜੋੜ ਦਿੱਤਾ। ਇਹ ਏਕਤਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਕੋਡਬੇਸ ਇਕ-ਆਫ਼ ਫੈਸਲਿਆਂ ਦੇ ਢੇਰ ਵਿੱਚ ਬਦਲ ਜਾਣ ਦੇ।
Rails ਜਨਰੇਟਰ ਸਿਰਫ "ਫਾਈਲਾਂ ਬਣਾਉਂਦਾ" ਨਹੀਂ। ਇਹ ਉਮੀਦ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਉਮੀਦ ਕੀਤੀਆਂ ਥਾਵਾਂ 'ਚ ਉਮੀਦ ਕੀਤਿਆਂ ਨਾਮਾਂ ਨਾਲ ਬਣਾਉਂਦਾ—ਮਾਡਲ app/models ਵਿੱਚ, ਕੰਟਰੋਲਰ app/controllers ਵਿੱਚ, ਟੈਸਟ ਸਹੀ ਫੋਲਡਰ ਵਿੱਚ, ਅਤੇ ਅਹਿਮ ਗੱਲ: ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜੋ ਡੇਟਾਬੇਸ ਰਚਨਾ ਨੂੰ ਅਪਡੇਟ ਕਰਦੀ ਹੈ।
ਕਿਉਂਕਿ Rails ਨੈਮਿੰਗ (User -> users ਟੇਬਲ ਵਰਗੀਆਂ) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਜਨਰੇਟ ਕੀਤੀਆਂ ਚੀਜ਼ਾਂ ਘੱਟ ਵਾਇਰਿੰਗ ਨਾਲ ਜੁੜ ਜਾਦੀਆਂ ਹਨ। ਘੱਟ ਸਮਾਂ ਇਸ ਗੱਲ 'ਤੇ ਲੱਗਦਾ ਕਿ ਕੁਝ ਕਿੱਥੇ ਜਾਂ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ, ਅਤੇ ਵੱਧ ਸਮਾਂ ਫੀਚਰ ਨੂੰ ਸੂਰਤ ਦੇਣ 'ਤੇ ਲੱਗਦਾ ਹੈ।
Migrations ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਐਸਾ ਕੁਝ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਐਪ ਦੇ ਨਾਲ-ਨਾਲ ਵਿਕਸਤ ਹੁੰਦਾ। "ਡੇਟਾਬੇਸ ਹੋ ਗਿਆ, ਹੁਣ ਅਸੀਂ ਕੋਡ ਕਰੀਏ" ਦੀ ਬਜੇ, Rails ਇੱਕ ਸਥਿਰੀ ਰਿਥਮ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ: ਫੀਚਰ ਬਣਾਓ, ਸਕੀਮਾ ਸੁਧਾਰੋ, ਅਸਲ ਉਪਭੋਗ ਤੋਂ ਸਿੱਖੋ, ਫਿਰ ਸੁਧਾਰੋ।
ਹਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਇੱਕ ਛੋਟਾ, ਟਾਈਮਸਟੈਂਪਡ ਕਦਮ ਹੁੰਦਾ ਜੋ ਸਮੀਖਿਆ, ਵਰਜਨ ਕੰਟਰੋਲ, ਅਤੇ ਵਾਤਾਵਰਣਾਂ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਟਰੇਟਿਵ ਉਤਪਾਦ ਬਦਲਾਵ—ਫੀਲਡ ਜੋੜਨ, ਪਾਬੰਦੀਆਂ ਠੀਕ ਕਰਨ, ਨਵੀਂ ਟੇਬਲਾਂ ਲਿਆਂਦੇ—ਟਾਈਮ ਨਾਲ ਘੱਟ ਖ਼ਤਰਨਾਕ ਹੁੰਦੇ ਹਨ।
ਕਹੋ ਤੁਸੀਂ ਉਪਭੋਗੀਆਂ ਵਿੱਚ role ਜ਼ੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ:
rails g migration AddRoleToUsers role:stringrails db:migrateUser ਵਿੱਚ ਵੈਲਿਡੇਸ਼ਨ ਜੋੜੋ (ਅਤੇ ਸ਼ਾਇਦ enum)ਇਹ ਇਕ ਤੰਗ ਲੂਪ ਹੈ: ਸਕੀਮਾ ਬਦਲਾਅ ਅਤੇ ਐਪ ਬਦਲਾਅ ਇਕੱਠੇ ਚਲਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ "ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਨਹੀਂ" ਵਾਲੇ ਕੋਲਮ ਜਾਂ ਐਸੀ ਕੋਡ ਨਾ ਰਹਿ ਜਾਵੇ ਜੋ ਡੇਟਾ ਮੌਜੂਦ ਹੋਣ ਦਾ ਅਸਥਿਰ ਅਨੁਮਾਨ ਕਰਦਾ ਹੋਵੇ।
ਤੇਜ਼ੀ ਸਿਰਫ਼ ਓਹੇ ਤਕ ਟਿਕਦੀ ਹੈ ਜਦੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਾਫ਼ ਰੱਖੇ ਜਾਂਦੇ ਹਨ: ਜਦ ਤਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਬਦਲੇ ਹੋਏ ਨਹੀਂ, ਉਨ੍ਹਾਂ ਨੂੰ ਸੋਧਣ ਤੋਂ ਬਚੋ, ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਵਾਪਸ ਕਰਨਯੋਗ ਬਦਲਾਅ ਲਿਖੋ, ਅਤੇ ਸਕੀਮਾ ਬਦਲਾਅ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡ ਵਾਂਗ ਹੀ ਸਮੀਖਿਆ ਕਰਕੇ ਨਾਂ ਰੱਖੋ। Rails ਇਟਰੇਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ; ਟੀਮਾਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ ਜਿਸ ਨਾਲ ਲਗਾਤਾਰ ਅਨੁਕੂਲਤਾ ਬਣੀ ਰਹਿੰਦੀ ਹੈ।
"Don't repeat yourself" (DRY) ਦਾ ਸਧਾਰਨ ਵਿਚਾਰ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਹਰ ਗਿਆਨ ਦਾ ਇੱਕ ਸਾਫ਼ ਸਰੋਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵੈੱਬ ਐਪ ਵਿੱਚ, ਦੁਹਰਾਉ ਅਕਸਰ ਅੱਚਾਨਕ ਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹੀ ਧਾਰਨਾ ਕਈ ਥਾਵਾਂ 'ਤੇ ਲਿਖੀ ਜਾਂਦੀ ਹੈ—ਰੂਟਸ, ਕੰਟਰੋਲਰ ਲਾਜਿਕ, ਵਿਊ ਟੈਂਪਲੇਟ, ਅਤੇ ਖ਼ਤੋ-ਖ਼ਤੋ ਡੇਟਾਬੇਸ ਕਵੇਰੀज़ ਵਿੱਚ।
ਕਲਪਨਾ ਕਰੋ ਤੁਸੀਂ 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 ਰਿਵਾਜ DRY ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਨਾਂ ਅਤੇ ਸਟਰਕਚਰ 'ਤੇ "ਸਹਿਮਤ" ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ RESTful ਰੂਟਸ (resources :posts) ਵਰਤਦੇ ਹੋ, Rails PostsController ਵਿੱਚ ਮਿਆਰੀ ਐਕਸ਼ਨਾਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ app/views/posts/show.html.erb ਵਰਗੀਆਂ ਪਾਥਾਂ 'ਤੇ ਵਿਊਜ਼ ਲਭਦਾ ਹੈ।
ਇਨ੍ਹਾਂ ਟੁਕੜਿਆਂ ਦੇ ਲਾਈਨ-ਅਪ ਹੋਣ ਕਾਰਨ, ਤੁਸੀਂ ਘੱਟ ਗਲੂ ਕੋਡ ਲਿਖਦੇ ਹੋ। ਇੱਕ ਲਿੰਕ ਹੈਲਪਰ ਜਿਵੇਂ link_to @post.title, @post ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ Rails ਮਾਡਲ ਇੰਸਟੈਂਸ ਤੋਂ ਸਹੀ ਰੂਟ ਅਨੁਮਾਨ ਲਾ ਸਕਦਾ ਹੈ। ਪਾਰਸ਼ਲ ਨੈਮਿੰਗ ਕਨਵੇਂਸ਼ਨ (render @posts) ਹਰ ਆਈਟਮ ਲਈ posts/_post ਆਟੋਮੈਟਿਕ ਚੁਣ ਸਕਦਾ ਹੈ।
DRY ਨੂੰ ਬਹੁਤ ਅਗੇ ਵਧਾਉਣਾ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ: ਬਹੁਤ ਹੀ ਛੋਟੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨ, ਮੈਟਾ-ਪ੍ਰੋਗਰਾਮਿੰਗ, ਜਾਂ "ਇੱਕ ਮੈਥਡ ਜੋ ਸਭ ਕੁਝ ਸੰਭਾਲੇ" ਲਾਈਨਾਂ ਬਚਾ ਸਕਦਾ ਹੈ ਪਰ ਸਮਝ ਦੀ ਕੀਮਤ ਤੇ। ਕੁਝ ਦਾਹਰ-ਦੁਹਰਾਅ ਕਈ ਵਾਰ ਸਪਸ਼ਟ ਰਹਿਣ ਲਈ ਠੀਕ ਹੁੰਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਵਿਊਜ਼ ਅਤੇ ਬਿਜ਼ਨਸ ਲੋਜਿਕ ਵਿੱਚ। ਲਕਸ਼ ਹੈ ਰੱਖਠਣਯੋਗਤਾ, ਨਾ ਕਿ ਘੱਟ ਤੋਂ ਘੱਟ ਚਰित्र ਗਿਣਤੀ।
Rails ਉਹਨਾਂ ਹਾਲਤਾਂ ਲਈ ਮਸ਼ਹੂਰ ਹੈ ਜੋ "ਖੁਸ਼ੀ ਦਾ路" (happy path) ਅਪਟੀਮਾਈਜ਼ ਕਰਦੀਆਂ ਹਨ: ਉਹ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਆਮ ਡੇਟਾਬੇਸ-ਅਧਾਰਿਤ ਵੈੱਬ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਬਨਾਉਣ ਅਤੇ ਸ਼ਿਪ ਕਰਨ 'ਚ ਸਹਾਇਤਾ ਦਿੰਦਾ। ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਯੂਜ਼ਰ, ਫਾਰਮ, ਵੈਲਿਡੇਸ਼ਨ, CRUD ਸਕ੍ਰੀਨਸ, ਰੂਟਸ, ਈਮੇਲ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, ਅਤੇ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਰਤੋਂਗੇ—ਅਤੇ ਇਹ ਮਾਰਗ ਸੁਗਮ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਖੁਸ਼ੀ ਰਸਤੇ ਦੀ ਵਿਕਾਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਜਿਆਦਾਤਰ ਸਮਾਂ "ਸਧਾਰਨ" ਚੀਜ਼ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਫਰੇਮਵਰਕ ਨਾਲ ਜੂੰਝਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਮਾਡਲ Order ਨਾਮ ਰੱਖਦੇ ਹੋ, Rails orders ਟੇਬਲ ਦੀ ਉਮੀਦ ਕਰਦਾ, ਜਾਣਦਾ ਹੈ ਕਿ ਫਾਈਲ ਕਿੱਥੇ ਰਹੇਗੀ, ਅਤੇ ਕੰਟਰੋਲਰ, ਵਿਊਜ਼, ਅਤੇ ਰੂਟਸ ਕਿਵੇਂ ਮਿਲਣੇ ਚਾਹੀਦੇ—ਤਾਂ ਕਿ ਤੁਸੀਂ ਹਰ ਚੋਣ ਨੂੰ ਸਬੂਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਮਹਿਸੂਸ ਕਰੋ।
ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਕੋਲ ਬੇਅੰਤ ਪਹਿਲੇ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ: ਫੋਲਡਰ ਸਟਰਕਚਰ, ਨੈਮਿੰਗ, ਕਨਫਿਗਰੇਸ਼ਨ ਸਟਾਈਲ, ਟੈਸਟ ਸੈਟਅੱਪ, ਫਾਰਮਸ ਨੂੰ ਸੰਭਾਲਣਾ, ਬਿਜ਼ਨਸ ਲੋਜਿਕ ਕਿੱਥੇ ਰੱਖਣਾ। Rails ਜ਼ਰੂਰੀ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਦਿੰਦਾ।
ਇਹ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ ਫੈਸਲੇ ਦੀ ਥਕਾਵਟ ਅਸਲੀ ਹੈ: ਜਿਹਨੇ ਵੱਧ ਛੋਟੇ-ਛੋਟੇ ਚੋਇਸ ਤੁਸੀਂ ਲੈਂਦੇ ਹੋ, ਉਹਨੀ ਦੇ ਨਾਲ ਤੁਸੀਂ ਢੀਰੇ ਹੋ ਜਾਂਦੇ ਹੋ—ਅਤੇ ਟੀਮ ਮੈਂਬਰਾਂ ਲਈ ਪਤਾ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਕੀਤਾ। Rails ਡਿਫੌਲਟ ਇੱਕ "ਠੀਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ" ਬਣਾਉਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੁਰੰਤ ਫੀਚਰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕੋ ਅਤੇ ਸਿਰਫ਼ ਜਦੋਂ ਜ਼ਰੂਰਤ ਹੋਵੇ ਅਨੁਕੂਲਤਾ ਕਰੋ।
ਉਤਪਾਦ ਇਟਰੇਸ਼ਨ ਦਾ ਮਕਸਦ ਵੱਧ (ਅਤੇ ਵਧੀਆ) ਪ੍ਰਯੋਗ ਚਲਾਉਣਾ ਹੈ: ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ, ਦੇਖੋ ਉਪਭੋਗੀ ਕੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਢਾਲੋ। Rails ਇਸ ਰਿਥਮ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ:
ਛੋਟੇ ਨਿਰਮਾਣ ਸਮੇਂ ਦਾ ਨਤੀਜਾ ਛੋਟੇ ਫੀਡਬੈਕ ਲੂਪ ਹਨ—ਅਤੇ ਇੱਥੇ ਤੇਜ਼ੀ ਸਿੱਖਣ ਵਿੱਚ ਬਦਲਦੀ ਹੈ।
Rails ਡਿਫੌਲਟ ਤਜੇ ਕਿ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਅਜਿਹੀ ਹੋਵੇ: ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਡੋਮੇਨ, ਅਤਿ-ਵੱਡੇ ਸਕੇਲ ਦੀਆਂ ਮੰਗਾਂ, ਕੜੇ ਨਿਯਮਤੀਆਂ ਪਾਬੰਦੀਆਂ, ਜਾਂ ਅਸਾਹਮਣੀ ਡੇਟਾ ਸਟੋਰੇਜ ਅਤੇ ਵਰਕਫਲੋਜ਼। ਇਨ੍ਹਾਂ ਹਾਲਤਾਂ 'ਚ ਤੁਸੀਂ ਕਈ ਵਾਰ ਕਨਵੇਂਸ਼ਨਾਂ ਨੂੰ ਮੋੜਨ 'ਤੇ ਵਧੇਰੇ ਸਮਾਂ ਲਗਾਉਂਦੇ ਹੋ। ਕੰਜੀਆਂ ਇਹ ਜਾਣਣ ਦੀ ਹਨ ਕਿ ਡਿਫੌਲਟ ਕਦੋਂ ਮਦਦ ਕਰ ਰਹੇ ਹਨ—ਅਤੇ ਕਦੋਂ ਤੁਸੀਂ ਜਾਣ-ਬੁਝ ਕੇ ਰਾਹ ਛੱਡਣਾ ਚਾਹੁੰਦੇ ਹੋ।
Rails ਸਿਰਫ਼ ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕੀਤਾ—ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ। "Rails way" ਅਸਲ ਵਿੱਚ ਸਾਂਝੀਆਂ ਉਮੀਦਾਂ ਦਾ ਇਕ ਸੈੱਟ ਹੈ: ਫਾਈਲਾਂ ਕਿੱਥੇ ਰਹਿੰਦੀਆਂ ਹਨ, ਕਲਾਸਾਂ ਦਾ ਨਾਂ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਰਿਕਵੈਸਟ ਕੰਟਰੋਲਰ ਤੋਂ ਵਿਊਜ਼ ਤੱਕ ਕਿਵੇਂ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਕਿਵੇਂ ਮਾਡਲ ਹੁੰਦਾ। ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਜੈਕਟ ਇੱਕੋ ਜਿਹੇ ਪੈਟਰਨ ਫੋਲੋ ਕਰਦੇ ਹਨ, ਤਾਂ ਟੀਮ-ਮੇਟਾਂ ਨੂੰ ਸਟਰੱਕਚਰ ਡਿਕੋਡ ਕਰਨ 'ਚ ਘੱਟ ਸਮਾਂ ਲੱਗਦਾ ਅਤੇ ਫੀਚਰ ਸ਼ਿਪ ਕਰਨ 'ਤੇ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ।
ਰਿਵਾਜ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਰਹੇ ਫੈਸਲਿਆਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
app/models, ਕੰਟਰੋਲਰ app/controllers, ਵਿਊਜ਼ app/views ਵਿੱਚPostsController Post ਨੂੰ ਮੈਨੇਜ ਕਰਦਾ)index, show, create, ਆਦਿ)ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਜਾਦੂਈ ਨਹੀਂ। ਇਕੱਠੇ ਇਹ "ਅਸੀਂ ਇੱਥੇ ਇਹੀ ਕਰੇਗੇ" ਵਾਲੇ ਗੱਲ-ਬਾਤਾਂ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ।
ਜਦੋਂ ਨਵਾਂ ਡਿਵੈਲਪਰ ਜੁੜਦਾ ਹੈ, Rails ਰਿਵਾਜ ਇਮਾਰਤ ਦੇ ਨਿਸ਼ਾਨਾਂ ਵਰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਤੁਸੀਂ ਬਿਨਾਂ ਗਾਈਡ ਟੂਰ ਦੇ ਜ਼ਰੂਰਤ ਆਸਾਨੀ ਨਾਲ ਲੋੜੀਂਦੀ ਚੀਜ਼ ਲੱਭ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਔਨਬੋਰਡਿੰਗ ਸਮਾਂ ਘਟਦਾ ਅਤੇ ਗਿਆਨ ਇਕ ਵਿਅਕਤੀ ਦੇ ਸਿਰ 'ਤੇ ਫੈਸਲਿਆ ਰਹਿਣ ਦਾ ਖਤਰਾ ਘਟਦਾ ਹੈ।
ਰਿਵਾਜ ਕੋਡ ਸਮੀਖਿਆਵਾਂ ਨੂੰ ਵੀ ਸੁਧਾਰਦੇ ਹਨ। ਸਮੀਖਿਆ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਡਕਟ ਲਾਜਿਕ, ਐਜ ਕੇਸ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਫੋਲਡਰ ਸਟਰਕਚਰ 'ਤੇ ਚਰਚਾ ਕਰਨ ਤੇ। ਜਦੋਂ ਇੱਕ ਡਿਫੌਲਟ ਹੁੰਦਾ ਹੈ, ਤਰਕ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਵੱਖਰੇ ਰਾਹ ਦੀ ਚੋਣ ਕਰ ਰਹੇ ਹੋ।
ਉਲਟ ਪਾਸਾ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਪੈਰੋਕਾਰਤਾ ਵਜੋਂ ਰਿਵਾਜ ਫੋਲੋ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਸਿਹਤਮੰਦ ਹੈ ਕਿ ਅਪਵਾਦਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਤਰਕਸ਼ੀਲ ਕੀਤਾ ਜਾਵੇ—ਖ਼ਾਸ ਕਰਕੇ ਅਜਿਹੇ ਡੋਮੇਨ, ਸਕੇਲਿੰਗ ਪਾਬੰਦੀਆਂ, ਜਾਂ ਸੁਰੱਖਿਆ ਦੀਆਂ ਲੋੜਾਂ ਲਈ—ਫਿਰ ਵੀ Rails ਡਿਫੌਲਟਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇ।
Rails ਨੇ ਆਪਣੀ "batteries included" ਖੁਬੀ ਨਾਲ ਇਕ ਵੈੱਬ ਐਪ ਨੂੰ ਇਕ ਸੰਪੂਰਨ ਉਤਪਾਦ ਵਜੋਂ ਵੇਖਿਆ, ਨਾ ਕਿ ਅਲੱਗ-ਅਲੱਗ ਭਾਗਾਂ ਦਾ ਪਜ਼ਲ। ਰਾਉਟਿੰਗ, ਟੈਂਪਲੇਟਿੰਗ, ਬੈਕਗ੍ਰਾਉਂਡ ਵਰਕ, ਈਮੇਲ, ਫ਼ਾਇਲ ਅੱਪਲੋਡ, ਸੁਰੱਖਿਆ ਡਿਫੌਲਟ, ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਸਟੈਕ ਨੂੰ ਜੋੜਨ ਦੀ ਬਜਾਏ, Rails ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੰਨ੍ਹਾ ਦੇਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਆਉਂਦਾ।
ਜ਼ਿਆਦਾਤਰ ਵੈੱਬ ਉਤਪਾਦ ਪਹਿਲੇ ਦੌਰਾਨ ਉਹੀ ਮੀਲ ਸਟੋਨ ਹਿੱਟ ਕਰਦੇ ਹਨ: ਯੂਜ਼ਰ ਅਕਾਊਂਟ, ਫਾਰਮ, ਵੈਲਿਡੇਸ਼ਨ, ਡੇਟਾਬੇਸ ਬਦਲਾਅ, ਈਮੇਲ ਭੇਜਣ, ਐਰਰ ਹੈਂਡਲਿੰਗ, ਅਤੇ ਭਰੋਸੇਮੰਦ ਤਰੀਕੇ ਨਾਲ ਡਿਪਲੌਇਮੈਂਟ। Rails ਇਨ੍ਹਾਂ ਦੁਹਰਾਏ ਜਾ ਰਹੇ ਲੋੜਾਂ 'ਤੇ ਬਣੇ ਮਿਆਰੀ ਪੈਟਰਨ ਅਤੇ ਸੈਂਸਿਬਲ ਡਿਫੌਲਟਸ ਨਾਲ ਉਮੀਦ ਰੱਖਦਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੀਮਾਂ ਘੱਟ ਸਮਾਂ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਗੁਜ਼ਾਰਦੀਆਂ ਕਿ ਕਿਹੜੀ ਲਾਇਬ੍ਰੇਰੀ ਚੁਣੀ ਜਾਵੇ ਜਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਵੇ, ਅਤੇ ਵੱਧ ਸਮਾਂ ਫੀਚਰ ਨੂੰ ਨਿਖਾਰਣ 'ਤੇ ਲਾਉਂਦੀਆਂ ਹਨ।
ਜਦੋਂ "ਮਿਆਰੀ" ਰਸਤਾ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਹੋਵੇ, ਤਾਂ ਸ਼ਿਪ ਕਰਨਾ ਅਰਥ ਹੈ ਕਿ ਐਪ-ਵੱਖ-ਵੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਭਰਨਾ—ਮਾਡਲ, ਨੀyam, ਅਤੇ UI—ਨਹੀਂ ਕਿ ਹਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਲਈ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣ।
ਤੇਜ਼ੀ ਸਿਰਫ ਟੂਲ ਹੋਣ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਇਸ ਗੱਲ ਬਾਰੇ ਵੀ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਮਿਲਦੇ ਹਨ। ਮਿਲੇ-ਝੁਲੇ ਸੈੱਟਅੱਪ ਵਿੱਚ, ਕਾਫ਼ੀ ਕੋਸ਼ਿਸ਼ ਗਲੂ ਕੋਡ ਵਿੱਚ ਲੱਗਦੀ ਹੈ: ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਰਮੈਟ ਨੂੰ ਦੂਜੇ ਨਾਲ ਮੇਲ ਬਣਾਉਣਾ, ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲੇ ਰਿਵਾਜਾਂ ਨੂੰ ਮਿਲਾਉਣਾ, ਜਾਂ ਲਾਗਿੰਗ, ਇੰਸਟ੍ਰੂਮੇਨਟੇਸ਼ਨ, ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ ਵਰਗੀਆਂ ਚਿੰਤਾਵਾਂ ਨਕਲ ਕਰਨਾ।
Rails ਆਪਣੀਆਂ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਸਾਂਝੇ ਰਿਵਾਜਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੰਟੀਗ੍ਰੇਟ ਕਰਕੇ ਇਸ ਤਣਾਅ ਨੂੰ ਘੱਟ ਕਰਦਾ। ਡੇਟਾ ਵੈਲਿਡੇਸ਼ਨ, ਡੇਟਾਬੇਸ ਪਰਸਿਸਟੈਂਸ, ਅਤੇ ਵਿਊਜ਼ ਰੈਂਡਰਿੰਗ ਲਗਾਤਾਰ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਐਰਰਜ਼ ਇੱਕ ਨਿਰਧਾਰਿਤ ਢੰਗ ਵਿੱਚ ਉਭਰਦੇ ਹਨ। ਕਨਫਿਗਰੇਸ਼ਨ ਆਮ ਥਾਵਾਂ 'ਤੇ ਰਹਿੰਦੀ ਹੈ। ਨਤੀਜਾ ਘੱਟ "ਗਲੂ ਕੋਡ" ਅਤੇ ਘੱਟ ਐਕਸਪੇਰੀਮੈਂਟਲ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ ਜੋ ਡਿਲਿਵਰੀ ਨੂੰ ਧੀਮਾ ਕਰਦੇ ਹਨ ਅਤੇ रख-ਰਖਾਵ ਨੂੰ ਜਟਿਲ ਬਣਾਉਂਦੇ ਹਨ।
ਤੰਗ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਾ ਉਲਟ ਪਾਸਾ ਇਹ ਹੈ ਕਿ ਅੱਪਗ੍ਰੇਡਸ ਦਾ ਪ੍ਰভাব ਵਿਆਪਕ ਹੋ ਸਕਦਾ ਹੈ। ਜਦੋਂ Rails ਡਿਫੌਲਟਾਂ ਨੂੰ ਬਦਲਦਾ ਜਾਂ ਕਿਸੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨੂੰ ਡਿਪ੍ਰਿਕੇਟ ਕਰਦਾ, ਤਾਂ ਐਪ ਦੇ ਕਈ ਹਿੱਸਿਆਂ 'ਤੇ ਇੱਕ ਵਾਰੀ ਧਿਆਨ ਲਾਉਣਾ ਪੈਂਦਾ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਾਗਤ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਦੈਨਿਕ ਡਿਲਿਵਰੀ ਤੇਜ਼ੀ ਅਤੇ ਸੰਗਠਨ ਬਨ੍ਹੇ ਰਹਿਣ ਦੇ ਫਾਇਦੇ ਕਈ ਵਾਰੀ ਘੱਟੋ-ਘੱਟ ਅਪਗ੍ਰੇਡ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲੋਂ ਵੱਧ ਹੁੰਦੇ ਹਨ—ਪਰ ਇਹ ਇੱਕ ਅਸਲੀ ਕਾਰਕ ਹੈ ਜੋ ਯੋਜਨਾ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
Rails ਰਿਵਾਜਾਂ ਇੱਕ ਗਤੀ ਵਧਾਉਣ ਵਾਲਾ ਕਾਰਨ ਬਣਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੇ ਨੇੜੇ ਰਹਿੰਦੇ ਹੋ। ਪਰ ਉਹੀ ਰਿਵਾਜਾਂ ਤੁਹਾਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਫਰੇਮਵਰਕ ਨੂੰ ਉਸ ਰੂਪ ਵਿੱਚ ਮੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ 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 ਵਿੱਚ ਵਿਖੇ ਖਿਸਕਣਾ। ਰਿਵਾਜ ਰੁਕਾਵਟ ਘਟਾਉਂਦੇ ਹਨ; ਉਹ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਹੱਦਾਂ ਨਹੀਂ ਲਗਾਉਂਦੇ।
ਇਰਾਦੇ ਨਾਲ ਕਸਟਮਾਈਜ਼ ਕਰੋ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਲਚਕੀਲਾਪਨ ਕਮਾਉ ਜਾਵੇ ਬਿਨਾਂ "convention over configuration" ਨੂੰ "ਹਰ ਜਗ੍ਹਾ configuration" ਵਿੱਚ ਬਦਲਣ ਦੇ।
Rails ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਸੰਰਚਨਾ ਨੂੰ ਸਧਾਰਨ ਕੀਤਾ: ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਜਾਂਦੀਆਂ, ਉਹਨਾਂ ਦਾ ਕਿਵੇਂ ਨਾਮ ਹੁੰਦਾ, ਅਤੇ ਪੀਸੇ ਕਿਵੇਂ ਜੁੜਦੇ। ਅਜਿਹੀ ਗਤੀ ਦਿਣ ਵਾਲੀ ਇੱਕ ਢੰਗ-ਨੈਅ ਸਥਿਤੀ ਅੱਜ "vibe-coding" ਪਲੈਟਫਾਰਮਾਂ ਨਾਲ ਉਭਰੀ ਹੋਈ ਹੈ, ਜਿਵੇਂ Koder.ai, ਜਿੱਥੇ "ਡਿਫੌਲਟ" ਫੋਲਡਰ ਲੇਆਊਟ ਤੋਂ ਘੱਟ ਅਤੇ ਇਰਾਦੇ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਐਪ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਜ਼ੋਰ ਹੁੰਦਾ ਹੈ।
Koder.ai ਉਹੀ ਨਤੀਜਾ ਟਾਰਗਟ ਕਰਦਾ ਜੋ Rails ਪਹਿਲਾਂ ਆਪਟਿਮਾਈਜ਼ ਕਰਦਾ: ਖਿਆਲ ਤੋਂ ਚਲ ਰਹੀ ਫੀਚਰ ਤੱਕ ਛੋਟਾ ਰਾਹ। ਹੱਥੋਂ-ਵਾਇਰਿੰਗ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਗੱਲਬਾਤ ਵਿੱਚ ਆਪਣੀ ਮੁਰਾਦ ਦੱਸਦੇ ਹੋ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਇੱਕ ਅਸਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਉਸ 'ਤੇ ਇਟਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਫਿਰ Rails scaffold ਦੇ ਬਾਅਦ ਵਾਂਗ—ਵਹਿਵਾਰ, ਪਰਮਿਸ਼ਨ, ਅਤੇ UX ਨੂੰ ਸੰਵਾਰਦੇ ਹੋ—ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋ।
ਨੀਵੀਂ ਸਿੱਖਿਆ ਇੱਕੋ ਜਿਹੀ ਰਹਿੰਦੀ ਹੈ: ਜਦੋਂ ਸ਼ੁਰੂਆਤੀ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਫੈਸਲੇ ਇਕ ਵਾਰੀ ਲਿਆਂਦੇ ਜਾਂਦੇ ਹਨ (ਫਰੇਮਵਰਕ ਜਾਂ ਪਲੈਟਫਾਰਮ ਦੁਆਰਾ), ਟੀਮਾਂ ਉਨ੍ਹਾਂ ਡਿਫੌਲਟਾਂ 'ਤੇ ਬਣਾਕੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੀਆਂ ਹਨ।
Rails ਸਭ ਤੋਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਦੀਆਂ ਰਿਵਾਜਾਂ ਨੂੰ ਆਪਣੀ ਉਤਪਾਦ ਟੀਮ ਲਈ ਡਿਫੌਲਟ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਜੋਂ ਸੁਵੀਕਾਰ ਕਰਦੇ ਹੋ—ਨਾ ਕਿ ਹਰ ਟਿਕਟ ਤੇ ਚਰਚਾ ਕਰਨ ਵਾਲਾ ਸੁਝਾਅ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਗਤੀ ਬਣੀ ਰਹੇ ਪਰ ਮਨਮਾਨੀ ਅਪਵਾਦਾਂ ਲਈ ਜਗ੍ਹਾ ਬਖ਼ਸ਼ੀ ਜਾਵੇ।
Rails ਦੇ "ਉਮੀਦ ਕੀਤੀਆਂ" ਚੋਣਾਂ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ: ਅਨੁਮਾਨਤ ਨੈਮਿੰਗ, ਮਿਆਰੀ ਫੋਲਡਰ ਸਟਰਕਚਰ, RESTful ਰੂਟਸ, ਅਤੇ ਫਾਰਮ, ਵੈਲਿਡੇਸ਼ਨ, ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਅੰਦਰੂਨੀ ਤਰੀਕਾ।
ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਵਜੋਂ, ਪੁੱਛੋ: "ਕੀ ਨਵਾਂ ਟੀਮ-ਮੈਂਬਰ ਅਨੁਮਾਨਤ ਤੌਰ 'ਤੇ ਪਤਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਕੋਡ ਕਿੱਥੇ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ?" ਜੇ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਰਿਵਾਜ ਦੇ ਨੇੜੇ ਰਹਿ ਰਹੇ ਹੋ—ਅਤੇ ਭਵਿੱਖ ਦੇ ਬਦਲਾਅ ਸਾਸਤੇ ਰਹਿਣਗੇ।
ਜਦੋਂ ਤਕ ਕੋਈ ਮਾਪਯੋਗ ਲੋੜ ਨਾ ਹੋਵੇ, ਰਿਵਾਜਾਂ ਦਾ ਪਾਲਣ ਕਰੋ। "ਮਾਪਯੋਗ" ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਦਰਸ਼ਾ ਸਕਦੇ, ਤਾਂ Rails ਤਰੀਕੇ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਇਹ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਦਾ ਅਤੇ ਇਟਰੇਸ਼ਨ ਨੂੰ ਸੁਗਮ ਬਣਾਉਂਦਾ।
ਹਰ ਟੀਮ ਆਖ਼ਿਰਕਾਰ ਕੁਝ ਸੋਚ-ਸਮਝ ਕੇ ਵੱਖ-ਵੱਖ ਹੋਣਗੀਆਂ—service objects, ਅਲਟਰਨੇਟ ਫਾਰਮ ਪੈਟਰਨ, ਖਾਸ ਰੂਟਿੰਗ ਨਿਯਮ, ਜਾਂ ਕਸਤਮ ਕਵੇਰੀ ਰੂਟੀਨ।
ਇਨ੍ਹਾਂ ਨੂੰ ਆਪਣੀ ਰੇਪੋ ਵਿੱਚ ਇੱਕ ਛੋਟੀ "ਟੀਮ ਪਲੇਪੁੱਕ" (ਇੱਕ ਸਫ਼ਾ) ਵਿੱਚ ਰੱਖੋ। ਸ਼ਾਮਲ ਕਰੋ:
ਇਹ ਅਪਵਾਦ ਕ੍ਰੀਪ ਨੂੰ ਰੋਕਦਾ ਅਤੇ ਨਵਿਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸ਼ਿਪ ਕਰਣ ਯੋਗ ਬਣਾਂਦਾ।
ਰਿਵਾਜ ਸਿਰਫ਼ ਕੋਡਿੰਗ ਪREFERENCES ਨਹੀਂ ਹਨ। ਜੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤੇ ਜਾਣ, ਇਹ ਇੱਕ ਉਤਪਾਦ ਰਣਨੀਤੀ ਦਾ ਸਾਜ਼-ਸਮਾਨ ਹਨ: ਇਹ ਫੈਸਲਿਆਂ ਦੀ ਭਾਰ ਘਟਾਉਂਦੇ ਹਨ, ਫੀਡਬੈਕ ਲੂਪ ਛੋਟੇ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਯੂਜ਼ਰਾਂ ਤੋਂ ਸਿੱਖਣ 'ਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਦਿੰਦੇ ਹਨ ਨਾ ਕਿ ਸਰੰਜਾਮ ਦੀ ਬਣਤਰ 'ਤੇ ਤਰਕਸ਼ੀਲ ਕਰਨ 'ਤੇ।