21 ਜੂਨ 2025·3 ਮਿੰਟ
Matz, Ruby, and Developer Happiness: Shaping Modern DX
Yukihiro “Matz” Matsumoto ਨੇ Ruby ਨੂੰ ਡਿਵੈਲਪਰ ਦੀ ਖੁਸ਼ੀ ਲਈ ਬਣਾਇਆ। ਜਾਨੋ ਕਿ ਇਹ ਖ਼ਿਆਲ ਕਿਵੇਂ ਫ੍ਰੇਮਵਰਕਾਂ, ਸਟਾਰਟਅੱਪ ਅਭਿਆਸਾਂ ਅਤੇ ਆਧੁਨਿਕ DX ਉਮੀਦਾਂ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ।
Yukihiro “Matz” Matsumoto ਨੇ Ruby ਨੂੰ ਡਿਵੈਲਪਰ ਦੀ ਖੁਸ਼ੀ ਲਈ ਬਣਾਇਆ। ਜਾਨੋ ਕਿ ਇਹ ਖ਼ਿਆਲ ਕਿਵੇਂ ਫ੍ਰੇਮਵਰਕਾਂ, ਸਟਾਰਟਅੱਪ ਅਭਿਆਸਾਂ ਅਤੇ ਆਧੁਨਿਕ DX ਉਮੀਦਾਂ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ।
Yukihiro “Matz” Matsumoto Ruby ਭਾਸ਼ਾ ਦੇ ਰਚਿਯਤਾ ਹਨ। 1990 ਦੇ ਦਰਮਿਆਨ Ruby ਜਦੋਂ ਉੱਭਰੀ, Matz ਦਾ ਮਕਸਦ ਕਿਸੇ benchmark ਜਿੱਤਣਾ ਜਾਂ “ਸਰਵੋਤਮ” ਅਕਾਦਮਿਕ ਭਾਸ਼ਾ ਬਣਾਉਣਾ ਨਹੀਂ ਸੀ। ਉਹ ਕੁਝ ਜ਼ਿਆਦਾ ਨਿੱਜੀ ਚਾਹੁੰਦੇ ਸਨ: ਇਕ ਐਸੀ ਭਾਸ਼ਾ ਜੋ ਵਰਤਣ ਵਿੱਚ "ਚੰਗੀ" ਮਹਿਸੂਸ ਹੋਵੇ।
ਅਕਸਰ developer happiness ਨੂੰ “ਕੋਡਿੰਗ ਨੂੰ ਮਜ਼ੇਦਾਰ ਬਣਾਉਣਾ” ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਇਸ ਦੇ ਨੇੜੇ ਹੈ: ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਘਟਾਉਣਾ ਜੋ ਧਿਆਨ ਅਤੇ ਭਰੋਸਾ ਨੁਕਸਾਨ ਪੁੰਚਾਉਂਦੀਆਂ ਹਨ।
ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਅਕਸਰ ਮਤਲਬ ਹੁੰਦਾ ਹੈ:
Ruby ਦੀ syntax ਅਤੇ ਡਿਜ਼ਾਈਨ ਇਹਨਾਂ ਤਰਜੀਹਾਂ ਨੂੰ ਮੁੱਖ ਰੱਖਦੀ ਸੀ: ਅਭਿਵਿਆਕਤਮਕ ਕੋਡ, ਦੋਸਤਾਨہ conventions, ਅਤੇ ਸਫਾਯਤ ਵੱਲ ਰੁਝਾਣ।
ਇਸ ਲੇਖ ਦਾ ਮਕਸਦ ਹੈ ਇਹ ਦਿਖਾਉਣਾ ਕਿ “ਖੁਸ਼ੀ ਪਹਿਲਾਂ” ਫਿਲਾਸਫੀ ਨੇ ਕਿਵੇਂ ਹੋਰ ਟੂਲਾਂ, ਅਭਿਆਸਾਂ ਅਤੇ ਆਮ ਉਮੀਦਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ Ruby ਨੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਛੱਡਿਆ:
ਇਹ Matz ਦੀ ਪੂਰੀ ਜੀਵਨੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਨਾਂ ਹੀ Ruby ਦੇ ਅੰਦਰੂਨੀ ਤਕਨੀਕੀ ਵਿਵਰਣ ਵਿੱਚ ਇੱਕ ਡੀਪ ਡਾਈਵ।
ਇਸ ਦੀ ਥਾਂ, ਇਹ ਵੀਖਾਂ ਕਰਦਾ ਹੈ ਕਿ “ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ ਸੁਖਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ” ਦੀ ਸਧਾਰਣ ਸੋਚ ਨੇ ਕਿਵੇਂ ਵਸੂਲਾਂ, ਆਦਤਾਂ ਅਤੇ ਨਿਯਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਜੋ ਅੱਜ ਟੀਮਾਂ ਲਈ ਆਮ ਸਮਝ ਬਣ ਚੁੱਕੀਆਂ ਹਨ।
Matz ਨੇ Ruby ਇਸ ਸਧਾਰਣ ਧਾਰਨਾ 'ਤੇ ਬਣਾਈ: ਮਨੁੱਖਾਂ ਲਈ optimize ਕਰੋ, ਮਸ਼ੀਨਾਂ ਲਈ ਨਹੀਂ। ਇਹ ਛੋਟੇ-ਛੋਟੇ ਰੋਜ਼ਾਨਾ ਮੋਮੈਂਟਾਂ ਵਿੱਚ ਦਿਖਦਾ ਹੈ — ਉਹ ਪਲ ਜਦੋਂ ਤੁਸੀਂ ਤਿੰਨ ਮਹੀਨੇ ਪੁਰਾਣਾ ਕੋਡ ਪੜ੍ਹ ਰਹੇ ਹੋ, ਜਾਂ ਇੱਕ pull request ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਰਹੇ ਹੋ, ਜਾਂ ਨਵੇਂ teammate ਨੂੰ ਇਕ ਪੈਟਰਨ ਸਿਖਾ ਰਹੇ ਹੋ ਬਿਨਾਂ ਇੱਕ rulebook ਦੇ।
Ruby ਅਕਸਰ ਤੁਹਾਨੂੰ ਮਕਸਦ ਸਿੱਧਾ ਅਭਿਵਿਕਤ ਕਰਨ ਦਿੰਦੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, 5.times { ... } ਇਕ ਵਾਕਯੇ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ user\u0026.email ਸਪਸ਼ਟ ਸੂਚਨਾ ਦਿੰਦਾ ਹੈ "ਸਿਰਫ਼ ਜੇ ਇਹ ਮੌਜੂਦ ਹੋਵੇ"। ਇਹਨੂੰ ਸਮਝਣ ਵਿੱਚ ਘੱਟ ਦਿਮਾਗੀ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਘੱਟ ਸਮਾਂ ਖਰਚਦੇ ਹੋ "ਕਮਪਿਊਟਰ-ਮੁਹਰਤ" ਕਦਮਾਂ ਨੂੰ ਮੁੜ-ਤਬਦੀਲ ਕਰਨ ਵਿੱਚ। ਜਦੋਂ ਕੋਡ ਵਿਚਾਰ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ, ਟੀਮਾਂ ਘੱਟ ਗਲਤਫਹਮੀਆਂ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਅਗੀ ਵਧ ਸਕਦੀਆਂ ਹਨ।
Ruby conventions ਤੇ ਨਿਰਭਰ ਹੈ ਜੋ ਇੱਕ ਵਾਰੀ ਸਿੱਖ ਲਈਆਂ ਜਾਣ, ਤਾਂ ਪੇਸ਼ਗੋਈ ਵਾਲੀਆਂ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: ਵਿਧੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਇਕਸਾਰ ਵਰਤਦੀਆਂ ਹਨ, ਨਾਮ ਆਮ ਤੌਰ 'ਤੇ ਲਿਟਰੇਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਟੈਂਡਰਡ ਲਾਇਬਰੇਰੀ ਜਾਣੇ-ਪਛਾਣ ਵਾਲੇ ਪੈਟਰਨ ਉੱਤੇ ਉਤਸ਼ਾਹ ਦਿੰਦੀ ਹੈ (each, map, select)। ਇਹ ਪੇਸ਼ਗੋਈ ਟੀਮ ਪੱਧਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਜਦੋਂ ਸਾਥੀ ਇਹ ਅਨੁਮਾਨ ਲਾ ਸਕਦੇ ਹਨ ਕਿ ਕੋਈ API ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ, ਉਹ ਘੱਟ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ, ਕੋਡ ਰਿਵਿਊ ਵਿਚ ਖ਼ਰੋਚ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ style debates ਹਫ਼ਤੇ ਖਾ ਨਹੀਂ ਲੈਂਦੇ। "principle of least surprise" ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਕਦੇ ਹੈਰਾਨੀ ਨਹੀਂ ਹੋਵੇਗੀ—ਪਰ ਇਹ ਵਿਅਰਥ ਹੈਰਾਨੀਆਂ ਘਟਾਉਂਦਾ ਹੈ।
Ruby ਦੀ ਲਚਕੀਲਾਪਣ ਦੋ ਧਾਰਾਂ ਵਾਲੀ ਤਰਕ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕੋ ਕੰਮ ਦੇ ਕਈ ਤਰੀਕੇ inconsistent ਕੋਡਬੇਸ ਬਣਾਉ ਸਕਦੇ ਹਨ ਜੇ ਸਹਿਮਤੀ ਅਤੇ conventions ਨਾ ਹੋਣ। dynamic typing ਕੁਝ ਗਲਤੀਆਂ ਨੂੰ compile-ਟਾਈਮ ਤੋਂ runtime 'ਤੇ ਖਿੱਚ ਸਕਦੀ ਹੈ।
ਲਾਭ ਤੇਜ਼ੀ ਅਤੇ ਸਫਾਈ ਹੈ ਜੇ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤੀ ਜਾਵੇ; ਕੀਮਤ ਸਖ਼ਤੀ ਹੈ: ਸਾਂਝੇ style, ਚੰਗੇ ਟੈਸਟ, ਅਤੇ ਐਸਾ ਸਭਿਆਚਾਰ ਜੋ ਆਉਣ ਵਾਲੇ ਪੜ੍ਹਨ ਵਾਲੇ ਦੀ ਸੋਚ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ—ਨਾ ਕਿ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਲੇਖਕ ਨੂੰ।
Rails ਨੇ Ruby ਦੀ "programmers ਨੂੰ ਖੁਸ਼ ਰੱਖੋ" ਫਿਲਾਸਫੀ ਨੂੰ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਵਰਕਫਲੋ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ: ਸੈੱਟਅਪ ਤੇ ਝਗੜਾ ਰੋਕੋ ਅਤੇ ਫੀਚਰ ਸ਼ਿਪ ਕਰੋ। Rails ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਵੱਖ-ਵੱਖ ਜੋੜਨ ਦੀ ਜਗ੍ਹਾ sensible default structure ਮੰਨਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉਸੇ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਨੁਟ ਕਰਦਾ ਹੈ।
ਵੈੱਬ ਵਿਕਾਸ ਵਿੱਚ ਪਹਿਲਾਂ ਕਾਫ਼ੀ ਨਿਰਾਸ਼ਾ repetitive ਫੈਸਲਿਆਂ ਤੋਂ ਆਉਂਦੀ ਸੀ: ਫਾਇਲਾਂ ਕਿੱਥੇ ਜਾਣ, URLs ਕਿਵੇਂ ਕੋਡ ਨਾਲ ਜੋੜੇ ਜਾਣ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ, ਕਿਹੜੇ ਨਾਮ ਵਰਤਣ। Rails conventions ਇਸ ਫੈਸਲਾ-ਭਾਰ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਜਦੋਂ framework "ਸਮਝਦਾ" ਹੈ ਕਿ User model users table ਨਾਲ ਮੈਪ ਹੁੰਦਾ ਹੈ, ਜਾਂ OrdersController ਆਰਡਰ-ਸੰਬੰਧੀ ਪੰਨਿਆਂ ਨੂੰ ਹੈਂਡਲ ਕਰੇਗਾ, ਤੁਸੀਂ wiring 'ਤੇ ਘੱਟ ਸਮਾਂ ਖਰਚਦੇ ਹੋ ਅਤੇ ਬਣਾਉਣ 'ਤੇ ਵੱਧ। ਇਹ ਸਧਾਰਣਤਾ ਜਾਦੂ ਨਹੀਂ—ਇਹ framework ਵਿੱਚ encode ਕੀਤਾ ਗਿਆ ਇੱਕ ਸਾਂਝਾ ਸਮਝੌਤਾ ਹੈ।
Rails ਨੇ ਇਹ ਵਿਚਾਰ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਕਿ ਇੱਕ ਵੈੱਬ ਐਪ ਲਈ opinionated ਸ਼ੁਰੂਆਤੀ ਨਕਸ਼ਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: routing, controllers, views, background jobs, migrations, ਅਤੇ ਇੱਕ ਸਟੈਂਡਰਡ ਫੋਲਡਰ ਲੇਆਊਟ। ਨਵੀਆਂ ਪ੍ਰੋਜੈਕਟਾਂ ਇੱਕ-ਦੂਜੇ ਵਰਗੀਆਂ ਲੱਗਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ patterns ਨਕਲ ਕਰਨਾ, ਟਿਊਟੋਰੀਅਲ ਫੋਲੋ ਕਰਨਾ ਅਤੇ ਟੀਮ ਨੋਲੇਜ ਦੁਬਾਰਾ ਵਰਤਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਇਹ "default path" ਤੇਜ਼ iteration ਨੂੰ ਵੀ ਸਮਰਥਨ ਦਿੰਦਾ: scaffolding, generators, ਅਤੇ integrated tooling ਇੱਕ IDEA ਨੂੰ ਘੱਟ ਕਦਮਾਂ ਵਿੱਚ ਕਾਰਜ ਕਰਦੇ ਹੱਕ ਵਿੱਚ ਬਦਲ ਦੇਂਦੇ ਹਨ।
ਕਿਉਂਕਿ Rails ਐਪਾਂ ਆਮ ਤੌਰ 'ਤੇ predictable ਬਣਤਰ ਅਨੁਸਰਣ ਕਰਦੀਆਂ ਹਨ, ਸਾਥੀ ਲਗਭਗ ਸਹੀ ਫਾਇਲ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭ ਲੈਂਦੇ ਹਨ—ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਨਹੀਂ ਲਿਖਿਆ। ਇਹ onboarding ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਲੋਕ conventions ਇੱਕ ਵਾਰੀ ਸਿੱਖ ਲੈਂਦੇ ਹਨ ਅਤੇ ਫਿਰ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਨੈਵੀਗੇਟ ਕਰਦੇ ਹਨ।
Conventions ਤਾਂਦੋਂ ਹੀ ਮਦਦਗਾਰ ਹੋਂਦੀਆਂ ਹਨ ਜਦੋਂ ਟੀਮ ਉਨ੍ਹਾਂ ਤੇ ਇਕੱਠੇ ਰਾਜ਼ੀ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ framework ਨੂੰ ਲਗਾਤਾਰ ਚੁਣੌਤੀ ਮਿਲ੍ਹਾ ਰਹੇ ਹੋ ਜਾਂ ਵੱਖ-ਵੱਖ patterns ਮਿਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਸਾਂਝਾ ਨਕਸ਼ਾ ਖੋ ਦੇਂਦੇ ਹੋ ਜੋ Rails ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦਾ ਹੈ।
Rails ਸਿਰਫ਼ ਸਿਰਲੇਖਨੁਮਾ ਹੈ, ਪਰ Ruby ਦਾ ecosystem ਹਮੇਸ਼ਾਂ ਵੱਖ-ਵੱਖ ਸਵਾਦਾਂ ਅਤੇ ਟੀਮਾਂ ਲਈ ਥਾਂ ਰੱਖਦਾ ਆਇਆ ਹੈ। ਇਹ ਧਰੋਹਤਾ ਹੀ ਇੱਕ ਕਾਰਨ ਹੈ ਕਿ Ruby pleasant ਰਹਿਣ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ, ਭਾਵੇਂ Rails ਹਰ ਸਥਿਤੀ ਲਈ ਠੀਕ ਨਾ ਸੀ।
ਜੇ Rails ਬਹੁਤ ਵਿਵਰਤ ਜਾਂ ਭਾਰ ਵਾਲਾ ਲੱਗੇ, ਟੀਮਾਂ ਬਹੁਤ ਵਾਰ Sinatra ਵਰਤੀਆਂ: ਘੱਟ routing, ਤੇਜ਼ endpoints, ਅਤੇ ਪਾਠਯੋਗ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਢਾਂਚਾ। Hanami ਹੋਰ explicit ਹੱਦਬੰਧੀਆਂ ਅਤੇ ਚੰਗੀ ਵੱਖਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਰੱਖਣ ਦਾ ਰਸਤਾ ਲਿਆ। ਤੁਸੀਂ ਹੋਰ ਚੋਣਾਂ ਵੀ ਵੇਖੋਗੇ ਜਿਵੇਂ Roda performance-ਕੇਂਦਰਤ apps ਲਈ ਅਤੇ Grape API-first ਸਰਵਿਸਾਂ ਲਈ।
ਮੁੱਖ ਬਿੰਦੂ: Ruby ਇੱਕ ਹੀ
ਇਹ ਇਸ ਗੱਲ ਦਾ ਖ਼ਿਆਲ ਹੈ ਕਿ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਟੂਲ ਰੋਜ਼ਾਨਾ ਆਉਣ ਵਾਲੀਆਂ ਰੁਕਾਵਟਾਂ ਘਟਾ ਕੇ ਕੰਮ ਨੂੰ ਸੁਖਦ ਬਣਾਉਣੇ ਚਾਹੀਦੇ ਹਨ: ਪਾੜ੍ਹਨਯੋਗ ਕੋਡ, ਸਹਿਜ਼ ਵਰਕਫਲੋ, ਅਤੇ ਓਹਨਾਂ ‘ਗੋੜ੍ਹੀਆਂ’ ਘਟਨਾਵਾਂ ਤੋਂ ਬਚਾਅ ਜੋ ਧਿਆਨ ਤੋੜਦੀਆਂ ਹਨ। ਇਹ “ਮਜ਼ੇ” ਬਾਰੇ ਤਾਂ ਨਹੀਂ, ਸਗੋਂ ਸਪਸ਼ਟੀ, ਭਰੋਸਾ ਅਤੇ ਬਣਾਈ ਰੱਖਣ ਦੇ ਲਾਇੱਕਤਾ ਬਾਰੇ ਹੈ।
Ruby ਨੂੰ ਮਨੁੱਖਾਂ ਲਈ optimize ਕੀਤਾ ਗਿਆ ਸੀ: ਅਭਿਵਿਆਕਤਮਕ syntax, ਲਗਾਤਾਰ ਨਾਮ-ਰਖਾਈ ਅਤੇ iteration ਪੈਟਰਨ (each, map, select), ਅਤੇ ਐਸਾ ਧਿਆਨ ਕਿ ਕੋਡ ਲਿਖਣ ਵਾਲੀ ਸੋਚ ਦੇ ਨੇੜੇ ਹੀ ਪੜ੍ਹੇ। ਉਦੇਸ਼ ਇਹ ਸੀ ਕਿ “ਮੈਂ ਕੀ ਸੋਚਦਾ/ਦੀ ਹਾਂ” ਅਤੇ “ਮੈਨੂੰ ਕੀ ਲਿਖਣਾ ਪੈਂਦਾ” ਵਿਚਕਾਰ ਘਟੋ-ਘਟਾਈ ਹੋਵੇ।
ਇਹ ਨਿਯਮ ਹੈ ਕਿ ਇਕ ਵਾਰ ਤੁਸੀਂ conventions ਸਿੱਖ ਲੈਓ, ਤਾਂ ਆਮ ਤੌਰ ਤੇ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਾ ਸਕਦੇ ਹੋ ਕਿ ਕੋਈ API ਜਾਂ ਪੈਟਰਨ ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ—ਇਸ ਤਰ੍ਹਾਂ ਅਚਾਨਕ ਹੈਰਾਨੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਹ ਟੀਮਾਂ ਨੂੰ ਕੋਡ ਰਿਵਿਊ ਤੇ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਅਤੇ ਫੈਸਲੇ-ਸਬੰਧੀ ਬਹਿਸਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਉਤਪਾਦ ਵਧਾਉਣ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੀਆਂ।
Ruby ਦੀ ਲਚਕੀਲਾਪਣ ਬਹੁਤ ਸਹਿਯੋਗੀ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਇਸ ਦੇ ਨੁਕਸਾਨ ਵੀ ਹਨ: ਇਕੋ ਕੰਮ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ inconsistent ਕੋਡਬੇਸ ਬਣਾ ਸਕਦੇ ਹਨ, ਤੇ dynamic typing ਕੁਝ ਗਲਤੀਆਂ ਨੂੰ runtime 'ਤੇ ਲਿਆ ਆਉਂਦਾ ਹੈ.
ਫਾਇਦੇ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ:
Rails ਸਾਂਝੇ defaults (ਨਾਮਕਰਨ, ਫੋਲਡਰ ਬਣਤਰ, routing conventions, ਮਾਡਲ/ਟੇਬਲ ਨਕਸ਼ਾ) encode ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਦਾ ਫ਼ੈਸਲਾ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਨਾ ਕਰਨਾ ਪਏ। ਇਹ ਫੈਸਲਾ-ਥਕਾਵਟ ਅਤੇ ਸੈੱਟਅਪ ਦਾ ਕੰਮ ਘਟਾਉਂਦਾ ਅਤੇ ਟੀਮਾਂ ਨੂੰ wiring ਦੀ ਬਜਾਏ ਫੀਚਰਾਂ ਉੱਤੇ ਧਿਆਨ ਦੇਣ ਲਾਇਕ ਬਣਾਉਂਦਾ।
ਜਦੋਂ Rails ਜ਼ਿਆਦਾ opinionated ਜਾਂ heavy ਲੱਗੇ, ਤਾਂ ਟੀਮਾਂ ਅਕਸਰ ਹੋਰ ਮਿੰਨੀਮਲ ਫ੍ਰੇਮਵਰਕ ਵਰਤਦੀਆਂ ਹਨ:
ਚੋਣ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਡਿਗਰੀ ਦਾ ਫ੍ਰੇਮਵਰਕ ਚਾਹੀਦਾ ਹੈ।
Ruby/Rails ਉਹਨਾਂ ਪ੍ਰੋਡਕਟਾਂ ਲਈ ਉਚਿਤ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਲੋੜਾਂ ਅਕਸਰ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ iteration ਦੀ رفتار ਮੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ: SaaS, marketplace, admin/internal tools, ਅਤੇ ਕਿਸੇ ਵੀ ਵੈੱਬ-ਭਾਰਤੀ ਵਰਕਫਲੋ ਜਿੱਥੇ UI, ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਵਰਕਫਲੋ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ। ਜਿੱਥੇ raw throughput ਜਾਂ low-latency compute ਮੁੱਖ ਗੱਲ ਹੋਵੇ, ਉੱਥੇ Ruby ਘੱਟ ਵਰਤੋਂ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ।
ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਣ ਵਾਲੇ ਹਥਿਆਰ:
bundle exec — ਪ੍ਰੋਜੈਕਟ ਦੇ ਜਾਣੇ-ਮਾਨੇ environment ਦੇ ਅੰਦਰ ਚਲਾਉਣ ਦਾ ਰਵਾਇਤੀ ਤਰੀਕਾਇਹ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਦੇ ਕੰਮ ਨੂੰ ਸਿਹਤਮੰਦ ਅਤੇ predictable ਬਣਾਉਂਦੀਆਂ ਹਨ।
Ruby ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ tests ਦੀ ਖਿਆਲ ਨੂੰ ਆਮ ਬਣਾਇਆ। RSpec readable, behavior-focused specs (describe/it ਸਟਾਈਲ) ਨਾਲ ਮਨਸੂਬੇ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਸੀ; Minitest ਹਲਕਾ ਫਰਮਾ ਦਿੱਦਾ।
ਵਰਤੋਂ ਵਿੱਚ, tests ਨੇ refactor ਕਰਨਾ ਵਧੇਰੇ ਨਿਰਭਰਤਾਪੂਰਕ ਬਣਾਇਆ ਅਤੇ regressions ਨੂੰ ਘੱਟ ਕੀਤਾ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ local runs ਤੇ CI ਫੇਡਬੈਕ ਤੇਜ਼ ਹੋਵੇ।
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ Ruby ਐਪ ਨੂੰ ਇਹਨਾਂ ਰਸਤੇ ਨਾਲ scale ਕਰਦੀਆਂ ਹਨ:
ਪਲੇਟਫਾਰਮ ਬਦਲਣ ਉਸ ਸਮੇਂ ਤਰਕਸੰਗਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ CPU saturation ਲਗਾਤਾਰ ਰਹਿੰਦੀ ਹੋਵੇ, ਖਰਚਾ ਬੇਹੁਦਾ ਵਧ ਰਿਹਾ ਹੋਵੇ, ਜਾਂ ਕਮਪਿਊਟ-ਭਾਰਤਾ ਕਾਰਜ low-latency ਮੰਗਦੇ ਹੋਣ। ਕਈ ਟੀਮ ਕੋਰ ਐਪ ਲਈ Ruby ਰੱਖ ਕੇ hotspots ਨੂੰ ਵਿਸ਼ੇਸ਼ ਸਰਵਿਸਾਂ 'ਤੇ ਆਫਲੋਡ ਕਰਦੀਆਂ ਹਨ।