AI ਵਿਕਾਸ ਵਿੱਚ ਇਨਸਾਨੀ ਸਮੀਖਿਆ ਚੈਕਪੌਇੰਟ: ਸਕੀਮਾ ਸੈਨਿਟੀ, auth ਨਿਯਮ, ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਾਂ ਲਈ 5-ਮਿੰਟ ਚੈਕ ਜੋ ਵੱਡੇ ਨੁਕਸਾਨ ਤੋਂ ਪਹਿਲਾਂ ਗਲਤੀਆਂ ਫੜ ਲੈਂਦੇ ਹਨ।
AI-ਸਹਾਇਤ ਨਿਰਮਾਣ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਵੇਖਾਉਂਦੇ ਹੋ, ਇੱਕ ਕੰਮ ਕਰਦਾ ਸਕ੍ਰੀਨ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਐਪ ਲੱਗਦਾ ਹੈ ਕਿ ਤਿਆਰ ਹੈ। ਫੇਰ ਵੀ, ਛੋਟੀਆਂ ਵਿਸਥਾਰਕ ਗਲਤੀਆਂ ਅਕਸਰ ਐਜ ਕੇਸ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ: ਅਸਲੀ ਡਾਟਾ, ਅਸਲੀ ਪਰਮਿਸ਼ਨ, ਅਸਲੀ ਪ੍ਰੋਡਕਸ਼ਨ ਸੈਟਿੰਗਾਂ। ਇਹ "ਛੋਟੀਆਂ" ਗਲਤੀਆਂ ਹੀ ਉਹ ਹਨ ਜੋ ਇੱਕ ਹਫਤੇ ਦੀ ਸਫਾਈ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਚੈਕਪੌਇੰਟ ਇਕ ਛੋਟੀ ਇਨਸਾਨੀ ਰੋਕ ਹੈ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਬਦਲਾਅ ਨੂੰ ਮਨਜ਼ੂਰ ਜਾਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਾਉਂਦੇ ਹੋ। ਇਹ ਕੋਈ ਮੀਟਿੰਗ ਨਹੀਂ ਅਤੇ ਨਾ ਹੀ ਲੰਮਾ QA ਚੱਕਰ ਹੈ। ਇਹ ਇੱਕ ਜਾਣਬੂਝ ਕੇ ਕੀਤਾ ਗਿਆ 5-ਮਿੰਟ ਦਾ ਸਕੈਨ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ: ਜੇ ਇਹ ਗਲਤ ਹੋਵੇ ਤਾਂ ਸਭ ਤੋਂ زیادہ ਕੀ ਟੁੱਟੇਗਾ?
ਸਭ ਤੋਂ ਦਰਦਨਾਕ ਸਫਾਈਆਂ ਚਾਰ ਉੱਚ-ਖਤਰਾ ਖੇਤਰਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ:
ਇੱਕ ਛੋਟੀ ਰੋਕ ਇਸ ਲਈ ਫਾਇਦੈਮੰਦ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਮੱਸਿਆਵਾਂ ਕ੍ਰਾਸ-ਕਟਿੰਗ ਹੁੰਦੀਆਂ ਹਨ। ਇਕ ਛੋਟੀ ਸਕੀਮਾ ਗਲਤੀ APIs, ਸਕ੍ਰੀਨ, ਰਿਪੋਰਟ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਵਿੱਚ ਛਾਪ ਛੱਡਦੀ ਹੈ। ਇੱਕ ਪਰਮੀਸ਼ਨ ਗਲਤੀ ਸੁਰੱਖਿਆ ਘਟਨਾ ਬਣ ਸਕਦੀ ਹੈ। ਇਕ ਗਲਤ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗ ਡਾਊਨਟਾਈਮ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ।
ਤੁਸੀਂ ਹੱਥ ਨਾਲ ਕੋਡ ਕਰੋ ਜਾਂ Koder.ai ਵਰਗੇ vibe-coding ਟੂਲ ਵਰਤੋ, ਨਿਯਮ ਇਕੋ ਹੀ ਹੈ: ਤੇਜ਼ੀ ਨਾਲ ਚੱਲੋ, ਪਰ ਜਿੱਥੇ ਨੁਕਸਾਨ ਵੱਡਾ ਹੋਵੇ ਓਥੇ ਛੋਟੇ ਗਾਰਡਰੇਲ ਲਗਾਓ।
ਚੈਕਪੌਇੰਟ ਉਹਨਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪੇਸ਼ਗਿਆਨੀਯੋਗ ਹੁੰਦੇ ਹਨ। ਹਰ ਚੀਜ਼ ਦੀ ਸਮੀਖਿਆ ਨਾ ਕਰੋ। ਉਸ ਕੁਝ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਜਿਸਨੂੰ ਵਾਪਸ ਕਰਨਾ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।
ਉਹ ਪਲ ਚੁਣੋ ਜੋ ਹਮੇਸ਼ਾ ਚੈਕਪੌਇੰਟ ਲੈਣ ਵਾਲੇ ਹੋਣ: ਫੀਚਰ ਪੂਰਾ ਹੋਣ ਦੇ ਬਾਅਦ, ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ, ਅਤੇ ਕਿਸੇ ਵੀ ਰਿਫੈਕਟਰ ਤੋਂ ਬਾਅਦ ਜੋ ਡਾਟਾ, auth, ਬਿਲਿੰਗ ਜਾਂ ਕੋਈ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ-ਮੁਹਾਂ-ਸੰਬੰਧਤ ਚੀਜ਼ ਛੂਹਦਾ ਹੈ।
5 ਮਿੰਟ ਲਈ ਟਾਈਮਰ ਸੈੱਟ ਕਰੋ। ਜਦੋਂ ਉਹ ਖਤਮ ਹੋ ਜਾਵੇ, ਰੁਕੋ। ਜੇ ਤੁਸੀਂ ਅਸਲ ਖਤਰਾ ਲੱਭਦੇ ਹੋ, ਤਾਂ ਲੰਬੇ ਫਾਲੋਅਪ ਦਾ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਜੇ ਨਹੀਂ, ਤਾਂ ਬੇਸ਼ੱਕ ਸ਼ਿਪ ਕਰੋ।
ਇੱਕ ਰਿਵਿਊਅਰ ਰੋਲ ਅਸਾਈਨ ਕਰੋ, ਭਾਵ "ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ" ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਉਸ ਟੀਮਮੀਟ ਲਈ ਮਨਜ਼ੂਰ ਕਰ ਰਹੇ ਹੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਿਘਟਿਤ ਨਹੀਂ ਕਰ ਸਕੋਗੇ।
ਇੱਕ ਛੋਟਾ ਟੈਂਪਲੇਟ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਰਹਿਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:
Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):
ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਆਖਰੀ ਕਦਮ ਨੂੰ ਸਾਬਤ ਉਦਦੇਸ਼ ਰੱਖੋ। ਸਨੈਪਸ਼ਾਟਸ ਅਤੇ ਰੋਲਬੈਕ "ਮੈਨੂੰ ਪੱਕਾ ਨਹੀਂ ਪਤਾ" ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਫੈਸਲਾ ਬਣਾਉਂਦੇ ਹਨ।
ਦਿਨਾਂ ਗਵਾ ਦੇਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਲਓ ਜੋ ਸਿਰਫ਼ "ਕਿਸੇ ਹੱਦ ਤੱਕ" ਤੁਹਾਡੇ ਮਤਲਬ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। ਛੋਟੀਆਂ ਡਾਟਾ ਗਲਤੀਆਂ ਹਰ ਸਕ੍ਰੀਨ, API ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੱਚ ਫੈਲਦੀਆਂ ਹਨ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਇਹ ਚੈੱਕ ਕਰਕੇ ਕਿ ਕੋਰ ਐਨਟੀਟੀਜ਼ ਅਸਲੀ ਦੁਨਿਆ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ ਕਿ ਨਹੀਂ। ਇੱਕ ਸਰਲ CRM ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ Customers, Contacts, Deals ਅਤੇ Notes ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ vague ਨਾਮਾਂ ਜਿਵੇਂ "ClientItem" ਜਾਂ "Record" ਵੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭਟਕ ਰਹੇ ਹੋ।
ਇੱਕ 5-ਮਿੰਟ ਦਾ ਸਕੀਮਾ ਸਕੈਨ:
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਇੱਕ Invoices ਟੇਬਲ ਜਿਸ ਵਿੱਚ unique invoice_number ਨਾ ਹੋਵੇ, ਡੈਮੋ ਵਿੱਚ ਠੀਕ ਲੱਗਦੀ ਹੈ। ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਡੁਪਲਿਕੇਟ ਆਉਂਦੇ ਹਨ, ਭੁਗਤਾਨ ਗਲਤ ਰਿਕਾਰਡ ਨੂੰ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਕਲੀਨਅੱਪ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਮਾਫ਼ੀ-ਈਮੇਲ ਲਿਖ ਰਹੇ ਹੁੰਦੇ ਹੋ। ਸਮੀਖਿਆ ਵਿੱਚ ਇਸਨੂੰ ਪਕੜਨਾ 30 ਸਕਿੰਟ ਦਾ ਫਿਕਸ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਇੱਕ ਸਵਾਲ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਇਹ ਹੋਵੇ: ਕੀ ਤੁਸੀਂ ਸਕੀਮਾ ਨੂੰ ਦੁਨੀਆ ਦੇ ਨਵੇਂ ਟੀਮਮੀਟ ਨੂੰ ਦੋ ਮਿੰਟ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ? ਜੇ ਨਹੀਂ, ਤਾਂ ਉਸਨੂੰ ਤੰਗ ਕਰੋ ਪਹਿਲਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।
Auth ਬੱਗ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਖੁਸ਼-ਰਸਤੇ ਡੈਮੋ ਉਨ੍ਹਾਂ ਨੂੰ ਛੁਪਾ ਲੈਂਦੇ ਹਨ। ਦੋ ਆਮ ਨਾਕਾਮੀਆਂ ਹਨ: "ਹਰੇਕ ਨੂੰ ਸਭ ਕੁਝ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ" ਅਤੇ "ਕੋਈ ਵੀ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦਾ"।
ਰੋਲ ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ: admin, staff, customer। ਜੇ ਐਪ ਵਿੱਚ ਟੀਮਾਂ ਹਨ, ਤਾਂ workspace member ਅਤੇ workspace owner ਵੀ ਜੋੜੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਰੋਲ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਨਿਯਮ ਫੈਲਣਗੇ।
ਫਿਰ ਇੱਕ ਨਿਯਮ ਲਾਗੂ ਕਰੋ: ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਪਹੁੰਚ। ਨਵੇਂ ਰੋਲਾਂ ਨੂੰ ਬਿਨਾਂ ਪਹੁੰਚ ਜਾਂ ਕੇਵਲ ਪੜ੍ਹਨ-ਕੇ-ਲਈ ਰੱਖਿਆ ਜਾਵੇ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਪਹੁੰਚ ਮਿਲੇ ਜੋ ਲੋੜੀਂਦੀ ਹੈ। AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਅਕਸਰ ਪ੍ਰਭਾਵਤ ਤੌਰ 'ਤੇ ਪਰਮਿਸਿਵ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟੈਸਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਛੇਤੀ ਤਸਦੀਕ ਕਰਨ ਲਈ, ਇੱਕ ਛੋਟਾ access matrix ਬਣਾਓ ਅਤੇ ਯੂਆਈ ਅਤੇ API ਦੋਹਾਂ ਵਿੱਚ ਅਸਲ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰੋ:
Ownership ਚੈੱਕਾਂ ਨੂੰ ਖਾਸ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ। "ਯੂਜ਼ਰ Task ਪੜ੍ਹ ਸਕਦਾ ਹੈ" ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: "ਯੂਜ਼ਰ Task ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਜਿੱਥੇ task.ownerId == user.id" (ਜਾਂ ਯੂਜ਼ਰ workspace ਦਾ ਮੈਂਬਰ ਹੋਵੇ)।
ਐਜ ਕੇਸ ਉਹਨਾਂ ਜਗ੍ਹਾਂ ਹਨ ਜਿੱਥੇ ਲੀਕਸ ਹੁੰਦੇ ਹਨ: ਨਿਮੰਤਰਤ-ਪਰ-ਸਵੀਕਾਰ-ਨਹੀਂ ਕੀਤੇ ਗਏ ਯੂਜ਼ਰ, ਮਿਟਾਏ ਗਏ ਖਾਤੇ, ਹਟਾਏ ਗਏ ਵਰਕਸਪੇਸ ਮੈਂਬਰ ਜਿਨ੍ਹਾਂ ਦੇ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਹਨ। ਇੱਕ ਛੁੱਟਿਆ ਹੋਇਆ ਐਜ ਕੇਸ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਸਫਾਈ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ Асਿਸਟੈਂਟ ਨੂੰ ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੋਲ ਅਤੇ ਇੱਕ ਐਕਸੈੱਸ ਟੇਬਲ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ ਕਹੋ, ਫਿਰ ਹਰ ਰੋਲ ਲਈ ਦੋ ਟੈਸਟ ਅਕਾਊਂਟ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ।
ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਛੋਟੀ ਗਲਤੀ ਤੋਂ ਦਿਨਾਂ ਦੀ ਸਫਾਈ ਤੱਕ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹਨ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸਭ ਕੁਝ ਲਿਸਟ ਕਰੋ ਜੋ ਡਾਟਾ ਮਿਟਾ ਸਕਦਾ ਹੈ ਜਾਂ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਡਿਲੀਟ ਬਟਨ ਹੀ ਨਹੀਂ ਹੈ—ਇਹ reset, sync, import/replace, rebuild index, seed actions, ਅਤੇ ਵਿਸ਼ਾਲ ਐਡਮਿਨ ਟੂਲ ਵੀ ਹਨ।
ਕੁਝ ਸਾਫ਼ ਸੁਰੱਖਿਆ ਸਿਗਨਲ ਲੱਭੋ:
ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ-ਜਨਰੇਟਡ ਡਾਟਾ ਲਈ soft delete ਤਰਜੀਹ ਦਿਓ। ਇੱਕ ਸਰਲ deleted_at ਫੀਲਡ ਤੇ ਫਿਲਟਰਿੰਗ undo ਸੰਭਵ ਰੱਖਦੀ ਹੈ ਅਤੇ ਜੇ ਬੱਗ ਨਿਕਲ ਆਏ ਤਾਂ ਤੁਹਾਨੂੰ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।
ਸਕੀਮਾ ਸੋਧਾਂ ਨੂੰ ਵੀ ਸੰਭਵ ਤੌਰ 'ਤੇ ਨਸ਼ਟ ਕਰਨ ਵਾਲਾ ਮਾਨੋ। ਕਾਲਮ ਡ੍ਰਾਪ ਕਰਨਾ, ਟਾਈਪ ਬਦਲਣਾ, ਅਤੇ ਕੰਸਟਰੈਂਟ ਤੀਖੇ ਕਰਨਾ ਡਾਟਾ ਗੁਆਚ ਵੀ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ AI ਨੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤਜਵੀਜ਼ ਕੀਤੀ, ਪੁੱਛੋ: ਮੌਜੂਦਾ rows ਨੂੰ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ بحਾਲ ਕਰਾਂਗੇ?
ਜੇ ਤੁਸੀਂ ਰੋਅਬੈਕ ਯੋਜਨਾ ਇਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਨਸ਼ਟ ਕਰਨ ਵਾਲਾ ਬਦਲਾਅ ਹੁਣੇ ਹੀ ਸ਼ਿਪ ਨਾ ਕਰੋ।
ਅਕਸਰ ਸਫਾਈ ਦੀਆਂ ਕਹਾਣੀਆਂ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਐਪ dev ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵੱਖਰਾ ਵਿਹਾਰ ਦਿਖਾਂਦਾ ਹੈ।
ਡਿਵ ਅਤੇ ਪ੍ਰੋਡ ਨੂੰ ਰੋਕੋ ਵਜੋਂ ਵੱਖ-ਵੱਖ: ਵੱਖ ਡੈਟਾਬੇਸ, ਕੀਜ਼, ਬੱਕੇਟ ਅਤੇ ਈਮੇਲ ਪ੍ਰੋਵਾਈਡਰ। ਜੇ ਦੋਹਾਂ ਵਾਤਾਵਰਣ ਇੱਕੋ ਡੇਟਾਬੇਸ ਨੂੰ ਪוਇੰਟ ਕਰ ਰਹੇ ਹਨ, ਇੱਕ ਟੈਸਟ ਸਕ੍ਰਿਪਟ ਅਸਲ ਡਾਟਾ ਨੂੰ ਪ੍ਰਦੂਸ਼ਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਇੱਕ "ਫੁਟਕਰਾ ਰੀਸੈਟ" ਸਭ ਕੁਝ ਮਿਟਾ ਸਕਦਾ ਹੈ।
ਫਿਰ ਸੀਕ੍ਰੇਟਸ ਚੈੱਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਨਫਿਗ ਫਾਇਲ, ਪ੍ਰੰਪਟ ਜਾਂ ਕਮਿੱਟ ਸੁਨੇਹੇ ਵਿੱਚ ਕੀਜ਼ ਦੇਖਦੇ ਹੋ, ਤਦ ਮੰਨੋ ਕਿ ਉਹ ਲੀਕ ਹੋਣਗੇ। ਸੀਕ੍ਰੇਟ ਤੈਨਾਤ ਸਮੇਂ ਹੀ inject (env vars ਜਾਂ secrets manager) ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਇੱਕ ਲਾਜ਼ਮੀ ਸੀਕ੍ਰੇਟ ਨਾ ਮਿਲਣ 'ਤੇ ਸ਼ੁਰੂ ਨਾ ਹੋਣਾ ਚਾਹੀਦਾ — ਇਹ ਤਸ਼ਖੀਸ ਨਾਲ ਫੈਲ ਹੋਣ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।
ਫਿਰ ਬਰਾਊਜ਼ਰ-ਸਮ੍ਹੇਤ ਸੈਟਿੰਗਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: allowed origins (CORS), redirect URLs, OAuth callback URLs। ਇਹ ਆਸਾਨੀ ਨਾਲ ਥੋੜ੍ਹੇ-ਬਹੁਤ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਇਸੀ ਲਈ ਤੁਸੀਂ "ਕ੍ਰਿਆ-ਸ਼ੀਲ ਲੌਗਿਨ" ਡਿਬੱਗ ਕਰ ਰਹੇ ਹੋ ਜਦੋਂ ਕੋਡ ਠੀਕ ਹੋਵੇ।
ਇੱਕ 5-ਮਿੰਟ ਡਿਪਲੋਇਮੈਂਟ ਚੈੱਕ:
ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਤੈਨਾਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਵੀ ਇੱਕ ਵਧੀਆ ਸਮਾਂ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਦਾ ਕਿ ਤੁਹਾਡੇ ਨੇ ਸਹੀ ਵਾਤਾਵਰਣ ਨੂੰ ਡਿਪਲੋਇ ਕੀਤਾ ਹੈ ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਰੋਲਬੈਕ ਉਪਲਬਧ ਹੈ।
AI-ਜਨਰੇਟਡ ਬਦਲਾਅ ਨੂੰ ਅੰਗੀਕਾਰ ਕਰਨ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਮਿੰਟ ਲਈ ਰੁਕੋ। ਤੁਸੀਂ ਸਟਾਈਲ ਦੀ ਸਮੀਖਿਆ ਨਹੀਂ ਕਰ ਰਹੇ — ਤੁਸੀਂ ਉਹ ਗਲਤੀਆਂ ਲੱਭ ਰਹੇ ਹੋ ਜੋ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਫਾਈ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਉਦਾਹਰਨ: ਤੁਸੀਂ "admin delete user" ਫੀਚਰ ਮਰਜ ਕਰ ਰਹੇ ਹੋ। 60 ਸਕਿੰਟ ਵਿੱਚ ਤੁਸੀਂ ਨੋਟ ਕਰਦੇ ਹੋ ਕਿ ਬੈਕਐਂਡ ਵਿੱਚ ਕੋਈ ਰੋਲ ਚੈੱਕ ਨਹੀਂ ਹੈ — ਸਿਰਫ਼ UI ਬਟਨ ਲੁਕਿਆ ਹੋਇਆ ਹੈ। ਕੋਈ ਵੀ ਯੂਜ਼ਰ ਡਾਇਰੈਕਟਲੀ ਏਂਡਪੌਇੰਟ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਕ ਕੈਚ ਤੁਹਾਨੂੰ ਇੱਕ ਘਟਨਾ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ ਇਕ ਸਵਾਲ ਪੁੱਛੋ ਜੋ ਹਕੀਕਤ ਨੂੰ ਜ਼ੋਰ ਦੇਵੇ:
ਇੱਥੇ ਇਕ ਅਸਲ ਯੂਜ਼ਰ ਸਭ ਤੋਂ ਬੁਰੀ ਤਰ੍ਹਾਂ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਇਛਾ ਕਰਕੇ ਜਾਂ ਅਕਸਮਾਤ?
ਜੇ ਜਵਾਬ ਵਿੱਚ "ਦੂਸਰੇ ਲੋਕਾਂ ਦਾ ਡਾਟਾ ਮਿਟਾਉਣਾ", "ਪ੍ਰਾਈਵੇਟ ਰਿਕਾਰਡ ਵੇਖਣਾ" ਜਾਂ "ਪ੍ਰੋਡ ਤੋੜਨਾ" ਆਉਂਦਾ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਤੰਗ ਕਰੋ।
ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ CRM ਬਣਾ ਰਹੇ ਹੋ ਅਤੇ AI ਟੂਲ ਨੂੰ customer ਪੇਜ 'ਤੇ "Delete customer" ਬਟਨ ਜੋੜਨ ਲਈ ਕਹਿੰਦੇ ਹੋ। ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇਹ UI, ਬੈਕਐਂਡ ਏਂਡਪੌਇੰਟ ਅਤੇ ਰਿਲੇਟਿਡ ਰਿਕਾਰਡ ਹਟਾਉਣ ਲਈ ਡੇਟਾਬੇਸ ਬਦਲਾਅ ਜਨਰੇਟ ਕਰ ਦਿੰਦਾ ਹੈ।
ਸਭ ਕੁਝ ਚੱਲਦਾ ਪਤਾ ਲੱਗਦਾ ਹੈ: ਬਟਨ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਰਿਕਵੈਸਟ 200 ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ customer ਲਿਸਟ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਬਹੁਤੇ ਟੀਮਾਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ।
ਇੱਕ 5-ਮਿੰਟ ਸਮੀਖਿਆ ਦੋ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੀ ਹੈ:
ਅਮਲ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਸਮੀਖਿਆ:
ਇੱਕ ਪ੍ਰੰਪਟ ਸੋਧ ਇਸਨੂੰ ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰ ਦਿੰਦੀ:
"Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized."
ਫਿਰ ਇਸਨੂੰ ਮੁੜ ਟੁੱਟਣ ਤੋਂ ਬਚਾਉਣ ਲਈ ਪ੍ਰੋਜੈਕਟ ਨੋਟਸ ਵਿੱਚ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਰਜ ਕਰੋ: delete ਨਿਯਮ (soft vs hard), permission ਲੋੜ (ਕੌਣ ਹਟਾ ਸਕਦਾ ਹੈ), ਅਤੇ ਉਮੀਂਦਿਤ ਸਾਈਡ-ਇਫੈਕਟਸ (ਕਿਹੜਾ ਸੰਬੰਧਤ ਡਾਟਾ ਰਹਿੰਦਾ ਹੈ)।
AI ਆਊਟਪੁੱਟ ਆਤਮ ਵਿਸ਼ਵਾਸ ਨਾਲ ਸੁਣਦਾ ਹੈ ਪਰ ਅਨੁਮਾਨ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਉਹਨਾਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਦਿੱਖਾਉਣਾ ਹੈ।
ਇਹ ਸ਼ਬਦ ਜੋ ਅਗਲੇ ਸਵਾਲ ਖੜੇ ਕਰਨ ਚਾਹੀਦੇ ਹਨ: “assume”, “default”, “simple”, “should”, “usually”. ਉਹ ਅਕਸਰ ਮਤਲਬ ਰੱਖਦੇ ਹਨ "ਮੈਂ ਕੁਝ ਚੁਣਿਆ ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਕਰਵਾਏ"।
ਉਪਯੋਗੀ ਪ੍ਰੰਪਟ ਪੁਨਰੂਪ:
“Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm.”
ਦੋ ਹੋਰ ਪ੍ਰੰਪਟ ਜੋ ਜੋਖਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਾਹਰ ਲੈਂਦੇ ਹਨ:
Auth ਲਈ:
“Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail.”
ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਚੀਜ਼ਾਂ ਹਮੇਸ਼ਾ ਮਨੁੱਖੀ-ਦੁਆਰਾ ਵੈਰੀਫਾਇ ਕੀਤੀਆਂ ਜਾਣ, ਅਤੇ ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ:
ਜ਼ਿਆਦਾਤਰ ਲੰਬੀਆਂ ਸਫਾਈਆਂ ਇਕੋ ਹੀ ਛੋਟੀ ਚੋਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਆਊੱਟਪੁੱਟ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਕਿਉਂਕਿ ਉਹ "ਹੁਣ" ਕੰਮ ਕਰਦਾ ਹੈ।
“ਇਹ ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਕਲਾਸਿਕ ਫੰਦੇ ਹੈ। ਇੱਕ ਫੀਚਰ ਲੋਕਲ ਟੈਸਟਾਂ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਅਸਲ ਡਾਟਾ ਸਾਈਜ਼ਾਂ, ਅਸਲ ਪਰਮਿਸ਼ਨਾਂ, ਜਾਂ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਵਾਤਾਵਰਣ ਹੋਣ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਐਮਰਜੈਂਸੀ ਪੈਚਾਂ ਦਾ ਲਿਕੜਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਸਕੀਮਾ ਡ੍ਰਿਫਟ ਇਕ ਹੋਰ ਮੈਗਨੇਟ ਹੈ। ਜਦੋਂ ਟੇਬਲਾਂ ਤਬਦੀਲ ਹੁੰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਸਪਸ਼ਟ ਨਾਂਵਾਂ, ਕੰਸਟਰੈਂਟਾਂ ਅਤੇ ਡਿਫਾਲਟਾਂ ਦੇ, ਤੁਸੀਂ ਇੱਕ-ਆਫ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਅਤੇ ਅਜੀਬ ਵਰਕਅਰਾਊਂਡਜ਼ ਨਾਲ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹੋ। ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਪੁੱਛਦਾ ਹੈ, "status ਦਾ ਕੀ ਮਤਲਬ ਹੈ?" ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਹੁੰਦਾ।
Auth ਨੂੰ ਆਖਿਰ ਵਿੱਚ ਜੋੜਨ ਨਾਲ ਦਰਦ ਹੋਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਐਸਾ ਬਣਾਉਂਦੇ ਹੋ ਜਿਵੇਂ ਹਰ ਯੂਜ਼ਰ ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੱਫ਼ਤਿਆਂ ਤਕ ਦੇ ਨਾਲ-ਨਾਲ ਰੰਦਿਆਂ ਦੀ ਭਰਾਈ ਕਰੋਗੇ।
ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਬਾਹੀਆਂ ਕਰਦੀਆਂ ਹਨ। "Delete project" ਜਾਂ "reset database" ਅਸਾਨੀ ਨਾਲ ਲਾਗੂ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਬਿਨਾਂ soft delete, snapshots ਜਾਂ ਰੋਲਬੈਕ ਯੋਜਨਾ ਦੇ ਅਸਾਨੀ ਨਾਲ ਅਫਸੋਸ ਦਾ ਕਾਰਨ ਬਣ ਜਾਂਦੇ ਹਨ।
ਕੁਝ ਮੁੜ-ਮੁੜ ਉਤਪੰਨ ਹੋਣ ਵਾਲੇ ਕਾਰਨ ਜਿਹੜੇ ਬਹੁ-ਦਿਨੀ ਸਫਾਈ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ:
ਚੈਕਪੌਇੰਟਾਂ ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖਣ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਪਲਾਂ ਨਾਲ ਜੋੜੋ ਜਿਹੜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ: ਇੱਕ ਫੀਚਰ ਸ਼ੁਰੂ ਕਰਨਾ, ਉਸਨੂੰ ਮਰਜ ਕਰਨਾ, ਤੈਨਾਤ ਕਰਨਾ, ਅਤੇ ਤਸਦੀਕ ਕਰਨਾ।
ਇੱਕ ਹਲਕਾ ਰਿਥਮ:
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸ ਦੀ planning mode "ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ" ਚੈਕਪੌਇੰਟ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ: ਫੈਸਲਿਆਂ ਨੂੰ ਲਿਖੋ ਜਿਵੇਂ "orders signed-in users ਬਣਾਉਣ ਲਾ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ admins status ਬਦਲ ਸਕਦੇ ਹਨ" ਪਹਿਲਾਂ ਹੀ, ਤਬ ਜਨਰੇਟਿੰਗ ਕਰੋ। ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵੀ ਇਹਨਾਂ ਨੂੰ ਮੁੜ-ਜਨਰੇਟ ਕਰਨ ਸਮੇਂ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ।
ਪੰਜ ਮਿੰਟ ਹਰ ਚੀਜ਼ ਨਹੀਂ ਪਕੜੇਗਾ। ਪਰ ਇਹ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸੇਵ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਅਜੇ ਵੀ ਸਸਤੇ ਹਨ।
ਇੱਕ ਫੀਚਰ ਜਨਰੇਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ, ਅਤੇ ਕਿਸੇ ਵੀ ਸੋਧ ਦੇ ਬਾਅਦ ਜੋ ਡਾਟਾ, auth, ਬਿਲਿੰਗ ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸੈਟਿੰਗਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ। ਇਹ ਸਮੇਂ ਸਭ ਤੋਂ ਵੱਧ “ਬਲਾਸਟ ਰੇਡੀਅਸ” ਰੱਖਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਛੋਟੀ ਸਮੀਖਿਆ ਮਹਿੰਗੇ ਗਲਤੀਆਂ ਨੂੰ ਜਲਦੀ ਕਬਰ ਕਰ ਲੈਂਦੀ ਹੈ।
ਸਖਤ ਰਿਹਾ ਕਿ: 5-ਮਿੰਟ ਟਾਈਮਰ ਲਗਾਓ ਅਤੇ ਹਰ ਵਾਰ ਇਹੀ ਕਦਮ ਦੋਹਰਾਓ। ਇੱਕ ਵਾਕ ਵਿੱਚ ਬਦਲਾਅ ਦਾ ਨਾਮ ਦਿਓ, ਦੇਖੋ ਕਿ ਇਹ ਕੀ ਛੂਹਦਾ ਹੈ (ਡਾਟਾ, ਰੋਲ, ਵਾਤਾਵਰਣ), ਚਾਰ ਖ਼ਤਰਨਾਕ ਖੇਤਰਾਂ ਨੂੰ ਸਕੈਨ ਕਰੋ, ਇੱਕ ਸਧਾਰਣ ਰੀਐਲਟੀ ਟੈਸਟ ਚਲਾਓ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ: ਅੱਗੇ ਵਧੋ, ਪ੍ਰੰਪਟ ਸੋਧੋ ਜਾਂ ਰੋਲਬੈਕ ਕਰੋ।
ਕਿਉਂਕਿ ਇਹ ਗਲਤੀਆਂ ਵਿਆਪਕ ਅਸਰ ਵਾਲੀਆਂ ਹੋਂਦੀਆਂ ਹਨ। ਇੱਕ ਛੋਟੀ ਸਕੀਮਾ ਗਲਤੀ APIs, ਸਕ੍ਰੀਨਾਂ, ਰਿਪੋਰਟਾਂ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਵਿੱਚ ਫੈਲ ਜਾਂਦੀ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਨਾ ਅਕਸਰ ਕਈ ਲੇਅਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਵਾਲਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ। ਤਾਜ਼ਾ ਬਦਲਾਅ ਵੇਲੇ ਕੈਚ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਛੋਟੀ ਸੋਧ ਹੁੰਦੀ ਹੈ ਨਾ ਕਿ ਵੱਡਾ ਸਫਾਈ ਪ੍ਰਾਜੈਕਟ।
ਖਾਤਾ ਕਰੋ ਕਿ ਟੇਬਲਾਂ ਅਤੇ ਫੀਲਡਸ ਅਸਲੀ ਸੰਕਲਪਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਨਾਂ ਇਕ_consistent ਹੋਣ, ਰਿਸ਼ਤੇ ਪੂਰੇ ਹਨ, ਅਤੇ ਕੰਸਟਰੈਂਟ ਜ਼ਰੂਰੀ ਅਤੇ ਅਤੇ ਜਾਣ-ਭੁਞੇ ਹਨ (not null, unique, foreign keys)। ਆਮ ਲੁੱਕਅਪ ਲਈ ਇੰਡੈਕਸ ਵੀ ਚੈੱਕ ਕਰੋ ਤਾਂ ਕਿ ਡਾਟਾ ਵੱਧਣ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨਾ ਡਿੱਗੇ।
UI ਨੂੰ ਛੱਡ ਕੇ ਸਰਵਰ ਸਾਈਡ ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਰੋਲ ਸਾਫ਼-ਸਪੱਸ਼ਟ ਲਿਖੋ, ਡਿਫਾਲਟ-ਡਿਫਾਈ ਰੱਖੋ (least access by default), ਅਤੇ ownership checks ਨੂੰ ਸਰਵਰ ਤੇ ਪਰਖੋ — ਇੱਕ ਹੋਰ ਯੂਜ਼ਰ ਦਾ ਆਈਟਮ ਖੋਲ੍ਹ ਕੇ ਜਾਂ ID ਬਦਲ ਕੇ ਟੈਸਟ ਕਰੋ। ਸੂਚੀ/ਸਰਚ/ਡਾਊਨਲੋਡ ਏਂਡਪਾਇੰਟ ਵੀ ਪਰਖੋ, ਨਾ ਸਿਰਫ਼ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ।
ਹਰ ਉਹ ਕਾਰਵਾਈ ਜੋ ਡਾਟਾ ਨੂੰ ਮਿਟਾਉਂਦੀ ਜਾਂ ਉਲਟ-ਫੇਰ ਸਕਦੀ ਹੈ ਉਸਨੂੰ ਲਿਸਟ ਕਰੋ: ਡਿਲੀਟ, ਰੀਸੈਟ, ਇੰਪੋਰਟ/ਰਿਪਲੇਸ, ਰੀਬਿਲਡ ਇੰਡੀਕਸ, ਸੀਡ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਵਿਸ਼ਾਲ ਐਡਮਿਨ ਟੂਲ। ਖਤਰਨਾਕ ਐਕਸ਼ਨਾਂ ਲਈ explicit confirmation (type-to-confirm ਵਧੀਆ), ਸਪੀਅਰਡ ਸਕੋਪ (ਇੱਕ ਰਿਕਾਰਡ/ਇੱਕ ਵਰਕਸਪੇਸ), ਲੌਗਿੰਗ ਅਤੇ ਸਾਫ਼-ਡਿਫਾਲਟ (ਡ੍ਰਾਈ-ਰਨ/ਪ੍ਰੀਵਿਊ/ਆਰਕਾਈਵ) ਰੱਖੋ।
ਬਹੁਤ ਸਾਰੇ ਕਾਰੋਬਾਰੀ ਡੈਟਾ ਲਈ ਸੌਫਟ-ਡਿਲੀਟ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਓ। ਇੱਕ ਸਰਲ deleted_at ਫੀਲਡ ਅਤੇ ਫਿਲਟਰਿੰਗ ਅਣਇਚਛਿਤ ਡਾਟਾ ਹਟਾਉਣ ਤੋਂ ਬਾਅਦ ਵੀ ਰੀਕਵਰੀ ਦੀ ਸੁਵਿਧਾ ਦਿੰਦੇ ਹਨ। ਕੇਵਲ ਜ਼ਰੂਰਤ ਹੋਣ 'ਤੇ ਹੀ ਹਾਰਡ-ਡਿਲੀਟ ਵਰਤੋ ਅਤੇ ਰੋਅਬੈਕ ਯੋਜਨਾ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕੋ।
ਡਿਵ ਅਤੇ ਪ੍ਰੋਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖੋ: ਵੱਖ ਡাটਾਬੇਸ, ਵੱਖ ਕੀਜ਼, ਵੱਖ ਬਕੈਟ, ਵੱਖ ਈਮੇਲ ਪ੍ਰੋਵਾਈਡਰ। ਸੀਕ੍ਰੇਟਸ ਕੋਡ/ਕਮਿੱਟ/ਪ੍ਰੰਪਟ ਵਿੱਚ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ — ਤੈਨਾਤ ਸਮੇਂ env vars ਜਾਂ ਸੀਕ੍ਰੇਟ ਮੈਨੇਜਰ ਰਾਹੀਂ ਇੰਜੈਕਟ ਕਰੋ। CORS origins, redirect URLs ਅਤੇ OAuth callbacks ਨੂੰ ਰੀਅਲ ਡੋਮੇਨ ਨਾਲ ਮੈਚ ਕਰੋ। ਪ੍ਰੋਡ ਵਿੱਚ ਲੋਗਿੰਗ ਅਤੇ ਐਰਰ ਰਿਪੋਰਟਿੰਗ ਚਾਲੂ ਰੱਖੋ (ਪਰ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਨਾ ਲੌਗ ਕਰੋ)।
ਇਸਨੂੰ ਸੁਰੱਖਿਆ ਜਾਲ ਸਮਝੋ, ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਸੋਚਣ ਦਾ ਬਦਲ ਨਹੀਂ। ਖਤਰੇ ਵਾਲੇ ਬਦਲਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਨੈਪਸ਼ਾਟ ਬਣਾਓ ਤਾਂ ਜੋ ਰੋਲਬੈਕ ਆਸਾਨ ਹੋਵੇ। ਸਮੀਖਿਆ ਵਿੱਚ ਜੇ ਅਸਲ ਖਤਰਾ ਮਿਲੇ ਤਾਂ ਤੁਰੰਤ ਰੋਲਬੈਕ ਕਰੋ ਅਤੇ ਫਿਰ ਉਹੀ ਬਦਲਾਅ ਬਿਹਤਰ ਸੀਮਾਵਾਂ ਨਾਲ ਮੁੜ-ਜਨਰੇਟ ਕਰੋ।
ਇੱਕ ਮਿੰਟ ਲਈ ਇਹ ਇਕ-ਮਿੰਟ ਦੀ ਸਕੈਨ ਹੈ: ਸਕੀਮਾ ਸਪਸ਼ਟ ਹੈ? ਕੰਸਟਰੈਂਟ ਹਨ? auth ਡਿਫਾਲਟ-ਡਿਨਾਈ ਹੈ ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਚੈਕ ਹਨ? ਨਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ ਅਤੇ ਰੀਕਵਰੀ ਹੈ? ਡਿਵ/ਪ੍ਰੋਡ ਵੱਖਰੇ ਹਨ ਅਤੇ ਸੀਕ੍ਰੇਟ ਸੁਰੱਖਿਅਤ ਹਨ? ਖ਼ਤਰਨਾਕ ਸਭ ਤੋਂ ਬੁਰੀ ਗਲਤੀ ਕੀ ਹੋ ਸਕਦੀ ਹੈ — ਜੇ ਜਵਾਬ ਵਿੱਚ ਡਾਟਾ ਨੁਕਸਾਨ, ਡਾਟਾ ਲੀਕ ਜਾਂ ਪ੍ਰੋਡ ਨੂੰ ਤੋੜਨਾ ਸ਼ਾਮਲ ਹੋਵੇ, ਤਾਂ ਰੋਕੋ।