Martin Fowler ਦੇ ਪ੍ਰਯੋਗਿਕ ਦਰਿਸ਼ਟਿਕੋਣ ਨਾਲ ਆਰਕੀਟੈਕਚਰ: ਪੈਟਰਨ, ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਇਵੋਲੂਸ਼ਨਰੀ ਬਦਲਾਅ ਜੋ ਟ੍ਰੈਂਡੀ ਸਟੈਕਸ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਟਿਕਦੇ ਹਨ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਖ਼ਤਰੇ ਘਟਾਉਂਦੇ ਹਨ।
ਨਵਾਂ ਫਰੇਮਵਰਕ, ਚਮਕੀਲਾ ਕਲਾਉਡ ਸੇਵਾ, ਜਾਂ ਕਿਸੇ ਗਰਮ ਕੰਪਨੀ ਦਾ “ਸਟੈਂਡਰਡ ਸਟੈਕ” ਇੱਕ ਛੇਤੀ ਢੰਗ ਵਰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਪਰ ਸਟੈਕ-ਪਹਿਲਾਂ ਸੋਚ ਅਕਸਰ ਟੂਲ ਨੂੰ ਸੰਰਚਨਾ ਨਾਲ ਗਲਤ ਮਿਲਾ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਸਭ ਤੋਂ ਆਧੁਨਿਕ ਤਕਨੀਕਾਂ ਨਾਲ ਇੱਕ ਗੁੰਝਲਦਾਰ, ਬਦਲਣ ਵਿੱਚ ਔਖਾ ਸਿਸਟਮ ਬਣਾ ਸਕਦੇ ਹੋ—ਜਾਂ ਬੋਰੀਂਗ ਪਰ ਚੰਗੇ ਚੋਣਾਂ ਨਾਲ ਇੱਕ ਸਾਫ਼, ਅਨੁਕੂਲ ਸਿਸਟਮ।
ਸਤੈਕ ਪਹਿਲਾਂ ਚੁਣਨ ਨਾਲ ਟੀਮਾਂ ਉਹ ਫੈਸਲੇ ਲੈਂਦੀਆਂ ਹਨ ਜੋ ਸਲਾਈਡ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦੇ ਹਨ ਪਰ ਅਸਲ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀਆਂ:
ਜਦੋਂ ਟੈਕ ਚੋਣ ਆਗੂ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਅਕਸਮਾਤ ਪਰਿਣਾਮ ਬਣ ਜਾਂਦੀ ਹੈ—ਜਿਸ ਨਾਲ ਤੰਗ ਕੁਪਲਿੰਗ, ਦੁਹਰਾਈ ਹੋਈ ਲੌਜਿਕ ਅਤੇ ਉਹ ਨਿਰਭਰਤਾਵਾਂ ਬਣਦੀਆਂ ਹਨ ਜੋ ਸਧਾਰਨ ਤਬਦੀਲੀਆਂ ਨੂੰ ਮਹਿੰਗਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
ਇਸੇ ਲਈ “ਅਸੀਂ ਮਾਇਕਰੋਸਰਵਿਸਿਜ਼ ਵਰਤ ਰਹੇ ਹਾਂ” (ਜਾਂ “ਅਸੀਂ ਹੁਣ ਸਰਵਰਲੈੱਸ ਹਾਂ”) ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੈ। ਇਹ ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਟੂਲਿੰਗ ਦੀ ਦਿਸ਼ਾ ਹੈ। ਆਰਕੀਟੈਕਚਰ ਇਹ ਹੈ ਕਿ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਕਿਵੇਂ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਫੈਸਲਿਆਂ ਨੇ ਭਵਿੱਖ ਦੇ ਕੰਮ ਨੂੰ ਕਿਵੇਂ ਸੀਮਿਤ ਕੀਤਾ, ਅਤੇ ਉਤਪਾਦ ਕਿੰਨੀ ਆਸਾਨੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਾ: ਟੂਲ ਡਿਲਿਵਰੀ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਆਰਕੀਟੈਕਚਰਲ ਸੋਚ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ। ਤੇਜ਼ੀ ਨਾਲ ਜੈਨਰੇਟ ਅਤੇ ਇਟਰੇਟ ਕਰਨ ਵਾਲੀਆਂ ਤਕਨੀਕਾਂ ਦੇ ਨਾਲ ਵੀ — ਉਹੀ ਸਵਾਲ ਹਨ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਨਾਉਣ ਵਿੱਚ ਬਹੁਤ ਤੇਜ਼ੀ ਲਿਆ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਉਹ ਟੀਮਾਂ ਲੈਂਦੀਆਂ ਹਨ ਜਿਹੜੀਆਂ ਬਾਊਂਡਰੀ, ਮਲਕੀਅਤ ਅਤੇ ਬਦਲਣਯੋਗਤਾ ਨੂੰ ਪਹਿਲ-ਕੱਤਰ ਮੰਨਦੀਆਂ ਹਨ (ਨ ਕਿ ਫਰੇਮਵਰਕ ਦੇ ਜਾਦੂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀਆਂ)।
Martin Fowler ਦੀ ਲਿਖਤ ਲਗਾਤਾਰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਵੱਲ ਧਿਆਨ ਖਿੱਚਦੀ ਹੈ ਜੋ ਗੱਲ ਕਰਦੀਆਂ ਹਨ: ਫੈਸ਼ਨੇਬਲ ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਬੇਹਤਰ ਸਪਸ਼ਟ ਡਿਜ਼ਾਈਨ, ਆਈਡੀਓਲੋਜੀ ਤੋਂ ਉੱਪਰ ਪ੍ਰਯੋਗਿਕ ਟ੍ਰੇਡ-ਅਫ਼, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਸਿੱਖਣ ਦੇ ਨਾਲ ਵਿਕਸਿਤ ਕਰਨ ਦੀ ਯੋਗਤਾ। ਉਹ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਇੱਕ ਐਸੀ ਚੀਜ਼ ਮੰਨਦੇ ਹਨ ਜਿਸਨੂੰ ਲਗਾਤਾਰ ਸੁਧਾਰਿਆ ਜਾਂਦਾ ਹੈ—ਨ ਕਿ ਇੱਕ ਵਾਰੀ ਦਾ ਵੱਡਾ ਡਿਜ਼ਾਈਨ।
ਤਿੰਨ ਮੁੜ-ਮੁੜ ਆਉਣ ਵਾਲੇ ਥੀਮਾਂ ਦੀ ਉਮੀਦ ਕਰੋ: ਪੈਟਰਨਾਂ ਨੂੰ ਵਿਕਲਪਕ ਟੂਲ ਵਜੋਂ ਵਰਤਣਾ (ਕਾਇਦੀ ਨਹੀਂ), ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਰੋਜ਼ਾਨਾ ਅਭਿਆਸ ਬਣਾਉਣਾ, ਅਤੇ ਇਵੋਲੂਸ਼ਨਰੀ ਆਰਕੀਟੈਕਚਰ—ਬਦਲਾਅ ਲਈ ਬਣਾਉਣਾ, ਨ ਕਿ ਯਕੀਨ ਲਈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਲੀਡ, ਟੈਕ ਲੀਡ, ਜਾਂ ਪ੍ਰੋਡਕਟ ਟੀਮ ਹੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ ਬਿਨਾਂ ਗੁਣਵੱਤਾ ਢਹਿ ਜਾਣ ਦੇ, ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਲਈ ਹੈ। ਮਕਸਦ “ਪੁਰਫੇਕਟ” ਸਟੈਕ ਚੁਣਨਾ ਨਹੀਂ ਹੈ—ਮਗਰ ਇਹ ਫੈਸਲੇ ਕਰਨਾ ਹੈ ਜੋ ਰੋਡਮੈਪ ਬਦਲਣ 'ਤੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਬਦਲਣਯੋਗ ਰੱਖਣ।
ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਉਹ ਫੈਸਲਿਆਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਸਿਸਟਮ ਨੂੰ ਅਜਿਹਾ ਆਕਾਰ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਔਖਾ ਅਤੇ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।
ਇਹ ਪਰਿਭਾਸ਼ਾ ਸਧਾਰਨ ਹੈ—ਇਹ ਕਿਸੇ ਖ਼ਾਸ ਡਾਇਗ੍ਰਾਮ ਜਾਂ “ਆਰਕੀਟੈਕਟ” ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ। ਇਹ ਉਹ ਚੋਣਾਂ ਹਨ ਜੋ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਸਾਫਟਵੇਅਰ ਕਿਵੇਂ ਵੱਧੇਗਾ, ਟੀਮਾਂ ਕਿਵੇਂ ਉਨ੍ਹਾਂ ਤੇ ਕੰਮ ਕਰ ਸਕਣਗੀਆਂ, ਅਤੇ ਚਲਾਉਣ ਦੀ ਕੀ ਲਾਗਤ ਹੋਵੇਗੀ।
ਫਰੇਮਵਰਕ, ਟੂਲ ਅਤੇ ਕੋਡਿੰਗ ਸਟਾਈਲ ਮਹੱਤਵਪੂਰਣ ਹਨ—ਪਰ ਜ਼ਿਆਦਾਤਰ ਟੂਲ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਸਰਲ ਤੌਰ 'ਤੇ ਬਦਲੇ ਜਾ ਸਕਦੇ ਹਨ।
ਆਰਕੀਟੈਕਚਰ ਜ਼ਿਆਦਾ ਕਰਕੇ কাঠਨਾ ਅਤੇ ਬਾਊਂਡਰੀਆਂ ਦੇ ਨੇੜੇ ਹੈ: ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਦੇ ਹਨ, ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਫੇਲ੍ਹਰ ਕਿਵੇਂ ਸਾਂਭੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਤਬਦੀਲੀਆਂ ਟੀਮਾਂ ਦੇ ਸਮਨਵਯ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ یونیਵਰਸਲ “ਚੰਗੀ” ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੁੰਦੀ। ਹਰ ਇੱਕ ਮੁੱਖ ਫੈਸਲਾ ਕੁਝ ਲਾਭ ਦੇਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਗੁਣਾਂ 'ਤੇ ਧੱਕਾ ਮਾਰਦਾ ਹੈ:
ਚੰਗੀ ਆਰਕੀਟੈਕਚਰ ਇਹ ਟ੍ਰੇਡ-ਅਫ਼ ਸਪਸ਼ਟ ਕਰਦੀ ਹੈ ਨਾ ਕਿ ਅਕਸਮਾਤ ਬਣਾਉਂਦੀ ਹੈ।
ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲਾ: “ਅਸੀਂ ਗਾਹਕ ਬਿਲਿੰਗ ਨੂੰ ਆਪਣੀ ਡਿਪਲੋਏਬਲ ਸੇਵਾ ਅਤੇ ਆਪਣੀ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਵੰਡਾਂਗੇ, ਅਤੇ ਬਾਕੀ ਸਿਸਟਮ ਅਸਿੰਕ ਇਵੈਂਟਾਂ ਰਾਹੀਂ ਇੰਟੀਗ੍ਰੇਟ ਕਰੇਗਾ।”
ਇਸ ਨਾਲ ਡਿਪਲੋਇਮੈਂਟ, ਡੇਟਾ ਮਲਕੀਅਤ, ਫੇਲ੍ਹਰ ਮੋਡ, ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਟੀਮ ਕੋਆਰਡੀਨੇਸ਼ਨ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੇ ਹਨ।
ਲਾਇਬ੍ਰੇਰੀ ਚੋਣ: “ਅਸੀੰ Library X ਨੂੰ PDF ਬਣਾਉਣ ਲਈ ਵਰਤਾਂਗੇ।”
ਲਾਭਕਾਰੀ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸੀਮਾ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਦਲਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਜੇ ਕਿਸੇ ਫੈਸਲੇ ਨੂੰ ਵਾਪਸ ਲੈਣ ਲਈ ਸਹਿਯੋਗੀ ਕੰਮ ਹਫਤੇ ਲਵੈਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸੰਭਵਤ: ਆਰਕੀਟੈਕਚਰ ਹੈ।
ਡਿਜ਼ਾਈਨ ਪੈਟਰਨਾਂ ਨੂੰ ਵਧ-ਵਧ ਕੇ ਮੁੜ ਆਉਂਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਹੱਲ ਵਜੋਂ ਸਮਝੋ—ਨ ਕਿ ਹੁਕਮ। Fowler ਦੀ ਰੁਖ ਪ੍ਰਾਗਟਿਕਲ ਹੈ: ਜਦੋਂ ਪੈਟਰਨ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦੇ ਹਨ ਤਾਂ ਉਪਯੋਗੀ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ ਸੋਚ ਦੀ ਥਾਂ ਲੈ ਲੈਂਦੇ ਹਨ ਤਾਂ ਨੁਕਸਾਨਦੇਹ।
ਚੰਗੇ ਢੰਗ ਨਾਲ ਵਰਤੇ ਜਾਣ 'ਤੇ, ਪੈਟਰਨ ਟੀਮਾਂ ਨੂੰ ਸਾਂਝੀ ਜ਼ਬਾਨ ਦਿੰਦੇ ਹਨ। “strategy” ਜਾਂ “repository” ਕਹਿਣ ਨਾਲ ਵੱਡੀ ਚੀਜ਼ ਇਕ ਸ਼ਬਦ ਵਿੱਚ ਸੰਕੁਚਿਤ ਹੋ ਸਕਦੀ ਹੈ, ਜੋ ਰਿਵਿਊਜ਼ ਤੇਜ਼ ਕਰਦਾ ਅਤੇ ਗਲਤਫਹਿਮੀਆਂ ਘਟਾਉਂਦਾ ਹੈ।
ਪੈਟਰਨ ਸਿਸਟਮ ਵਿਹਾਰ ਨੂੰ ਭਵਿੱਖਵਾਣੀਯੋਗ ਬਣਾਉਂਦੇ ਹਨ—ਉਮੀਦੀਆਂ ਸੈਟ ਕਰਦੇ ਹਨ ਕਿ ਲੌਜਿਕ ਕਿੱਥੇ ਰਹੇਗੀ, ਆਬਜੈਕਟ ਕਿਵੇਂ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨਗੇ, ਅਤੇ ਕਿਹੜੇ ਤਬਦੀਲੇ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਹੋਣਗੇ। ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਘੱਟ ਹੈਰਾਨੀਆਂ ਅਤੇ ਨਵੇਂ ਮੈਂਬਰਾਂ ਲਈ ਘੱਟ “ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?” ਪਲ ਲਿਆਉਂਦਾ ਹੈ।
ਫੇਲ੍ਹਰ ਮੋਡ cargo-culting ਹੈ: ਕਿਸੇ ਪੈਟਰਨ ਨੂੰ ਇਸ ਲਈ ਲਗਾਉਣਾ ਕਿ ਉਹ ਮਸ਼ਹੂਰ ਹੈ ਜਾਂ ਕਿਉਂਕਿ “ਇਹ ਇੱਥੇ ਅਸੀਂ ਐਸਾ ਕਰਦੇ ਹਾਂ।” ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਓਵਰ-ਇੰਜੀਨੀਅਰਿੰਗ ਲਿਆਉਂਦਾ—ਵਾਧੂ ਲੇਅਰ, ਇੰਦਰਾਜ਼ ਅਤੇ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਜਿਹੜੀਆਂ ਲਾਭ ਨਹੀਂ ਦਿੰਦੀਆਂ।
ਹੋਰ ਫਸਲਾਵਾਂ ਹਨ “ਹਰ ਚੀਜ਼ ਲਈ ਇੱਕ ਪੈਟਰਨ।” ਜਦੋਂ ਹਰੇਕ ਛੋਟੀ ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਨਾਂ ਮਿਲ ਜਾਂਦਾ ਹੈ, ਕੋਡਬੇਸ ਇੱਕ ਚਤੁਰਾਈ ਦੀ ਮਿਊਜ਼ੀਅਮ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ ਬਜਾਏ ਇੱਕ ਐਸ਼ਿਆ ਲਈ ਜੋ ਪੈਦਾ ਕਰਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਲਈ ਅਸਾਨ ਹੋਵੇ।
ਸਮੱਸਿਆ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਨ ਕਿ ਪੈਟਰਨ ਤੋਂ।
ਸਵਾਲ ਪੁੱਛੋ:
ਫਿਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਸਧਾਰਨ ਪੈਟਰਨ ਚੁਣੋ ਜੋ ਅੱਜ ਫਿੱਟ ਬੈਠਦਾ ਹੋਵੇ ਅਤੇ ਵਿਕਲਪ ਖੁੱਲ੍ਹੇ ਰੱਖੇ। ਜੇ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਢਾਂਚਾ ਦੀ ਲੋੜ ਆਏ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ—ਅਕਸਰ ਅਸਲ ਦਰਦ ਦੀ ਰਹਿਤ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਦੇ ਨਾਲ, ਨਾ ਕਿ ਪੂਰਵ ਅਨੁਮਾਨ ਤੋਂ।
ਰੀਫੈਕਟਰਿੰਗ ਅੰਦਰੂਨੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸੁਧਾਰਨ ਦਾ ਅਭਿਆਸ ਹੈ ਬਿਨਾਂ ਵਿਹਾਰ ਨੂੰ ਬਦਲੇ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੀਫੈਕਟਰਿੰਗ ਤੋਂ ਬਾਅਦ ਕੁਝ ਵੱਖਰਾ ਮਹਿਸੂਸ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ—ਸਿਵਾਏ ਇਸ ਦੇ ਕਿ ਭਵਿੱਖ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਆਸਾਨ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
Fowler ਦਾ ਨੁਕਤਾ ਇਹ ਨਹੀਂ ਕਿ “ਕੋਡ ਸੁੰਦਰ ਰੱਖੋ।” ਇਹ ਹੈ ਕਿ ਆਰਕੀਟੈਕਚਰ ਕੋਈ ਇੱਕ ਵਾਰੀ ਦਾ ਡਾਇਗ੍ਰਾਮ ਨਹੀਂ; ਇਹ ਉਹ ਫੈਸਲੇ ਹਨ ਜੋ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ ਕਿ ਸਿਸਟਮ ਕਿੰਨੀ ਆਸਾਨੀ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ। ਰੀਫੈਕਟਰਿੰਗ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਉਹ ਫੈਸਲੇ ਮਜ਼ਬੂਤ ਰੱਖਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹ ਜ਼ਆਹਿਰ ਨ ਹੀ ਹੋਣ।
ਸਮੇਂ ਦੇ ਨਾਲ, ਭਲੜੀ ਰਚਨਾ ਵੀ ਡ੍ਰਿਫਟ ਕਰਦੀ ਹੈ। ਨਵੇਂ ਫੀਚਰ ਤੁਰੰਤ ਦਬਾਅ 'ਤੇ ਜੋੜੇ ਜਾਂਦੇ ਹਨ, ਜਲਦੀ ਦੇ ਫਿਕਸ ਸਥਾਈ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਬਾਊਂਡਰੀ ਧੁੰਦਲੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਰੀਫੈਕਟਰਿੰਗ ਨਾਲ ਤੁਸੀਂ ਸਪਸ਼ਟ ਵੰਡ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋ ਅਤੇ ਅਕਸਮਾਤੀ ਜਟਿਲਤਾਂ ਘਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਜੋ ਸਿਸਟਮ "ਬਦਲਣਯੋਗ" ਰਹੇ।
ਇੱਕ ਸਿਹਤਮੰਦ ਆਰਕੀਟੈਕਚਰ ਉਹ ਹੈ:
ਰੀਫੈਕਟਰਿੰਗ ਦਿਨ-ਪ੍ਰਤੀ-दਿਨ ਕੰਮ ਹੈ ਜੋ ਇਹ ਗੁਣ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਰੀਫੈਕਟਰਿੰਗ ਸਮਾਂ-ਸੂਚੀ 'ਤੇ ਨਹੀਂ ਰੱਖਦੇ। ਤੁਸੀਂ ਇਸਨੂੰ ਉਹ ਸਮਾਂ ਕਰੋਗੇ ਜਦੋਂ ਕੋਡ ਵਿਰੋਧ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇ:
ਜਦੋਂ ਇਹ ਨਿਸ਼ਾਨ ਮਿਲਦੇ ਹਨ, ਤਾਂ ਆਰਕੀਟੈਕਚਰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਭਾਵਿਤ ਹੋ ਚੁੱਕੀ ਹੈ—ਰੀਫੈਕਟਰਿੰਗ ਮੁਰੰਮਤ ਹੈ।
ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰਿੰਗ ਕੁਝ ਆਦਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਰੀਫੈਕਟਰਿੰਗ ਰੋਜ਼ਾਨਾ ਮੇਂਟੇਨੈਂਸ ਬਣ ਜਾਂਦੀ ਹੈ—ਸਿਸਟਮ ਨੂੰ ਅਗਲੇ ਬਦਲਾਅ ਲਈ ਤਿਆਰ ਰੱਖਣਾ, ਬਜਾਏ ਪਿਛਲੇ ਇੱਕ ਲਈ ਨਾਜ਼ੁਕ ਹੋਣ ਦੇ।
ਟੈਕਨੀਕਲ ਡੈਬਟ ਆਉਂਦੇ ਸਮੇ: “ਅੱਜ ਦੇ shortcut ਦੀਆਂ ਭਵਿੱਖ ਦੀਆਂ ਲਾਗਤਾਂ।” ਇਹ ਨੈਤਿਕ ਵਿਫਲਤਾ ਨਹੀਂ; ਇਹ ਇੱਕ ਵਪਾਰਕ ਟ੍ਰੇਡ-ਅਫ਼ ਹੈ ਜੋ ਅਕਸਰ ਭਵਿੱਖ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਕੀਮਤ ਵਧਾਉਂਦੀ ਹੈ। Martin Fowler ਦੀ ਫਰੇਮਿੰਗ ਉਪਯੋਗੀ ਹੈ: ਡੈਬਟ ਤਦ ਹੀ ਸਮੱਸਿਆ ਬਣਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਟ੍ਰੈਕ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹੋ ਕਿ ਇਹ ਮੌਜੂਦ ਹੀ ਨਹੀਂ।
ਇਰਾਦਤ ਵਾਲਾ ਡੈਬਟ ਉਹ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋ ਕੇ ਲੈਣਾ ਪੈਂਦਾ: “ਅਸੀਂ ਹੁਣ ਸਧਾਰਨ ਵਰਜ਼ਨ ਰਿਲੀਜ਼ ਕਰਾਂਗੇ, ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰਾਂਗੇ।” ਇਹ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਭਵਿੱਖ ਵਿੱਚ ਇਸ ਦੀ ਭੁਗਤਾਨੀ ਦੀ ਯੋਜਨਾ ਵੀ ਬਣਾਉ।
ਅਣਜਾਣ ਡੈਬਟ ਉਦੋਂ ਬਣਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਨਹੀਂ ਜਾਣਦੀ ਕਿ ਉਹ ਕਰਜ਼ਾ ਲੈ ਰਹੀ ਹੈ: ਗੁੰਝਲਦਾਰ ਨਿਰਭਰਤਾਵਾਂ, ਅਸਪਸ਼ਟ ਡੋਮੇਨ ਮਾਡਲ, ਜਾਂ ਇੱਕ ਤੁਰੰਤ ਠੀਕ-ਪਉਲ ਹੀ ਡਿਫੌਲਟ ਬਣ ਜਾਣਾ। ਅਣਜਾਣ ਡੈਬਟ ਜ਼ਿਆਦਾਤਰ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਦਾ ਮਲਕੀਅਤ ਨਹੀਂ ਹੁੰਦੀ।
ਸਧਾਰਨ ਦਬਾਅ ਰਾਹੀਂ ਡੈਬਟ ਇੱਕઠਾ ਹੁੰਦਾ ਹੈ:
ਨਤੀਜਾ ਭਵਿੱਖਵਾਣੀਯੋਗ ਹੈ: ਫੀਚਰ ਸੁਸਤ ਹੋ ਜਾਂਦੇ ਹਨ, ਬੱਗ ਵੱਧਦੇ ਹਨ, ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਬਜਾਏ ਰੋਜ਼ਾਨਾ ਕੰਮ ਕਲ।
ਤੁਹਾਨੂੰ ਡੈਰੇਕਟ ਪ੍ਰੋਗਰਾਮ ਦੀ ਲੋੜ ਨਹੀਂ: ਛੋਟੇ, ਲਗਾਤਾਰ ਕਦਮ ਕਾਫ਼ੀ ਹਨ।
ਜੇ ਤੁਸੀਂ ਡੈਬਟ-ਸਬੰਧੀ ਫੈਸਲੇ ਦਿੱਖਾ ਦਿੰਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ADRs), ਤਾਂ ਤੁਸੀਂ ਛੁਪੇ ਹੋਏ ਖ਼ਰਚ ਨੂੰ ਮੈਨੇਜ ਕਰਨਯੋਗ ਕੰਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹੋ।
ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਐਸਾ ਰੂਪ-ਨਕਸ਼ਾ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ ਠੀਕ ਕਰਕੇ ਛੱਡ ਦਿਉ। Fowler ਦੀ ਰਾਏ ਕਹਿੰਦੀ ਹੈ: ਲੋੜਾਂ, ਟ੍ਰੈਫਿਕ, ਟੀਮਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਬਦਲਣਗੀਆਂ—ਉਸ ਲਈ ਐਸਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਸਿਸਟਮ ਬਿਨਾਂ ਦਰਦ ਦੇ ਢਲ ਸਕੇ।
ਇਵੋਲੂਸ਼ਨਰੀ ਆਰਕੀਟੈਕਚਰ ਦਾ ਮਤਲਬ ਹੈ ਬਦਲਾਅ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ, ਨ ਕਿ ਪਰਫੈਕਸ਼ਨ ਲਈ। ਲੰਬੇ ਸਮੇਂ ਦੀ ਅਨੁਮਾਨ 'ਤੇ ਸੱਟ ਲਗਾਉਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਐਸਾ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉ ਜੋ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਿਕਸਤ ਹੋ ਸਕੇ: ਸਪਸ਼ਟ ਬਾਊਂਡਰੀਆਂ, automated ਟੈਸਟ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਅਭਿਆਸ ਜੋ ਛੋਟੇ, ਘੱਟ-ਜੋਖਿਮ ਵਾਲੇ ਐਡਜਸਟਮੈਂਟਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ।
ਯੋਜਨਾਵਾਂ ਅਨੁਮਾਨ ਹਨ; ਪ੍ਰੋਡਕਸ਼ਨ ਹਕੀਕਤ। ਛੋਟੀਆਂ ਇੰਕ੍ਰੀਮੈਂਟ ਰਿਲੀਜ਼ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ, ਸਿਸਟਮ ਚਲਾਉਣ ਦੀ ਕੀ ਲਾਗਤ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂ ਭਰੋਸੇਯੋਗਤਾ ਮਹੱਤਵਪੂਰਣ ਹੈ।
ਛੋਟੀ ਰਿਲੀਜ਼ ਵੀ ਫੈਸਲੇ ਕਰਨ ਦੇ ਸਟਾਈਲ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ: ਤੁਸੀਂ ਇਕ ਮੋਡੇਸਟ ਸੁਧਾਰ (ਜਿਵੇਂ ਇੱਕ ਮਾਡਿਊਲ ਨੂੰ ਵੰਡਣਾ ਜਾਂ ਨਵੀਂ API ਵਰਜਨ ਲਿਆਉਣਾ) ਅਜ਼ਮਾ ਸਕਦੇ ਹੋ ਅਤੇ ਮਾਪ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਕਿਤਨਾ ਮਦਦਗਾਰ ਹੈ—ਬਜਾਏ ਕਿਸੇ ਮਹਾਨ ਮਾਇਗਰੇਸ਼ਨ ਨੂੰ ਅੰਗੀਕਾਰ ਕਰਨ ਦੇ।
ਇਹ ਓਸ ਸਮੇਂ ਵੀ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਟੂਲ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ—ਪਰ ਜੇ ਤੁਸੀਂ ਆਰਕੀਟੈਕਚਰਲ ਗਾਰਡਰੇਲ ਰੱਖਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਵਰਤਦੇ ਹੋ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਫੀਚਰ ਬਣਾਉਣ ਅਤੇ ਇਟਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲ ਸਕਦੀ ਹੈ, ਪਰ ਤੇਜ਼ੀ ਨੂੰ ਸਥਿਰ ਮੋਡੀਊਲ ਬਾਊਂਡਰੀਆਂ, ਚੰਗੇ ਟੈਸਟ ਅਤੇ ਅਕਸਰ ਡਿਪਲੋਇਮੈਂਟ ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ “ਤੇਜ਼ ਰਿਲੀਜ਼ ਕਰਕੇ ਆਪਣੇ ਆਪ ਨੂੰ ਕੋਲਿਰਟ” ਨਾ ਕਰ ਲਵੋ।
ਇੱਕ ਮੁੱਖ ਇਵੋਲੂਸ਼ਨਰੀ ਵਿਚਾਰ “ਫਿਟਨੈੱਸ ਫੰਕਸ਼ਨ” ਹੈ: ਇੱਕ ਮਾਪੀ ਜਾਂਚ ਜੋ ਆਰਕੀਟੈਕਚਰਲ ਲਕੜੀ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਗਾਰਡਰੇਲ ਸਮਝੋ। ਜੇ ਗਾਰਡਰੇਲ ਆਟੋਮੈਟਿਡ ਅਤੇ ਲਗਾਤਾਰ ਚੱਲਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਭਰੋਸੇ ਨਾਲ ਬਦਲਾਅ ਕਰ ਸਕਦੇ ਹੋ ਕਿਉਂਕਿ ਗਾਰਡਰੇਲ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦੇਵੇਗਾ ਜਦੋਂ ਤੁਸੀਂ ਡ੍ਰਿਫਟ ਕਰੋਂਗੇ।
ਫਿਟਨੈੱਸ ਫੰਕਸ਼ਨ ਮਹਿੰਗੇ ਨਹੀਂ ਹੋਣੇ; ਇਹ ਸਧਾਰਨ ਮੈਟਰਿਕਸ, ਟੈਸਟ ਜਾਂ ਥ੍ਰੈਸ਼ਹੋਲਡ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਲਈ ਅਹਿਮ ਹਨ।
ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਸਭ ਕੁਝ ਮਾਪਿਆ ਜਾਵੇ। ਕੁਝ ਚੈੱਕਸ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰਲ ਵਾਅਦਾਂ (ਚੇਂਜ ਦੀ ਰਫ਼ਤਾਰ, ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ, ਅਤੇ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ) ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ—ਤੇ ਉਹਨਾਂ ਨੂੰ ਦੈਨੀਕ ਫੈਸਲਿਆਂ 'ਤੇ ਰਾਹ ਦਿਣ ਦਿਓ।
ਮਾਇਕਰੋਸਰਵਿਸਿਸ ਇੰਜੀਨੀਅਰਿੰਗ ਪਰਪੱਖਤਾ ਦਾ ਨਿਸ਼ਾਨ ਨਹੀਂ ਹਨ। Fowler ਦਾ ਨੁਕਤਾ ਸਧਾਰਨ ਹੈ: ਸਿਸਟਮ ਨੂੰ ਸਰਵਿਸਾਂ ਵਿੱਚ ਵੰਡਣਾ ਇੱਕ ਸਾਥ-ਸੰਰਚਣਕ ਤੇ ਜ਼ਿਆਦਾ ਸੰਗਠਨਾਤਮਕ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਯੋਜਨਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਟੀਮਾਂ ਸਰਵਿਸਾਂ ਨੂੰ end-to-end ਮਾਲਿਕੀਅਤ ਦੇ ਨਾਲ ਚਲਾ ਸਕਣ (ਬਨਾਉਣਾ, ਡਿਪਲੋਏ, ਚਲਾਉਣਾ ਅਤੇ ਵਿਕਸਤ ਕਰਨਾ), ਤਾਂ ਤੁਸੀਂ ਲਾਭ ਦੇ ਬਿਨਾਂ ਜਟਿਲਤਾ ਪ੍ਰਾਪਤ ਕਰੋਗੇ।
ਇੱਕ ਮੋਨੋਲੀਥ ਇਕ deployable ਯੂਨਿਟ ਹੈ। ਇਹ ਫਾਇਦਾ ਹੈ: ਘੱਟ ਹਿਲਜੁਲ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ, ਸਧਾਰਨ ਡੀਬੱਗਿੰਗ, ਅਤੇ ਸਧਾਰਨ ਡੇਟਾ ਕੰਸਿਸਟੈਂਸੀ। ਨੁਕਸਾਨ ਉੱਥੇ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਕੋਡਬੇਸ ਗੁੰਝਲਦਾਰ ਬਣ ਜਾਂਦਾ ਹੈ—ਛੋਟੀ ਤਬਦੀਲੀਆਂ ਲਈ ਵੱਡੀ ਸਮਨਵਯ ਲੋੜਦੀ ਹੈ।
ਇੱਕ ਮਾਡਿਊਲਰ ਮੋਨੋਲੀਥ ਫਿਰ ਵੀ ਇੱਕ deployable ਯੂਨਿਟ ਹੈ, ਪਰ ਕੋਡ ਇरਾਦਤ ਨਾਲ ਸਪਸ਼ਟ ਮੋਡਿਊਲਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਤੁਸੀਂ ਮੋਨੋਲੀਥ ਦੀ ਆਪਰੇਸ਼ਨਲ ਸਾਦਗੀ ਰੱਖਦੇ ਹੋ ਪਰ ਅੰਦਰੂਨੀ ਕੁਪਲਿੰਗ ਘਟਾਉਂਦੇ ਹੋ। ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਲਈ ਇਹ ਸਭ ਤੋਂ ਚੰਗਾ ਡਿਫੌਲਟ ਹੈ।
ਮਾਇਕਰੋਸਰਵਿਸਿਸ ਹਰ ਸਰਵਿਸ ਨੂੰ ਆਪਣੀ ਡਿਪਲੋਏਬਿਲਿਟੀ ਅਤੇ ਲਾਈਫਸਾਈਕਲ ਦਿੰਦੇ ਹਨ। ਜੇ ਸੰਗਠਨ ਇਸ ਲਈ ਤਿਆਰ ਹੈ ਤਾਂ ਇਹ ਤੇਜ਼ ਸਵਤੰਤਰ ਰਿਲੀਜ਼ ਅਤੇ ਸਪਸ਼ਟ ਮਲਕੀਅਤ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ ਇਹ ਅਕਸਰ “ਇੱਕ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆ” ਨੂੰ “ਦੱਸ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆਵਾਂ” ਵਿੱਚ ਬਦਲ ਦੇਂਦਾ ਹੈ।
ਮਾਇਕਰੋਸਰਵਿਸਿਸ ਉਹ overhead ਜੋ ਆਰਕੀਟੈਕਚਰ ਡਾਇਗ੍ਰਾਮਾਂ 'ਤੇ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ:
ਇੱਕ ਮਾਡਿਊਲਰ ਮੋਨੋਲੀਥ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਅਸਲ ਦਬਾਅ ਮਾਪੋ ਫਿਰ ਵੰਡੋ: ਰਿਲੀਜ਼ ਬੋਤਲਨੈਕ, ਮਾਡਿਊਲ 'ਤੇ ਟੀਮ ਟਕਰਾਅ, ਸਕੇਲਿੰਗ ਹੌਟਸਪਾਟਸ, ਜਾਂ ਭਰੋਸੇਯੋਗਤਾ ਆਈਸੋਲੇਸ਼ਨ ਦੀ ਲੋੜ। ਜਦੋਂ ਇਹ ਦਬਾਅ ਲਗਾਤਾਰ ਅਤੇ ਨੰਮਾਂਤਿਤ ਹੋਣ, ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਬਾਊਂਡਰੀ, ਸਮਰਪਿਤ ਮਲਕੀਅਤ ਅਤੇ ਚਲਾਉਣ ਦੀ ਯੋਜਨਾ ਦੇ ਨਾਲ ਸਰਵਿਸ ਬਣਾਓ—ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ।
ਚੰਗੀ ਆਰਕੀਟੈਕਚਰ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿੰਨੀ ਸਰਵਿਸਾਂ ਹਨ; ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਅਣਜਾਣੀ ਤੌਰ 'ਤੇ ਹੋਰ ਤਿੰਨ ਨੂੰ ਤੋੜੇ। Martin Fowler ਅਕਸਰ ਇਸਨੂੰ ਕੁਪਲਿੰਗ (ਕਿੰਨੀ ਤਰ੍ਹਾਂ ਹਿੱਸੇ ਜੁੜੇ ਹਨ) ਅਤੇ cohesion (ਕਿੰਨਾ ਇੱਕ ਹਿੱਸਾ ਇਕੱਠਾ ਕੰਮ ਕਰਦਾ ਹੈ) ਨੂੰ ਮੈਨੇਜ ਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਂਦਾ ਹੈ।
ਇੱਕ ਰੈਸਟੋਰੈਂਟ ਰਸੋਈ ਦੀ ਸੋਚ ਕਰੋ। ਇੱਕ cohesive ਸਟੇਸ਼ਨ (ਜਿਵੇਂ “ਸੈਲਾਡਸ”) ਕੋਲ ਸਾਰਾ ਸਮਾਨ ਹੁੰਦਾ ਹੈ—ਸਮੱਗਰੀ, ਸੰਦ, ਅਤੇ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ। ਇੱਕ ਤੰਗ coupled ਰਸੋਈ ਉਹ ਹੈ ਜਿੱਥੇ ਸੈਲਾਡ ਬਣਾਉਣ ਲਈ ਗ੍ਰਿੱਲ ਕੁੱਕ ਨੂੰ ਰੋਕਣਾ ਪੈਂਦਾ, ਪੇਸਟਰੀ ਸ਼ੈਫ਼ ਨੂੰ ਡਰੈਸਿੰਗ ਮਨਜ਼ੂਰ ਕਰਵਾਉਣੀ ਪੈਂਦੀ, ਅਤੇ ਪ੍ਰਬੰਧਕ ਤੋਂ ਫ੍ਰਿਜ਼ ਖੋਲ੍ਹਵਾਉਣਾ ਪੈਂਦਾ।
ਸਾਫਟਵੇਅਰ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ: cohesive ਮਾਡਿਊਲਾਂ ਕੋਲ ਇੱਕ ਸਪਸ਼ਟ ਕੰਮ ਹੁੰਦਾ ਹੈ; loosely coupled ਮਾਡਿਊਲ ਸਾਫ਼ ਅਤੇ ਸਥਿਰ ਸਮਝੌਤਿਆਂ ਰਾਹੀਂ ਘੱਟ-ਕੱਢ-ਵਾਲੇ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ।
ਅਣਹੈਲਥੀ ਕੁਪਲਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਵਿੱਚ ਵੇਲ਼ੇ ਦੀ ਥਾਂ ਸੈਡਿਊਲ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਆਮ ਸਿਗਨਲ:
ਜੇ ਤੁਹਾਡੀ ਡਿਲਿਵਰੀ ਪ੍ਰਕਿਰਿਆ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਗਰੁੱਪ ਕੋਆਰਡੀਨੇਸ਼ਨ ਮੰਗਦੀ ਹੈ, ਤਾਂ ਡਿਪੈਂਡੇੰਸੀ ਖ਼ਰਚ ਪਹਿਲਾਂ ਹੀ ਭੁਗਤਿਆ ਜਾ ਰਿਹਾ—ਸਿਰਫ਼ ਮੀਟਿੰਗਾਂ ਅਤੇ ਦੇਰਾਂ ਵਿੱਚ।
ਕੁਪਲਿੰਗ ਘਟਾਉਣ ਲਈ ਰੀ-ਰਾਈਟ ਦੀ ਲੋੜ ਨਹੀਂ। ਪ੍ਰਯੋਗਿਕ ਕਦਮ:
ਜਦੋਂ ਫੈਸਲੇ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ ਅਤੇ ਰੱਖੋ—ਉਦਾਹਰਨ ਲਈ /blog/architecture-decision-records—ਤਾਂ ਜੋ ਬਾਊਂਡਰੀਆਂ ਇਰਾਦਤ ਵਾਲੀਆਂ ਰਹਿਣ।
ਸ਼ੇਅਰਡ ਡੇਟਾਬੇਸ "ਛੁਪਾ" coupling ਬਣਾਉਂਦਾ ਹੈ: ਕੋਈ ਵੀ ਟੀਮ ਇੱਕ ਟੇਬਲ ਬਦਲ ਸਕਦੀ ਹੈ ਅਤੇ ਦੂਜਿਆਂ ਨੂੰ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਬਰਬਾਦ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਸਾਂਝਾ DB ਆਮ ਤੌਰ 'ਤੇ ਸਮਨਵਯਤ ਰਿਲੀਜ਼ਜ਼ ਮਜ਼ਬੂਰ ਕਰਦੀ ਹੈ, ਭਾਵੇਂ ਸਰਵਿਸਾਂ ਅਲੱਗ-ਅਲੱਗ ਦਿਖਦੀਆਂ ਹੋਣ।
ਇਕ ਸਿਹਤਮੰਦ ਤਰੀਕਾ ਹੈ ਡੇਟਾ ਮਲਕੀਅਤ: ਇਕ ਸਿਸਟਮ ਇੱਕ ਡੈਟਾਸੈੱਟ ਦਾ ਮਾਲਿਕ ਹੋਵੇ ਅਤੇ API ਜਾਂ events ਰਾਹੀਂ ਇਸਨੂੰ ਪ੍ਰਦਾਨ ਕਰੇ। ਇਹ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਦਿਖਾਉਂਦਾ—ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਮੈਨੇਜ ਕਰਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਸਿਰਫ ਡੱਬਿਆ ਅਤੇ ਤੀਰ ਨਹੀਂ ਹੈ। ਇਹ ਲੋਕਾਂ ਬਾਰੇ ਵੀ ਹੈ: ਕੰਮ ਕਿਵੇਂ ਵੰਡਿਆ ਗਿਆ, ਫੈਸਲੇ ਕਿਵੇਂ ਲਏ ਜਾਂਦੇ, ਅਤੇ ਜਦੋਂ ਹਕੀਕਤ ਡਿਜ਼ਾਈਨ ਨਾਲ ਨਹੀਂ ਮਿਲਦੀ ਤਾਂ ਟੀਮ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ। ਇਹ socio-technical ਆਰਕੀਟੈਕਚਰ ਹੈ—ਤਾਪਮਾਨ ਕਿ ਸਿਸਟਮ ਦੀ ਸੰਰਚਨਾ ਅਕਸਰ ਟੀਮ ਸੰਰਚਨਾ ਦੀ ਨਕਲ ਕਰਦੀ ਹੈ।
ਅਕਸਰ ਫੇਲ੍ਹਰ ਮੋਡ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਕਾਗਜ਼ 'ਤੇ ਸਾਫ ਬਾਊਂਡਰੀਆਂ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਪਰ ਰੋਜ਼ਾਨਾ ਕੰਮ ਉਹਨਾਂ ਨੂੰ ਕੱਟਦਾ ਹੈ। ਸਿਸਟਮ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਅਤੇ ਡਿਪਲੋਏ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਤਬਦੀਲੀਆਂ ਮਹਿੰਗੀਆਂ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ।
ਮਿਸ਼ਨਦਾਰ ਸਿਗਨਲ:
ਮਲਕੀਅਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪਰਫੈਕਸ਼ਨ ਨਾਲ ਨਹੀਂ। ਉਹ ਬਾਊਂਡਰੀਆਂ ਪਸੰਦ ਕਰੋ ਜੋ ਤੁਹਾਡੀਆਂ ਟੀਮਾਂ ਵਰਤਣ ਯੋਗ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਕਈ ਵਾਰੀ ਤੁਸੀਂ ਟੀਮਾਂ ਦੀ ਪੁਨਰ-ਸੰਰਚਨਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਇੱਕ ਲੇਗਸੀ ਮਾਡਿਊਲ ਨੂੰ ਨਹੀਂ ਵੰਡ ਸਕਦੇ, ਜਾਂ ਭਰਤੀ ਕਰਕੇ ਬੋਤਲਨੈਕ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਏਸ ਹਾਲਤ ਵਿੱਚ, ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਇੱਕ ਮੋਲ-ਬਾਤਚੀਤ ਵਜੋਂ ਲਈਓ: ਉਹ ਬਾਊਂਡਰੀਆਂ ਚੁਣੋ ਜੋ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਸੁਧਾਰ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ ਜਿੱਥੇ ਇਹ ਆਜ਼ਾਦੀ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਤਬਦੀਲੀ ਦੌਰਾਨ ਔਪਚਾਰਿਕ ਸਮਝੌਤੇ ਮੰਨੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਟੈਕਨੀਕਲ ਅਤੇ ਸੰਗਠਨਾਤਮਕ ਡੈਬਟ ਦੀ ਭੁਗਤਾਨੀ ਨਾ ਕਰ ਲਵੋ।
ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਸਿਰਫ਼ ਜੋ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ ਨਹੀਂ—ਇਹ ਉਹ ਫੈਸਲੇ ਵੀ ਹਨ ਜੋ ਰਸਤੇ ਵਿੱਚ ਲਿਆਂਦੇ ਗਏ। Architecture Decision Records (ADRs) ਛੋਟੇ ਨੋਟ ਹਨ ਜੋ ਉਹ ਫੈਸਲੇ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਜਦੋਂ ਸੰਦਰਭ ਹਾਲੇ ਤਾਜ਼ਾ ਹੁੰਦਾ ਹੈ।
ADR ਇੱਕ ਇਕ-ਪੇਜ ਮੈਮੋ ਹੈ ਜੋ ਇਹ ਜਵਾਬ ਦਿੰਦਾ: "ਅਸੀਂ ਕੀ ਫੈਸਲਾ ਕੀਤਾ, ਅਤੇ ਕਿਉਂ?" ਇਹ ਕੋਈ ਲੰਮਾ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਕੋਈ ਪਰਮੀਸ਼ਨ ਸਲਿਪ ਹੈ। ਇਸਨੂੰ ਟੀਮ ਲਈ ਇੱਕ ਟਿਕਾਊ ਯਾਦ ਰੱਖਣ ਵਾਲੀ ਚੀਜ਼ ਸਮਝੋ।
ਲੋਕਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਲਈ ਬਣਾਓ। ਇੱਕ ਹਲਕਾ ADR ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:
ADRs ਨਵੇਂ ਟੀਮ ਮੈਂਬਰਾਂ ਲਈ on-boarding ਤੇਜ਼ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬਸ ਅੰਤ ਨਤੀਜੇ ਨਹੀਂ, ਬਲਕਿ ਵਿਚਾਰ ਕਰਨ ਦਾ ਤਰੀਕਾ ਵੀ ਦਿਖਾਉਂਦੇ ਹਨ। ਇਹ ਮੁੜ ਮੁਕਾਬਲਿਆਂ ਨੂੰ ਰੋਕਦੇ ਹਨ: ਜੇ ਉਹੀ ਸਵਾਲ ਮਾਸਿਆਂ baad ਫਿਰ ਆਏ, ਤੁਸੀਂ ADR ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਅਤੇ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ ਬਜਾਏ ਮੁੜ-ਚਰਚਾ ਕਰਨ ਦੇ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਕ, ADRs ਟਰੇਡ-ਅਫ਼ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ—ਜਦੋਂ ਹਕੀਕਤ ਬਦਲੇ ਅਤੇ ਯੋਜਨਾ ਨਵੀਨੀਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ, ADR ਅੱਪਡੇਟ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਸਾਦੇ ਟੈਂਪਲੇਟ ਵਰਤੋਂ, ADRs ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖੋ (ਉਦਾਹਰਨ: /docs/adr/), ਅਤੇ ਇੱਕ ADR ਲਿਖਣ ਲਈ 10–20 ਮਿੰਟ ਦਾ ਟੀਚਾ ਰੱਖੋ।
# ADR 012: API versioning strategy
Date: 2025-12-26
Status: Accepted
Owners: Platform team
Context:
We need to evolve public APIs without breaking partners.
Decision:
Adopt URL-based versioning (/v1/, /v2/).
Alternatives:
- Header-based versioning
- No versioning; rely on backward compatibility
Consequences:
+ Clear routing and documentation
- More endpoints to support over time
ਜੇ ADR paperwork ਵਰਗਾ ਮਹਿਸੂਸ ਹੋਵੇ, ਤਾਂ ਇਸਨੂੰ ਛੋਟਾ ਕਰੋ—ਆਦਤ ਛੱਡੋ ਨਹੀਂ।
ਆਰਕੀਟੈਕਚਰ "ਅਚਛੀ" ਨਹੀਂ ਰਹਿੰਦੀ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਇੱਕ ਵਾਰੀ ਇੱਕ ਸਾਫ ਡਾਇਗ੍ਰਾਮ ਬਣਾਇਆ। ਇਹ ਉਸ ਵੇਲੇ ਬਣੀ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਸਿਸਟਮ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕੇ ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਦਬਾਅ ਹੇਠ ਆਟੋਮੈਟਿਕ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰੇ। ਇਸੀ ਲਈ continuous delivery (CD) ਅਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ ਮਹੱਤਵਪੂਰਕ ਹਨ: ਉਹ ਵਿਕਾਸ ਨੂੰ ਇਕ ਖਤਰਨਾਕ ਘਟਨਾ ਨਹੀਂ ਬਣਾ ਕੇ ਆਮ ਆਦਤ ਬਣਾਦੇ ਹਨ।
ਰੀਫੈਕਟਰਿੰਗ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ ਜਦੋਂ ਤਬਦੀਲੀਆਂ ਛੋਟੀਆਂ ਅਤੇ ਵਾਪਸੀਯੋਗ ਹੁੰਦੀਆਂ ਹਨ। ਇਕ ਸਿਹਤਮੰਦ CI/CD ਪਾਈਪਲਾਈਨ ਹਰ ਤਬਦੀਲੀ ਨੂੰ ਯੂਜ਼ਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਬਿਲਡ, ਟੈਸਟ, ਅਤੇ ਵੈਰੀਫਾਈ ਕਰੇ। ਜਦੋਂ ਪਾਈਪਲਾਈਨ ਭਰੋਸੇਯੋਗ ਹੋਵੇ, ਟੀਮਾਂ ਲਗਾਤਾਰ ਡਿਜ਼ਾਈਨ ਸੁਧਾਰ ਸਕਦੀਆਂ ਹਨ ਬਜਾਏ ਕਿਸੇ "ਵੱਡੀ ਰੀਰਾਈਟ" ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ।
ਕੁਆਲਿਟੀ ਗੇਟਸ ਤੇਜ਼, ਲਗਾਤਾਰ ਅਤੇ ਉਹ ਨਤੀਜੇ ਨਾਲ ਜੁੜੇ ਹੋਣ ਚਾਹੀਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਕ ਹਨ। ਆਮ ਗੇਟ:
ਮਕਸਦ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ; ਇਹ ਹੈ ਟੁੱਟਣ ਵਾਲੇ ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਵਧਾਉਣਾ ਜਦੋਂ ਕਿ ਸੁਰੱਖਿਅਤ ਸੁਧਾਰਾਂ ਦੀ ਲਾਗਤ ਘਟਾਉਣਾ।
ਚੰਗੀ ਆਰਕੀਟੈਕਚਰ ਹਿੱਸਾ ਹੈ ਪਤਾ ਲਾਉਣਾ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਿਸਟਮ ਕੀ ਕਰ ਰਹਾ ਹੈ। ਬਿਨਾਂ ਫੀਡਬੈਕ ਦੇ, ਤੁਸੀਂ ਅਨੁਮਾਨਾਂ 'ਤੇ Optimize ਕਰ ਰਹੇ ਹੋ।
ਜਦੋਂ ਇਹ ਸਿਗਨਲ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲਿਆਂ ਨੂੰ ਸਬੂਤ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ, ਰਾਏ ਨਾਲ ਨਹੀਂ।
ਵਿਕਾਸ ਲਈ ਅਕਸਰ ਰਿਲੀਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਐਸਾਪ-ਹੈਚਸ ਹੋਣ ਚਾਹੀਦੇ ਹਨ। ਫੀਚਰ ਫਲੈਗਜ਼ ਡਿਪਲੋਇਮੈਂਟ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਅਲੱਗ ਕਰਦੇ ਹਨ। ਕੈਨੇਰੀ ਰਿਲੀਜ਼ਜ਼ ਨਾਲ ਬਲਾਸਟ ਰੇਡਿਅਸ ਘੱਟ ਰਹਿੰਦਾ ਹੈ। ਵਾਪਸੀ ਦੀ ਸਪਸ਼ਟ ਰਣਨੀਤੀ (ਡੇਟਾਬੇਸ ਵਿਚਾਰ ਸਮੇਤ) ਫੇਲ੍ਹਰਾਂ ਨੂੰ ਹੱਲਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ ਜੋ snapshots ਅਤੇ rollback ਸਮਰਥਨ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: Koder.ai), ਤਾਂ ਤੁਸੀਂ ਇਹੀ ਸਿਧਾਂਤ ਪ੍ਰੋਡਕਟ-ਡਿਲਿਵਰੀ ਲੇਅਰ 'ਤੇ ਮਜ਼ਬੂਤ ਕਰ ਸਕਦੇ ਹੋ: ਤੇਜ਼ੀ ਨਾਲ ਚਲੋ, ਪਰ ਵਾਪਸੀਯੋਗਤਾ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੁਰੱਖਿਆ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਓ।
ਇਕੱਠਾ ਕੀਤਾ, CI/CD ਅਤੇ ਫੀਡਬੈਕ ਇਕ ਐਸਾ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਲਗਾਤਾਰ ਵਿਕਸਿਤ ਹੋ ਸਕਦਾ—ਉਹੀ ਆਰਕੀਟੈਕਚਰ ਜੋ ਰੁਝਾਨਾਂ ਤੋਂ ਬਾਹਰ ਟਿਕਦੀ ਹੈ।
ਤੁਹਾਨੂੰ ਰੀ-ਰਾਈਟ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਕੁਝ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਆਦਤਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਡਿਜ਼ਾਈਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦਿੱਖਾਉਂਦੀਆਂ, ਵਾਪਸੀਯੋਗ ਅਤੇ ਲਗਾਤਾਰ ਸੁਧਰੀਆਂ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਅਗਲੇ 30 ਦਿਨ: ਇੱਕ “ਹੌਟ ਸਪਾਟ” ਚੁਣੋ (ਉੱਚ-ਚਰਨ, ਅਕਸਰ ਘਟਨਾ ਵਾਲੀ). ਇੱਕ characterization test suite ਜੋੜੋ, ਇੱਕ dependency chain ਕੀ ਸਾਦਗੀ ਕਰੋ, ਅਤੇ ਨਵੇਂ ਬਦਲਾਅਾਂ ਲਈ ਹਲਕੀਆਂ ਫੈਸਲੇ ਨੋਟ ਲਿਖਣ ਸ਼ੁਰੂ ਕਰੋ।
60 ਦਿਨ ਤੱਕ: ਇੱਕ ਸਮੱਸਿਆ-ਭਰੇ ਸੀਮ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰੋ: ਇੱਕ ਮੋਡਿਊਲ ਕੱਢੋ, ਇੱਕ ਇੰਟਰਫੇਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਜਾਂ ਪੇਰਿਸਟੈਂਸ/ਮੈਸੇਜਿੰਗ ਜਿਹੇ ਢਾਂਚੇ ਨੂੰ ਬਾਊਂਡਰੀ ਪਿੱਛੇ ਅਲੱਗ ਕਰੋ। ਬਦਲਾਅ ਦੇ “ਬਲਾਸਟ ਰੇਡਿਅਸ” ਨੂੰ ਘਟਾਓ।
90 ਦਿਨ ਤੱਕ: ਆਪਣੀ ਡਿਲਿਵਰੀ ਲੂਪ ਸੁਧਾਰੋ। ਛੋਟੇ ਪੈਚੇ, ਤੇਜ਼ builds, ਅਤੇ ਇਕ ਪੇਸ਼ਗੋਈਯੋਗ ਰਿਲੀਜ਼ ਕੈਡੰਸ ਲਈ ਲਕੜੀਆਂ ਠਹਿਰਾਓ। ਜੇ ਤੁਸੀਂ ਮਾਇਕਰੋਸਰਵਿਸਜ਼ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹੋ, ਤਾਂ ਬਦਲੀ ਦੀ ਲੋੜ ਸਾਬਤ ਕਰੋ ਇਹ ਦਰਸਾ ਕੇ ਕਿ ਇੱਕ ਬਾਊਂਡਰੀ ਅਜਿਹੀ ਹੈ ਜੋ ਮੌਜੂਦਾ ਕੋਡਬੇਸ ਦੇ ਅੰਦਰ ਸਮਭਾਲੀ ਨਹੀਂ ਜਾ ਸਕਦੀ।
(ਜੇ ਤੁਹਾਡਾ ਲਕੜਾ ਸਿਰਫ਼ ਹੋਰ ਪ੍ਰੋਡਕਟ ਜ਼ਿਆਦਾ ਤੇ ਘੱਟ ਹੈ, ਸੋਚੋ ਕਿ ਕਿੱਥੇ ਆਟੋਮੇਸ਼ਨ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ। ਕੁਝ ਟੀਮਾਂ ਲਈ, planning mode, source export, deployment/hosting, custom domains ਅਤੇ ਮੁਫ਼ਤ ਤੋਂ ਇੰਟਰਪ੍ਰਾਈਜ਼ ਤੱਕ tiered pricing ਵਾਲੀ chat-driven build workflow ਵਾਲੀ ਪਲੇਟਫਾਰਮ Koder.ai ਵਰਗੀਆਂ ਸੇਵਾਵਾਂ ਮਕੈਨਿਕਲ ਓਵਰਹੈਡ ਘਟਾ ਸਕਦੀਆਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਬਾਊਂਡਰੀਆਂ, ਟੈਸਟਾਂ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਫੀਡਬੈਕ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹੋ।)
ਮਹੀਨਾਵਾਰ ਕੁਝ ਸਿਗਨਲ ਟਰੈਕ ਕਰੋ:
ਜੇ ਇਹ ਸੁਧਰ ਰਹੇ ਨਹੀਂ, ਤਾਂ ਯੋਜਨਾ ਅਨੁਕੂਲ ਬਦਲੋ—ਆਰਕੀਟੈਕਚਰ “ਚੰਗੀ” ਬਣਦੀ ਹੈ ਜਦੋਂ ਇਹ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਸਤੀ ਬਣਾਉਂਦੀ ਹੈ।
ਸਟੈਕਸ ਬਦਲਦੇ ਰਹਿਣਗੇ। ਬੁਨਿਆਦੀ ਗੱਲਾਂ—ਸਪਸ਼ਟ ਬਾਊਂਡਰੀਆਂ, ਰੀਫੈਕਟਰਿੰਗ ਅਨੁਸ਼ਾਸਨ, ਅਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ—ਅਮਲ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ।
ਆਰਕੀਟੈਕਚਰ ਉਹ ਫੈਸਲੇ ਹਨ ਜੋ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਮਹਿੰਗਾ ਅਤੇ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ: ਬਾਊਂਡਰੀਆਂ, ਡੇਟਾ ਮਲਕੀਅਤ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੀ ਸਟੀਲ ਅਤੇ ਫੇਲ੍ਹਰ ਹੈਂਡਲਿੰਗ।
ਟੈਕ ਸਟੈਕ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਉਹ ਟੂਲ ਹਨ ਜੋ ਇਹ ਫੈਸਲੇ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹੋ—ਫਰੇਮਵਰਕ, ਲਾਇਬ੍ਰੇਰੀਆਂ, ਕਲਾਉਡ ਪ੍ਰੋਡਕਟ ਆਦਿ। ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਬਦਲੇ ਜਾ ਸਕਦੇ ਹਨ; ਪਰ ਬਾਊਂਡਰੀਆਂ ਜਾਂ ਡੇਟਾ ਫਲੋ ਬਦਲਣਾ ਅਕਸਰ ਹਫਤੇ ਲੈ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕਈ ਟੀਮਾਂ ਦੀ ਰਚਨਾ ਮੰਗਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਟੈਸਟ ਰਿਵਰਸਿਬਿਲਿਟੀ ਹੈ: ਜੇ ਕਿਸੇ ਫੈਸਲੇ ਨੂੰ ਉਲਟਣਾ ਕਰਨਾ ਹਫਤਿਆਂ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਦੀ ਸਹਿਯੋਗੀ ਕੰਮਕਾਜ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਰਕੀਟੈਕਚਰਲ ਹੈ।
ਉਦਾਹਰਨਾਂ:
ਪੈਟਰਨਾਂ ਨੂੰ ਕਿਸੇ ਮੁੜ-ਉੱਠਦੇ ਸਮੱਸਿਆ ਲਈ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹੱਲ ਵਜੋਂ ਵਰਤੋ—ਇਹ ਕੋਈ ਰਿਵਾਜ ਨਹੀਂ।
ਛੋਟਾ ਚੈਕਲਿਸਟ:
ਜੇ ਤੁਸੀਂ ਸਮੱਸਿਆ ਸਪੱਸ਼ਟ ਨਹੀਂ ਦੱਸ ਸਕਦੇ, ਤਾਂ ਹੁਣੇ ਪੈਟਰਨ ਨਾ ਜੋੜੋ।
ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਰੁਟੀਨ ਮੇਂਟੇਨੈਂਸ ਵਜੋਂ ਲਓ—ਸੱਚੇ ਘਰਲੂ ਕੰਮ ਜਿਸ ਨਾਲ ਅੰਦਰੂਨੀ ਡਿਜ਼ਾਈਨ ਸੁਧਰਦਾ ਹੈ ਬਿਨਾਂ ਵਿਹਾਰ ਬਦਲੇ।
ਆਮ ਟ੍ਰਿਗਰ:
ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰਿੰਗ ਲਈ ਟੈਸਟ, ਛੋਟੇ ਕਦਮ ਅਤੇ ਕੋਡ ਰਿਵਿਊਜ਼ ਜਰੂਰੀ ਹਨ।
ਟੈਕਨੀਕਲ ਡੈਬਟ ਨੂੰ ਇੱਕ ਲੁਕਾਈ ਹੋਈ ਚੀਜ਼ ਨਾ ਬਣਾਓ—ਇਸਨੂੰ ਇਕ ਲਾਗਤ ਵਜੋਂ ਟ੍ਰੈਕ ਕਰੋ।
ਪ੍ਰਯੋਗਿਕ ਤਰੀਕੇ:
ਫੈਸਲੇ ਖੁਲ੍ਹੇ ਰੱਖੋ—ਛੋਟੀਆਂ ADRs ਵਰਗੀਆਂ ਨੋਟਸ ਨਾਲ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਇਹ ਮੰਨਣਾ ਕਿ ਲੋੜਾਂ, ਟ੍ਰੈਫਿਕ, ਟੀਮਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਬਦਲਣਗੀਆਂ—ਤਾਂਅ ਉਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਸਿਸਟਮ ਦਰਦ-ਰਹਿਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕੇ।
ਆਮ ਤੱਤ:
ਮਕਸਦ ਹੈ ਅਡੈਪਟੇਬਿਲਿਟੀ—ਸਫ਼ਲਤਾ ਨਹੀਂ, ਬਲਕਿ ਬਦਲਣ ਯੋਗ ਬਣਾਉਣਾ।
ਫਿਟਨੈੱਸ ਫੰਕਸ਼ਨ ਇਕ automated ਗਾਰਡਰੇਲ ਹੈ ਜੋ ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਨਿਸ਼ਾਨੇ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ।
ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਉਪਯੋਗ ਉਦਾਹਰਨ:
ਕੁਝ ਮੁੱਖ ਚੈਕ ਪਕੜੋ ਜੋ ਤੁਹਾਡੇ ਵਾਅਦੇ ਦਰਸਾਉਂਦੇ—ਚੇਂਜ ਦੀ ਰਫ਼ਤਾਰ, ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ—and ਉਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਚਲਾਓ।
ਇੱਕ ਮੋਨੋਲੀਥ ਡਿਫੌਲਟ ਵਜੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਮਾਪੇ ਹੋਏ, ਲਗਾਤਾਰ ਦਬਾਅ ਨਹੀਂ ਵੇਖਦੇ ਕਿ ਅਲੱਗ ਡਿਪਲੋਏਬਿਲਿਟੀ ਚਾਹੀਦੀ ਹੈ।
ਮਾਇਕਰੋਸਰਵਿਸਿਸ ਉਹਨਾਂ ਸਮੇਂ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ:
ਜੇ ਤੁਸੀਂ ਇਕ ਸਰਵਿਸ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਨਹੀਂ ਚਲਾ ਸਕਦੇ, ਤਾਂ ਦੱਸ ਸਰਵਿਸਾਂ 'ਚ ਵੰਡਣਾ ਆਮ ਤੌਰ 'ਤੇ ਦਰਦ ਬਦਲਦਾ ਹੈ।
ਉੱਚ-ਇੰਪੈਕਟ ਕਦਮ:
ਸਾਂਝੇ ਡੀਬੀ 'ਚ ਛੁਪਾ coupling ਬਣਦਾ ਹੈ: ਕੋਈ ਵੀ ਟੀਮ ਟੇਬਲ ਤਬਦੀਲ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਹੋਰਾਂ ਨੂੰ ਟੁੱਟਾਉਣ ਦਾ ਖਤਰਾ।
ADRs (Architecture Decision Records) ਉਸ ਫੈਸਲੇ ਦਾ ਸਾਰ ਰੱਖਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਕੀਤਾ—ਕਿਉਂ ਕੀਤਾ ਅਤੇ ਕੀ ਨਤੀਜੇ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਹਲਕਾ ADR ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:
ਇਹਨਾਂ ਨੂੰ ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖੋ (ਉਦਾਹਰਨ: /docs/adr/) ਅਤੇ ਜ਼ਰੂਰੀ ਹੋਣ 'ਤੇ ਅਪਡੇਟ ਕਰੋ।