08 ਜੁਲਾ 2025·8 ਮਿੰਟ
ਡਾਈਕਸਟਰਾ ਅਤੇ ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ: ਉਹ ਅਨੁਸ਼ਾਸਨ ਜੋ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ
Edsger Dijkstra ਦੇ ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੇ ਵਿਚਾਰ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਵੇਂ ਅਨੁਸ਼ਾਸਿਤ, ਸਧਾਰਨ ਕੋਡ ਟੀਮਾਂ, ਫੀਚਰਾਂ ਅਤੇ ਸਿਸਟਮ ਵਧਣ ਦੇ ਨਾਲ ਸਹੀ ਅਤੇ maintainable ਰਹਿੰਦਾ ਹੈ।
Edsger Dijkstra ਦੇ ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਦੇ ਵਿਚਾਰ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਵੇਂ ਅਨੁਸ਼ਾਸਿਤ, ਸਧਾਰਨ ਕੋਡ ਟੀਮਾਂ, ਫੀਚਰਾਂ ਅਤੇ ਸਿਸਟਮ ਵਧਣ ਦੇ ਨਾਲ ਸਹੀ ਅਤੇ maintainable ਰਹਿੰਦਾ ਹੈ।
ਸੌਫਟਵੇਅਰ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਫੇਲ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇਹ ਲਿਖਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਇਹ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ ਕਿ ਇਕ ਸਾਲ ਬਾਅਦ, ਕੋਈ ਵੀ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਨਹੀਂ ਸਕਦਾ।
ਜਦੋਂ ਕੋਡਬੇਸ ਵਧਦੇ ਹਨ, ਹਰ “ਛੋਟੀ” ਸੁਧਾਰ ਰਿਪਲ ਵਾਂਗ ਫੈਲਦਾ ਹੈ: ਇੱਕ ਬੱਗ ਦੂਜੇ ਫੀਚਰ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਨਵੀਂ ਲੋੜ rewrite ਮੰਗਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਰੀਫੈਕਟਰ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਸੁਮੇਟਣਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਮੁਸ਼ਕਲ ਗੱਲ ਕੋਡ ਸ਼ਾਮਲ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਹੈ ਕਿ ਜਿਸ ਵਿਹਾਰ ਨੂੰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਨਿਰੰਤਰ ਕਿਉਂ ਰਹੇ ਜਦੋਂ ਸਭ ਕੁਝ ਬਦਲਦਾ ਹੈ।
Edsger Dijkstra ਦਾ ਦਲੀਲ ਸੀ ਕਿ correctness ਅਤੇ simplicity ਪਹਿਲਾ ਦਰਜੇ ਦੇ ਲਕੜੇ ਹੋਣ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ ਸੁੰਦਰ ਚੀਜ਼ਾਂ। ਨਤੀਜਾ ਅਕੈਡੈਮਿਕ ਨਹੀਂ; ਜਦੋਂ ਸਿਸਟਮ ਸੌਚਣ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਸ਼ੁਰੂਆਤ ਦੇ ਅਗਲ ਕੰਮਾਂ ਲਈ ਘੱਟ ਸਮਾਂ firefighting 'ਚ ਗੁਜ਼ਾਰਦੀਆਂ ਹਨ ਅਤੇ ਵਧੇਰੇ ਸਮਾਂ ਬਣਾਉਣ ਵਿੱਚ ਲਗਾਦੀਆਂ ਹਨ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਸੌਫਟਵੇਅਰ ਨੂੰ “ਸਕੇਲ” ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਅਕਸਰ ਪਰਫਾਰਮੈਂਸ ਦਾ ਜ਼ਿਕਰ ਕਰਦੇ ਹਨ। ਡਾਈਕਸਟਰਾ ਦੀ ਨੁਕਤਾ ਵੱਖਰੀ ਹੈ: ਜਟਿਲਤਾ ਵੀ ਸਕੇਲ ਹੁੰਦੀ ਹੈ।
ਸਕੇਲ ਇਸ ਤਰ੍ਹਾਂ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਆਪਣੀ ਖੁਦ ਦੀ ਮਰਜ਼ੀ ਲਈ ਕਠੋਰ ਹੋਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਐਸਾ ਕੰਟਰੋਲ ਫਲੋ ਅਤੇ ਵਿਭਾਜਨ ਚੁਣੋ ਜੋ ਇਹ ਜਵਾਬ ਦਿੰਦੇ ਹੋਣ:
ਜਦੋਂ ਵਿਹਾਰ ਅਨੁਮਾਨਯੋਗ ਹੁੰਦਾ ਹੈ, ਤਦ ਬਦਲਾਅ ਰੁਟੀਨ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਖਤਰਨਾਕ। ਇੱਥੇ ਹੀ ਡਾਈਕਸਟਰਾ ਦੀ ਮਹੱਤਤਾ ਹੈ: ਉਸਦਾ ਅਨੁਸ਼ਾਸਨ ਵਧਦੇ ਸੌਫਟਵੇਅਰ ਦੀ ਅਸਲੀ ਰੁਕਾਵਟ—ਇਸਨੂੰ ਸਮਝਣ ਦੀ ਸਮਰੱਥਾ—ਤੇ ਨਿਸ਼ਾਨਾ ਲਗਾਉਂਦਾ ਹੈ।
Edsger W. Dijkstra (1930–2002) ਇੱਕ ਡੱਚ ਕੰਪਿਊਟਰ ਸਾਇੰਟਿਸਟ ਸੀ ਜਿਸਨੇ ਭਰੋਸੇਯੋਗ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਦੇ ਤਰੀਕਿਆਂ ਨੂੰ ਰੂਪ ਦਿੱਤਾ। ਉਸਨੇ ਸ਼ੁਰੂਆਤੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ 'ਤੇ ਕੰਮ ਕੀਤਾ, ਕੁਝ ਅਲਗੋਰਿਦਮਾਂ (ਉਸਦੇ ਨਾਮ ਵਾਲਾ shortest-path algorithm ਸ਼ਾਮਿਲ) ਵਿੱਚ ਯੋਗਦਾਨ ਦਿੱਤਾ, ਅਤੇ—ਦੈਨੰਦਿਨ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ—ਇਹ ਵਿਚਾਰ ਦਿੰਦਾ ਰਿਹਾ ਕਿ programming ਉਹ ਚੀਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ 'ਤੇ ਅਸੀਂ ਤਰਕ ਕਰ ਸਕੀਏ, ਨਾ ਕਿ ਸਿਰਫ ਪਰਖੀਏ ਜਦ ਤੱਕ ਇਹ ਕੰਮ ਕਰੇ।
Dijkstra ਲਈ ਇਹ ਮੌੱਦਾ ਨਹੀਂ ਸੀ ਕਿ ਪ੍ਰੋਗ੍ਰਾਮ ਕੁਝ ਉਦਾਹਰਨਾਂ ਲਈ ਸਹੀ ਨਤੀਜਾ ਦੇ ਸਕਦਾ ਹੈ, ਬਲਕਿ ਇਹ ਕਿ ਅਸੀਂ ਇਸਦੀ ਸਹੀਤਾ ਨੂੰ ਵਿਆਖਿਆ ਕਰ ਸਕੀਏ।
ਜੇ ਤੁਸੀਂ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਕੋਡ ਕਿਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਦਲੀਲ ਦੇ ਕੇ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਸਹੀ ਹੈ। ਇਹ ਮਨੋਭਾਵ ਸਾਫ਼-ਪਾਠਯੋਗ, ਸਮੀਖਿਆਯੋਗ ਅਤੇ ਹੀਰੋਇਕ ਡੀਬੱਗਿੰਗ 'ਤੇ ਨਿਰਭਰਤਾ ਘਟਾਉਂਦਾ ਹੈ।
Dijkstra ਦੀਆਂ ਲਿਖਤਾਂ ਕਈ ਵਾਰੀ ਕਠੋਰ ਲੱਗਦੀਆਂ ਹਨ। ਉਸਨੇ “ਚਤੁਰ” ਤਰਕੀਬਾਂ, ਫਿੱਕੀ ਕੰਟਰੋਲ ਫਲੋ ਅਤੇ ਉਹ coding ਅਦੇਤਾਂ criticise ਕੀਤੀਆਂ ਜੋ reasoning ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀਆਂ। ਇਹ ਕਠੋਰਤਾ style policing ਲਈ ਨਹੀਂ ਸੀ; ਇਹ ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਣ ਲਈ ਸੀ। ਜਦੋਂ ਕੋਡ ਦਾ ਅਰਥ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮਨਜ਼ੂਰੀਆਂ 'ਤੇ ਘੱਟ ਵਾਦ-ਵਿਵਾਦ ਕਰਦੇ ਹੋ ਅਤੇ ਵਿਹਾਰ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਗਾਉਂਦੇ ਹੋ।
ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਹ ਅਭਿਆਸ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਕੁਝ ਸਾਦੇ ਕੰਟਰੋਲ ਸਟ੍ਰੱਕਚਰਾਂ—sequence, selection (if/else), ਅਤੇ iteration (loops)—ਦੁਆਰਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਗੁੰਝਲਦਾਰ jumps ਦੁਆਰਾ। ਮਕਸਦ ਸਾਦਾ ਹੈ: ਪ੍ਰੋਗਰਾਮ ਰਾਹ ਨੂੰ ਸਮਝਣਯੋਗ ਬਣਾਉਣਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਯਕੀਨ ਦੇ ਨਾਲ ਵਿਆਖਿਆ, ਰੱਖ-ਰਖਾਅ ਅਤੇ ਬਦਲਾਅ ਕਰ ਸਕੋ।
ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਸੌਫਟਵੇਅਰ ਗੁਣਵੱਤਾ ਨੂੰ “ਤੀਜ਼”, “ਖੂਬਸੂਰਤ” ਜਾਂ “ਫੀਚਰ-ਭਰਪੂਰ” ਵਜੋਂ ਵੇਰਵਾ ਕਰਦੇ ਹਨ। ਉਪਭੋਗਤਾ correctness ਨੂੰ ਵੱਖਰੀ ਢੰਗ ਨਾਲ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ: ਅੱਜ-ਕੱਲ੍ਹ ਐਪ ਉਨ੍ਹਾਂ ਨੂੰ ਹੈਰਾਨ ਨਹੀਂ ਕਰੇਗੀ—ਇਹ ਹੀ ਸ਼ਾਂਤ ਵਿਸ਼ਵਾਸ correctness ਹੈ। ਜੇ correctness ਹੈ ਤਾਂ ਕੋਈ ਨੋਟਿਸ ਨਹੀਂ ਕਰਦਾ; ਜੇ ਇਹ ਨਹੀਂ ਹੈ ਤਾਂ ਹੋਰ ਕੁਝ ਵੀ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਰਹਿੰਦਾ।
“ਹੁਣ ਚੱਲਦਾ ਹੈ” ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੁਝ ਰਸਤੇ ਅਜ਼ਮਾਏ ਅਤੇ ਉਮੀਦ ਅਨੁਸਾਰ ਨਤੀਜਾ ਮਿਲਿਆ। “ਇਹ ਚਲਦਾ ਰਹੇਗਾ” ਮਤਲਬ ਹੈ ਕਿ ਇਹ refactors, ਨਵੀਆਂ ਇੰਟੈਗ੍ਰੇਸ਼ਨ, ਵੱਧ ਭਾਰ ਅਤੇ ਨਵੇਂ ਟੀਮ ਮੈਂਬਰਾਂ ਨੂੰ ਛੇੜਨ ਦੇ ਬਾਵਜੂਦ ਇਰਾਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਰਹੇਗਾ।
ਕੋਈ ਫੀਚਰ “ਹੁਣ ਚੱਲ ਸਕਦਾ ਹੈ” ਪਰ ਫਿਰ ਵੀ ਨਾਜੁਕ ਹੋ ਸਕਦਾ ਹੈ:
Correctness ਦਾ ਮਤਲਬ ਹੈ ਇਨ੍ਹਾਂ ਲੁਕੀਆਂ ਧਾਰਣਾਵਾਂ ਨੂੰ ਹਟਾਉਣਾ—ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਨਾ।
ਇੱਕ ਨੁਕਸਾਨ ਅਕਸਰ ਛੋਟਾ ਨਹੀਂ ਰਹਿੰਦਾ ਜਦੋਂ ਸੌਫਟਵੇਅਰ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਗਲਤ ਸਥਿਤੀ, ਇੱਕ off-by-one boundary, ਜਾਂ ਇੱਕ ਅਸਪਸ਼ਟ error-handling rule ਨਵੇਂ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਨਕਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਹੋਰ ਸਰਵਿਸਜ਼ ਦੁਆਰਾ ਗਿਆ ਜਾਂਦੇ ਹਨ, ਕੈਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਜਾਂ retry ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਸਮੇਂ ਨਾਲ, ਟੀਮਾਂ “ਕੀ ਸੱਚ ਹੈ?” ਪੁੱਛਣਾ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ “ਅਮੂਮਨ ਕੀ ਹੁੰਦਾ ਹੈ?” ਉੱਤੇ ਨਿਰਭਰ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ। ਇੱਥੇ incident response ਇੱਕ ਅਰਕੀਓਲੋਜੀ ਬਣ ਜਾਂਦੀ ਹੈ।
ਗੁਣਾ dependency ਹੈ: ਇੱਕ ਛੋਟੀ ਗਲਤੀਆ ਬਹੁਤ ਸਾਰੇ downstream ਗਲਤੀਆਂ ਬਣ ਜਾਵੇਗੀ, ਹਰ ਇੱਕ ਆਪਣੀ ਅਰਧ-ਸੰਬੰਧੀ ਠੀਕ ਕਰਨ ਨਾਲ।
ਸਪਸ਼ਟ ਕੋਡ correctness ਨੂੰ ਇੰਝ ਸੁਧਾਰਦਾ ਹੈ ਕਿ ਇਹ ਸੰਚਾਰ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ:
Correctness ਮਤਲਬ: ਜੋ ਇਨਪੁੱਟ ਅਤੇ ਸਥਿਤੀਆਂ ਅਸੀਂ ਸਹਾਇਤਾ ਕਰਨ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਾਂ, ਉਨ੍ਹਾਂ ਲਈ ਸਿਸਟਮ ਲਗਾਤਾਰ ਉਹ ਨਤੀਜੇ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਅਸੀਂ ਵਾਅਦਾ ਕਰਦੇ ਹਾਂ—ਅਤੇ ਜਦੋਂ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ ਤਾਂ ਉਹ predictable, explained ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਸਾਦਗੀ ਦਾ ਮਤਲਬ ਕੋਡ ਨੂੰ “ਪਿਆਰਾ” ਜਾਂ ਘੱਟ ਲਾਈਨਾਂ ਵਾਲਾ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਵਿਹਾਰ ਨੂੰ ਅਨੁਮਾਨਯੋਗ, ਵਿਆਖਿਆਯੋਗ ਅਤੇ ਡਰ ਤੋਂ ਬਿਨਾਂ ਸੋਧਣਯੋਗ ਬਣਾਇਆ ਜਾਵੇ। Dijkstra ਸਾਦਗੀ ਨੂੰ ਪ੍ਰਸੱਤ ਕਰਦਾ ਸੀ ਕਿਉਂਕਿ ਇਹ ਪ੍ਰੋਗਰਾਮਾਂ ਬਾਰੇ reasoning ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਂਦੀ ਹੈ—ਖਾਸ ਕਰ ਕੇ ਜਦੋਂ ਕੋਡਬੇਸ ਅਤੇ ਟੀਮ ਵਧਦੇ ਹਨ।
ਸਧਾਰਨ ਕੋਡ ਇੱਕ ਸਮੇਂ 'ਤੇ ਥੋੜੀਆਂ ਹੀ ਵਿਚਾਰਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ: ਸਪਸ਼ਟ ਡੇਟਾ ਫਲੋ, ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ, ਅਤੇ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀਆਂ। ਇਹ ਪੜ੍ਹਨਹਾਰੇ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਰਸਤੇ ਆਪਣੇ ਸਿਰ ਵਿੱਚ ਸਿਮੁਲੇਟ ਕਰਨ ਲਈ ਨਹੀਂ ਮੰਗਦਾ।
ਸਾਦਗੀ ਇਹ ਨਹੀਂ ਹੈ:
ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ ਨਾ ਇਸਲਈ ਕਿ ਡੋਮੇਨ ਖੁਦ ਹੀ ਜਿਆਦਾ ਜਟਿਲ ਹੈ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਅਸੀਂ ਅਣਚਾਹੀ complexity ਜੋੜਦੇ ਹਾਂ: ਝੰਡੇ ਜੋ ਅਣਉਮੀਦ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ, ਖਾਸ-ਮਾਮਲੇ patch ਜੋ ਕਦੇ ਹਟਦੇ ਨਹੀਂ, ਅਤੇ ਪਰਤਾਂ ਜੋ ਪਹਿਲੇ ਫੈਸਲਿਆਂ ਦੇ ਚੱਕਰ ਵਿੱਚ ਮੌਜੂਦ ਹਨ।
ਹਰ ਵਾਧੂ exception ਸਮਝਣ ਤੇ ਇੱਕ ਟੈਕਸ ਜੋੜਦਾ ਹੈ। ਲਾਗਤ ਬਾਅਦ ਵਿੱਚ ਵੇਖਣ ਨੂੰ ਮਿਲਦੀ ਹੈ, ਜਦੋਂ ਕੋਈ ਬੱਗ ਠੀਕ ਕਰਨ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਬਦਲਾਅ ਕਈ ਹੋਰ ਜਗ੍ਹਾਂ ਨੂੰ ਨਾਜੁਕ ਤਰੀਕੇ ਨਾਲ ਤੋੜ ਦਿੰਦਾ ਹੈ।
ਜਦੋਂ ਡਿਜ਼ਾਈਨ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ, ਤਰੱਕੀ steady ਕੰਮ ਦੇ ਰਾਹੀਂ ਆਉਂਦੀ ਹੈ: ਸਮੀਖਿਆਯੋਗ ਬਦਲਾਅ, ਛੋਟੇ diffs, ਅਤੇ ਘੱਟ ਐਮਰਜੈਂਸੀ ਫਿਕਸ। ਟੀਮਾਂ ਨੂੰ ਉਹ “ਹੀਰੋ” ਵਿਕਾਸਕਾਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਜੋ ਹਰ ਇਤਿਹਾਸਕ ਐਜ ਕੇਸ ਨੂੰ ਯਾਦ ਰੱਖਦੇ ਹਨ ਜਾਂ 2 ਵਜੇ ਥਾਂ ਤੇ ਡੀਬੱਗ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਨ। ਬਜਾਏ, ਸਿਸਟਮ ਆਮ ਮਨੁੱਖੀ ਧਿਆਨ ਦੀ ਸਮਰੱਥਾ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਾਉਟਿਕਲ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਲਗਾਤਾਰ exceptions ਜੋੜ ਰਹੇ ਹੋ (“ਜਦ ਤੱਕ…”, “ਇਸ ਨੂੰ ਛੱਡ ਕੇ…”, “ਸਿਰਫ ਇਸ ਕਸਟਮਰ ਲਈ…”), ਤਾਂ ਤੁਸੀਂ ਸੰਭਵ ਤੌਰ ਤੇ accidental complexity ਇਕਠੀ ਕਰ ਰਹੇ ਹੋ। ਓਹਨਾਂ ਹੱਲਾਂ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ ਜੋ branching ਘਟਾਉਂਦੀਆਂ ਹਨ—ਇੱਕ ਇੱਕਸਾਰ ਨਿਯਮ ਪੰਜ ਖਾਸ ਮਾਮਲਿਆਂ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ, ਭਾਵੇਂ ਉਹ ਨਿਯਮ ਸ਼ੁਰੂ ਵਿੱਚ ਥੋੜ੍ਹਾ ਜਿਆਦਾ ਜਨਰਲ ਹੋਵੇ।
ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇਕ ਸਾਦਾ ਵਿਚਾਰ ਹੈ ਜਿਸ ਦੇ ਵੱਡੇ ਨਤੀਜੇ ਹਨ: ਕੋਡ ਐਸਾ ਲਿਖੋ ਕਿ ਉਸਦਾ ਐਕਜ਼ੈਕਿਊਸ਼ਨ ਰਸਤਾ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਹੋਵੇ। ਸਾਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਗਰਾਮ ਤਿੰਨ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ—sequence, selection, ਅਤੇ repetition—ਦੁਆਰਾ ਬਣ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ tangled jumps 'ਤੇ ਨਿਰਭਰ ਹੋਏ।
if/else, switch).for, while).ਜਦੋਂ ਕੰਟਰੋਲ ਫਲੋ ਇਨ੍ਹਾਂ ਸਟ੍ਰੱਕਚਰਾਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਤੌਪ-ਟੂ-ਬੋਟਮ ਪੜ੍ਹ ਕੇ ਸਮਝਾ ਸਕਦੇ ਹੋ ਕਿ ਪ੍ਰੋਗਰਾਮ ਕੀ ਕਰਦਾ ਹੈ, ਬਿਨਾਂ ਫਾਇਲ 'ਚੋਂ “ਟੈਲੀਪੋਰਟ” ਹੋਏ।
ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਮਿਆਰੀ ਹੋਣ ਤੱਕ, ਕਈ ਕੋਡਬੇਸ arbitrary jumps (goto-ਟਾਈਪ) 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਸਨ। ਮੁੱਦਾ ਇਹ ਨਹੀਂ ਕਿ jumps ਸਦਾ ਬੁਰੇ ਹਨ; ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਅਣ-ਪਾਬੰਦ ਜੰਪ execution paths ਨੂੰ ਅਣਪਛਾਤਾ ਬਣਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਪੁੱਛਣ ਲੱਗਦੇ ਹੋ “ਅਸੀਂ ਇੱਥੇ ਕਿਵੇਂ ਪਹੁੰਚੇ?” ਅਤੇ “ਇਸ ਵਾਰੀ ਵਿਵਹਾਰ ਕਿਹੜਾ ਹੈ?”—ਅਤੇ ਕੋਡ ਸਾਫ਼ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।
ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ ਮਨੁੱਖਾਂ ਨੂੰ ਇੱਕ ਸਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਹ ਮਾਡਲ ਉਹੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਡੀਬੱਗਿੰਗ, ਪੂਲ ਰਿਕਵੈਸਟ ਸਮੀਖਿਆ, ਜਾਂ ਜਲਦੀ ਵੇਲੇ ਵਿਹਾਰ ਬਦਲਣ ਲਈ ਭਰੋਸਾ ਕਰਦੇ ਹੋ।
ਜਦੋਂ ਸੰਰਚਨਾ consistent ਹੁੰਦੀ ਹੈ, ਸੋਧ ਹੋਣਾ ਸੁਰੱਖਿਅਤ ਹੋ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ branch ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ branch ਨੂੰ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ, ਜਾਂ ਇੱਕ loop ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਛੁਪੇ exit ਰਸਤੇ ਨੂੰ ਛੱਡ ਦਿੱਤੇ। readability ਸਿਰਫ ਸੁੰਦਰਤਾ ਨਹੀਂ—ਇਹ ਵਿਹਾਰ ਨੂੰ ਯਕੀਨੀ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣ ਦਾ ਆਧਾਰ ਹੈ।
Dijkstra ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਸੀ: ਜੇ ਤੁਸੀਂ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਕਿਉਂ ਸਹੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਚਿੰਤਾ ਘੱਟ ਕਰਕੇ ਇਸਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ। ਤਿੰਨ ਛੋਟੇ reasoning ਟੂਲ ਇਸਨੂੰ ਪ੍ਰਯੋਗਕਾਰੀ ਬਣਾਉਂਦੇ ਹਨ—ਬਿਨਾਂ ਟੀਮ ਨੂੰ ਗਣਿਤੀ ਮਾਹਰ ਬਣਾਏ।
ਇੱਕ invariant ਉਹ ਤੱਥ ਹੈ ਜੋ ਕਿਸੇ ਕੋਡ ਹਿੱਸੇ ਦੌਰਾਨ, ਖਾਸ ਕਰਕੇ ਲੂਪ ਦੇ ਅੰਦਰ, ਸੱਚ ਰਹਿੰਦਾ ਹੈ।
ਉਦਾਹਰਣ: ਤੁਸੀਂ ਕਾਰਟ ਵਿੱਚ ਕੀਮਤਾਂ ਦਾ ਜੋੜ ਰਹੇ ਹੋ। ਇੱਕ ਉਪਯੋਗ invariant ਹੋ ਸਕਦੀ ਹੈ: “total ਹੁਣ ਤੱਕ ਪ੍ਰੋਸੈੱਸ ਕੀਤੇ ਸਾਰੇ ਆਈਟਮਾਂ ਦਾ ਜੋੜ ਦੇ ਬਰਾਬਰ ਹੈ।” ਜੇ ਇਹ ਹਰ ਕਦਮ 'ਤੇ ਸੱਚ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਜਦੋਂ ਲੂਪ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਨਤੀਜਾ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ।
Invariants ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡਾ ਧਿਆਨ ਇਸ 'ਤੇ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਕਦੇ ਨਹੀਂ ਟੁੱਟਣਾ ਚਾਹੀਦਾ, ਨਾ ਕਿ ਸਿਰਫ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇ।
ਇੱਕ precondition ਉਹ ਹੈ ਜੋ ਇੱਕ ਫੰਕਸ਼ਨ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸੱਚ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ। ਇੱਕ postcondition ਉਹ ਹੈ ਜੋ ਫੰਕਸ਼ਨ ਖ਼ਤਮ ਹੋਣ 'ਤੇ ਗਰੰਟੀ ਕਰਦਾ ਹੈ।
ਰੋਜ਼ਾਨਾ ਉਦਾਹਰਣ:
ਕੋਡ ਵਿੱਚ, ਇੱਕ precondition ਹੋ ਸਕਦੀ ਹੈ “input list sorted ਹੈ,” ਅਤੇ postcondition ਹੋ ਸਕਦੀ ਹੈ “output list sorted ਹੈ ਅਤੇ ਉਹੀ ਐਲੀਮੈਂਟਸ ਰੱਖਦੀ ਹੈ ਨਾਲ ਇਕ ਨਵਾਂ ਐਲਮੈਂਟ ਜੋੜਿਆ ਗਿਆ।”
ਜਦੋਂ ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ (ਭਾਵੇਂ ਅਨੁਪਚਾਰਕ) ਲਿਖਦੇ ਹੋ, ਡਿਜ਼ਾਈਨ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ ਕਿ ਫੰਕਸ਼ਨ ਕੀ ਉਮੀਦ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਕੇਂਦਰੀ ਬਣਾਉਂਦੇ ਹੋ।
ਸਮੀਖਿਆ ਵਿੱਚ, ਇਹ ਵਰਤਾਰਿਕ ਵਿਰੋਧ ਨੂੰ style ਤੋਂ ਹਟਾ ਕੇ correctness 'ਤੇ ਲੈ ਜਾਂਦਾ ਹੈ: “ਕੀ ਇਹ ਕੋਡ invariant ਨੂੰ ਬਣਾਈ ਰੱਖਦਾ ਹੈ?” “ਅਸੀਂ precondition ਨੂੰ enforce ਕਰਦੇ ਹਾਂ ਜਾਂ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦੇ ਹਾਂ?”
ਤੁਹਾਨੂੰ ਫੌਰਮਲ ਪ੍ਰਮਾਣਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਸਭ ਤੋਂ ਬੱਗੀ ਲੂਪ ਜਾਂ ਸਭ ਤੋਂ ਜਟਿਲ ਸਟੇਟ ਅਪਡੇਟ ਚੁਣੋ ਅਤੇ ਇਸ ਦੇ ਉਪਰ ਇੱਕ ਇੱਕ-ਲਾਈਨ invariant ਟਿੱਪਣੀ ਜੋੜੋ। ਜਦੋਂ ਕੋਈ ਬਾਅਦ ਵਿੱਚ ਕੋਡ ਸੋਧਦਾ ਹੈ, ਉਹ ਟਿੱਪਣੀ ਇੱਕ ਗਾਰਡਰੇਲ ਵਰਗੀ ਕੰਮ ਕਰਦੀ ਹੈ: ਜੇ ਕੋਈ ਬਦਲਾਅ ਇਸ ਤੱਥ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਤਾਂ ਕੋਡ ਹੁਣ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਰਹਿੰਦਾ।
ਟੈਸਟਿੰਗ ਅਤੇ reasoning ਇੱਕੋ ਹੀ ਨਤੀਜੇ ਵੱਲ ਮਸਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ—ਉਹ ਹੈ ਸੌਫਟਵੇਅਰ ਜਿਸ ਦਾ ਵਿਹਾਰ ਇਛਿਤ ਹੈ—ਪਰ ਉਹ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਟੈਸਟਾਂ ਪ੍ਰਸੰਗਿਕ ਉਦਾਹਰਨਾਂ ਚਲਾ ਕੇ ਸਮੱਸਿਆਵਾਂ ਖੋਜਦੀਆਂ ਹਨ। reasoning logical clarity ਨਾਲ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਰੋਕਦੀ ਹੈ।
ਟੈਸਟ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸੁਰੱਖਿਅਤ ਜਾਲ ਹਨ। ਉਹ regressions ਫੜਦੇ ਹਨ, ਅਸਲ-ਦੁਨੀਆ ਸਿਨਾਰਿਓ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਪੂਰੀ ਟੀਮ ਲਈ ਆਪਰੇਸ਼ਨਲ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦੇ ਹਨ।
ਪਰ ਟੈਸਟ ਸਿਰਫ ਤਰੁੱਟੀਆਂ ਦੀ ਮੌਜੂਦਗੀ ਦਿਖਾ ਸਕਦੇ ਹਨ, ਗੈਰ-ਮੌਜੂਦਗੀ ਨਹੀਂ। ਕੋਈ ਵੀ ਟੈਸਟ ਸੂਟ ਹਰ ਇਨਪੁੱਟ, ਹਰ ਟਾਈਮਿੰਗ ਵਿਰਣ ਅਤੇ ਫੀਚਰਾਂ ਦੇ ਹਰ ਇੰਟਰੈਕਸ਼ਨ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਕਈ “ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ ਚੱਲਦਾ ਹੈ” ਨੁਕਸ ਸਾਨਿਲ ਕੌਂਬੋਜ਼ ਤੋਂ ਆਉਂਦੇ ਹਨ: ਇੱਕ ਨਿਰਾਲਾ ਇਨਪੁੱਟ, অপੂਰਨ ਓਪਰੇਸ਼ਨ ਆਰਡਰ, ਜਾਂ ਉਹ ਸਟੇਟ ਜੋ ਕਈ ਕਦਮਾਂ ਬਾਅਦ ਹੀ ਹੁੰਦੀ ਹੈ।
reasoning ਕੋਡ ਦੀਆਂ ਗੁਣਾਂ ਨੂੰ ਸਾਬਤ ਕਰਨ ਬਾਰੇ ਹੈ: “ਇਹ ਲੂਪ ਸਦਾ ਖਤਮ ਹੁੰਦਾ ਹੈ,” “ਇਹ ਵੈਰੀਏਬਲ ਕਦੇ ਨੈਗੇਟਿਵ ਨਹੀਂ ਹੁੰਦਾ,” “ਇਹ ਫੰਕਸ਼ਨ ਕਦੇ ਗਲਤ ਓਬਜੈਕਟ ਨਹੀਂ ਵਾਪਸ ਕਰਦਾ।” ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਗਿਆ reasoning defect ਦੀਆਂ ਪੂਰੀਆਂ ਵਰਗਾਂ ਨੂੰ ਰੂਲ ਆਊਟ ਕਰ ਸਕਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਬਾਊਂਡਰੀ ਅਤੇ ਐਜ ਕੇਸਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ।
ਮਰਿਆਦਾ ਹੈ ਕੀਤੀ ਜਾਵੇ ਤਾਂ ਪੂਰੇ ਉਤਪਾਦ ਲਈ formal proofs ਆਰਥਿਕ ਨਹੀਂ ਹੁੰਦੇ। reasoning ਸਭ ਤੋਂ ਅੱਛਾ ਤਰੀਕਾ ਹੈ ਜਦੋਂ ਇਹ selective ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ: ਕੋਰ ਅਲਗੋਰਿਦਮ, ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਫਲੋ, ਪੈਸਾ/ਬਿਲਿੰਗ ਲੌਜਿਕ, ਅਤੇ concurrency ਲਈ।
ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਟੈਸਟ ਵਰਤੋ, ਅਤੇ ਜਿੱਥੇ failure ਮਹਿੰਗਾ ਹੈ ਉੱਥੇ deeper reasoning ਲਗਾਓ।
ਟੈਸਟ ਅਤੇ reasoning ਦਰਮਿਆਨ ਦਾ ਪ੍ਰਾਇਗਤ ਪੁਲ ਇਹ ਹੈ ਕਿ ਇਰਾਦਾ executable ਬਣਾਇਆ ਜਾਵੇ:
ਇਹ ਤਕਨੀਕਾਂ ਟੈਸਟ ਦਾ ਸਥਾਨ ਨਹੀਂ ਲੈਂਦੀਆਂ—ਪਰ ਉਹ ਨੈੱਟ ਨੂੰ ਤੰਗ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਧੁੰਦਲੇ ਉਮੀਦਾਂ ਨੂੰ ਜਾਂਚਣਯੋਗ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਬੱਗ ਲਿਖਣਾ ਮੁਸ਼ਕਲ ਅਤੇ ਪਛਾਣਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
“ਚਤੁਰ” ਕੋਡ ਅਕਸਰ ਤੁਰੰਤ ਜੀਤ ਵਾਂਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ: ਘੱਟ ਲਾਈਨਾਂ, ਸੁਜ਼ Наш trick, ਇੱਕ-ਲਾਈਨਰ ਜੋ ਤੁਹਾਨੂੰ ਚਤੁਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। ਪਰ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਚਤੁਰਤਾ ਸਮੇਂ ਤੇ ਜਾਂ ਲੋਕਾਂ ਦੇ ਅਰਸੇ-ਪਾਰ ਨਹੀਂ ਸਕੇਲ ਕਰਦੀ। ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਲੇਖਕ ਟ੍ਰਿਕ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਨਵਾਂ ਟੀਮੀ ਇਹਨੂੰ ਅੱਖਰੀ ਤੌਰ 'ਤੇ ਪੜਦਾ ਹੈ, ਛੁਪੇ assumptions ਨੂੰ ਨਹੀਂ ਵੇਖਦਾ, ਅਤੇ ਇਸਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਵਿਹਾਰ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਇਹ “ਚਤੁਰਤਾ ਕਰਜ਼ਾ” ਹੈ: ਤੁਰੰਤ ਤੇਜ਼ੀ ਖਰੀਦ ਕੇ ਲੰਬੀ ਅਵਧੀ ਦੀ ਸਮਝਦਾਰੀ ਵੇਚ ਦਿੱਤੀ।
Dijkstra ਦੀ ਨੁਕਤਾ ਇਹ ਨਹੀਂ ਸੀ ਕਿ “ਬੋਰਿੰਗ ਕੋਡ ਲਿਖੋ”—ਇਹ ਸੀ ਕਿ ਅਨੁਸ਼ਾਸਨੀ ਬੰਧਨਾਂ ਨਾਲ پروگرام reasoning ਲਈ ਆਸਾਨ ਬਣ ਜਾਂਦੇ ਹਨ। ਟੀਮ 'ਤੇ, ਬੰਧਨ ਫੈਸਲੇ-ਥਕਾਨ ਘੱਟ ਕਰਦੇ ਹਨ। ਜੇ ਹਰ ਕੋਈ ਪਹਿਲਾਂ ਹੀ defaults ਜਾਣਦਾ ਹੈ (ਕਿਵੇਂ ਨਾਮ ਰੱਖਣੇ, ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕੰਢੇ ਰੱਖਣਾ, ਕੀ “ਪੂਰਾ” ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ), ਤਾਂ ਤੁਸੀਂ ਹਰ ਪੂਲ ਰਿਕਵੈਸਟ 'ਚ ਬੇਸਿਕ ਵਿਵਾਦ ਮੁੜ-ਚਰਚਾ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਸਮਾਂ ਫਿਰ ਉਤਪਾਦਕ ਕੰਮ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦਾ ਹੈ।
ਅਨੁਸ਼ਾਸਨ routine ਅਭਿਆਸਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਕੁਝ ਕੰਕ੍ਰੀਟ ਅਭਿਆਸ ਜੋ ਚਤੁਰਤਾ ਕਰਜ਼ਾ ਰੋਕਦੇ ਹਨ:
calculate_total() ਨੂੰ do_it() ਉੱਤੇ ਤਰਜੀਹ ਦਿਓ)।ਅਨੁਸ਼ਾਸਨ perfection ਬਾਰੇ ਨਹੀਂ—ਇਹ ਅਗਲੇ ਬਦਲਾਅ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਣ ਬਾਰੇ ਹੈ।
ਮੋਡੀਊਲਰਟੀ ਸਿਰਫ “ਫਾਈਲਾਂ ਵਿੱਚ ਵੰਡਣਾ” ਨਹੀਂ ਹੈ। ਇਹ ਫੈਸਲਿਆਂ ਨੂੰ ਸਪਸ਼ਟ ਸਰਹੱਦਾਂ ਦੇ ਪਿੱਛੇ ਲੁਕਾਉਣ ਬਾਰੇ ਹੈ, ਤਾਂ ਜੋ ਸਿਸਟਮ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਨੂੰ ਅੰਦਰਲੇ ਵਿਵਰਣਾਂ ਦੀ ਚਿੰਤਾ ਨਾ ਹੋਵੇ। ਇੱਕ ਮੋਡੀਊਲ ਗੰਦੇ ਹਿੱਸਿਆਂ—ਡੇਟਾ ਸਟ੍ਰਕਚਰ, ਐਜ ਕੇਸ, ਪਰਫਾਰਮੈਂਸ ਟ੍ਰਿਕ—ਨੂੰ ਛੁਪਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ ਛੋਟਾ, ਸਥਿਰ surface ਉਪਲਬਧ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਬਦਲਾਅ ਆਉਂਦਾ ਹੈ, ਆਦਰਸ਼ ਨਤੀਜਾ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਇੱਕ ਮੋਡੀਊਲ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਅਪਰਿਵੱਤ ਰਹਿੰਦਾ ਹੈ। ਇਹੀ “ਚੇਂਜ ਨੂੰ ਸਥਾਨਕ ਰੱਖਣ” ਦਾ ਅਰਥ ਹੈ। ਸਰਹੱਦ Coupling ਰੋਕਦੇ ਹਨ—ਜਿੱਥੇ ਇੱਕ ਅਪਡੇਟ ਚਾਪੜੀ ਤੌਰ 'ਤੇ ਤਿੰਨ ਹੋਰ ਫੀਚਰ ਤੋੜ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੇ assumptions ਸਾਂਝੀਆਂ ਕੀਤੀਆਂ ਹਨ।
ਇੱਕ ਚੰਗੀ ਸਰਹੱਦ reasoning ਨੂੰ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਹਿ ਸਕੋ ਕਿ ਇੱਕ ਮੋਡੀਊਲ ਕੀ ਗਾਰੰਟੀ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮ ਬਾਰੇ ਬਿਨਾਂ ਉਸ ਦੀ ਪੂਰੀ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਨੂੰ ਫਿਰ-ਫਿਰ ਪੜ੍ਹਨ ਦੇ ਤਰਕ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਇੰਟਰਫੇਸ ਇੱਕ ਵਾਅਦਾ ਹੁੰਦਾ ਹੈ: “ਇਨ੍ਹਾਂ ਇਨਪੁੱਟਾਂ ਦੇ ਹੇਠ, ਮੈਂ ਇਹ ਆਊਟਪੁੱਟ ਦਿਆਂਗਾ ਅਤੇ ਇਹ ਨਿਯਮ ਬਰਕਰਾਰ ਰੱਖਾਂਗਾ।” ਜਦੋਂ ਉਹ ਵਾਅਦਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਸਮਾਂਨੁਕੂਲ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ:
ਇਹ ਕਿਸੇ ਬਿਊਰੋਕਰੇਸੀ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਸਮਨੁਵੀਕਰਨ ਪੁਆਇੰਟ ਬਣਾਉਣ ਬਾਰੇ ਹੈ।
ਤੁਹਾਨੂੰ ਵੱਡੀ वास्तਵਿਕਤਾ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਨਹੀਂ:
ਚੰਗੀ ਤਰ੍ਹਾਂ ਰੇਖਾਂਤ ਸਰਹੱਦ “ਚੇਂਜ” ਨੂੰ ਸਿਸਟਮ-ਵਿਆਪਕ ਘਟਨਾ ਤੋਂ ਇੱਕ ਸਥਾਨਕ ਸੋਧ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਜਦੋਂ ਸੌਫਟਵੇਅਰ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਸਭ ਕੁਝ ਆਪਣੇ ਸਿਰ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ। ਸਕੇਲ ਤੇ, ਇਹ ਸਹੀ ਨਹੀਂ ਰਹਿੰਦਾ—ਅਤੇ failure modes ਜਾਣੇ-ਪਛਾਣੇ ਹੋ ਜਾਂਦੇ ਹਨ।
ਆਮ ਲਛਣ ਇਸ ਤਰ੍ਹਾਂ ਹਨ:
Dijkstra ਦੀ ਮੁੱਖ ਸੋਚ ਇਹ ਸੀ ਕਿ ਮਨੁੱਖ ਹੀ ਰੁਕਾਵਟ ਹਨ। ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ, ਛੋਟੇ ਵਧੀਆ-ਪਰਿਭਾਸ਼ਤ ਯੂਨਿਟ, ਅਤੇ ਐਸਾ ਕੋਡ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ reasoning ਕਰ ਸਕਦੇ ਹੋ aesthetic ਚੋਣਾਂ ਨਹੀਂ—ਇਹ ਸਮਰੱਥਾ ਵਧਾਉਣ ਵਾਲੇ ਹਨ।
ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ, ਸੰਰਚਨਾ ਸਮਝਣ ਲਈ ਇੱਕ ਕਿਸਮ ਦੀ ਸੰਕੋਚਣ ਵਾਂਗ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਫੰਕਸ਼ਨਾਂ ਦੇ ਸਪਸ਼ਟ ਇਨਪੁੱਟ/ਆਊਟਪੁੱਟ ਹਨ, ਮੋਡੀਊਲਾਂ ਦੀਆਂ ਸਰਹੱਦਾਂ ਤੁਹਾਨੂੰ ਨਾਮ ਦੇ ਕੇ ਸਨਮੁੱਖ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ “happy path” ਹਰ ਐਜ ਕੇਸ ਨਾਲ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਜ਼ ਘੱਟ ਸਮਾਂ ਨਿਰੁਪਣ ਕਰਕੇ ਅਤੇ ਵਧੇਰੇ ਸਮਾਂ ਇਰਾਦੇ ਨਾਲ ਬਦਲਾਅ ਕਰਨ ਵਿੱਚ ਗੁਜ਼ਾਰਦੇ ਹਨ।
ਜਿਵੇਂ ਟੀਮਾਂ ਵਧਦੀਆਂ ਹਨ, ਸੰਚਾਰ ਦੀ ਲਾਗਤ line count ਦੇ ਮੁਕਾਬਲੇ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀ ਹੈ। ਅਨੁਸ਼ਾਸਤ, ਪੜ੍ਹਨਯੋਗ ਕੋਡ tribal knowledge ਦੀ ਲੋੜ ਘੱਟ ਕਰਦਾ ਹੈ।
ਇਹ ਤੁਰੰਤ onboarding 'ਚ ਦਰਸਾਈ ਦਿੰਦਾ ਹੈ: ਨਵੇਂ ਇੰਜੀਨੀਅਰ predictable patterns ਫੋਲੋ ਕਰ ਸਕਦੇ ਹਨ, ਥੋੜ੍ਹੀਆਂ conventions ਸਿੱਖ ਕੇ ਬਿਨਾਂ ਲੰਮੇ “gotchas” ਟੂਰ ਦੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਾਅ ਕਰ ਸਕਦੇ ਹਨ। ਕੋਡ ਖ਼ੁਦ ਸਿਸਟਮ ਨੂੰ ਸਿਖਾਉਂਦਾ ਹੈ।
ਇੱਕ incident ਦੌਰਾਨ, ਸਮਾਂ ਘੱਟ ਅਤੇ ਭਰੋਸਾ ਕਮਜ਼ੋਰ ਹੁੰਦਾ ਹੈ। explicit assumptions (preconditions), ਮਾਯਨੇ ਰੱਖਣ ਵਾਲੇ checks, ਅਤੇ ਸਿੱਧੇ ਕੰਟਰੋਲ ਫਲੋ ਵਾਲਾ ਕੋਡ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ pressure ਹੇਠ ਟਰੇਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਜਿਵੇਂ ਹੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਹੈ, ਅਨੁਸ਼ਾਸਤ ਬਦਲਾਅ undo ਕਰਨ ਲਈ ਵੀ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। ਛੋਟੇ, ਸਥਾਨਕ ਸੋਧ ਅਤੇ ਸਪਸ਼ਟ ਸਰਹੱਦ rollback ਵੇਲੇ ਨਵੇਂ failures ਦੇ ਚਾਂਸ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਨਤੀਜਾ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ—ਇਹ ਘੱਟ ਹੈਰਾਨੀਆਂ, ਤੇਜ਼ recovery, ਅਤੇ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਹੈ ਜੋ ਸਾਲਾਂ ਅਤੇ ਯੋਗਦਾਨਕਾਰਾਂ ਦੇ ਇਕੱਠੇ ਹੋਣ ਨਾਲ maintain ਰਹਿੰਦਾ ਹੈ।
Dijkstra ਦੀ ਗੱਲ ਇਹ ਨਹੀਂ ਸੀ ਕਿ “ਪੁਰਾਣੇ ਢੰਗ ਨਾਲ ਕੋਡ ਲਿਖੋ।” ਇਹ ਸੀ “ਉਹ ਕੋਡ ਲਿਖੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਿਆਖਿਆ ਕਰ ਸਕੋ।” ਤੁਸੀਂ ਇਹ ਮਨੋਭਾਵ ਅਪਣਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਫੀਚਰ ਨੂੰ formal proof ਵਿੱਚ ਬਦਲੇ।
ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਚੋਣਾਂ ਨਾਲ reasoning ਸਸਤਾ ਬਣਾਓ:
ਇੱਕ ਵਧੀਆ heuristics: ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਇੱਕ ਫੰਕਸ਼ਨ ਕੀ guarantee ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਬਹੁਤ ਕੁਝ ਕਰ ਰਿਹਾ ਹੈ।
ਤੁਹਾਨੂੰ ਵੱਡੇ ਰੀਫੈਕਟਰ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ:
isEligibleForRefund)।ਇਹ ਅਪਗਰੇਡ ਇੰਕ੍ਰੀਮੈਂਟਲ ਹਨ: ਉਹ ਅਗਲੇ ਬਦਲਾਅ ਲਈ cognitive load ਘਟਾਉਂਦੇ ਹਨ।
ਸਮੀਖਿਆ ਜਾਂ ਲਿਖਦੇ ਸਮੇਂ ਪੂਛੋ:
ਜੇ ਸਮੀਖਿਆਕ ਤੁਰੰਤ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਕੋਡ hidden dependencies ਦਾ ਸਿਗਨਲ ਦੇ ਰਿਹਾ ਹੈ।
ਉਹ ਟਿੱਪਣੀਆਂ ਜੋ ਸਿਰਫ਼ ਕੋਡ ਨੂੰ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ ਜਲਦੀ outdated ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਬਣਾ ਦਿਓ ਕਿਉਂ ਕੋਡ ਸਹੀ ਹੈ: ਮੁੱਖ assumptions, edge cases ਜਿਹਨਾਂ ਦੀ ਤੁਸੀਂ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਕੀ ਟੁੱਟੇਗਾ ਜੇ ਇਹ assumptions ਬਦਲ ਜਾਵੇ। ਇੱਕ ਛੋਟੀ ਟਿੱਪਣੀ ਜਿਵੇਂ “Invariant: total ਸਦਾ processed items ਦੇ ਜੋੜ ਦੇ ਬਰਾਬਰ ਹੈ” ਇੱਕ ਲੰਬੀ ਵਰਣਨਾ ਨਾਲੋਂ ਵਧੇਰੇ ਕੀਮਤੀ ਹੋ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ ਆਦਤਾਂ ਇਕ ਥਾਈਂ ਇਕੱਠਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ shared checklist ਵਿੱਚ ਰੱਖੋ (ਵਿੱਚ ਵੇਖੋ /blog/practical-checklist-for-disciplined-code).
ਕਿਉਂਕਿ ਜਦੋਂ ਕੋਡਬੇਸ ਵੱਡੇ ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਮੁੱਖ ਰੁਕਾਵਟ ਸਮਝ ਬਣ ਜਾਂਦੀ ਹੈ—ਨਾ ਕਿ ਸਿਰਫ ਟਾਈਪ ਕਰਨਾ। ਡਾਈਕਸਟਰਾ ਦਾ zor predictable control flow, ਸਪਸ਼ਟ contracts, ਅਤੇ correctness ਉਤੇ ਹੈ, ਜੋ ਘੱਟ-ਖੇਡ-ਵਾਲੀ ਘਲਤੀਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਟੀਮਾਂ ਦੀ ਰਫਤਾਰ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਇੱਥੇ “ਸਕੇਲ” ਦਾ ਮਤਲਬ ਪ੍ਰਦਰਸ਼ਨ ਤੋਂ ਘੱਟ ਅਤੇ ਜਟਿਲਤਾ ਦੇ ਬੂਝਣ ਤੋਂ ਵੱਧ ਹੈ:
ਇਹ ਤੱਤ reasoning ਅਤੇ ਪੂਰਵਾਨੁਮਾਨ ਨੂੰ cleverness ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਬਣਾਉਂਦੇ ਹਨ।
ਸੰਰਚਿਤ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇੱਕ ਛੋਟੀ ਗਿਣਤੀ ਦੇ ਸਾਫ਼ ਕੰਟਰੋਲ ਸਟ੍ਰੱਕਚਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ:
if/else, switch)for, while)ਮਕਸਦ ਕਠੋਰਤਾ ਨਹੀਂ—ਪਰ ਐਕਜ਼ੈਕਿਊਸ਼ਨ ਰਸਤੇ ਨੂੰ ਸਮਝਣ ਯੋਗ ਬਣਾਉਣਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਵਿਹਾਰ ਨੂੰ ਵਿਆਖਿਆ ਕਰ ਸਕੋ, ਬਦਲ ਸਕੋ ਅਤੇ ਡੀਬੱਗ ਕਰ ਸਕੋ ਬਿਨਾਂ ਕੋਡ ਵਿੱਚ “ਟੈਲੀਪੋਰਟ” ਕਰਨ ਤੋਂ।
ਮੁੱਦਾ ਅਣ-ਸੀਮਤ ਜੰਪਾਂ ਵਿੱਚ ਹੈ ਜੋ execution paths ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਪਛਾਤਾ ਅਤੇ state ਨੂੰ ਅਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਕੰਟਰੋਲ ਫਲੋ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਵਿਕਾਸਕਾਰ ਬੁਨਿਆਦੀ ਸਵਾਲ ਪੁੱਛਣ ਵਿੱਚ ਸਮਾਂ ਗੁੰਮ ਕਰਦੇ ਹਨ—“ਅਸੀਂ ਇੱਥੇ ਕਿਵੇਂ ਪਹੁੰਚੇ?” ਅਤੇ “ਇਸ ਵੇਲੇ ਕਿਸ ਸਟੇਟ ਵਿੱਚ ਵੈਰੀਏਬਲ ਹੈ?”—ਅਤੇ ਕੋਡ ਸਾਫ਼ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।
ਆਧੁਨਿਕ ਸਮਾਨ ਹਨ ਤੇਜ਼ nested branching, scattered early exits, ਅਤੇ ਗੁਪਤ state ਬਦਲਾਅ ਜੋ ਵਿਹਾਰ ਨੂੰ ਟ੍ਰੇਸ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ।
Correctness ਉਹ “ਚੁੱਪ ਚੀਜ਼” ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਭਰੋਸਾ ਕਰਦੇ ਹਨ: ਸਿਸਟਮ ਲਗਾਤਾਰ ਉਹੀ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ ਜੋ ਅਸੀਂ ਵਾਅਦਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਜਦੋਂ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ ਤਾਂ voorspelbare ਅਤੇ explained ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਇਹ ਫਰਕ ਹੈ “ਕੁਝ ਉਦਾਹਰਨਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਅਤੇ “refactors, integrations ਅਤੇ edge cases ਦੇ ਬਾਵਜੂਦ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ” ਦੇ ਵਿਚਕਾਰ।
ਗਲਤੀਆਂ dependency ਦੁਆਰਾ ਵਧਦੀਆਂ ਹਨ। ਇੱਕ ਛੋਟੀ ਗਲਤ ਸਥਿਤੀ ਜਾਂ ਬਾਊਂਡਰੀ ਬੱਗ ਨਕਲ ਹੁੰਦੀ ਹੈ, ਕੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ, retry ਹੁੰਦੀ ਹੈ ਜਾਂ ਹੋਰ ਸੇਵਾਾਂ ਦੇ ਦੁਆਰਾ ਵਰਕਾਰਾਉਂਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਮੇਂ ਨਾਲ, ਟੀਮਾਂ “ਕੀ ਸੱਚ ਹੈ?” ਪੁੱਛਣਾ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ “ਆਮ ਤੌਰ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ?” ਉੱਤੇ ਆਧਾਰਿਤ ਕੰਮ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ—ਇਸ ਨਾਲ incidents archaeology ਵਰਗੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਬਦਲਾਅ ਜੋਖਿਮ ਭਰੇ ਬਣ ਜਾਂਦੇ ਹਨ।
ਸਾਦਗੀ ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਸਮੇਂ 'ਤੇ ਥੋੜੀਆਂ ਹੀ ਸੋਚਾਂ—ਸਾਫ਼ ਡੇਟਾ ਫਲੋ, ਸਾਫ਼ ਕੰਟਰੋਲ ਫਲੋ, ਅਤੇ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀਆਂ। ਇਹ ਲਾਈਨਾਂ ਘੱਟ ਕਰਨ ਜਾਂ ਕੋਈ ਚਤੁਰ ਇੱਕ-ਲਾਈਨਰ ਲਈ ਨਹੀਂ ਹੈ।
ਇੱਕ ਚੰਗਾ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਕੀ ਵਿਹਾਰ ਅਨੁਮਾਨਤ ਰਿਹਾ? ਜੇ ਹਰ ਨਵੀਂ ਕੇਸ ਨਾਲ “ਸਿਵਾਏ…” ਨਿਯਮ ਵੱਧਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ accidental complexity ਜਮ੍ਹਾ ਕਰ ਰਹੇ ਹੋ।
ਇਨਵੈਰੀਅੰਟ ਉਹ ਤੱਥ ਹੈ ਜੋ ਇੱਕ ਲੂਪ ਜਾਂ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦੌਰਾਨ ਸੱਚ ਰਹਿੰਦਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਲਈ ਇੱਕ ਹਲਕਾ ਤਰੀਕਾ:
total ਪ੍ਰੋਸੈੱਸ ਕੀਤੇ ਆਈਟਮਾਂ ਦਾ ਜੋੜ ਹੈ”)ਇਸ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਹੋਣ ਵਾਲੀਆਂ ਸੋਧਾਂ ਸੁਰੱਖਿਅਤ ਹੋ ਜਾਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਜਾਣਦਾ ਹੈ ਕਿ ਕੀ ਨਹੀਂ ਟੁੱਟ ਸਕਦਾ।
ਟੈਸਟ bugs ਲੱਭਦੇ ਹਨ ਤੇ ਉਦਾਹਰਣ ਚਲਾ ਕੇ ਦਿਖਾਉਂਦੇ ਹਨ; reasoning ਕੁਝ ਗਲਤੀਆਂ ਦੇ ਪੂਰੇ ਵਰਗਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤਰਕ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ। ਟੈਸਟ ਹਰ ਇਨਪੁੱਟ ਜਾਂ ਟਾਈਮਿੰਗ ਕਂਬੋ ਕਵਰ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਅਤੇ practical ਮਿਲਾਪ: ਵਿਆਪਕ ਟੈਸਟ + ਟਰਗੇਟਡ assertions + ਸੰਵੇਦਨਸ਼ੀਲ ਲੌਜਿਕ ਲਈ ਸਪਸ਼ਟ preconditions/postconditions।
ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕਦਮ ਸ਼ੁਰੂ ਕਰੋ ਜੋ cognitive load ਘਟਾਉਂਦੇ ਹਨ:
ਇਹ incremental “structure upgrades” ਬਿਨਾਂ rewrite ਦੇ ਅਗਲੇ ਬਦਲਾਵ ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦੀਆਂ ਹਨ।