𝗦𝗽𝗲𝗰 𝗗𝗲𝗯𝘁 𝒖𝒅ੋਂ 𝒈𝒂𝒂𝒚𝒊𝒃 𝒏𝒂𝒉𝒊 𝒉𝒐𝒏𝒅𝒂 𝒋𝒂𝒅𝒐 𝒕𝒖𝒔𝒉𝒊 𝒊𝒔𝒔𝒖𝒏𝒖 𝒕𝒉𝒆𝒆𝒌 𝒌𝒂𝒓𝒅𝒆 𝒉𝒐। ਇਹ ਸਿਰਫ਼ ਇੱਕ ਥਾਂ ਤੋਂ ਦੂਜੀ ਥਾਂ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਕਿਸੇ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲ ਉਹ ਹਮੇਸ਼ਾ ਖ਼ਤਮ ਨਹੀਂ ਹੁੰਦੀ। ਕਈ ਵਾਰ, ਤੁਸੀਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਕਿਸੇ ਹੋਰ ਜਗ੍ਹਾ ਤਬਦੀਲ ਕਰ ਦਿੰਦੇ ਹੋ।

ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ spec debt ਲੱਭਣ ਲਈ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦਾ ਆਡਿਟ ਕੀਤਾ। ਇਹ ਹਦਾਇਤਾਂ ਵਿੱਚ ਉਹ ਕਮੀਆਂ ਹਨ ਜੋ ਬੱਗ (bugs) ਜਾਂ ਮਾੜੇ AI ਵਿਵਹਾਰ ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ। ਮੈਂ ਸੱਤ ਖਾਸ ਚੀਜ਼ਾਂ ਨੂੰ ਠੀਕ ਕੀਤਾ। ਠੀਕ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਟੈਸਟ ਪਾਸ ਹੋ ਗਏ। ਸਭ ਕੁਝ ਸਹੀ (green) ਲੱਗ ਰਿਹਾ ਸੀ।

ਪਰ ਉਹ debt ਗਾਇਬ ਨਹੀਂ ਹੋਇਆ। ਇਹ feature files ਤੋਂ step definitions ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਗਿਆ।

ਇੱਥੇ ਉਹ ਹੈ ਜੋ ਮੈਂ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਤੋਂ ਸਿੱਖਿਆ:

  • ਸਟੀਕਤਾ (Precision) ਮਹੱਤਵਪੂਰਨ ਹੈ। "the response is fast" ਕਹਿਣ ਦੀ ਬਜਾਏ, "the response returns within 12 seconds of the order submission" ਕਹੋ। ਇਹ ਸਮੇਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ।
  • ਅਸਪਸ਼ਟਤਾ ਤੋਂ ਬਚੋ। "Retried 2 times" ਅਸਪਸ਼ਟ ਹੈ। ਕੀ ਇਸਦਾ ਮਤਲਬ ਕੁੱਲ 2 ਕੋਸ਼ਿਸ਼ਾਂ ਹੈ ਜਾਂ 3? ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ "no more than 2 charge requests total" ਦੀ ਵਰਤੋਂ ਕਰੋ।
  • ਮਕੈਨਿਜ਼ਮ (mechanism) ਦਾ ਨਾਮ ਲਓ। "the inventory is released" ਕਹਿਣਾ ਅਸਪਸ਼ਟ ਹੈ। ਦੱਸੋ ਕਿ "the inventory service receives a release request for item X।"
  • ਗਲਤ ਭਰੋਸੇ ਹਟਾਓ। ਜੇਕਰ ਕੋਈ ਸਟੈਪ ਇਸ ਲਈ ਪਾਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਫੀਚਰ ਅਜੇ ਤੱਕ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਸ ਸਟੈਪ ਨੂੰ ਹਟਾ ਦਿਓ। ਕਿਸੇ ਗੈਰ-ਮੌਜੂਦ ਫਲੋ (flow) ਲਈ ਪਾਸ ਹੋਣ ਵਾਲਾ ਟੈਸਟ ਇੱਕ ਝੂਠ ਹੈ।
  • "ਸਹੀ" (correct) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਬਿਨਾਂ ਸਖ਼ਤ ਵੈਲਯੂਜ਼ (hard values) ਦੇ ਕਦੇ ਵੀ "correct" ਜਾਂ "proper" ਵਰਗੇ ਸ਼ਬਦਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। "contains the right id" ਦੀ ਬਜਾਏ "contains order_id 123" ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਮੈਂ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਇੱਕ ਫਰੇਮਵਰਕ ਬਣਾਇਆ ਹੈ। ਹਰ ਸੀਨਾਰੀਓ ਲਈ ਇਹ ਪੰਜ ਸਵਾਲ ਪੁੱਛੋ:

  • ਇਸ ਸੀਨਾਰੀਓ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ?
  • ਇਹ ਕਿਹੜੇ ਫੈਸਲੇ ਅਧੂਰੇ ਛੱਡਦਾ ਹੈ?
  • ਕੀ ਇੱਥੇ ਸਾਰੇ ਸ਼ਬਦ ਪਰਿਭਾਸ਼ਿਤ ਹਨ?
  • ਕੀ ਇਹ ਵਿਵਹਾਰ (behavior) ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜਾਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (implementation) ਦਾ?
  • ਇਸ ਵਰਣਨ ਵਿੱਚ ਕੀ ਗੁੰਮ ਹੈ?

ਸਭ ਤੋਂ ਵੱਡਾ ਜਾਲ ਟੈਕਸਟ ਅਤੇ ਕੋਡ ਵਿਚਕਾਰਲੀ ਦੂਰੀ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ spec ਵਿੱਚ ਇੱਕ ਸੰਪੂਰਨ, ਸਟੀਕ ਹਦਾਇਤ ਲਿਖ ਸਕਦੇ ਹੋ। ਪਰ ਜੇਕਰ ਤੁਹਾਡਾ ਅੰਡਰਲਾਈਂਗ ਕੋਡ ਉਸ ਟੈਸਟ ਨੂੰ ਪਾਸ ਕਰਨ ਲਈ ਕੋਈ ਸ਼ਾਰਟਕੱਟ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਵੀ debt ਹੈ।

spec ਕਹਿੰਦਾ ਹੈ "create an order via API।" ਕੋਡ ਅਸਲ ਵਿੱਚ ਸਮਾਂ ਬਚਾਉਣ ਲਈ ਸਿੱਧਾ ਡਾਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਆਰਡਰ ਇੰਜੈਕਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਟੈਸਟ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ, ਪਰ debt ਲੋੜ (requirement) ਤੋਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (implementation) ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਪਹਿਲੀ ਵਾਰ ਵਿੱਚ ਹੀ ਸੰਪੂਰਨ spec ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ, ਉਹਨਾਂ ਦਾ ਆਡਿਟ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।

Source: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25

Optional learning community: https://t.me/GyaanSetuAi