ਮੈਂ ਕੋਡਿੰਗ ਕਰਨਾ ਕਿਉਂ ਛੱਡ ਦਿੱਤਾ ਅਤੇ ਡਿਜ਼ਾਈਨਿੰਗ ਕਿਉਂ ਸ਼ੁਰੂ ਕੀਤੀ
ਮੈਂ ਪਹਿਲਾਂ ਸੋਚਦਾ ਸੀ ਕਿ ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਦਾ ਮਤਲਬ ਫੀਚਰਸ ਲਿਖਣਾ ਹੈ। ਮੈਨੂੰ ਲੱਗਦਾ ਸੀ ਕਿ ਮੇਰਾ ਕੰਮ entities ਬਣਾਉਣਾ, controllers ਤਿਆਰ ਕਰਨਾ ਅਤੇ databases ਨੂੰ ਜੋੜਨਾ ਹੈ।
ਇੱਕ ਹਾਲੀਆ ਪ੍ਰੋਜੈਕਟ ਨੇ ਮੇਰਾ ਨਜ਼ਰੀਆ ਬਦਲ ਦਿੱਤਾ। ਮੈਂ ਸਿੱਖਿਆ ਕਿ ਕੋਡਿੰਗ ਹੱਲ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਹੈ। ਅਸਲੀ ਕੰਮ ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਤੁਹਾਨੂੰ architecture ਬਾਰੇ ਫੈਸਲਾ ਲੈਣਾ ਪੈਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਕਿਉਂ ਢੁਕਵਾਂ ਹੈ, ਇਸਦੀ ਕੀ ਕੀਮਤ ਹੈ, ਅਤੇ ਇਹ ਕਿਹੜੇ ਜੋਖਮਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।
ਇੱਥੇ ਮੇਰੇ ਮੁੱਖ ਸਬਕ ਹਨ:
• Architecture ਉਤਪਾਦ ਦੇ ਪੜਾਅ ਦੇ ਅਨੁਕੂਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਰੰਤ microservices, Kubernetes, ਅਤੇ ਗੁੰਝਲਦਾਰ event queues ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮਨ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਲਈ, ਅਸੀਂ ਇੱਕ single process ਵਿੱਚ layered architecture ਦੀ ਚੋਣ ਕੀਤੀ। ਇਸ ਨੇ ਸਾਨੂੰ ਇੱਕ distributed system ਦੀ ਮੁਸ਼ਕਲ ਤੋਂ ਬਿਨਾਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਜਦੋਂ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਸਾਦਗੀ ਹੀ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ।
• ਕੁਝ ਫੈਸਲੇ ਹੁਣ ਸਸਤੇ ਹੁੰਦੇ ਹਨ ਪਰ ਬਾਅਦ ਵਿੱਚ ਮਹਿੰਗੇ ਪੈਂਦੇ ਹਨ। ਅਸੀਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਹੀ ਆਪਣੇ data model ਵਿੱਚ TenantId ਜੋੜ ਦਿੱਤਾ ਸੀ। ਭਾਵੇਂ ਸਾਡਾ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕਲਾਇੰਟ ਸੀ, ਪਰ ਇਸ ਨਾਲ ਭਵਿੱਖ ਵਿੱਚ SaaS ਮਾਡਲ ਵੱਲ ਜਾਣਾ ਆਸਾਨ ਹੋ ਗਿਆ। ਜੇਕਰ ਤੁਸੀਂ multi-tenancy ਜੋੜਨ ਲਈ ਬਹੁਤ ਦੇਰ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ migration ਇੱਕ ਭਿਆਨਕ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦੀ ਹੈ।
• Design ਭਵਿੱਖ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ। Programming ਇੱਕ ਤੁਰੰਤ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ। Designing ਭਵਿੱਖ ਦੇ ਰਸਤੇ ਬੰਦ ਕੀਤੇ ਬਿਨਾਂ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ। ਅਸੀਂ ਵੱਖ-ਵੱਖ infrastructure 'ਤੇ ਜਾਣਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ containers ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਅਸੀਂ providers ਨੂੰ ਬਦਲਣਾ ਸੌਖਾ ਬਣਾਉਣ ਲਈ interfaces ਦੀ ਵਰਤੋਂ ਕੀਤੀ।
• Business ਤਬਦੀਲੀਆਂ ਤਕਨੀਕੀ ਤਬਦੀਲੀਆਂ ਲਿਆਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਸਿਸਟਮ microservices ਵੱਲ ਉਦੋਂ ਵਧਦਾ ਹੈ ਜਦੋਂ business ਵਧਦਾ ਹੈ। ਇੱਕ ਸਿੰਗਲ clinic app ਸੈਂਕੜੇ clinics ਲਈ ਇੱਕ SaaS platform ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹ ਤਬਦੀਲੀ billing, subscriptions, ਅਤੇ scaling ਨੂੰ ਸੰਭਾਲਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ।
• Reliability ਲਈ ਸਮਾਰਟ patterns ਦੀ ਲੋੜ ਹੁੰ
ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਅਤੇ ਇੱਕ ਡਿਜ਼ਾਈਨਰ ਵਿਚਕਾਰ ਅੰਤਰ "ਕਿਉਂ" ਹੈ।
ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਪੁੱਛਦਾ ਹੈ: "ਮੈਂ ਇਸਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਵਾ ਸਕਦਾ ਹਾਂ?" ਇੱਕ ਡਿਜ਼ਾਈਨਰ ਪੁੱਛਦਾ ਹੈ: "ਇਹ ਇਸ ਖਾਸ ਸਮੱਸਿਆ ਲਈ ਸਹੀ ਹੱਲ ਕਿਉਂ ਹੈ?"