ਜਾਣੋ ਕਿ Ruby ਨੇ ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ ਨੂੰ ਕੇਂਦਰ ਰੱਖ ਕੇ Rails ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਅਤੇ ਕੰਵੈਂਸ਼ਨ, ਟੂਲਿੰਗ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਰਾਹੀਂ ਆਧੁਨਿਕ ਵੈੱਬ ਫ੍ਰੇਮਵਰਕਾਂ ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੱਤਾ।
“ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ” ਇੱਕ ਨਾਅਰਾ ਜਿਹਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਅਮਲੀ ਰੂਪ ਵਿੱਚ, ਇਹ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਦਾ ਰੋਜ਼ਾਨਾ ਅਹਸਾਸ ਹੈ: ਪੜ੍ਹਨਯੋਗ ਕੋਡ, ਇਕਸਰ APIs, ਅਤੇ ਵਰਕਫਲੋ ਜੋ ਤੁਹਾਨੂੰ flow ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਨਾ ਕਿ ਤੁਹਾਨੂੰ ਆਪਣੇ ਟੂਲਾਂ ਨਾਲ ਲੜਨ਼ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।
ਇਸਦਾ ਮਤਲਬ ਘੱਟ ਹੈਰਾਨੀਆਂ ਵੀ ਹੈ—ਸਪਸ਼ਟ error ਸੁਨੇਹੇ, ਸਮਝਦਾਰ defaults, ਅਤੇ ਐਸੇ ਪੈਟਰਨ ਜੋ ਹਰ ਟੀਮ ਨੂੰ ਉਹੀ ਫੈਸਲੇ ਮੁੜ-ਖੋਜਣ 'ਤੇ ਨਾਜ਼ਰ ਨਹੀਂ ਕਰਨ ਦਿੰਦੇ।
ਇਸ ਲੇਖ ਵਿੱਚ, ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ ਦਾ ਮਤਲਬ ਹੈ:
Ruby 1990 ਦੇ ਮੱਧ ਵਿੱਚ ਉਭਰੀ, ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਦਰਸਤੀ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂ ਕਠੋਰ ਫਾਰਮੈਲਿਟੀ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀਆਂ ਸਨ। ਬਹੁਤੀਆਂ ਤਾਕਤਵਰ ਤਾਂ ਸਨ, ਪਰ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਲਈ ਰੁਕਾਵਟੀ ਜਾਂ ਲੰਬੀਆਂ ਲਾਈਨਾਂ ਵਾਲੀਆਂ ਲੱਗਦੀਆਂ ਸਨ।
Ruby ਓਹੋ ਹੀ ਨਾ ਸੀ—ਇਸਨੇ ਪ੍ਰੋਗ੍ਰਾਮਰ ਅਨੁਭਵ ਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਡਿਜ਼ਾਇਨ ਲਕਸ਼ ਬਣਾਇਆ। ਭਾਸ਼ਾ ਨੂੰ ਵਿਕਾਸਕਾਂ ਨੂੰ ਅਡਾਪਟ ਕਰਨ ਦੀ ਬਜਾਏ, Ruby ਨੇ ਉਨ੍ਹਾਂ ਦੇ ਸੋਚਣ ਅਤੇ ਲਿਖਣ ਦੇ ਢੰਗ ਨਾਲ ਢਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ।
ਇਹ ਪੀਸ ਵੇਖਦੀ ਹੈ ਕਿ Ruby ਦੀਆਂ ਕੀਮਤਾਂ ਨੇ Rails ਨੂੰ ਕਿਵੇਂ ਸੰਵਾਰਿਆ ਅਤੇ Rails ਰਾਹੀਂ ਇੱਕ ਪੀੜ੍ਹੀ ਦੇ ਵੈੱਬ ਫ੍ਰੇਮਵਰਕਾਂ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਪਾਇਆ:
ਅਸੀਂ ਵਪਾਰ-ਆਧਾਰਤ ਟ੍ਰੇਡਆਫ਼ਾਂ ਬਾਰੇ ਵੀ ਸਚਬੋਲਾਂਗੇ। “ਖੁਸ਼ੀ” ਸਦਾ ਸਾਦਗੀ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ: opinionated defaults ਪਿੱਛੇ-ਪਿੱਛੇ ਸੀਮਾਬੱਧ ਮਹਿਸੂਸ ਹੋ ਸਕਦੇ ਹਨ, “ਜਾਦੂ” ਜਟਿਲਤਾ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਜਦ ਸਿਸਟਮ ਵੱਡੇ ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂ ਰੱਖ-ਰਖਾਅ ਸੰਬੰਧੀ ਚਿੰਤਾਵਾਂ ਸਾਹਮਣੇ ਆ ਸਕਦੀਆਂ ਹਨ। ਹਦਫ ਸਬਕ ਕੱਢਣਾ ਹੈ—ਹਾਇਪ ਨਹੀਂ।
Yukihiro Matsumoto—ਜੋ “Matz” ਦੇ ਤੌਰ 'ਤੇ ਵੱਧ ਜਾਣੇ ਜਾਂਦੇ ਹਨ—ਨੇ 1990 ਦੇ ਮੱਧ ਵਿੱਚ Ruby ਬਣਾਈ ਇੱਕ ਸਾਫ, ਬੇਮਿਸਾਲ ਨਿੱਜੀ ਲਕਸ਼ ਦੇ ਨਾਲ: ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਮਨੋਰੰਜਕ ਬਣਾਉ। ਉਹ Ruby ਨੂੰ ਇੱਕ ਐਸੀ ਭਾਸ਼ਾ ਵਜੋਂ ਤੇ ਵਾਰ-ਵਾਰ ਦਰਸਾਉਂਦੇ ਰਹੇ ਹਨ ਜੋ ਡਿਵੈਲਪਰ ਦੀ ਖੁਸ਼ੀ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰੇ, ਸਿਰਫ਼ ਮਸ਼ੀਨ ਕੁਸ਼ਲਤਾ ਨਹੀਂ। ਇਸ ਨੇ syntax ਤੋਂ ਲੈ ਕੇ ਕਮਿਊਨਿਟੀ ਨਿਯਮਾਂ ਤੱਕ ਹਰ ਚੀਜ਼ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ।
Ruby ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਸਬੰਧਿਤ ਇੱਕ ਮੁੱਖ ਵਿਚਾਰ “ਘੱਟੋ-ਘੱਟ ਹੈਰਾਨੀ ਦਾ ਸਿਧਾਂਤ” ਹੈ: ਜਦ ਤੁਸੀਂ ਕੋਡ ਪੜ੍ਹਦੇ ਹੋ, ਨਤੀਜਾ ਇੱਕ ਵਾਜਿਬ ਵਿਕਾਸਕ ਦੀ ਉਮੀਦ ਦੇ ਅਨੁਸਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ ਹੈ ਕਿ Ruby ਆਮ “ਖਾਲੀ” ਹਾਲਤਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ। ਇੱਕ ਖਾਲੀ ਏਰੇ ਦੇ ਪਹਿਲੇ ਤੱਤ ਲਈ ਪੁੱਛਣਾ ਤੁਹਾਡੇ ਪ੍ਰੋਗ੍ਰਾਮ ਨੂੰ exception ਨਾਲ ਠੋਕਰ ਨਹੀਂ ਖਵਾਂਦਾ—ਇਹ ਸ਼ਾਂਤਿਭਾਵ ਨਾਲ nil ਵਾਪਸ ਕਰਦਾ ਹੈ:
[].first # => nil
ਉਹ ਵਿਹੇਵਿਅਰ ਭਵਿੱਖ-ਬੁੱਧੀ ਅਤੇ ਵਰਤਣ ਵਿੱਚ ਆਸਾਨ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦ ਤੁਸੀਂ ਡਾਟਾ ਦੀ ਛਾਣ-ਬੀਨ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਰਹੇ ਹੋ। Ruby ਆਮ ਤੌਰ 'ਤੇ “ਨਰਮ defaults” ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅੱਗੇ ਵਧਣ ਦਿੰਦੇ ਹਨ, ਫਿਰ ਵੀ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਖ਼ਤ ਹੋਣ ਦੇ ਟੂਲ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।
Ruby ਗੱਲਬਾਤ ਵਰਗੀ ਪੜ੍ਹਦਾ ਹੈ: ਵਿਅਕਤੀਗਤ ਮੈਥਡ ਨਾਮ, ਵਿਕਲਪਿਕ ਕੋਠੇਸ, ਅਤੇ ਕੋਡ ਬਲਾਕ ਜੋ ਇਤਰੈਸ਼ਨ ਨੂੰ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਾਉਂਦੇ ਹਨ। ਅੰਦਰੋਂ-ਅੰਦਰ, ਇਹ ਇਕਸਰਤਾ ਲਈ ਵੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ—ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਤੌਰ 'ਤੇ, “ਹਰ ਚੀਜ਼ ਇੱਕ ਆਬਜੈਕਟ ਹੈ।” ਨੰਬਰ, ਸਟਰਿੰਗ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਕਲਾਸਾਂ ਵੀ ਬੁਨਿਆਦੀ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਤੁਹਾਨੂੰ ਯਾਦ ਰੱਖਣ ਵਾਲੀ ਖਾਸ ਮਾਮਲਾ-ਥੀਮਾਹਤ ਘਟਾਉਂਦਾ ਹੈ।
ਇਹ ਜੋੜ—ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਇਕਸਰਤਾ—ਐਸਾ ਕੋਡ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਹੈ ਜੋ pull request ਵਿੱਚ ਸਕੈਨ ਕਰਨ ਲਈ ਆਸਾਨ, ਟੀਮਮੇਟ ਨੂੰ ਸਿਖਣ ਲਈ ਆਸਾਨ, ਅਤੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਰੱਖ-ਰਖਾਅ ਲਈ ਆਸਾਨ ਹੋਵੇ।
Ruby ਦੇ ਮਨੁੱਖ-ਪਹਿਲੇ ਪ੍ਰਾਥਮਿਕਤਾ ਨੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਫ੍ਰੇਮਵਰਕਾਂ ਦੀ ਸਭਿਆਚਾਰ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਇਆ। Gem ਲੇਖਕ ਆਮ ਤੌਰ 'ਤੇ ਸਾਫ APIs, ਮਦਦਗਾਰ error ਸੁਨੇਹੇ, ਅਤੇ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਅਸਲ ਲੋਕ ਪੜ੍ਹ ਰਹੇ ਹਨ। Ruby 'ਤੇ ਬਣੇ ਫ੍ਰੇਮਵਰਕ (ਖਾਸ ਕਰਕੇ Rails) ਨੇ ਇਸ ਮਨੋਭਾਵ ਨੂੰ ਵਾਰਸੇ ਵਿੱਚ ਲਿਆ: convention ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਸਪਸ਼ਟਤਾ ਲਈ optimize ਕਰੋ, ਅਤੇ “ਖੁਸ਼ ਰਸਤਾ” ਨੂੰ ਸੰਮਿਲਿਤ ਕਰੋ ਤਾਂ ਕਿ ਵਿਕਾਸਕ ਤੁਰੰਤ ਮੂਲ ਪ੍ਰਦਰਸ਼ਨ ਤੇ ਧਿਆਨ ਦੇ ਸਕਣ ਬਿਨਾਂ ਟੂਲਚੇਨ ਨਾਲ ਜੱਝਣ ਦੇ।
Ruby ਦਾ “ਖੁਸ਼” ਅਨੁਭਵ ਇਸ ਗੱਲ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਪੜ੍ਹਦਾ ਹੈ। syntax ਦਾ ਮਕਸਦ ਤੁਹਾਡੇ ਰਸਤੇ ਵਿੱਚ ਰੁਕਾਵਟ ਨਾ ਬਣਨਾ ਹੈ: ਘੱਟ ਪੰਕਚੂਏਸ਼ਨ, ਇਕਸਰ ਮੈਥਡ ਕਾਲ, ਅਤੇ ਇੱਕ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਆਮ ਕੰਮਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਦੀ ਹੈ। ਬਹੁਤ ਸਾਰਿਆਂ ਲਈ, ਇਹ ਉਦਾਹਰਨ ਉਹਨਾ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲੀ ਕਰਦਾ ਹੈ ਜੋ ਲਿਖਣ, ਰਿਵਿਊ ਅਤੇ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
Ruby ਆਮ ਤੌਰ 'ਤੇ ਮਨੋਭਾਵ-ਬਤਾਉਣ ਵਾਲੇ ਕੋਡ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਚਤੁਰ shortcuts ਨੂੰ। ਤੁਸੀਂ ਅਕਸਰ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਕੋਡ ਪੜ੍ਹ ਕੇ ਤੁਸੀਂ ਜਾਣ ਸਕੋ ਕਿ ਉਹ ਕੀ ਕਰ ਰਿਹਾ ਹੈ। ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਇਸ ਗੱਲ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀ ਹੈ: ਸਟਰਿੰਗ, ਐਰੇ, ਹੈਸ਼ ਅਤੇ ਸਮਾਂ/ਤਾਰੀਖ ਯੂਟਿਲਿਟੀ ਆਮ ਕੰਮਾਂ ਲਈ ਬਣੇ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਛੋਟੇ-ਛੋਟੇ ਹੁਨਰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਵਿੱਚ ਘੰਟਿਆਂ ਨਾ ਗੁਜ਼ਾਰੋਂ।
ਇਹ ਪੜ੍ਹਨਯੋਗਤਾ ਸਿਰਫ਼ ਸੁੰਦਰਤਾ ਲਈ ਨਹੀਂ—ਇਹ ਡੀਬੱਗਿੰਗ ਦੌਰਾਨ friction ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਸਹਿਯੋਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦ ਟੀਮਮੇਟਾਂ ਦੇ ਪਿਛੋਕੜ ਵੱਖ-ਵੱਖ ਹੋਣ।
Ruby ਦੇ ਬਲਾਕ (ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਬਣੇ iterator methods) ਡਾਟਾ ਤਬਦੀਲ ਕਰਨ ਲਈ ਇੱਕ ਫ਼ਲੂਅਿਡ ਅੰਦਾਜ਼ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦੇ ਹਨ। ਹੱਥੋਂ-ਹੱਥ ਲੂਪ ਅਤੇ ਅਸਥਾਈ ਵੈਰੀਏਬਲਾਂ ਦੀ ਜਗ੍ਹਾ, ਤੁਸੀਂ ਬਦਲਾਅ ਦੀ ਸ਼ਕਲ ਸਿੱਧਾ ਵਿਅਕਤ ਕਰ ਸਕਦੇ ਹੋ:
names = users
.select { |u| u.active? }
.map { |u| u.name.strip }
.sort
ਇਹ ਪੈਟਰਨ ਸਧਾਰਨ ਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਲੈ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਤੱਕ ਸਕੇਲ ਹੁੰਦੀ ਹੈ। ਇਹ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਛੋਟੀਆਂ, ਰਚਨੀਯੋਗ ਕਦਮਾਂ ਵੱਲ ਧਿਰਾਉਂਦੀ ਹੈ—ਅਕਸਰ ਸੂਚਕਾਂਕਾਂ, ਮਿਊਟੇਸ਼ਨ ਅਤੇ ਨਿਯੰਤਰਣ ਪ੍ਰਵਾਹ ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਸੰਭਾਲਣ ਦੀ ਬਜਾਏ ਇੱਕ ਸੁਖਦ ਮਾਨਸਿਕ ਨਕਸ਼ਾ।
Ruby ਤੁਹਾਨੂੰ metaprogramming ਦੇ ਐਸੇ ਟੂਲ ਦਿੰਦਾ ਹੈ ਜੋ ਪਹੁੰਚਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ: open classes ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਬਿਹੈਵਿਅਰ ਨੂੰ ਵਧਾਉਣ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ dynamic dispatch (ਜਿਸ ਵਿੱਚ method_missing ਸ਼ਾਮਲ ਹੈ) ਲਚਕੀਲੇ APIs ਅਤੇ ਆੰਦਰੂਨੀ DSLs ਬਣਾਉਣ ਲਈ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਸੋਚ-ਸਮਝ ਕੇ ਵਰਤੋਂ ਕਰਨ 'ਤੇ, ਇਹ ਖ਼ਾਸੀਅਤਾਂ ਕੋਡਬੇਸ ਨੂੰ "ਡੋਮੇਨ-ਅਨੁਕੂਲ" ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ—ਘੱਟ ਬੋਇਲਰਪਲੇਟ, ਪ੍ਰੋਗਰਾਮ ਦੇ ਮਾਫ਼ੂਮ 'ਤੇ ਹੋਰ ਧਿਆਨ।
ਟਰੇਡਆਫ਼ ਇਹ ਹੈ ਕਿ ਪ੍ਰਗਟਤਾ ਅਕਸਰ “ਜਾਦੂ” ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ ਜੇ ਧੂਪ-ਧਾਰ ਨਾਲ ਵਰਤੀ ਜਾਵੇ। ਭਾਰੀ metaprogramming ਇਹ ਛੁਪਾ ਸਕਦੀ ਹੈ ਕਿ ਮੈਥਡ ਕਿੱਥੋਂ ਆ ਰਹੇ ਹਨ, ਟੂਲਿੰਗ ਨੂੰ ਘੱਟ ਮਦਦਗਾਰ ਬਣਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਨਵੇਂ ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦੀ ਹੈ। ਸਭ ਤੋਂ ਖੁਸ਼ Ruby ਕੋਡ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਇਹ ਤਾਕਤਾਂ ਸੰਯਮ ਨਾਲ ਵਰਤਦਾ ਹੈ: ਸਪਸ਼ਟ defaults, ਉਮੀਦਜੋਗ ਨਾਂ, ਅਤੇ meta ਤਕਨੀਕਾਂ ਸਿਰਫ ਉਸ ਵੇਲੇ ਜਦ ਇਹ ਮਾਨੇ ਜਾਂ ਸਕੈਂਗ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆਉਂਦੀਆਂ ਹਨ।
Ruby ਨੇ ਕੋਡ ਲਿਖਣ ਉਨਦਾ ਕਿ ਅਨੰਦਦਾਇਕ ਹੋਵੇ—Rails ਨੇ ਉਸ ਦਰਸ਼ਨ ਨੂੰ ਇੱਕ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹੋ: ਘੱਟ ਫੈਸਲੇ, ਤੇਜ਼ ਤਰੱਕੀ, ਅਤੇ ਘੱਟ glue code.
Rails ਸਿਰਫ਼ routing ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ORM ਨਹੀਂ ਸੀ—ਇਹ "ਨਵੇਂ ਵਿਚਾਰ" ਤੋਂ "ਚੱਲ ਰਹੇ ਐਪ" ਤੱਕ ਪੂਰੇ-ਸਟੈਕ ਰਸਤਾ ਦਿੱਤਾ। ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਐਕਸੇਸ (Active Record), ਰਿਕੁਏਸਟ ਹੈਂਡਲਿੰਗ (Action Pack), ਟੇਮਪਲੇਟਿੰਗ (Action View), background jobs, mailers, asset handling, ਅਤੇ ਇੱਕ ਮਿਆਰੀ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚਾ ਪ੍ਰਾਪਤ ਕੀਤਾ।
ਇਹ "ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਡ" ਢੰਗ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਸਭ ਕੁਝ ਤੁਹਾਡੇ ਲਈ ਕੀਤਾ ਜਾਵੇ। ਇਹ ਆਮ ਰਸਤੇ ਨੂੰ ਸਗ m ਬਣਾਉਣ ਬਾਰੇ ਸੀ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਊਰਜਾ ਵਾਇਰਿੰਗ ਦੀ ਬਜਾਏ ਪ੍ਰੋਡਕਟ 'ਤੇ ਜਾਵੇ।
"Convention over configuration" ਦਾ ਮਤਲਬ ਹੈ Rails ਸਮਝਦਾਰ defaults ਮੰਨਦਾ ਹੈ: ਫਾਇਲਾਂ ਕਿੱਥੇ ਰਹਿਣਗੀਆਂ, ਕਿਵੇਂ ਕਲਾਸਾਂ ਦਾ ਨਾਮ ਰੱਖਿਆ ਜਾਵੇ, ਟੇਬਲਾਂ ਮਾਡਲਾਂ ਨਾਲ ਕਿਵੇਂ ਮੈਪ ਹੋਦੀਆਂ ਹਨ, ਅਤੇ ਰੂਟਾਂ ਕਿਵੇਂ ਕੰਟਰੋਲਰਾਂ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਇਹ ਫੈਸਲੇ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਨੂੰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਫਾਇਦਾ ਸਿਰਫ਼ ਘੱਟ config files ਨਹੀਂ—ਇਹ ਘੱਟ ਮਾਈਕ੍ਰੋ-ਫੈਸਲੇ ਹਨ। ਜਦ ਨਾਮਕਰਨ ਅਤੇ ਢਾਂਚਾ ਉਮੀਦਜੋਗ ਹੁੰਦੇ ਹਨ, onboarding ਆਸਾਨ ਹੁੰਦੀ ਹੈ, ਕੋਡ ਰੀਵਿਊਜ਼ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਉਹ ਪੈਟਰਨ ਮੁਤਾਬਕ ਘੱਟ ਵਕਤ ਵਿਚ ਬੈਠ ਜਾਂਦੀਆਂ ਹਨ।
Rails ਨੇ "Don’t Repeat Yourself" ਨੂੰ عملی ਰੂਪ ਦਿੱਤਾ। ਸਾਂਝਾ ਬਿਹੈਵਿਅਰ helpers, concerns, validations, scopes, ਅਤੇ partials ਵਿੱਚ ਖਿੱਚਿਆ ਜਾਂਦਾ ਹੈ, ਬਜਾਏ ਹਰ ਫਾਇਲ 'ਤੇ ਕਾਪੀ ਕਰਨ ਦੇ।
ਜਦ ਤੁਸੀਂ ਨਕਲ ਹਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਐਸੀਆਂ ਥਾਵਾਂ ਘਟਾਉਂਦੇ ਹੋ ਜਿਥੇ bugs ਲੁਕ ਸਕਦੇ ਹਨ—ਅਤੇ ਜਿਥੇ ਤਬਦੀਲੀ ਕਰਨੀ ਪਵੇਗੀ ਉਹਨਾਂ ਥਾਵਾਂ ਦੀ ਗਿਣਤੀ ਵੀ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਸਿੱਧਾ-ਸਿੱਧਾ ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ ਨੂੰ ਬਢ਼ਾਵਾ ਦਿੰਦਾ ਹੈ: ਘੱਟ ਰੁਕਾਵਟ, ਜ਼ਿਆਦਾ ਆਤਮ-ਵਿਸ਼ਵਾਸ।
Ruby ਕੋਡ ਲਿਖਣਾ ਸੁਖਦ ਬਣਾਉਂਦਾ ਸੀ। Rails ਨੇ ਵੈੱਬ ਐਪ ਬਣਾਉਣਾ ਗਠਜੋੜੀਹੀਨ ਮਹਿਸੂਸ ਕਰਵਾਇਆ। ਦੁਨੋਂ ਮਿਲ ਕੇ ਉਹ ਫ੍ਰੇਮਵਰਕ ਡਿਜ਼ਾਇਨ ਦੀ ਰਵਾਇਤ ਪ੍ਰਸਾਰਿਤ ਕੀਤੀ ਜਿੱਥੇ ਸਭ ਤੋਂ ਖੁਸ਼ ਰਾਹ ਵੀ ਆਮ ਰਾਹ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਜਿੱਥੇ ਤੇਜ਼ੀ ਇਕਸਰਤਾ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ shortcuts ਤੋਂ।
Rails ਨੇ Ruby ਦੀ "ਇਨਸਾਨਾਂ ਲਈ optimize" ਸੋਚ ਨੂੰ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਦੇ ਫਾਇਦਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਇਹ ਤੁਹਾਨੂੰ ਹਰ ਫੋਲਡਰ, ਨਾਮਕਰਨ ਸਕੀਮ, ਅਤੇ ਵਾਇਰਿੰਗ ਫੈਸਲੇ ਨੂੰ ਸਿਰਫ਼ ਖੋਜਣ ਲਈ ਨਹੀਂ ਕਹਿੰਦਾ—ਇਹ ਸੈਂਸਿਬਲ ਕੰਵੈਂਸ਼ਨ ਚੁਣਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਹ ਕੰਵੈਂਸ਼ਨ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਨ ਲਈ ਤਕਨੀਕੀ ਟੂਲ ਦਿੰਦਾ ਹੈ।
Rails ਜਨਰੇਟਰ ਤੁਹਾਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਐਪ ਦਾ ਇੱਕ ਕੰਮਕਾਜ਼ ਹਿੱਸਾ ਬਣਾਉਣ ਦੇ ਸਕਦੇ ਹਨ: models, controllers, routes, views, tests, ਅਤੇ ਬੋਇਲਰਪਲੇਟ ਫਾਰਮ। ਮਕਸਦ ਜਨਰੇਟ ਕੀਤੇ ਸ਼ੈਫੋਲਡ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਸ਼ਿਪ ਕਰਨਾ ਨਹੀਂ—ਇਹ blank-page ਸਮੱਸਿਆ ਨੂੰ ਦੂਰ ਕਰਨਾ ਹੈ।
ਜਦ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਬੇਸਲਾਈਨ CRUD ਫਲੋ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੀ ਧਿਆਨ ਵਿਸ਼ੇਸ਼ bagayਾਂ 'ਤੇ ਰੱਖਦੇ ਹੋ: validations, authorization, UX, ਅਤੇ domain ਨਿਯਮ। ਜਨਰੇਟਰ ਉਹ ਕੋਡ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਕਮਿਊਨਿਟੀ ਦੇ ਨਿਯਮਾਂ ਦੇ ਅਨੁਕੂਲ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਹ ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਲਈ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ।
ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਬਾਹਰ ਦੇ ਆਬਜੈਕਟ ਵਜੋਂ ਨਹੀਂ ਲੈਣ ਦੀ ਥਾਂ, Rails migrations ਬਦਲਾਵਾਂ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਵਰਜਨਡ ਬਣਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਮਨੋਰਥ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ ("ਕਾਲਮ ਸ਼ਾਮਲ ਕਰੋ", "ਟੇਬਲ ਬਣਾਓ"), ਇਸਨੂੰ ਆਪਣੇ ਕੋਡ ਨਾਲ commit ਕਰਦੇ ਹੋ, ਅਤੇ ਮਨੋ ਜਗਾਹਾਂ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹੋ।
ਇਹ ਟੀਕੜੀ coupling "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਵਾਲੀਆਂ ਹੈਰਾਨੀਆਂ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਸਕੀਮਾ ਵਿਕਾਸ ਨੂੰ ਰੋਜ਼ਾਨਾ ਬਜਾਏ ਖ਼ਤਰਨਾਕ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ।
ਇਕ ਉਮੀਦਜੋਗ ਪ੍ਰੋਜੈਕਟ ਲੇਆਊਟ (app/models, app/controllers, app/views) ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹ ਨਾ ਖੋਜੋ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਹਨ। ਪਰੀਖਣ ਚਲਾਉਣਾ, ਮਾਈਗਰੇਟ ਕਰਨਾ, caches ਸਾਫ਼ ਕਰਨਾ—ਇਹ ਸਾਰੇ ਕਾਰਜ Rake (ਅੱਜ-ਕੱਲ੍ਹ rails commands) ਰਾਹੀਂ ਕੇਂਦ੍ਰਿਤ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਜੋ ਟੀਮ ਇੱਕ ਆਮ ਸ਼ਬਦਾਵਲੀ ਸਾਂਝੀ ਕਰ ਸਕੇ।
ਜਨਰੇਟਰ, migrations, ਅਤੇ convention ਉਹ ਰਸਤਾ ਛੋਟਾ ਕਰਦੇ ਹਨ ਜੋ ਵਿਚਾਰ ਨੂੰ ਚੱਲਦੇ ਕੋਡ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ। ਤੇਜ਼ ਫੀਡਬੈਕ—ਇੱਕ ਪੰਨਾ render ਹੁੰਦਾ ਵੇਖਣਾ, ਇੱਕ ਟੈਸਟ ਪਾਸ ਹੋਣਾ, ਇੱਕ migration ਲਾਗੂ ਹੋਣਾ—ਸਿਖਣ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਚਿੰਤਾ ਘਟਾਉਂਦਾ ਹੈ। ਛੋਟੀਆਂ ਜਿੱਤਾਂ ਜੋੜ ਕੇ, ਡਿਵੈਲਪਰ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਉਤਪਾਦਕ ਬਹਾਉ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ।
ਇਹ ਵਿਚਾਰ—ਇਰਾਦੇ ਅਤੇ ਕੰਮਕਾਜ਼ ਸੋਫਟਵੇਅਰ ਦਰਮਿਆਨ ਦੀ ਦੂਰੀ ਨੂੰ ਕਾਂਪ੍ਰੈੱਸ ਕਰਨ ਦਾ—ਉਹੀ ਹੈ ਜੋ ਨਵੇਂ "vibe-coding" ਟੂਲਾਂ ਵੀ ਲੱਭਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇੱਕੋ ਜਿਹੇ DX ਸਿਧਾਂਤ (ਤੇਜ਼ ਫੀਡਬੈਕ, ਸਮਝਦਾਰ defaults) ਨੂੰ ਵਰਕਫਲੋ ਪੱਧਰ 'ਤੇ ਲਾਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਐਪ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਤੇਜ਼ੀ ਨਾਲ ਦੁਹਰਾਉਂਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਵੀ ਯਥਾਰਥ ਗਾਰਡਰੇਲਜ਼ ਜਿਵੇਂ planning mode, snapshots/rollback, ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ ਸੋర్స్-ਕੋਡ ਐਕਸਪੋਰਟ ਰੱਖਦਾ ਹੈ।
Ruby ਦੀ "ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ" ਸਿਰਫ਼ ਭਾਸ਼ਾ-ਪੱਧਰ ਦੀ ਗੱਲ ਨਹੀਂ—ਇਹ ਇਕੋਸਿਸਟਮ ਰਾਹੀਂ ਭੀ ਮਜ਼ਬੂਤ ਹੁੰਦੀ ਹੈ ਜੋ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨੂੰ ਸਹਿਜ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। Ruby ਦੇ DX ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ ਕੋਡ ਕਿਵੇਂ ਪੈਕ ਕੀਤਾ, ਸਾਂਝਾ ਕੀਤਾ, ਅਤੇ ਇੰਟੇਗਰੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Ruby gems ਨੇ reuse ਨੂੰ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਵਾਇਆ। ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ snippets ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਨੂੰ gem ਵਿੱਚ ਕੱਢ ਸਕਦੇ ਹੋ, ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਲਾਭ ਦੇ ਸਕਦੇ ਹੋ। ਇਸ ਨਾਲ ਯੋਗਦਾਨ ਪਾਉਣ ਦੀ ਸਮਾਜਿਕ ਅਤੇ ਤਕਨੀਕੀ friction ਘਟਦੀ ਹੈ: gems ਆਮ ਤੌਰ 'ਤੇ ਕੇਂਦਰਤ, ਪੜ੍ਹਨਯੋਗ, ਅਤੇ ਘੱਟ ਤਿਉਹਾਰ ਨਾਲ "ਸਲਟ-ਇਨ" ਹੋਣ ਲਈ ਬਣੇ ਹੁੰਦੇ ਹਨ।
ਇਹ ਛੋਟੇ, ਜੋੜ-ਯੋਗ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਸਭਿਆਚਾਰ ਭੀ ਕਮਿਊਨਿਟੀ ਨੂੰ ਸਾਫ APIs ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਵੱਲ ਧੱਕਦੀ ਹੈ। ਜਦ ਵੀ gems metaprogramming ਅਤੇ DSLs ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ, ਉਦੇਸ਼ ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗ ਨੂੰ ਸਧਾਰਨ ਰੱਖਣਾ ਹੁੰਦਾ ਹੈ—ਇਹ ਇਕ ਅਿਦਿਆਸ ਹੈ ਜਿਸ ਨੇ ਹੋਰ ਇਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਪੈਕੇਜਿੰਗ ਨੌਰਮਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
Bundler dependency ਪ੍ਰਬੰਧਨ ਨੂੰ ਇਕ ਪੇਸ਼ਗੋਈਯੋਗ ਰੁਟੀਨ ਬਣਾਉਂਦਾ ਹੈ ਬਜਾਏ ਰੋਕ-ਰੋਕ ਕੇ ਹੰਗਾਮਾ ਹੋਣ ਦੇ। Gemfile ਅਤੇ lockfile ਨਾਲ, ਤੁਸੀਂ ਨਾ ਸਿਰਫ਼ ਇਹ ਦਰਸਾਉਂਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕਿੱਥੋਂ ਨਿਰਭਰ ਹੋ, ਸਗੋਂ ਉਹ ਸਹੀ ਵਰਜਨਾਂ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ ਵੀ ਫਿਕਸ ਕਰ ਲੈਂਦੇ ਹੋ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਖੁਸ਼ੀ ਲਈ:
Ruby ਅਤੇ Rails ਨੇ batteries-included ਫ੍ਰੇਮਵਰਕਾਂ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਬਣਾਇਆ ਕਿ curated defaults ਸਧਾਰਨ ਵਿਕਲਪਾਂ ਨੂੰ ਨਾਰਮਲ ਬਣਾਉਂਦੇ ਹਨ: ਆਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ (ਡੇਟਾਬੇਸ ਐਡੈਪਟਰ, ਟੈਸਟਿੰਗ ਟੂਲ, background jobs, deployment ਹੇਲਪਰ) ਆਮ ਰਸਤੇ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਚੋਣਾਂ ਵਾਲੇ ਹੁੰਦੇ ਹਨ।
ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ Rails ਦੇ convention over configuration ਨਾਲ ਜੁੜਿਆ ਹੈ: ਜਦ ਇਕੋਸਿਸਟਮ ਕੁਝ ਚੰਗੀਆਂ ਚੋਣਾਂ 'ਤੇ ਇਕੱਠ ਹੋ ਜਾਂਦੀ ਹੈ, ਤੁਸੀਂ ਘੱਟ ਸਮਾਂ ਮੁਲਾਂਕਣ ਅਤੇ ਵਾਇਰਿੰਗ ਵਿੱਚ ਗੁਜਾਰਦੇ ਹੋ ਅਤੇ ਵੱਧ ਸਮਾਂ ਪ੍ਰੋਡਕਟ ਬਣਾਉਣ 'ਤੇ ਲਗਦੇ ਹੋ। ਟਰੇਡਆਫ਼ ਇਹ ਹੈ ਕਿ ਕਈ ਵਾਰ ਤੁਸੀਂ ਕਮਿਊਨਿਟੀ ਫੈਸਲਿਆਂ ਨੂੰ ਵਾਰਸੇ ਵਿੱਚ ਲੈਂਦੇ ਹੋ—ਪਰ ਉਤਪਾਦਕਤਾ, ਇਕਸਰਤਾ, ਅਤੇ ਘੱਟ ਵਿਚਾਰ-ਵਿਵਾਦ ਇਸਦਾ ਫਾਇਦਾ ਹਨ।
ਹੋਰ ਕਮਿਊਨਿਟੀਆਂ ਨੇ ਇਹ ਸਬਕ ਲਿਆ: ਪੈਕੇਜਿੰਗ ਅਤੇ ਟੂਲਿੰਗ ਨੂੰ ਮੁੱਖ ਅਨੁਭਵ ਦਾ ਹਿੱਸਾ ਮੰਨੋ, ਪ੍ਰੋਜੈਕਟ ਮੈਟਾਡੇਟਾ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ, ਡਿਪੈਂਡੇਂਸੀਜ਼ ਲਾਕ ਕਰੋ, ਅਤੇ “ਖੁਸ਼ ਰਸਤਾ” ਨੂੰ ਆਸਾਨ ਬਣਾਓ। Ruby ਦਾ ਇਕੋਸਿਸਟਮ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਤਪਾਦਕਤਾ ਸਿਰਫ਼ ਫੀਚਰ ਨਹੀਂ—ਇਹ ਮਹਿਸੂਸ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟੂਲ ਤੁਹਾਡੇ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਨ।
Ruby ਦੀ “ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ” ਕਹਾਣੀ ਸਿਰਫ਼ ਸੁੰਦਰ syntax ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇਸ ਗੱਲ ਬਾਰੇ ਵੀ ਹੈ ਕਿ ਆਪਣੇ ਕੋਡ ਨੂੰ ਕੰਮ ਕਰਦਾ ਸਾਬਤ ਕਰਨਾ ਕਿੰਨਾ ਆਸਾਨ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। Ruby ਕਮਿਊਨਿਟੀਆਂ ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਸਮਾਨ ਕਰਵਾ ਦਿੱਤਾ ਕਿ ਟੈਸਟ ਗ੍ਰਹਣਯੋਗ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਰੋਜ਼ਾਨਾ ਟੂਲ ਹਨ ਜੋ ਤੁਸੀਂ ਫੀਚਰ ਲਿਖਦੇ ਸਮੇਂ ਵਰਤਦੇ ਹੋ।
RSpec ਅਤੇ Minitest ਵਰਗੇ ਟੂਲਾਂ ਨੇ ਟੈਸਟਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ, ਅਕਾਦਮਿਕ ਅਨੁਸ਼ਾਸਨ ਦੀ ਥਾਂ Ruby ਕੋਡ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਇਆ। RSpec ਦੇ ਪ੍ਰਗਟ matchers ਅਤੇ ਵੇਰਵੇ ਟੈਸਟਾਂ ਨੂੰ ਸਾਦੇ ਅੰਗਰੇਜ਼ੀ ਨੁੰੂੰ ਵਰਗਾ specification ਪੜ੍ਹਾਈ ਕਰਾਉਂਦੇ ਹਨ, ਜਦਕੀ Minitest ਇੱਕ ਹਲਕਾ, ਤੇਜ਼ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ ਜੋ Ruby ਦੀ “ਸਧਾਰ ਰੱਖੋ” ਸ਼ੈਲੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਇਹ ਪੜ੍ਹਨਯੋਗਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦ ਟੈਸਟਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਕੈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਰੀਵਿਊ, ਰੱਖ-ਰਖਾਅ ਅਤੇ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹੋ। ਜਦ ਉਹ ਦਰਦਨਾਕ ਹੁੰਦੇ ਹਨ, ਉਹ ਰੁੱਠ ਜਾਂਦੇ ਹਨ।
ਟੈਸਟ ਖੁਸ਼ੀ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਸੈਟਅਪ ਹੈ। Ruby ਦਾ ਇਕੋਸਿਸਟਮ ਟੈਸਟ ਡਾਟਾ ਅਤੇ ਟੈਸਟ ਬਾਰਡਰਲਾਈਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ 'ਤੇ ਬਹੁਤ ਨਿਵੇਸ਼ ਕੀਤਾ—ਫੈਕਟਰੀਜ਼ (ਅਕਸਰ FactoryBot ਰਾਹੀਂ), ਜਿੱਥੇ ਜਰੂਰੀ ਹੋ ਫਿਕਸਚਰ, ਅਤੇ ਉਹ ਹੇਲਪਰ ਜੋ ਬੋਇਲਰਪਲੇਟ ਘਟਾਉਂਦੇ ਹਨ।
ਵਧੀਆ ਐਰਗੋਨੋਮਿਕਸ ਛੋਟੀ-ਛੋਟੀ ਚੀਜ਼ਾਂ ਵਿੱਚ ਵੀ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ: ਸਪਸ਼ਟ ਫੇਲਿਅਰ ਸੁਨੇਹੇ, ਸਧਾਰਨ stubbing/mocking APIs, ਅਤੇ ਟੈਸਟ ਫਾਈਲਾਂ ਨੂੰ ਅਯੋਜਿਤ ਕਰਨ ਦੇ convention। ਨਤੀਜਾ ਇੱਕ ਕਸਰਤੀ ਫੀਡਬੈਕ ਲੂਪ ਹੈ ਜਿਥੇ ਟੈਸਟ ਲਿਖਨਾ ਓਵਰਹੈਡ ਨਹੀਂ, ਬਲਕਿ ਪ੍ਰਗਤੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਇੱਕ ਫਰੇਮਵਰਕ ਟੈਸਟ ਨੂੰ ਉਮੀਦ ਬਣਾਉਂਦਾ ਹੈ, ਇਹ ਆਮਤੌਰ 'ਤੇ ਕੋਡ ਨੂੰ ਐਸੇ ਯੂਨਿਟਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਲੱਗ ਕਰਕੇ ਪਰਖਿਆ ਜਾ ਸਕੇ। Rails ਦੇ ਪੈਟਰਨ models, controllers, ਅਤੇ (ਬਹੁਤ ਸਾਰਿਆਂ ਕੋਡਬੇਸਾਂ ਵਿੱਚ) service objects ਬਾਰੇ ਸੋਚਣਾ ਇਸ ਗੱਲ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਹੈ ਕਿ ਕੀ ਅਲੱਗ ਕਰਕੇ ਟੈਸਟ ਕਰਨ ਲਾਇਕ ਹੈ।
ਜੀ ਹاں, ਮਿਆਰੀ ਢਾਂਚਾ ਵੀ ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਵੱਖ-ਵੱਖ ਜ਼ਿੰਮੇਦਾਰੀਆਂ ਰੱਖਣ ਵੱਲ ਧੱਕਦਾ ਹੈ: ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਰੱਖੋ ਜਿਥੇ ਉਹ instantiate ਅਤੇ assert ਕੀਤਾ ਜਾ ਸਕੇ, controllers ਨੂੰ ਪਤਲਾ ਰੱਖੋ, ਅਤੇ ਅਜਿਹੇ ਇੰਟਰਫੇਸ ਡਿਜ਼ਾਇਨ ਕਰੋ ਜੋ mocked ਜਾਂ faked ਕੀਤੇ ਜਾ ਸਕਣ ਬਿਨਾਂ ਵੱਡੀ ਕੋਸ਼ਿਸ਼ ਦੇ।
ਹੋ ਸਕਦਾ ਹੈ ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ ਸੱਭਿਆਚਾਰਕ ਹੋਵੇ: Ruby ਟੀਮਾਂ ਅਕਸਰ ਟੈਸਟਾਂ ਨੂੰ ਮੁੱਖ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਮੰਨਦੀਆਂ ਹਨ—ਲੋਕਲੀ ਚਲਾਓ, CI ਵਿੱਚ ਚਲਾਓ, ਅਤੇ ਫੀਚਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਲਿਖੋ। ਇਹ ਨਿਯਮ refactoring ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ, ਅਪਗਰੇਡਾਂ ਨੂੰ ਘੱਟ ਡਰਾਵਣਾ ਬਣਾਉਂਦਾ, ਅਤੇ ਸਹਿਯੋਗ ਨੂੰ ਸੁਚਿੱਤ ਦੋਸਤਾਨਾ ਬਣਾਉਂਦਾ ਕਿਉਂਕਿ ਟੈਸਟਾਂ ਇਰਾਦੇ ਦੀ ਸਾਂਝੀ ਦਸਤਾਵੇਜ਼ ਬਣ ਜਾਂਦੇ ਹਨ।
Rails ਨੇ ਸਿਰਫ਼ Ruby ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਬਣਾਇਆ ਨਹੀਂ—ਇਸਨੇ ਉਹ ਉਮੀਦਾਂ ਵੀ ਰੀਸੇਟ ਕਰ ਦਿਤੀਆਂ ਕਿ ਇੱਕ ਵੈੱਬ ਫ੍ਰੇਮਵਰਕ ਬਣਾਉਂਦੇ ਸਮੇਂ ਉਸਨੂੰ ਵਿਅਕਤੀ ਨੂੰ ਕਿੰਨਾ ਆਸਾਨ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਈ “ਆਧੁਨਿਕ” ਫ੍ਰੇਮਵਰਕ ਵਿਚਾਰ ਹੁਣ ਇੰਨੇ ਆਮ ਹੋ ਗਏ ਹਨ ਕਿ ਭੁੱਲ ਜਾਣਾ ਅਸਾਨ ਹੈ ਕਿ ਇਹ ਪਹਿਲਾਂ ਕਿਵੇਂ ਵਿਵਾਦਾਸਪਦ ਸਨ: ਤੁਹਾਡੀ ਥਾਂ defaults ਚੁਣਨਾ, ਕੋਡ ਜਨਰੇਟ ਕਰਨਾ, ਅਤੇ ਪ੍ਰਗਟ ਸਹਾਇਕਾਂ ਨੂੰ ਅਧਾਰ ਬਣਾਉਣਾ।
Rails ਨੇ ਦਲੀਲ ਕੀਤੀ ਕਿ ਫ੍ਰੇਮਵਰਕਾਂ ਨੂੰ ਆਮ ਫੈਸਲਿਆਂ ਨੂੰ ਕੋਡਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਫੋਲਡਰ ਢਾਂਚਾ, ਨਾਮਕਰਨ, routing ਪੈਟਰਨ, ਡੇਟਾਬੇਸ ਕੰਵੈਨਸ਼ਨ। ਇਹ ਦਰਸ਼ਨ ਕਈ ਏਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਭਾਵੇਂ ਭਾਸ਼ਾ ਅਤੇ ਰਨਟਾਈਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਹੋਣ।
ਉਦਾਹਰਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਸਾਂਝਾ ਹੱਦਫ ਇੱਕੋ-ਏ: ਵਾਇਰਿੰਗ ਘੱਟ, ਸ਼ਿਪਿੰਗ ਵੱਧ।
Rails ਨੇ ਇਹ ਆਮ ਕੀਤਾ ਕਿ ਫ੍ਰੇਮਵਰਕ ਆਮ ਕੰਮਾਂ ਲਈ ਦੋਸਤਾਨਾ ਛੋਟੀ-ਭਾਸ਼ਾ ਪ੍ਰਦਾਨ ਕਰਨ। ਰਾਊਟਿੰਗ ਫਾਈਲਾਂ ਜੋ ਘੋਸ਼ਣਾ ਵਾਂਗ ਪੜ੍ਹਦੀਆਂ ਹਨ, ਵੈਧਤਾ ਜੋ ਸਾਦੇ ਅੰਗਰੇਜ਼ੀ ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਅਤੇ ਫਾਰਮ ਬਿλਡਰ ਜੋ ਬੋਇਲਰਪਲੇਟ ਘਟਾਉਂਦੇ ਹਨ—ਸਭ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ flow ਲਈ ਹਨ।
ਕਈ ਫ੍ਰੇਮਵਰਕਾਂ ਨੇ ਸਮਾਨ ਪੈਟਰਨ ਅਪਣਾਏ—ਕਦੇ DSL ਵਜੋਂ, ਕਦੇ fluent APIs ਵਜੋਂ। ਟਰੇਡਆਫ਼ ਇਹ ਹੈ ਕਿ ਇਹ ਸਹੂਲਤਾਂ ਜਟਿਲਤਾ ਨੂੰ ਛੁਪਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਨ੍ਹਾਂ ਨਾਲ “ਖੁਸ਼ ਰਸਤਾ” ਤੇਜ਼ ਅਤੇ ਪਹੁੰਚਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ।
Rails scaffolding ਨੇ CLI-ਫਰਸਟ ਵਰਕਫਲੋ ਦੀ ਇੱਕ ਪੀੜ੍ਹੀ ਨੂੰ ਪ੍ਰੇਰਿਆ:
artisanmix phx.gen.*django-admin startproject ਅਤੇ startappਜਿਸ ਤਰ੍ਹਾਂ ਟੀਮਾਂ generated ਕੋਡ ਨਹੀਂ ਰੱਖਦੀਆਂ, ਫਿਰ ਵੀ ਫੀਡਬੈਕ ਲੂਪ ਮੁੱਲਵਾਨ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਕੰਮਕਾਜ਼ ਹਿੱਸਾ ਵੇਖ ਸਕਦੇ ਹੋ, ਫਿਰ ਉਸਨੂੰ ਸੁਧਾਰ ਕਰੋ।
Rails ਨੇ defaults ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਫੀਚਰ ਵਜੋਂ ਦੇਖਿਆ। ਆਧੁਨਿਕ ਫ੍ਰੇਮਵਰਕ ਅਕਸਰ ਇਹੋ ਹੀ ਕਰਦੇ ਹਨ—ਸਮਝਦਾਰ ਲੌਗਿੰਗ, ਵਾਤਾਵਰਣ configs, ਟੈਸਟਿੰਗ hooks, ਅਤੇ deployment-friendly ਸੈਟਿੰਗਾਂ ਚੁਣਦੇ ਹਨ—ਤਾਂ ਜੋ ਟੀਮਾਂ ਮੁੱਢਲੀਆਂ ਗੱਲਾਂ 'ਤੇ ਘੱਟ ਸੋਚਣ ਅਤੇ ਅਪਣੇ ਐਪ 'ਤੇ ਵੱਧ ਧਿਆਨ ਦੇ ਸਕਣ।
Ruby ਅਤੇ Rails ਮਨੁੱਖ-ਮਿੱਤਰਪੂਰਨ ਕੋਡ ਅਤੇ ਤੇਜ਼ iteration ਲਈ optimize ਕਰਦੇ ਹਨ—ਪਰ ਹਰ ਪਸੰਦ ਦੇ ਮੁੱਲ-ਬਿੰਦੂ ਕੁਝ ਦਰਦ ਵਾਲੇ ਮੁੱਦੇ ਲਿਆਉਂਦੇ ਹਨ। ਟੀਮਾਂ ਨੂੰ ਇਹ ਸਮਝਣਾ ਜਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਖੁਸ਼ੀ ਰੱਖ ਸਕਣ ਬਿਨਾਂ ਅਣਹੌਣੇ ਦਰਦ ਦੇ।
Ruby ਦੀ ਪ੍ਰਗਟਤਾ ਅਕਸਰ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ ਮੰਚਾ ਵਿੱਚ ਤੁਹਾਨੂੰ ਜਲਦੀ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੀ ਹੈ। ਲਾਗਤ ਦੇ ਤੌਰ ਤੇ ਇਹ ਵੱਧ CPU ਅਤੇ ਮੈਮੋਰੀ ਵਰਤੋਂ ਵਿੱਚ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਨੀਵੀਂ-ਸਤਹ਼ ਵਾਲੇ ਸਟੈਕਾਂ ਨਾਲ, ਜਾਂ ਜਦ ਐਪ ਵੱਧਦਾ ਹੈ ਤਾਂ "worst case" endpoints ਹੌਲੇ ਹੋ ਸਕਦੇ ਹਨ।
ਅਮਲੀ ਤੌਰ ਤੇ, ਕਈ Ruby ਟੀਮਾਂ ਥੋੜ੍ਹਾ ਵੱਧ ਇਨਫਰਾਸਟਰਕਚਰ ਬਿੱਲ ਸਵੀਕਾਰ ਕਰਦੀਆਂ ਹਨ ਬਦਲੇ ਵਿੱਚ ਤੇਜ਼ ਪ੍ਰੋਡਕਟ ਸਿੱਖਣ ਲਈ। ਜਦ ਪਰਫਾਰਮੈਂਸ ਸਚਮੁਚ ਇੱਕ ਸੀਮਾ ਬਣਦੀ ਹੈ, ਆਮ ਰਸਤਾ ਹੈ ਨਿਸ਼ਾਨੇਵਾਰ ਅਪਟੀਮਾਈਜੇਸ਼ਨ: caching, background jobs, ਡੇਟਾਬੇਸ ਟਿਊਨਿੰਗ, ਅਤੇ profiling hotspots—ਸਾਰਾ ਸਿਸਟਮ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਣਾ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਫੈਸਲਾ ਸਮਝੋ, ਨਾ ਕਿ ਭਾਸ਼ਾ ਦੀ ਨਿੰਦ।
Rails ਦੀਆਂ ਸੁਵਿਧਾ ਫੀਚਰ—ਡਾਇਨਾਮਿਕ ਮੈਥਡ, callbacks, implicit loading, DSLs—ਕੋਡ ਨੂੰ ਐਸਾ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ ਕਿ ਇਹ "ਸਿਰਫ਼ ਕੰਮ ਕਰਦਾ ਹੈ"। ਇਹੀ ਜਾਦੂ ਜਦ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ ਤਦ ਕਾਲ ਪਾਥ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ।
ਦੋ ਆਮ_failure ਮੋਡ ਹਨ:
ਟੀਮਾਂ ਇਸਨੂੰ ਸੀਮਾਵਾਂ ਰੱਖ ਕੇ ਕਮ ਕਰਦੀਆਂ ਹਨ: repetitive boilerplate ਹਟਾਉਣ ਲਈ metaprogramming ਵਰਤੋ, ਪਰ ਜਦ ਲੌਜਿਕ ਕਾਰੋਬਾਰੀ-ਨਿਰਭਰ ਹੋਵੇ ਤਾਂ ਸਪਸ਼ਟ, ਸਧਾਰਨ Ruby ਨੂੰ ਔਸਤ ਦਿੱਤਾ ਜਾਏ। ਜਦ ਤੁਸੀਂ ਜਾਦੂ ਵਰਤਦੇ ਹੋ, ਇਸਨੂੰ ਖੋਜਯੋਗ ਬਣਾਓ—ਸਪਸ਼ਟ ਨਾਂ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ, ਅਤੇ ਉਮੀਦਜੋਗ ਫਾਇਲ ਢਾਂਚਾ।
Rails ਐਪ ਅਕਸਰ ਇੱਕ ਵਿਸ਼ਾਲ gem ਇਕੋਸਿਸਟਮ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਸਦਾ ਨਤੀਜਾ dependency drift ਹੋ ਸਕਦਾ ਹੈ: pinned ਵਰਜਨ, conflicting requirements, ਅਤੇ ਅਪਗਰੇਡਾਂ ਜੋ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ।
ਲੰਬੇ ਸਮੇਂ ਚਲਣ ਵਾਲੇ ਕੋਡਬੇਸ ਛੋਟੇ, ਅਕਸਰ ਅਪਗਰੇਡਾਂ ਨਾਲ ਬਿਹਤਰ ਹੋਂਦੇ ਹਨ; ਘੱਟ ਛੱਡੇ ਹੋਏ gems; ਅਤੇ "gem debt" ਰੋਜ਼ਾਨਾ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਆਦਤ। Surface area ਘੱਟ ਰੱਖੋ—ਜਦ Rails builtin ਚੰਗੇ ਹਨ ਤਾਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ—ਤਾਂ ਜੋ ਅਪਗਰੇਡ friction ਘੱਟ ਰਹੇ।
ਜਦ ਟੀਮਾਂ ਲਘੂ ਨਿਯਮ ਜੋੜਦੀਆਂ ਹਨ ਤਾਂ ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ ਸਕੇਲ ਕਰਦੀ ਹੈ:
ਹਦਫ Ruby ਨੂੰ ਘੱਟ Ruby ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਇਸਦੀ ਲਚਕ ਨੂੰ ਚੈਨਲ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਅੱਜ ਦੀ ਗਤੀ ਕੱਲ੍ਹ ਦਾ ਔਲਟਪੰਥ ਨਾ ਬਣ ਜਾਏ।
Ruby ਅਤੇ Rails ਨੇ ਹਰ ਫੀਚਰ ਜੋੜ ਕੇ ਨਹੀਂ “ਜਿੱਤ” ਕੀਤੀ। ਉਹ ਜਿਸ ਨਾਲ ਜਿੱਤ ਕਰੇ, ਉਹ ਸੀ ਆਮ ਕੰਮ ਨੂੰ ਸਪਸ਼ਟ, ਪੜ੍ਹਨਯੋਗ, ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਦੇ ਲਈ ਮੁਸ਼ਕਲ ਬਣਾਉਣਾ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਫ੍ਰੇਮਵਰਕ, SDK, ਜਾਂ ਉਤਪਾਦ API ਡਿਜ਼ਾਇਨ ਕਰ ਰਹੇ ਹੋ, ਤੁਸੀਂ ਉਹੀ ਪੈਟਰਨ ਅਪਣਾ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਚੀਜ਼ਾਂ ਦੀ ਨਕਲ ਕੀਤੇ।
ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਇੱਕੋ ਕੰਮ ਬਾਰ-ਬਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਜਿੱਥੇ ਚੋਣਾਂ ਉਤਪਾਦ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤਰ੍ਹਾਂ ਵੱਖ ਕਰਦੀਆਂ ਨਹੀਂ, conventions ਸਭ ਤੋਂ ਵਧੀਆ ਮੁੱਲ ਦਿੰਦੀਆਂ ਹਨ।
ਕੁਝ ਵਿਹਾਰਿਕ ਹੈਰੀਸਟਿਕ:
API ਨੂੰ ਇੱਕ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਵਜੋਂ ਸਵਾਗਤ ਕਰੋ।
ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ ਅਕਸਰ ਪਹਿਲੇ ਘੰਟੇ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲ ਹੁੰਦੀ ਹੈ।
ਵਿਗਿਆਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ:
ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ ਇਸ ਵਿਚਾਰ ਨੂੰ ਅੱਗੇ ਵਧਾ ਸਕਦੇ ਹਨ ਕਿ “ਪਹਿਲਾ ਘੰਟਾ” ਜ਼ਿਆਦਾਤਰ ਚੈਟ-ਆਧਾਰਤ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਉਹ ਦਿਸ਼ਾ ਖੋਜ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai Rails ਦੀਓ ਹੀ DX ਨਿਯਮ 'ਤੇ ਬਣਿਆ ਹੈ: ਸੈਟਅਪ friction ਘੱਟ ਕਰੋ, ਦੁਹਰਾਈ ਟਾਜ਼ਾ ਰੱਖੋ, ਅਤੇ conventions ਖੋਜਯੋਗ ਰੱਖੋ—ਫਿਰ ਭੀ ਟੀਮਾਂ ਨੂੰ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੌਇ, ਅਤੇ standard web (React), backend (Go + PostgreSQL), ਅਤੇ mobile (Flutter) stacks ਨਾਲ ਸਥਿਰ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ।
ਕੋਮੀਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ:
Ruby ਦੀ ਐਸਥਾਈ ਯੋਗਦਾਨ ਇੱਕ ਇੱਕਲੌਤਾ ਫੀਚਰ ਜਾਂ ਫ੍ਰੇਮਵਰਕ ਚਾਲ ਨਹੀਂ—ਇਹ ਇਸ ਜ਼ੋਰ ਦਾ ਰਹਿਣਾ ਹੈ ਕਿ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣਾ ਚੰਗਾ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। “ਡਿਵੈਲਪਰ ਖੁਸ਼ੀ” ਇੱਕ ਨਾਅਰਾ ਨਹੀਂ; ਇਹ syntax ਤੋਂ ਟੂਲਿੰਗ ਤੇ ਕਮਿਊਨਿਟੀ ਨਿਯਮ ਤੱਕ ਹਰ ਚੀਜ਼ ਨੂੰ ਆਕਾਰ ਦੇਣ ਵਾਲਾ ਇੱਕ ਡਿਜ਼ਾਇਨ ਸੀਮਾ ਹੈ।
ਇਸ ਦ੍ਰਿਸ਼ਟੀ ਤੋਂ ਲੈਣ ਵਾਲੀਆਂ ਕੁਝ ਮੁੱਖ ਗੱਲਾਂ:
Ruby ਅਤੇ Rails ਅਜੇ ਵੀ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਬਿਹਤਰੀਨ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਵਿਚਾਰ ਤੋਂ ਚੱਲਦੇ ਐਪ ਤੱਕ ਇੱਕ ਉਤਪਾਦਕ, ਗਠਜੋੜੀ ਰਸਤਾ ਚਾਹੁੰਦੇ ਹੋ: internal ਟੂਲ, SaaS ਬੈਕਐਂਡ, ਕੰਟੈਂਟ-ਭਰਪੂਰ ਪ੍ਰੋਡਕਟ, ਅਤੇ ਉਹ ਟੀਮਾਂ ਜੋ ਰੱਖ-ਰਖਾਅ ਅਤੇ ਸਪਸ਼ਟ convention ਨੂੰ ਮਹੱਤਵ ਦਿੰਦੇ ਹਨ।
ਜਦ ਕੱਚਾ throughput, ਤੰਗ ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ, ਜਾਂ ਬਹੁਤ ਘੱਟ latency ਮੁੱਖ ਲੋੜਾਂ ਹੋਣ, ਜਾਂ ਜਦ ਤੁਹਾਡੀ ਸੰਸਥਾ ਕਿਸੇ ਹੋਰ ਰਨਟਾਈਮ 'ਤੇ ਸਥਿਰ ਹੋਵੇ, ਤਾਂ ਹੋਰ ਸਟੈਕ ਵਧੀਆ ਮੈਚ ਹੋ ਸਕਦੇ ਹਨ। ਕਿਸੇ ਹੋਰ ਵਿਕਲਪ ਦੀ ਚੋਣ Ruby ਦੀਆਂ ਮੁੱਲਾਂ ਨੂੰ ਖਾਰਜ ਨਹੀਂ ਕਰਦੀ—ਅਕਸਰ ਇਹ ਵੱਖਰੀਆਂ ਤਰਜੀਹਾਂ ਜਾਂਦੀ ਹੈ।
ਚਾਹੇ ਤੁਸੀਂ Ruby ਕਦੇ ਨਹੀਂ ਲਿਖੋਗੇ, ਤੁਸੀਂ ਉਹੇ ਡਿਵੈਲਪਰ-ਅਨੁਭਵ ਸਰੋਤ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ:
ਜੇ ਤੁਸੀਂ ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਸੁਧਾਰਣ ਲਈ ਹੋਰ ਵਿਹਾਰਿਕ ਦ੍ਰਿਸ਼ਟਿਕੋਣ ਲੱਭਣਾ ਚਾਹੁੰਦੇ ਹੋ, /blog ਦੇਖੋ. ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਟੀਮ ਲਈ DX-ਕੇਂਦ੍ਰਿਤ ਟੂਲਾਂ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, /pricing ਵੇਖੋ.
ਇਹ ਰੋਜ਼ਾਨਾ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਦਾ ਅਨੁਭਵ ਹੈ: ਪੜ੍ਹਨਯੋਗ ਕੋਡ, ਮਿਲਦੇ-ਜੁਲਦੇ APIs, ਸਮਝਦਾਰ defaults, ਸਾਫ਼ error ਸੁਨੇਹੇ, ਅਤੇ ਐਸੇ ਵਰਕਫਲੋ ਜੋ ਤੁਹਾਨੂੰ ਟੂਲਾਂ ਨਾਲ ਜੱਝਣ ਦੀ ਬਜਾਏ flow ਵਿੱਚ ਰੱਖਦੇ ਹਨ.
ਇਸ ਲੇਖ ਦੀ ਤਹਿ-ਮਨਜ਼ਰ ਵਿੱਚ, ਇਹ ਮੁੱਖ ਰੂਪ ਵਿੱਚ:
Ruby ਨੂੰ ਇੱਕ ਮਨੁੱਖ-ਪਹਿਲੇ ਲਕਸ਼ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਉਹ ਸਮਾਂ ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਮੁੱਖ ਭਾਸ਼ਾਵਾਂ ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂ ਫੋਰਮਾਲਿਟੀ 'ਤੇ ਜ਼ੋਰ ਦਿੱਤਾ ਸੀ.
ਉਹ ਫੋਕਸ ਇਨ੍ਹਾਂ ਢੰਗਾਂ ਨਾਲ ਜ਼ਾਹਿਰ ਹੁੰਦਾ ਸੀ:
nil ਵਾਪਸ ਕਰਨਾ)ਇਹ خیال ਹੈ ਕਿ ਕੋਡ ਉਹੀ ਵਰਤੋਂ ਕਰੇ ਜੋ ਇੱਕ ਸਮਝਦਾਰ ਵਿਕਾਸਕ ਦੀ ਉਮੀਦ ਹੋਵੇ, ਤਾਕਿ “ਚੰਗਾ ਹੈਰਾਨੀ” ਘੱਟ ਹੋਵੇ.
ਛੋਟੀ ਉਦਾਹਰਣ ਇਹ ਹੈ ਕਿ [].first exception ਫੈਲਾਉਣ ਦੀ ਬਜਾਏ nil ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜੋ exploratory ਕੋਡਿੰਗ ਅਤੇ ਆਮ edge-cases ਨੂੰ ਨਰਮ ਬਣਾਉਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਸਖ਼ਤ ਹੇਠਾਂ-ਕੰਟਰੋਲ ਵਰਤ ਸਕਦੇ ਹੋ।
Blocks ਤੁਹਾਨੂੰ ਡਾਟਾ ਬਦਲਾਅ ਨੂੰ ਛੋਟੇ, ਪੜ੍ਹਨਯੋਗ ਕਦਮਾਂ ਦੇ ਪਾਈਪਲਾਈਨ ਵਜੋਂ ਵਿਅਕਤ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ, ਬਦਲੇ ਵਿੱਚ ਹੱਥੋਂ-ਹੱਥ ਲੂਪਾਂ ਅਤੇ ਅਸਥਾਈ ਵੈਰੀਏਬਲਾਂ ਦੇ।
ਆਮ ਪੈਟਰਨ ਸ਼ਾਮਲ ਹਨ:
select ਫਿਲਟਰ ਕਰਨ ਲਈmap ਤਬਦੀਲ ਕਰਨ ਲਈsort ਆਰਡਰ ਕਰਨ ਲਈਇਸ ਤਰ੍ਹਾਂ ਦਾ ਕੋਡ ਸੰਖੇਪ, ਇਨਸਪੈਕਟ ਅਤੇ ਰੀਫੈਕਟਰ ਕਰਨ ਲਈ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ।
Metaprogramming ਬੋਇਲਰਪਲੇਟ ਘਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਸਾਫ਼ ਆਨ-ਇੰਟਰਨਲ DSLs ਬਣਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ (ਰਾਉਟਿੰਗ, ਵੈਰੀਫਿਕੇਸ਼ਨ, ਕਨਫਿਗਰੇਸ਼ਨ ਆਦਿ)।
ਇਸਨੂੰ “ਜਾਦੂ” ਬਣਨ ਤੋਂ ਬਚਾਉਣ ਲਈ ਕਈ ਟੀਮਾਂ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਵਰਤਦੀਆਂ ਹਨ:
Rails ਨੇ Ruby ਦੀਆਂ ਕੀਮਤਾਂ ਨੂੰ ਇੱਕ ਸੰਗਠਿਤ, ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਡ ਵਰਕਫਲੋ ਵਿੱਚ ਪੈਕ ਕੀਤਾ: convention, ਇੱਕ ਮਿਆਰੀ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚਾ, ਅਤੇ ਇਕੱਤਰ ਸੰਘਟਕ (routing, ORM, views, jobs, mailers ਆਦਿ).
ਹਰ ਚੀਜ਼ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਜੋੜਨ ਦੀ ਬਜਾਏ, Rails ਆਮ ਰਸਤੇ ਨੂੰ ਸੂਗਮ ਬਣਾਉਂਦਾ ਤਾਂ ਜੋ ਟੀਮਾਂ ਪਲੱਗ-ਕੋਡ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਪੈਰੋਡਕਟ-ਵਰਤੋਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਣ।
ਇਹ ਫੈਸਲੇ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ Rails ਨਾਮਾਂ, ਫਾਇਲ ਸਥਾਨਾਂ ਅਤੇ ਨਕਸ਼ਾ ਬਾਰੇ ਸਮਝਦਾਰ defaults ਮੁਹੱਈਆ ਕਰਵਾਉਂਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਟੇਬਲਾਂ ਨਾਲ ਮਾਡਲ ਮੈਪਿੰਗ ਅਤੇ ਰੂਟਾਂ ਨਾਲ ਕੰਟਰੋਲਰ).
ਅਮਲ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ:
Generators ਇਕ ਕਾਰਜਕਾਰੀ ਬੇਸਲਾਈਨ (models, controllers, routes, views, tests) ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਖਾਲੀ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰੋ.
ਉਹ ਸਭ ਤੋਂ ਵਧੀਆ ਤਾਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ:
Bundler Gemfile ਅਤੇ lockfile ਨਾਲ dependencies ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਰੁਟੀਨ ਬਣਾਉਂਦਾ.
ਇਹ ਟੀਮਾਂ ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ:
Ruby/Rails ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ iteration ਅਤੇ ਰੱਖ-ਰਖਾਅ ਲਈ ਕੱਚੇ ਰਨਟਾਈਮ ਕੁਸ਼ਲਤਾ ਨੂੰ ਤਿਆਗਦੇ ਹਨ.
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਭੁਗਤਾਨ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਜਦੋਂ ਪਰਫਾਰਮੈਂਸ ਸਚਮੁਚ ਬੋਧ ਹੋਵੇ ਤਾਂ ਉਹ ਲਕੜੀ ਦੇ ਉਪਾਇ ਵਰਤਦੇ ਹਨ: