23 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
Yehuda Katz ਅਤੇ ਵੈੱਬ ਫਰੇਮਵਰਕ: ਰਿਵਾਇਤਾਂ, DX ਅਤੇ ਟੂਲਿੰਗ
Yehuda Katz ਦੇ ਪ੍ਰਭਾਵ 'ਤੇ ਇੱਕ ਵਰਤੋਂਕਾਰ-ਕੇਂਦਰਤ ਨਜ਼ਰੀਆ — Rails ਤੋਂ Ember ਅਤੇ ਆਧੁਨਿਕ ਟੂਲਿੰਗ ਤੱਕ; ਵੇਖੋ ਕਿ ਕਿਵੇਂ ਰਿਵਾਇਤਾਂ, ਡਿਵੈਲਪਰ ਤਜਰਬਾ ਅਤੇ CLI ਅਪਣਾਉਣ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
Yehuda Katz ਦੇ ਪ੍ਰਭਾਵ 'ਤੇ ਇੱਕ ਵਰਤੋਂਕਾਰ-ਕੇਂਦਰਤ ਨਜ਼ਰੀਆ — Rails ਤੋਂ Ember ਅਤੇ ਆਧੁਨਿਕ ਟੂਲਿੰਗ ਤੱਕ; ਵੇਖੋ ਕਿ ਕਿਵੇਂ ਰਿਵਾਇਤਾਂ, ਡਿਵੈਲਪਰ ਤਜਰਬਾ ਅਤੇ CLI ਅਪਣਾਉਣ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਫਰੇਮਵਰਕ ਅਕਸਰ ਸਿਰਫ਼ ਫੀਚਰ ਦੀ ਤੁਲਨਾ ਨਹੀਂ ਹੁੰਦੇ। ਟੀਮਾਂ ਉਹ ਸੰਦ ਵਰਤਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ ਜੋ "ਰਹਿਣ ਲਈ ਆਸਾਨ" ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ—ਨਾ ਕਿ ਕਿਉਂਕਿ ਉਹ ਜ਼ਿਆਦਾ ਸਮਰੱਥ ਹਨ, ਬਲਕਿ ਕਿਉਂਕਿ ਉਹ ਰੋਜ਼ਾਨਾ ਦੀ ਰਗੜ ਘਟਾਉਂਦੇ ਹਨ।
Yehuda Katz ਦੇ ਕੰਮ ਦਾ ਰਾਹ—Ruby on Rails ਤੋਂ Ember.js ਯੁੱਗ ਅਤੇ ਅੱਜ ਦੇ ਟੂਲਿੰਗ-ਭਰੀ JavaScript ਦੁਨੀਆ ਤੱਕ—ਇਹ ਸਮਝਣ ਲਈ ਇੱਕ ਉਪਯੋਗੀ ਦਰਸ਼ਣ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਸ ਚੀਜ਼ ਨਾਲ ਇੱਕ ਫਰੇਮਵਰਕ ਟੀਮਾਂ ਦੇ ਲਈ "ਫਿੱਟ" ਹੁੰਦਾ ਹੈ।
ਕਈ ਫਰੇਮਵਰਕ ਪੰਨਿਆਂ ਨੂੰ ਰੈਂਡਰ ਕਰ ਸਕਦੇ ਹਨ, ਡਾਟਾ ਲੈ ਸਕਦੇ ਹਨ ਅਤੇ ਕੋਡ ਰਚਨਾ ਕਰ ਸਕਦੇ ਹਨ। ਅੰਤਰ ਉਹਨਾਂ ਮੋੜਾਂ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ: ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣਾ, ਰੂਟ ਜੋੜਨਾ, ਇਕ ਉਲਝਣ ਭਰੀ ਗਲਤੀ ਦਾ ਸਮਨਾ ਕਰਨਾ, ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਅਪਗਰੇਡ ਕਰਨਾ, ਜਾਂ ਨਵੇਂ ਸਾਥੀ ਨੂੰ ਓਨਬੋਰਡ ਕਰਨਾ। ਜਦੋਂ ਫਰੇਮਵਰਕ ਐਸੇ ਪਲਾਂ ਨੂੰ ਸੰਵੇਤਨਸ਼ੀਲ ਡੀਫਾਲਟਾਂ ਅਤੇ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸੁਗਮ ਕਰਦੇ ਹਨ, ਉਹ ਮਨ-ਸ਼ੇਅਰ ਜਿੱਤਦੇ ਹਨ।
ਅਸੀਂ ਤਿੰਨ ਅਧਿਆਏ ਵੇਖਾਂਗੇ:
ਇਹ ਜੀਵਨੀ ਨਹੀਂ ਅਤੇ ਨਾ ਹੀ ਗਹਿਰੀ ਤਕਨੀਕੀ ਇਤਿਹਾਸ; ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਇਹ ਅਧਿਆਏ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਫਰੇਮਵਰਕ ਕਿਵੇਂ ਭਰੋਸਾ ਜਿੱਤਦੇ ਹਨ।
"ਡਿਵੈਲਪਰ ਤਜਰਬਾ" (DX) ਸੁਨੇਹਰੀਅਨ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਠੋਸ ਹੁੰਦਾ ਹੈ। ਇਹ ਸ਼ਾਮਿਲ ਹੈ:
ਜੇ ਤੁਸੀਂ ਕਦੇ ਸੋਚਿਆ ਹੈ ਕਿ ਇੱਕ ਫਰੇਮਵਰਕ ਕੰਪਨੀਆਂ ਵਿੱਚ ਫੈਲਦਾ ਕਿਉਂ ਹੈ ਅਤੇ ਦੂਜਾ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਇਹ ਲੇਖ ਤੁਹਾਡੇ ਲਈ ਹੈ। ਤੁਸੀਂ ਮਾਹਿਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ: ਅਸੀਂ ਪ੍ਰਯੋਗਿਕ ਇਸ਼ਾਰੇ—ਰਿਵਾਇਤਾਂ, ਟੂਲਿੰਗ ਅਤੇ ਅਪਗਰੇਡ ਰਸਤੇ—ਤੇ ਧਿਆਨ ਰੱਖਾਂਗੇ ਜੋ ਅਸਲ ਦੁਨੀਆ ਵਿੱਚ ਅਪਣਾਉਣ ਦੀ ਵਜ੍ਹਾ ਦੱਸਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ ਕਿਲਰ API ਕਰ ਕੇ ਫਰੇਮਵਰਕ ਨਹੀਂ ਚੁਣਦੀਆਂ। ਉਹ ਇਸ ਲਈ ਚੁਣਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਫਰੇਮਵਰਕ ਸੈਂਕੜੇ ਛੋਟੇ-ਛੋਟੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦਾ ਹੈ—ਤਾਂ ਜੋ ਟੀਮ ਬਣਾਉਣ ਤੇ ਧਿਆਨ ਦੇ ਸਕੇ।
ਰਿਵਾਇਤਾਂ ਆਮ ਸਵਾਲਾਂ ਦੇ ਡਿਫਾਲਟ ਜਵਾਬ ਹਨ: ਇਹ ਫਾਇਲ ਕਿੱਥੇ ਜਾਵੇਗੀ? ਇਸਨੂੰ ਕੀ ਨਾਂ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ? ਪੰਨੇ ਡਾਟਾ ਕਿਵੇਂ ਲਭਦੇ ਹਨ? Rails ਵਿੱਚ, ਹਰ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਫੋਲਡਰ ਸਟ੍ਰੱਕਚਰ ਦੀ ਮੁੜ-ਚਰਚਾ ਨਹੀਂ ਹੁੰਦੀ—ਤੁਸੀਂ ਉਸਨੂੰ ਮੰਨਦੇ ਹੋ।
ਸੌਖਾ ਉਦਾਹਰਨ:
app/controllers/users_controller.rb ਵਿੱਚ ਰੱਖੋapp/models/user.rb ਵਿੱਚ ਰੱਖੋapp/views/users/show.html.erb ਵਿੱਚ ਰੱਖੋਨਾਂ ਅਤੇ ਫੋਲਡਰ ਸਿਰਫ਼ ਸਾਫ-ਸੁਥਰੇ ਨਹੀਂ; ਇਹ ਉਹ ਤਰੀਕੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਫਰੇਮਵਰਕ ਚੀਜ਼ਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ।
Ember ਨੇ ਇਹੀ ਵਿਚਾਰ ਫਰੰਟਐਂਡ 'ਤੇ ਅੱਗੇ ਲਿਆਂਦਾ: ਇੱਕ ਪੇਸ਼ਗੋਈਯੋਗ ਪ੍ਰੋਜੈਕਟ ਲੇਆਉਟ ਅਤੇ ਨਾਂ-ਦਿੱਤੀਆਂ ਰੀਤਾਂ ਜੋ ਐਪ ਨੂੰ ਸਮਝਣਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਤੁਸੀਂ ਉਸਨੂੰ ਨਾ ਹੀ ਲਿਖਿਆ ਹੋਵੇ।
ਰਿਵਾਇਤਾਂ ਫੈਸਲੇ ਦੀ ਥਾਕ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਜਦ ਇੱਕ "ਨਾਰਮਲ ਰੀਤ" ਹੁੰਦੀ ਹੈ, ਟੀਮਾਂ ਘੱਟ ਸਮਾਂ ਅੰਦਰ ਅੰਦਰ ਅੰਦਰੂਨੀ ਮਿਆਰ ਬਣਾਉਣ ਵਿੱਚ ਲਾਂਦੀਆਂ ਹਨ ਅਤੇ ਵੱਧ ਸਮਾਂ ਨਵੇਂ ਫੀਚਰ ਬਣਾਉਣ ਵਿੱਚ।
ਉਹ ਓਨਬੋਰਡਿੰਗ ਵੀ ਤੇਜ਼ ਕਰਦੀਆਂ ਹਨ: ਨਵੇਂ ਕਰੋੜ ਪਿਛਲੇ ਨੌਕਰੀਆਂ ਤੋਂ ਪੈਟਰਨ ਪਛਾਣ ਸਕਦੇ ਹਨ, ਅਤੇ ਜੂਨੀਅਰ ਟਿਊਟੋਰਿਯਲਾਂ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਹਰ ਵਾਰ "ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ" ਸੁਣਣ ਦੇ। ਸਾਂਝੇ ਪੈਟਰਨ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਇੱਕ ਸਾਂਝਾ ਮਨਸਿਕ ਮਾਡਲ ਬਣਾਉਂਦੇ ਹਨ।
ਰਿਵਾਇਤਾਂ ਲਚੀਲਾਪਣ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਕਈ ਵਾਰ ਤੁਸੀਂ ਵੱਖਰਾ ਫੋਲਡਰ ਲੇਆਉਟ ਜਾਂ ਕਸਟਮ ਵਰਕਫਲੋ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ Rails ਜਾਂ Ember ਵਰਗੇ ਫਰੇਮਵਰਕ ਤੁਹਾਨੂੰ "Rails/Ember ਰੀਤ" ਵੱਲ ਧੱਕ ਸਕਦੇ ਹਨ। ਫਾਇਦਾ ਇੱਕਸਰਤਾ ਹੈ; ਲਾਗਤ ਘਰ ਦੇ ਨਿਯਮ ਸਿੱਖਣ ਦੀ ਹੈ।
ਜਿੰਨੀ ਵੱਡੀ ਕਮੇਊਨਿਟੀ ਹੋਵੇਗੀ, ਰਿਵਾਇਤਾਂ ਉਹਨਾਂ ਲਈ ਉਹਨਾਂ ਦੀ ਕੀਮਤ ਵਧਦਾ ਹੈ। ਟਿਊਟੋਰਿਯਲ ਇੱਕੋ ਸਟ੍ਰੱਕਚਰ ਮੰਨ ਕੇ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਹਾਇਰਿੰਗ ਅਸਾਨ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਮੀਦਵਾਰ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ। ਕੋਡ ਰਿਵਿਊ ਵੀ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ: ਗੱਲਾਂ "ਆਪਾਂ ਇਹ ਕਿਵੇਂ ਕਰੀਏ?" ਤੋਂ "ਕੀ ਅਸੀਂ ਸਟੈਂਡਰਡ ਫਾਲੋ ਕੀਤਾ?" ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
Rails ਮਹੱਤਵਪੂਰਕ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ "ਵੈੱਬ ਐਪ ਬਣਾਉਣਾ" ਨੂੰ ਇੱਕ ਪੂਰਾ ਕੰਮ ਮੰਨਿਆ, ਨਾ ਕਿ ਹਿੱਸਿਆਂ ਦਾ ਇਕ ਢੇਰ। ਹਰ ਟੀਮ ਨੂੰ ਥੋੜ੍ਹੇ ਹਿੱਸਿਆਂ ਤੋਂ ਸਟੈਕ ਬਣਾਉਣ ਦੀ ਥਾਂ, Rails ਆਮ ਲੋੜਾਂ ਲਈ ਇੰਟੀਗ੍ਰੇਟਿਡ ਡੀਫਾਲਟਸ ਨਾਲ ਆਇਆ: routing, controllers, views, ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਟੈਸਟਿੰਗ ਪੈਟਰਨ, ਅਤੇ ਕੋਡ ਨੂੰ ਆਯੋਜਿਤ ਕਰਨ ਦਾ ਇੱਕ ਸਪੱਸ਼ਟ ਤਰੀਕਾ।
ਕ੍ਰੂਡ-ਸਟਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਫੀਚਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਇਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ—ਤੁਸੀਂ ਤੁਰੰਤ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਸੀ।
ਉਸ ਤੇਜ਼ੀ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਜੈਨਰੇਟਰ ਅਤੇ ਰਿਵਾਇਤਾਂ ਦਾ ਮਿਲਾਪ ਸੀ। Rails ਸਿਰਫ API ਨਹੀਂ ਦਿੱਤਾ; ਇਸ ਨੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ਕਲ ਦਿੱਤੀ।
ਜਦੋਂ ਤੁਸੀਂ model ਜਾਂ scaffold ਜਨਰੇਟ ਕਰਦੇ ਹੋ, Rails ਪੂਰੇ-ਪਣੀ-ਜਗ੍ਹਾ ਫਾਇਲਾਂ ਬਣਾਉਂਦਾ, ਨਾਂ-ਨਿਰਧਾਰਨ ਜੋੜਦਾ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਂਝੇ ਵਰਕਫਲੋ ਵੱਲ ਧੱਕਦਾ। ਇਸ ਸਥਿਰਤਾ ਦੇ ਦੋ ਅਮਲੀ ਪ੍ਰਭਾਵ ਸਨ:
ਇੱਕ ਸ਼ਬਦ ਵਿੱਚ, ਫੋਲਡਰ ਸਟ੍ਰੱਕਚਰ ਅਤੇ ਨਾਂ-ਨਿਯਮ ਸਿਰਫ਼ ਸੌੰਦਰਤਾ ਨਹੀਂ—ਉਹ ਸਹਯੋਗ ਦਾ ਇੱਕ ਟੂਲ ਸਨ।
Rails ਨੇ ਪਹਿਲੇ ਫੀਚਰ ਤੱਕ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਕਿਉਂਕਿ ਪਹਿਲੇ ਫੈਸਲੇ ਹਟਾ ਦਿੱਤੇ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਉਤਪਾਦ ਮੁੱਲ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਤੁਹਾਨੂੰ ORM, controllers ਦੀ ਬਣਤਰ ਜਾਂ migrations ਕਿਵੇਂ ਬਣਾਉਣੇ—ਇਹ ਸਾਰੇ ਚੋਣਾਂ 'ਤੇ ਬਹਿਸ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਫਰੇਮਵਰਕ ਨੇ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਕੀਤਾ, ਅਤੇ ਕਿਉਂਕਿ ਡੀਫਾਲਟ ਗਠਜੋੜ ਵਾਲੇ ਸਨ, ਇੱਕ ਖ਼ਿਆਲ ਤੋਂ ਚੱਲਦੇ(endpoint) ਤੱਕ ਰਸਤਾ ਛੋਟਾ ਸੀ।
ਇਹ ਤਜਰਬਾ ਉਮੀਦਾਂ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਸੀ: ਫਰੇਮਵਰਕ ਸਿਰਫ ਰਨਟਾਈਮ ਬਿਹਿਵਅਰ ਬਾਰੇ ਨਹੀਂ—ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਐਪ ਵੱਡਾ ਹੋਣ 'ਤੇ ਉਤਪਾਦਕਤਾ ਬਨਾਏ ਰੱਖਣ ਬਾਰੇ ਵੀ ਸੀ।
Rails ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਸਧਾਰਨ ਕੀਤਾ ਕਿ ਟੂਲਿੰਗ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹੈ। ਕਮਾਂਡ ਲਾਈਨ ਵਿਕਲਪ ਨਹੀਂ ਸੀ—ਉਹ ਦਾਖਲਾ ਦਰਵਾਜ਼ਾ ਸੀ। ਜੈਨਰੇਟਰ, migrations ਅਤੇ ਮਿਆਰੀ ਕੰਮਾਂ ਨੇ ਫਰੇਮਵਰਕ ਨੂੰ ਮਾਰਗਦਰਸ਼ਕ ਮਹਿਸੂਸ ਕਰਵਾਇਆ ਨਾਂ ਕਿ ਕੇਵਲ ਕਨਫ਼ਿਗਰ ਕੀਤਾ ਜਾ ਸਕਣ ਵਾਲੀ ਚੀਜ਼।
ਇਹ "ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਿਡ" ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਬਾਅਦ ਵਿੱਚ ਫਰੰਟਐਂਡ ਸੋਚ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਗਿਆ, ਜਿਸ ਵਿੱਚ Yehuda Katz ਨੇ ਜ਼ੋਰ ਦਿੱਤਾ ਕਿ ਅਕਸਰ ਅਪਣਾਉਣ ਉਹਨਾਂ ਟੂਲਾਂ ਅਤੇ ਰਿਵਾਇਤਾਂ ਤੋਂ ਹੁੰਦੀ ਹੈ ਜੋ ਫਰੇਮਵਰਕ ਨੂੰ ਪੂਰਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀਆਂ ਹਨ।
ਜਿਸ ਤਰ੍ਹਾਂ Rails ਨੇ "ਯੋਜਨਾ-ਸਮेत ਫਰੇਮਵਰਕ" ਦੀ ਸੋਚ ਪ੍ਰਸਿੱਧ ਕੀਤੀ, ਫਰੰਟਐਂਡ ਵਿਕਾਸ ਅਜੇ ਵੀ ਕਈ ਵਾਰ ਹਿਸਿਆਂ ਦਾ ਢੇਰ ਸੀ। ਟੀਮਾਂ jQuery plugin, ਟੈਮਪਲੇਟ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਐਡ-ਹਾਕ AJAX ਅਤੇ ਹੱਥ-ਲਿਖੇ ਬਿਲਡ ਸਟੈਪ ਮਿਲਾ ਦਿੰਦੀਆਂ। ਇਹ ਚਾਲੂ ਸੀ—ਜਦ ਤੱਕ ਐਪ ਵੱਡਾ ਨਾ ਹੋ ਜਾਵੇ।
ਫਿਰ ਹਰ नया ਸਕ੍ਰੀਨ ਜ਼ਿਆਦਾ ਮੈਨੁਅਲ ਵਾਇਰਿੰਗ ਮੰਗਦਾ: URLs ਨੂੰ ਵਿਊਜ਼ ਨਾਲ ਸਿੰਕ ਕਰਨਾ, ਸਟੇਟ ਹੋਲਡ ਕਰਨਾ, ਡਾਟਾ ਦੀ ਥਾਂ ਨਿਰਧਾਰਿਤ ਕਰਨਾ, ਅਤੇ ਹਰ ਨਵੇਂ ਡਿਵੈਲਪਰ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਨਿੱਜੀ ਰੀਤਾਂ ਸਿਖਾਉਣਾ।
ਸਿੰਗਲ-ਪੇਜ਼ ਐਪਾਂ ਨੇ ਬਰਾਊਜ਼ਰ ਨੂੰ ਇੱਕ ਅਸਲੀ ਐਪ ਰਨਟਾਈਮ ਬਣਾਇਆ, ਪਰ ਸ਼ੁਰੂਆਤੀ ਟੂਲਿੰਗ ਇੱਕ ਸਾਂਝਾ ਢਾਂਚਾ ਨਹੀਂ ਦਿੰਦੀ ਸੀ। ਨਤੀਜਾ ਅਸਮਾਨ ਕੋਡਬੇਸ ਸੀ ਜਿਸ ਵਿੱਚ:
Ember ਨੇ ਫਰੰਟਐਂਡ ਨੂੰ ਪਹਿਲ-ਸ਼੍ਰੇਣੀ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ ਵਜੋਂ ਦੇਖਿਆ—ਕੇਵਲ UI ਵਿਜੇਟਸ ਦਾ ਸਮੂਹ ਨਹੀਂ। "ਆਪਣਾ ਸਭ ਕੁਝ ਚੁਣੋ" ਕਹਿਣ di ਥਾਂ, ਇਹ coherence ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਇਕੱਠੇ ਲਿਆਉਣ ਵਾਲੇ ਡੀਫਾਲਟ ਦਿੱਤੇ।
ਉੱਚ-ਸਤਰ 'ਤੇ Ember ਨੇ ਜ਼ੋਰ ਦਿੱਤਾ:
Ember ਦੀ ਪੇਸ਼ਕਸ਼ ਨਵੀਂ ਕੁਝ ਨਹੀਂ ਸੀ—ਇਹ ਸਥਿਰਤਾ ਅਤੇ ਸਾਂਝੀ ਸਮਝ ਸੀ। ਜਦ ਫਰੇਮਵਰਕ "ਖੁਸ਼ ਰਸਤਾ" ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਚਰਚਾ ਕਰਨ ਦੀ ਥਾਂ ਫੀਚਰ ਸ਼ਿਪ ਕਰਨ 'ਤੇ ਘੱਟ ਸਮਾਂ ਗੁਜ਼ਾਰਦੀਆਂ ਹਨ।
ਇਹ ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਉਨ੍ਹਾਂ ਐਪਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਕ ਹੈ ਜੋ ਸਾਲਾਂ ਤੱਕ ਚਲਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਓਨਬੋਰਡਿੰਗ, ਅਪਗਰੇਡ ਅਤੇ ਸਥਿਰ ਪੈਟਰਨ ਲਚੀਲਾਪਣ ਵਜੋਂ ਹੀ ਨਹੀਂ, ਪ੍ਰਧਾਨ ਹਨ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਇੰਸਟਾਲ ਕਰਨ ਯੋਗ ਕੋਡ ਨਹੀਂ—ਇਹ ਇਕ ਰਿਸ਼ਤਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਦੇਖਭਾਲ ਕਰਦੇ ਹੋ। ਇਸੀ ਲਈ Ember ਨੇ ਸਥਿਰਤਾ 'ਤੇ ਅਸਧਾਰਣ ਤੌਰ 'ਤੇ ਜ਼ੋਰ ਦਿੱਤਾ: ਨਿਰਧਾਰਿਤ ਰਿਲੀਜ਼, ਸਪੱਸ਼ਟ ਡਿਪ੍ਰੇਕੇਸ਼ਨ ਚੇਤਾਵਨੀਆਂ, ਅਤੇ ਦਸਤਾਵੇਜ਼ਬੱਧ ਅਪਗਰੇਡ ਰਸਤੇ। ਮਨੋਰਥ ਇਹ ਨਹੀ ਸੀ ਕਿ ਨਵੀਨਤਾ ਰੁਕੀ ਰਹੇ—ਬਲਕਿ ਇਹ ਕਿ ਬਦਲਾਅ ਉਹਨਾਂ ਲਈ ਯੋਜਨਾਬੱਧ ਹੋਣ ਜੋ ਟੀਮਾਂ ਕਰਦੀਆਂ ਹਨ।
ਕਈ ਟੀਮਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡੀ ਲਾਗਤ ਪਹਿਲੀ ਬਿਲਡ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਤੀਜੇ ਸਾਲ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਜਦ ਕੋਈ ਫਰੇਮਵਰਕ ਦਿਖਾ ਦੇਂਦਾ ਹੈ ਕਿ ਅਪਗਰੇਡ ਸਮਝਦਾਰ ਅਤੇ ਕਦਮ-ਬਦ-ਕਦਮ ਹੋਣਗੇ, ਤਾਂ ਉਹ ਇੱਕ ਠੋਸ ਡਰ ਘਟਾਉਂਦਾ ਹੈ: ਪੁਰਾਣੀ ਵਰਜਨ 'ਤੇ ਫਸ ਜਾਣ ਦਾ ਡਰ।
ਕੋਈ ਵੀ ਫਰੇਮਵਰਕ ਕਹਿ ਨਹੀਂ ਸਕਦਾ ਕਿ ਅਪਗਰੇਡ ਪੂਰੇ ਤੌਰ 'ਤੇ ਦਰਦ ਰਹਿਤ ਹੋਣਗੇ। ਜੋ ਮਾਇਦਾ ਹੈ ਉਹ ਹੈ ਫਲਸਫਾ ਅਤੇ ਆਦਤਾਂ: ਮਨੋਰਥ ਸਪੱਸ਼ਟ ਕੀਤਾ ਜਾਣ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡ ਦਿੱਤੇ ਜਾਣ, ਅਤੇ ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਿਟੀ ਨੂੰ ਉਪਭੋਗਤਾ-ਸਮਰੱਥ ਫੀਚਰ ਮਨਿਆ ਜਾਣ।
Ember ਨੇ RFC-ਸ਼ੈਲੀ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਸਿੱਧ ਕੀਤੀ ਜੋ ਬਦਲਾਅ ਪ੍ਰਸਥਾਵਿਤ ਅਤੇ ਚਰਚਾ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। RFC ਪਹੁੰਚ ਫਰੇਮਵਰਕ ਵਿਕਾਸ ਨੂੰ ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ:
ਵਧੀਆ ਗਵਰਨੈਂਸ ਇੱਕ ਫਰੇਮਵਰਕ ਨੂੰ ਇਕ ਉਤਪਾਦ ਵਾਂਗ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸਦਾ ਰੋਡਮੈਪ ਹੋਵੇ, ਨਾ ਕਿ APIs ਦਾ ਬੇਰੁਖਾ ਢੇਰ।
ਫਰੇਮਵਰਕ ਸਿਰਫ਼ API ਸੈੱਟ ਨਹੀਂ—ਇਹ ਨਵੇਂ ਡਿਵੈਲਪਰ ਦੇ ਪਹਿਲੇ 30 ਮਿੰਟ ਹਨ। ਇਸੀ ਲਈ CLI ਫਰੇਮਵਰਕ ਅਪਣਾਉਣ ਲਈ "ਫਰੰਟ ਡੋਰ" ਬਣ ਗਿਆ: ਇਹ "ਆਸਾਨ ਸ਼ੁਰੂ" ਦੇ ਵਾਅਦੇ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਅਨੁਭਵ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਜਦੋਂ CLI ਤੁਹਾਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ, ਚਲਾਉਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਬਿਲਡ ਕਰਨ ਦੇ ਅਨੁਭਵ ਨੂੰ ਨਿਰਧਾਰਿਤ ਹੁਕਮਾਂ ਨਾਲ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਭ ਤੋਂ ਵੱਡੀ ਸ਼ੁਰੂਆਤੀ ਫੇਲ੍ਹ-ਮੋਡ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ:
ਆਮ ਪਲ ਜੋ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ ਇਹ ਹਨ:
rails new … ਜਾਂ ember new …rails server, ember serverails test, ember testrails assets:precompile, ember buildਕਮਾਂਡਾਂ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਵਾਅਦਾ ਇੱਕੋ ਹੀ ਹੈ: "ਤੁਹਾਨੂੰ ਆਪਣਾ ਸਟਾਰਟਰ ਕਿੱਟ ਖੁਦ jੁਟਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ।"
ਫਰੇਮਵਰਕ ਟੂਲਿੰਗ ਉਹ عملي ਫੈਸਲੇ ਹਨ ਜੋ ਟੀਮਾਂ ਹਰ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਫਿਰ-ਫਿਰ ਕਰਦੀਆਂ ਹੋਣਗੀਆਂ:
Rails ਨੇ ਜੈਨਰੇਟਰ ਅਤੇ ਰਿਵਾਇਤਾਂ ਨਾਲ ਇਹ ਅਹਿਸਾਸ ਪਹਿਲਾਂ ਹੀ ਪੈਦਾ ਕੀਤਾ; Ember ਨੇ ember-cli ਨਾਲ ਕਮਾਂਡ ਲਾਈਨ ਨੂੰ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਸਹਯੋਗੀ ਪਰਤ ਬਣਾਇਆ।
ਚੰਗੇ ਡੀਫਾਲਟ ਲੰਬੇ-ਲੋੜੇ ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਕਾਪੀ-ਪੇਸਟ ਸੈਟਅਪ ਦੀ ਲੋੜ ਘਟਾਉਂਦੇ ਹਨ। "ਇਹ 18 ਕਦਮ ਪ従 ਥੋੜੇ ਹਨ" ਦੀ ਥਾਂ onboarding ਹੁੰਦੀ ਹੈ "ਰੇਪੋ ਕਲੋਨ ਕਰੋ ਅਤੇ ਦੋ ਕਮਾਂਡ ਚਲਾਓ"। ਇਸ ਦਾ ਨਤੀਜਾ ਤੇਜ਼ ਰੈਂਪ-ਅੱਪ, ਘੱਟ ਮਸ਼ੀਨ-ਨਿਰਭਰ ਸਮੱਸਿਆਵਾਂ, ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦਰਮਿਆਨ ਘੱਟ ਸੁੱਖਣ ਅੰਤਰ ਹੁੰਦਾ ਹੈ।
ਇਹੀ ਅਪਣਾਉਣ ਗਤੀਵਿਧੀ CLI ਤੋਂ ਉਪਰ ਵੀ ਵਧ ਰਹੀ ਹੈ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai "ਫਰੰਟ ਡੋਰ" ਵਿਚ ਹੋਰ ਅੱਗੇ ਵਧਾਉਂਦੀਆਂ ਹਨ—ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਵਿੱਚ ਐਪ ਦਾ ਵੇਰਵਾ ਦੇਣ ਦੀ ਆਗਿਆ ਦੇ ਕੇ ਇੱਕ ਢਾਂਚਾਬੱਧ ਕੋਡਬੇਸ ਜਨਰੇਟ ਕਰਨ ਦੀ ਆਸਾਨੀ; ਉਦਾਹਰਨ ਲਈ React ਫਰੰਟਐਂਡ, Go + PostgreSQL ਬੈਕਐਂਡ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਡਿਪਲੌਇਮੈਂਟ ਅਤੇ ਹੋਸਟਿੰਗ।
ਮੁੱਦਾ ਇਹ ਨਹੀਂ ਕਿ ਚੈਟ ਫਰੇਮਵਰਕ ਨੂੰ ਬਦਲ ਦੇਵੇ—ਬਲਕਿ ਇਹ ਕਿ ਓਨਬੋਰਡਿੰਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਅਨੁਭਵ ਹੁਣ ਉਤਪਾਦੀ ਫੀਚਰ ਹੈ। ਚਾਹੇ ਦਾਖਲਾ CLI ਹੋਵੇ ਜਾਂ ਚੈਟ-ਚਲਿਤ ਬਿਲਡਰ, ਜਿੱਤਣ ਵਾਲੇ ਟੂਲ ਸੈਟਅੱਪ ਦੀ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਇਕ ਸਤਿਕਾਰਤ ਰਾਹ 'ਤੇ ਰੱਖਦੇ ਹਨ।
DX ਇੱਕ ਆਭਾਸ ਨਹੀਂ। ਇਹ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਫੀਚਰ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਬੱਗ ਠੀਕ ਕਰਦੇ ਸਮੇਂ, ਅਤੇ ਸਾਥੀਆਂ ਨੂੰ ਓਨਬੋਰਡ ਕਰਦੇ ਸਮੇਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ—ਅਤੇ ਇਹੀ ਸੰਕੇਤ ਅਕਸਰ ਉਹ ਫੈਸਲਾ ਕਰਦਿਆਂ ਕਿ ਫਰੇਮਵਰਕ ਟੀਮ ਰੱਖੇਗੀ ਜਾਂ ਨਹੀਂ।
ਫਰੇਮਵਰਕ ਦਾ DX ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪਲਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਏਹ ਉਹ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਸਿੱਖਿਆ ਨੂੰ ਪ੍ਰਗਤੀ ਵਿੱਚ ਬਦਲਦੀਆਂ ਹਨ ਨਾ ਕਿ ਰੁਕਾਵਟ।
ਅਪਣਾਉਣ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ "ਪਿੱਟ ਆਫ ਸੱਕਸੈਸ" ਹੈ: ਸਹੀ ਕੰਮ ਕਰਨਾ ਵੀ ਸਭ ਤੋਂ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦ ਰਿਵਾਇਤਾਂ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਡੀਫਾਲਟ, ਇਕਸਾਰ ਪੈਟਰਨ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ-ਦੋਸਤਾਨਾ ਸੈਟਅੱਪ ਵੱਲ ਦਿਸ਼ਾ ਦਿੰਦੀਆਂ ਹਨ, ਟੀਮਾਂ ਘੱਟ ਗਲਤੀਆਂ ਕਰਦੀਆਂ ਹਨ।
ਇਸ ਲਈ ਰਿਵਾਇਤਾਂ ਅਜ਼ਾਦੀ ਵਰਗੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀਆਂ ਹਨ: ਉਹ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਫੈਸਲਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾ ਦਿੰਦੀਆਂ ਹਨ।
ਡੌਕਸ DX ਵਿੱਚ ਬਾਅਦ ਨੂੰਵੀਂ ਨਹੀਂ; ਉਹ ਇਕ ਮੁੱਖ ਫੀਚਰ ਹਨ। ਉੱਚ-ਗੁਣਵੱਤਾ ਡੌਕਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਿਲ ਹੈ:
ਜਦ ਡੌਕਸ ਮਜ਼ਬੂਤ ਹੁੰਦੀਆਂ ਹਨ, ਟੀਮਾਂ ਆਪਣਾ ਹੱਲ ਖੁਦ ਲੱਭ ਲੈਂਦੀਆਂ ਹਨ ਨਾਂ ਕਿ ਸਿਰਫ਼ ਕਬਾਈਲੀ ਗਿਆਨ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਇੱਕ ਟੀਮ "ਚਲਾਕ" ਸੈੱਟਅੱਪ ਨੂੰ ਸਹਿਣ ਕਰ ਸਕਦੀ ਹੈ। ਜਿਵੇਂ-जਿਵੇਂ ਕੋਡਬੇਸ ਵੱਧਦਾ ਹੈ, ਇਕਸਾਰਤਾ ਜੀਵਨ ਰੱਖਣ ਲਈ ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ: ਪੇਟਰਨ ਸਮੀਖਿਆ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹਨ, ਬੱਗ ਟਰੇਸ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਓਨਬੋਰਡਿੰਗ ਘੱਟ ਜੋਖਮ ਵਾਲੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਸਮਾਂ ਦੇ ਨਾਲ, ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਫਰੇਮਵਰਕ ਚੁਣ ਲੈਂਦੀ ਹੈ ਜੋ ਦਿਨ-ਪਰ-ਦਿਨ ਕੰਮ ਨੂੰ ਸ਼ਾਂਤ ਰੱਖਦਾ—ਨਾ ਕਿ ਉਹ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ।
ਜਦ ਟੂਲਿੰਗ ਵਿਖਿੜੀ ਹੋਵੇ, ਪਹਿਲੀ "ਫੀਚਰ" ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਸ਼ਿਪ ਕਰਦੀ ਹੈ ਉਹ ਫੈਸਲਿਆਂ ਦਾ ਢੇਰ ਹੁੰਦਾ ਹੈ। ਕਿਹੜਾ router? ਕਿਹੜਾ build system? ਕਿਹੜਾ ਟੈਸਟਿੰਗ ਸੈੱਟਅੱਪ? ਸਟਾਈਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਗੇ? Environment variables ਕਿੱਥੇ ਰਹਿਣਗੇ?
ਇਹ ਚੋਣਾਂ ਖ਼ਰਾਬ ਨਹੀਂ—ਪਰ ਸੰਯੋਜਨ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਮੁਕਾਬਲਿਆਂ ਨੂੰ ਵਧਾ ਦਿੰਦੀਆਂ ਹਨ: ਪੈਕੇਜ ਵੱਖ-ਵੱਖ ਨਿਰਯਾਤ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਪਲੱਗਇਨ ਓਵਰਲੈਪ ਕਰਦੇ, ਅਤੇ "ਸਰਵੋਤਮ ਅਭਿਆਸ" ਟਕਰਾਉਂਦੇ। ਦੋ ਡਿਵੈਲਪਰ ਇੱਕੋ ਪ੍ਰੋਜੈਕਟ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ ਤੇ ਬਹੁਤ ਵੱਖਰੇ ਸੈਟਅੱਪਸ ਨਤੀਜੇ ਵਜੋਂ ਉਤਪੰਨ ਹੋ ਸਕਦੇ ਹਨ।
ਇਸੇ ਕਾਰਨ "ਮਿਆਰੀ ਸਟੈਕ" ਮਨ-ਸ਼ੇਅਰ ਜਿੱਤਦਾ ਹੈ। ਇੱਕ ਮਿਆਰੀ ਸਟੈਕ ਪੂਰਨ ਹੋਣ ਦੀ ਥਾਂ ਭਵਿੱਖ ਬਰਾਬਰ ਹੋਣ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ: ਡੀਫਾਲਟ router, ਡੀਫਾਲਟ ਟੈਸਟ ਕਰਨ ਦੀ ਰੀਤ, ਡੀਫਾਲਟ ਫੋਲਡਰ ਸਟ੍ਰੱਕਚਰ, ਅਤੇ ਡੀਫਾਲਟ ਅਪਗਰੇਡ ਰਾਹ।
ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਸੰਯੋਗਤ ਲਾਭ ਦਿੰਦੀ ਹੈ:
ਇਹ Rails ਅਤੇ ਬਾਅਦ ਵਿੱਚ Ember ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਸੀ: ਸਾਂਝੀ ਭਾਸ਼ਾ। ਤੁਸੀਂ ਕੇਵਲ ਇੱਕ ਫਰੇਮਵਰਕ ਹੀ ਨਹੀਂ ਸਿਖਦੇ—ਤੁਸੀਂ "ਉਹ ਤਰੀਕਾ" ਸਿੱਖਦੇ ਹੋ ਜਿਸ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਆਮ ਤੌਰ 'ਤੇ ਬਣਦੇ ਹਨ।
ਲਚੀਲਾਪਣ ਟੀਮਾਂ ਨੂੰ ਓਪਟਿਮਾਈਜ਼ ਕਰਨ ਦੀ ਜਗ੍ਹਾ ਦਿੰਦਾ: ਕਿਸੇ ਖਾਸ ਜ਼ਰੂਰਤ ਲਈ ਸਰਵੋਤਮ ਲਾਇਬ੍ਰੇਰੀ ਚੁਣੋ, ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲੋ, ਜਾਂ ਨਵੇਂ ਵਿਚਾਰ ਪਹਿਲਾਂ ਅਪਣਾਓ। ਅਨੁਭਵੀ ਟੀਮਾਂ ਲਈ ਜੋ ਆਪਣੇ ਅੰਦਰੂਨੀ ਮਿਆਰ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੀਆਂ ਹਨ, modularity ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦੀ ਹੈ।
ਪਰ ਇਕਸਾਰਤਾ ਹੀ ਇੱਕ ਫਰੇਮਵਰਕ ਨੂੰ ਉਤਪਾਦ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ। ਇੱਕ ਸਥਿਰ ਸਟੈਕ ਘੱਟ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਪੈਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਟੀਮ ਬਦਲਣ ਜਾਂ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟ ਰੱਖ-ਰਖਾਵ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ।
ਅਪਣਾਉਣ ਸਿਰਫ ਤਕਨੀਕੀ ਮੈਰਿਟ 'ਤੇ ਨਹੀਂ ਹੁੰਦਾ। ਮਿਆਰੀਕਰਨ ਟੀਮਾਂ ਨੂੰ ਘੱਟ ਬਹਿਸ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਫੈਸਲੇ ਨੂੰ ਹੁੰਦਾ ਹੈ ਕਿ ਹਿੱਸਾ-ਦਾਰੀਆਂ ਨੂੰ ਸਹੀ ਠਹਿਰਾਉਣ ਵਿੱਚ ਆਸਾਨੀ। ਜਦ ਫਰੇਮਵਰਕ ਦੀਆਂ ਰਿਵਾਇਤਾਂ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ stakeholdeਰਾਂ ਨੂੰ ਜਸਟਿਫਾਇ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਹਾਇਰਿੰਗ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ (ਕਿਉਂਕਿ ਸਕਿਲ ਟਰਾਂਸਫਰ ਹੁੰਦੀ ਹੈ), ਅਤੇ ਕਮੇਊਨਿਟੀ ਸਿੱਖਾਉਣਾ ਮੋਹਰੀ ਬਣ ਜਾਂਦੀ ਹੈ।
ਦੂਸਰੇ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਮਿਆਰ ਮਨ-ਸ਼ੇਅਰ ਜਿੱਤਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵੈੱਬ ਐਪ ਬਣਾਉਣ ਦੀ "ਫੈਸਲਾ ਸਤਹ" ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ—ਤਾਂ ਜੋ ਵੱਧ ਊਰਜਾ ਐਪ ਵਿੱਚ ਹੀ ਲੱਗੇ, ਨਾਂ ਕਿ ਉਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਢਾਂਚੇ ਵਿੱਚ।
ਕਦੇ ਫਰੇਮਵਰਕ ਨੂੰ "ਮੁਕੰਮਲ" ਮਹਿਸੂਸ ਕਰਨ ਲਈ ਕਾਫੀ ਸੀ ਜੇ ਉਹ routing, ਟੈਮਪਲੇਟ ਅਤੇ ਇੱਕ ਢੰਗ ਦਾ ਫੋਲਡਰ ਸਟ੍ਰੱਕਚਰ ਦਿੰਦਾ। ਫਿਰ ਭਾਰੀ ਕੇਂਦਰ ਬਦਲਿਆ: bundlers, compilers, package managers ਅਤੇ deployment ਪਾਈਪਲਾਈਨ ਰੋਜ਼ਾਨਾ ਕੰਮ ਦਾ حصہ ਬਣ ਗਏ।
ਟੀਮਾਂ ਹੁਣ ਇਹ ਨਹੀਂ ਪੁੱਛਦੀਆਂ "ਕਿਹੜਾ ਫਰੇਮਵਰਕ ਵਰਤਣਾ ਹੈ?" ਪਰ ਪੁੱਛਦੀਆਂ ਹਨ "ਅਸੀਂ ਕਿਸ ਟੂਲਚੇਨ ਨਾਲ ਦਸਤਖਤ ਕਰ ਰਹੇ ਹਾਂ?"
ਆਧੁਨਿਕ ਐਪਾਂ ਹੁਣ ਦਹਰਾਉਣਯੋਗ ਛੋਟੇ-ਖੰਡਾਂ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: components, styles, translations, images, ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਪੈਕੇਜ। ਬਿਲਡ ਟੂਲ ਉਹ ਮਸ਼ੀਨਰੀ ਹੈ ਜੋ ਇਹ ਸਭ ਕੁਝ ਇੱਕ ਤੀਆਂ-ਛੋਟਾ, ਅਨੁਕੂਲ ਫਾਇਲਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਬਰਾਊਜ਼ਰ ਤੇਜੀ ਨਾਲ ਲੋਡ ਕਰ ਸਕੇ।
ਸਰਲ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾਓ: ਤੁਸੀਂ ਕਈ ਛੋਟੇ ਫਾਈਲਾਂ ਲਿਖਦੇ ਹੋ ਕਿਉਂਕਿ ਇਹ ਸੰਭਾਲਣ ਲਈ ਆਸਾਨ ਹਨ, ਅਤੇ ਬਿਲਡ ਕਦਮ ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਅਨੁਕੂਲ ਫਾਈਲਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਤਾਂ ਜੋ ਉਪਭੋਗਤਾ ਤੇਜ਼ ਐਪ ਡਾਊਨਲੋਡ ਕਰ ਸਕਣ।
ਬਿਲਡ ਟੂਲ ਮਹੱਤਵਪੂਰਨ ਹੋ ਗਏ ਹਨ ਕਿਉਂਕਿ ਉਹ:
ਇੱਕ ਵਾਰੀ ਇਹ ਸਟੈਂਡਰਡ ਹੋ ਗਿਆ, ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਹੁਣ ਸਿਰਫ API ਹੀ ਨਹੀਂ—ਉਹਨਾਂ ਨੂੰ ਸਰੋਤ ਕੋਡ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਆਉਟਪੁੱਟ ਤੱਕ ਇੱਕ ਸਮਰਥਤ ਰਾਹ ਮੁਹੱਈਆ ਕਰਨਾ ਪੈ ਗਿਆ।
ਫਾਇਦਾ ਤੇਜ਼ੀ ਅਤੇ ਪੈਮਾਨੇ 'ਤੇ ਹੈ। ਲਾਗਤ ਹੈ ਜੰਕਸ਼ਨ: ਕਨਫ਼ਿਗਰੇਸ਼ਨ, ਪਲੱਗਇਨ ਵਰਜਨ, ਕੰਪਾਈਲਰ quirks, ਅਤੇ ਸੁਖੜ ਤੋੜ-ਫੋੜ।
ਇਸੀ ਲਈ "ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਿਡ" ਦਾ ਅਰਥ ਹੁਣ ਅਕਸਰ ਹੁੰਦਾ ਹੈ ਸਥਿਰ ਬਿਲਡ ਡੀਫਾਲਟ, ਸਮਝਦਾਰ ਅਪਗਰੇਡ ਰਸਤੇ, ਅਤੇ ਉਹ ਟੂਲਿੰਗ ਜੋ ਸਮਝਦਾਰ ਗਲਤੀਆਂ ਨਾਲ ਫੇਲ ਹੋਵੇ—ਸਿਰਫ ਇੱਕ ਸੁੰਦਰ component ਮਾਡਲ ਨਹੀਂ।
ਫਰੇਮਵਰਕ ਅਪਗਰੇਡ ਸਿਰਫ਼ ਰਖ-ਰਖਾਵ ਦਾ ਕੰਮ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਇਹ ਉਹ ਮੋੜ ਹੈ ਜਿੱਥੇ ਫਰੇਮਵਰਕ ਜਾਂ ਤਾਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਭਰੋਸਾ ਜਿੱਤਦਾ ਹੈ—ਜਾਂ ਅਗਲੀ ਰੀਰਾਈਟ ਤੱਕ ਚੁਪਚਾਪ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਜਦ ਅਪਗਰੇਡ ਗਲਤ ਜਾਂਦੇ ਹਨ ਤਾਂ ਲਾਗਤ ਸਧਾਰਨ ਨਹੀਂ ਰਹਿੰਦੀ। ਉਹ ਸ਼ਡਿਊਲ ਖਿਸਕਣ, ਅਣਪਛਾਤੇ ਰਿਗ੍ਰੈਸ਼ਨ, ਅਤੇ ਛੇਜ-ਛੇਜ ਡਰ ਵਜੋਂ ਉਭਰਦੀਆਂ ਹਨ।
ਆਮ ਤਕਲੀਫ਼ਾਂ:
ਆਖਰੀ ਪਾਏਂਟ ਉੱਥੇ ਜਿੱਥੇ ਰਿਵਾਇਤਾਂ ਅਹੰਕਾਰ ਖੇਡਦੀਆਂ ਹਨ: ਇੱਕ ਫਰੇਮਵਰਕ ਜੋ "ਮਿਆਰੀ ਤਰੀਕਾ" ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ, ਉਹ ਸੁਸਾਇਟੀ ਅਪਗਰੇਡ ਰਾਹਾਂ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਪర్యਾਵਰਣ ਵੱਧਰੇ ਤਰੀਕੇ ਨਾਲ ਸਹਮਤ ਹੁੰਦੇ ਹਨ।
DX ਸਿਰਫ਼ ਨਵਾਂ ਐਪ ਕਿਸ ਤਰ੍ਹਾਂ ਜਲਦੀ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇਹ ਵੀ ਹੈ ਕਿ ਮੌਜੂਦਾ ਐਪ ਨੂੰ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖਣਾ ਕਿੰਨਾ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਅਪਗਰੇਡ ਦੀ ਪ੍ਰਡਿਕਟਬਿਲਟੀ ਸੰਵੇਦਾ ਘਟਾਉਂਦੀ ਹੈ: ਟੀਮਾਂ ਘੱਟ ਸਮਾਂ ਉਦਾਹਰਣੀਆਂ ਬਦਲਾਅ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ 'ਚ ਗੁਜ਼ਾਰਦੀਆਂ ਹਨ ਤੇ ਵੱਧ ਸਮਾਂ ਸ਼ਿਪ ਕਰਨ 'ਚ।
ਇਸੇ ਕਾਰਨ Yehuda Katz ਦੇ ਸੋਚ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਫਰੇਮਵਰਕ ਅਪਗਰੇਡ ਐਰਗਨੋਮਿਕਸ 'ਤੇ ਵਾਸਤਵਿਕ ਉਤਪਾਦ-ਮਾਵਾਂ ਜੁਟਾਉਂਦੇ ਹਨ: ਸਪੱਸ਼ਟ ਵਰਜਨ ਨੀਤੀਆਂ, ਸਥਿਰ ਡੀਫਾਲਟ, ਅਤੇ ਟੂਲਿੰਗ ਜੋ ਬਦਲਾਅ ਨੂੰ ਘੱਟ ਡਰਾਉਣਾ ਬਣਾਉਂਦੀ ਹੈ।
ਸਰਵੋਤਮ ਅਪਗਰੇਡ ਕਹਾਣੀਆਂ ਦੋਹਰਾਏ ਜਾਣ-ਯੋਗ ਤਰੀਕਿਆਂ ਨਾਲ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਰੀਤਾਂ ਜੋ ਸਹੁਲਤ ਦਿੰਦੀਆਂ ਹਨ:
ਜਦ ਇਹ ਕੰਮ ਚੰਗੇ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਪਗਰੇਡ ਰੁਟੀਨ ਬਨ ਜਾਂਦੇ ਹਨ ਨਾ ਕਿ ਮਿਆਦੀ-ਸੰਕਟ।
ਟੀਮਾਂ ਉਹੀ ਚੁਣਦੀਆਂ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਐਸਾ ਲੱਗੇ ਕਿ ਉਹ ਅਪਡੇਟ ਰੱਖ ਸਕਦੀਆਂ ਹਨ। ਜੇ ਅਪਗਰੇਡ ਰੂਲੇਟ ਦੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਉਹ ਵਰਜਨਾਂ ਨੂੰ ਜਮ੍ਹਾਂ ਕਰਕੇ ਖਤਰਾ ਇਕੱਠਾ ਕਰਨਗੇ ਅਤੇ ਆਖ਼ਿਰਕਾਰ ਇਕ ਬਾਹਰਲੇ ਵਿਕਲਪ ਦੀ ਯੋਜਨਾ ਬਣਾ ਲੈਣਗੇ।
ਜੇ ਅਪਗਰੇਡ ਦਸਤਾਵੇਜ਼ਬੱਧ, ਆਟੋਮੇਟਿਕ ਅਤੇ ਕਦਮ-ਬ-ਕਦਮ ਲੱਗਦੇ ਹਨ, ਉਹ ਡੀਪ ਵੀ ਨਿਵੇਸ਼ ਕਰਨਗੇ—ਕਿਉਂਕਿ ਫਰੇਮਵਰਕ ਇੱਕ ਸਾਥੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਹਿਲਦਾ ਨਿਸ਼ਾਨਾ।
"ਇੰਟੀਗ੍ਰੇਟਡ" ਫਰੇਮਵਰਕ (Rails ਜਾਂ Ember ਦੇ ਸਭ ਤੋਂ ਅਧਿਕ ਰਾਇਤਪਸੰਦ ਰੂਪ) ਆਮ ਰਸਤੇ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। "ਮੋਡਿਊਲਰ ਸਟੈਕ" ਸਰਵੋਤਮ-ਟੂ-ਬ੍ਰੀਡ ਹਿੱਸਿਆਂ (router, state/data layer, build tool, test runner) ਨੂੰ ਜੁਟਾ ਕੇ ਕੁਝ ਵਿਸ਼ੇਸ਼ ਬਣਾਉਂਦਾ ਹੈ।
ਚੰਗੀ ਇੱਕੀਕਰਨ ਦਾ ਮਤਲਬ ਜ਼ਿਆਦਾ ਫੀਚਰ ਨਹੀਂ; ਘੱਟ ਸਿਲਾਂ ਹੋਣ ਹਨ।
ਜਦ ਇਹ ਹਿੱਸੇ ਇਕੱਠੇ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਟੀਮਾਂ ਘੱਟ ਪੈਟਰਨ ਚਰਚਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਵੱਧ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ।
ਮੋਡਿਊਲਰ ਸਟੈਕ ਅਕਸਰ ਛੋਟੇ ਰੂਪ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਅਤੇ ਲਚਕੀਲਾ ਮਹਿਸੂਸ ਹੁੰਦਾ। ਲਾਗਤ ਬਾਅਦ ਵਿੱਚ ਕਿੱਤੇ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: glue ਕੋਡ ਅਤੇ ਇੱਕ-ਛੋਟੀਆਂ ਫ਼ੈਸਲੀਆਂ: ਖਾਸ ਫੋਲਡਰ ਸਟ੍ਰੱਕਚਰ, ਕਸਟਮ middleware, ਘਰ-ਬਣਾਇਆ ਡਾਟਾ ਫੈਚਿੰਗ ਕੰਵੈਨਸ਼ਨ, ਅਤੇ ਐਡ-ਹਾਕ ਟੈਸਟ ਯੂਟਿਲਿਟੀ।
ਹਰ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਇਹੀ ਗੱਲਾਂ ਫਿਰ-ਫਿਰ ਦੁਹਰਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਓਨਬੋਰਡਿੰਗ ਪਿਛਲੇ ਕਮਿਟਾਂ 'ਚੋਂ ਸਕੈਵੈਂਜਰ ਹਂਟ ਬਣ ਜਾਂਦੀ ਹੈ।
ਮੋਡਿਊਲਰਿਟੀ ਵਧੀਆ ਹੈ ਜਦ ਤੁਹਾਨੂੰ ਹਲਕਾ ਫੁੱਟਪ੍ਰਿੰਟ, ਵਿਸ਼ੇਸ਼ ਲੋੜਾਂ, ਜਾਂ ਮੌਜੂਦਾ ਸਿਸਟਮ ਵਿੱਚ ਏਕੀਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ। ਇਹ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਵੀ ਕਾਰਗਰ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਅੰਦਰੂਨੀ ਮਿਆਰ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ।
ਗੌਰ ਕਰੋ: ਟੀਮ ਦਾ ਆਕਾਰ (ਵਧੇਰੇ ਲੋਕ = ਵੱਧ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਾਗਤ), ਐਪ ਦੀ ਉਮਰ (ਸਾਲ = ਇੱਕਤਾ ਫ਼ਾਇਦੇ), ਕੁਸ਼ਲਤਾ (ਕੀ ਤੁਸੀਂ ਆਪਣੇ ਕਨਵੈਨਸ਼ਨ ਰੱਖ ਸਕਦੇ ਹੋ?), ਅਤੇ ਤੁਸੀਂ ਕਿੰਨੇ ਪ੍ਰੋਜੈਕਟ ਉਸੇ ਢੰਗ ਨਾਲ ਬਣਾਉਣ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ।
ਫਰੇਮਵਰਕ ਅਪਣਾਉਣ ਇਸ ਗੱਲ 'ਤੇ ਘੱਟ ਹੈ ਕਿ ਕੀ "ਸਭ ਤੋਂ ਵਧੀਆ" ਹੈ ਅਤੇ ਜ਼ਿਆਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਭਰੋਸੇ ਨਾਲ ਉਸ 'ਤੇ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕੇਗੀ। Yehuda Katz ਦਾ ਕੰਮ (Rails ਦੀਆਂ ਰਿਵਾਇਤਾਂ ਤੋਂ Ember ਦੀ ਟੂਲਿੰਗ ਤੱਕ) ਇੱਕੋ ਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਜ਼ੋਰ ਦਿੰਦਾ: ਜਦ ਤੁਸੀਂ ਅਸਲ ਉਤਪਾਦ ਬਣਾ ਰਹੇ ਹੋ, ਇਕਸਾਰਤਾ ਨਵੀਆਪਣ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਦਿੰਦੀ ਹੈ।
ਇਕਸਪਲੇਨਰ ਜਾਂ ਇਕਠੇ ਕਰਦੇ ਸਮੇਂ ਇਸ ਛੋਟੀ-ਜਿਹੀ ਸਵਾਲ-ਕਤਾਰ ਵਰਤੋ:
ਮਿਸ਼ਰਤ ਤਜਰਬੇ ਵਾਲੀਆਂ ਟੀਮਾਂ, ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਉਤਪਾਦ, ਅਤੇ ਉਹ ਸੰਸਥਾਵਾਂ ਜੋ ਪੇਸ਼ਗੋਈਯੋਗ ਓਨਬੋਰਡਿੰਗ ਨੂੰ ਮਹੱਤਵ ਦਿੰਦੀਆਂ ਹਨ ਆਮ ਤੌਰ 'ਤੇ ਰਿਵਾਇਤ-ਭਾਰਿਤ ਫਰੇਮਵਰਕ ਨਾਲ ਜ਼ਿਆਦਾ ਫਾਇਦਾ ਵੇਖਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਘੱਟ ਫੈਸਲਿਆਂ ਲਈ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਵਧੀਆ ਸਾਂਝੀ ਭਾਸ਼ਾ, ਅਤੇ ਇੱਕ ਮਿੱਠੀ ਅਪਗਰੇਡ ਕਹਾਣੀ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਛੋਟੀ ਐਪ ਬਣ ਰਹੇ ਹੋ, ਜਾਂ ਤੁਹਾਡੇ ਕੋਲ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਹਨ ਜੋ ਕਸਟਮ ਟੂਲਿੰਗ ਬਣਾਉਣਾ ਪਸੰਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਮੋਡਿਊਲਰ ਸਟੈਕ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਲੰਬੀ ਮਿਆਦ ਦੀ ਲਾਗਤ ਨੂੰ ਸੱਚ-ਪੱਕਾ ਮੰਨੋ: ਤੁਸੀਂ ਇੰਟਿਗਰੇਟਰ ਅਤੇ ਮੇਨਟੇਨਰ ਬਣ ਜਾਂਦੇ ਹੋ।
ਰਿਵਾਇਤਾਂ, DX, ਅਤੇ ਟੂਲਿੰਗ "ਫ਼ਿਰ-ਜਿਨ੍ਹਾਂ" ਚੀਜ਼ਾਂ ਨਹੀਂ ਹਨ। ਉਹ ਅਪਣਾਉਣ ਨੂੰ ਗੁਣਾ-ਵਧਾ ਦੇਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਸੈਟਅੱਪ, ਰੋਜ਼ਾਨਾ ਕੰਮ, ਅਤੇ ਅਪਗਰੇਡ ਵੇਲੇ।
ਉਸ ਵਿਕਲਪ ਨੂੰ ਚੁਣੋ ਜਿਸੇ ਟੀਮ ਦੁਬਾਰਾ ਦੁਹਰਾ ਸਕੇ, ਨਾ ਕਿ ਉਹ ਜੋ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਮਾਹਰਾਂ ਹੀ ਬਚਾ ਸਕਦੇ ਹਨ। ਅਤੇ ਜੇ ਤੁਹਾਡੀ ਬੋਟਲਨੇਕ "ਕਿਹੜਾ ਫਰੇਮਵਰਕ" ਤੋਂ ਘੱਟ "ਅਸੀਂ ਲਗਾਤਾਰ ਫੁੱਲ-ਸਟੈਕ ਸੌਫ਼ਟਵੇਅਰ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੀਏ" ਹੈ, ਤਾਂ ਇੱਕ ਗਾਈਡ ਕੀਤੀ, ਰਿਵਾਇਤ-ਭਾਰੀ ਵਰਕਫਲੋ—ਚਾਹੇ ਇੱਕ ਫਰੇਮਵਰਕ CLI ਰਾਹੀਂ ਜਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ—ਲਗਾਤਾਰ ਡਿਲਿਵਰੀ ਅਤੇ ਸਦੀਵੀ ਸਕੈਫੋਲਡਿੰਗ ਵਿਚਕਾਰ ਫਰਕ ਬਣ ਸਕਦੀ ਹੈ।
ਫਰੇਮਵਰਕ ਦੀ ਚੋਣ ਅਕਸਰ ਦਿਨ-ਬਰ-ਦਿਨ ਦੀ ਰਗੜ ਨਾਲ ਨਿਧਾਰਿਤ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸਿਰਲੇਖੀਆਂ ਫੀਚਰਾਂ ਨਾਲ। ਟੀਮਾਂ ਇਹ ਦੇਖਦੀਆਂ ਹਨ ਕਿ ਸੈਟਅੱਪ ਸਧਾਰਨ ਹੈ ਕਿ ਨਹੀਂ, ਡੀਫ਼ੌਲਟ ਕਿਸੇ ਲੋਜਿਕ ਵਿੱਚ ਹਨ ਕਿ ਨਹੀਂ, ਡੌਕੂਮੈਂਟੇਸ਼ਨ ਆਮ ਵਰਕਫ਼ਲੋਜ਼ ਦੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ ਨਹੀਂ, ਏਰਰ ਸੁਝਾਵਣਯੋਗ ਹਨ ਕਿ ਨਹੀਂ, ਅਤੇ ਅਪਗਰੇਡ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿ ਨਹੀਂ।
ਜੇ ਇਹ ਪਲ ਭਰੋਸੇਯੋਗ ਹਨ, ਤਾਂ ਫਰੇਮਵਰਕ ਇੱਕ ਅੰਗਠੇ ਵਾਂਗ ਸੰਸਥਾ ਵਿੱਚ ‘ਠਹਿਰ’ ਜਾਂਦਾ ਹੈ।
Conventions ਆਮ ਤੌਰ 'ਤੇ ਦੁਹਰਾਉਣਯੋਗ ਸਵਾਲਾਂ ਲਈ ਡਿਫ਼ੌਲਟ ਜਵਾਬ ਹਨ—ਫਾਇਲ ਕਿੱਥੇ ਰੱਖਣੀ, ਨਾਮ ਕੀ ਰੱਖਣਾ, ਅਤੇ ਆਮ ਫੀਚਰਾਂ ਨੂੰ ਬਣਾਉਣ ਦੀ “ਸਧਾਰਨ ਰੀਤ”।
ਵੈਕੀਤੀ ਨਤੀਜੇ:
ਟ੍ਰੇਡ-ਆਫ ਇਹ ਹੈ ਕਿ ਆਪਣੀ ਮਰਜ਼ੀ ਨਾਲ ਅਲੱਗ ਆਰਕੀਟੈਕਚਰ ਲੈਣ 'ਤੇ ਵਧੇਰੇ ਰੋੜ ਆ ਸਕਦਾ ਹੈ।
‘‘Batteries-included’’ ਦਾ ਅਰਥ ਹੈ ਕਿ ਫਰੇਮਵਰਕ ਆਮ ਐਪ ਕੰਮਾਂ ਲਈ ਇੱਕ ਪੂਰਾ ਰਸਤਾ ਦਿੰਦਾ ਹੈ: routing, structure, generators, ਟੈਸਟਿੰਗ ਪੈਟਰਨ ਅਤੇ ਇੱਕ ਮਾਰਗ-ਦਰਸ਼ਕ ਵਰਕਫਲੋ।
ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦੇ ਹੀ ਪਹਿਲੀ ਫੀਚਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਕਸਟਮ ਸਟੈਕ ਜਾਂ ਬਹੁਤ ਸਾਰਾ ਗਲੂ ਕੋਡ ਲਿਖੇ।
ਜਦੋਂ ਫਰੰਟਐਂਡ ਐਪ ਵੱਡੇ ਹੋਣ लगे, ਤਦ ਇਮਪ੍ਰੋਵਾਈਜ਼ਡ routing, ਅਸਮੰਜਸ ਡਾਟਾ-ਫੈਚਿੰਗ ਅਤੇ ਪ੍ਰੋਜੈਕਟ-ਵਿਸ਼ੇਸ਼ ਰੀਤਾਂ ਸਮੱਸਿਆ ਬਣ ਗਈਆਂ।
Ember ਨੇ ਇਹ ਮੁੱਦਾ ਹੱਲ ਕਰਨ ਲਈ ਪਹਿਲ ਕੀਤੀ:
ਇਸ ਨਾਲ ਰੱਖ-ਰਖਾਵ ਅਤੇ ਨਵੇਂ ਲੋਕਾਂ ਨੂੰ ਢਾਲਣਾ ਆਸਾਨ ਹੋਇਆ।
ਸਥਿਰਤਾ ਇੱਕ ਉਤਪਾਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਲਾਗਤ ਦੂਜੇ ਜਾਂ ਤੀਜੇ ਸਾਲ ਵਿੱਚ ਉਭਰ ਕੇ ਆਉਂਦੀ ਹੈ।
ਭਰੋਸਾ ਬਣਾਉਣ ਵਾਲੇ ਸੰਕੇਤਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ:
ਇਹ ਟੀਮਾਂ ਨੂੰ ਪੁਰਾਣੀ ਵਰਜਨ 'ਤੇ ਫਸਣ ਦੇ ਡਰ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
CLI ਅਕਸਰ “ਫਰਾਂਟ ਡੋਰ” ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਾਅਦੇ ਨੂੰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਅਨੁਭਵ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ:
ਚੰਗੀ CLI ਸੈਟਅੱਪ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਇੱਕ ਰੇਖ 'ਤੇ ਰੱਖਦੀ ਹੈ।
ਅਮਲੀ DX ਉਹ ਛੋਟੇ-ਛੋਟੇ ਲਹਿਜ਼ੇ ਹਨ ਜੋ ਤੁਸੀਂ ਲਗਾਤਾਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ:
ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਫਰੇਮਵਰਕ ਚੁਣਦੇ ਹਨ ਜੋ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨੂੰ ਸ਼ਾਂਤ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਚੌਣ ਦਾ ਬੋਝ ਉਸ ਸਮੇਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹਰ ਚੀਜ਼ ਆਪਣੇ ਆਪ ਨੂੰ ਪਸੰਦ ਦੀ ਜਗ੍ਹਾ ਤੋਂ ਚੁਣਨੀ ਪੈਂਦੀ ਹੈ: router, build system, testing, ਡਾਟਾ ਪੈਟਰਨ ਆਦਿ।
ਇਸ ਨਾਲ ਜੋਖਮ ਵਧਦਾ ਹੈ ਕਿਉਂਕਿ ਕਈ-ਕਈ ਕੰਪੋਨੈਂਟ ਇਕ-ਦੂਜੇ ਨਾਲ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੇ। ਇੱਕ ਮਿਆਰੀ ਸਟੈਕ ਅਸਲ ਵਿੱਚ ਪੂਰਨ ਹੋਣ ਤੋਂ ਵੱਧ ਭਵਿੱਖਬਾਣੀਯੋਗ ਹੋਣ ਦਾ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ: ਨਵੀਆਂ ਪ੍ਰੋਜੈਕਟਾਂ ਅਤੇ ਨਵਿਆਂ ਕਰਮਚਾਰੀਆਂ ਲਈ ਤੇਜ਼ ਸੈਟਅੱਪ, ਸਹਿ-ਸੰਪਾਦਨ ਵਿੱਚ ਘੱਟ ਘਟਨਾ, ਅਤੇ ਸਹਾਇਤਾ ਅਸਾਨ।
ਆਧੁਨਿਕ ਐਪਾਂ ਇੱਕ-ਦੋ ਫਾਇਲਾਂ ਦੀ ਬਜਾਏ ਸੈਂਕੜੇ ਫਾਇਲਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਬਿਲਡ ਟੂਲ ਉਹ ਮਸ਼ੀਨਰੀ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਬਰਾਊਜ਼ਰ ਲਈ ਤਿਆਰ ਕਰਦੀ ਹੈ।
ਬਿਲਡ ਕਦਮ ਕੇਂਦਰੀ ਹੋਣ ਕਾਰਨ ਫਰੇਮਵਰਕਾਂ ਤੋਂ ਹੁਣ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
ਇਸ ਕਾਰਨ, “ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡਿਡ” ਹੁਣ ਅਕਸਰ ਵੀ ਬਿਲਡ ਡੀਫਾਲਟ ਅਤੇ ਅਪਗਰੇਡ ਸਹੂਲਤਾਂ ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ।
ਅਪਗਰੇਡ ਸਿਰਫ਼ ਰਖ-ਰਖਾਵ ਨਹੀਂ ਹੁੰਦੇ—ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜਦ ਫਰੇਮਵਰਕ ਜਾਂ ਤਾਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਭਰੋਸਾ ਜਿਤਦਾ ਹੈ ਜਾਂ ਅਗਲੇ ਰੀਰਾਇਟ ਤੱਕ ਚੁਪਚਾਪ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਦਰਦਨਾਕ ਪਲ:
ਅਚ্ছে ਫਰੇਮਵਰਕ ਅਪਗਰੇਡ ਨੂੰ ਨਿਆਮਤ, ਦਸਤਾਵੇਜ਼ਬੱਧ ਅਤੇ ਬਹੁਤ ਹਦ ਤੱਕ ਆਟੋਮੇਟਿਡ ਬਣਾਉਂਦੇ ਹਨ: ਡਿਪ੍ਰੇਕੇਸ਼ਨ ਚੇਤਾਵਨੀਆਂ, codemods, ਅਤੇ ਸਟੀਅਰਡ ਗਾਈਡ।
ਚੰਗੀ ਇੱਕਤਾ ਦਾ ਮਤਲਬ ਜ਼ਿਆਦਾ ਫੀਚਰ ਨਹੀਂ—ਘੱਟ ਸਿਲਾਵਾਂ ਹਨ।
ਉਦਾਹਰਨ:
ਇਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਦੇ ਇਕੱਠੇ ਡਿਜ਼ਾਇਨ ਹੋਣ ਨਾਲ ਟੀਮਾਂ ਘੱਟ ਰੀਚਰ ਅਤੇ ਜ਼ਿਆਦਾ ਡਿਲੀਵਰੀ ਕਰਦੀਆਂ ਹਨ।