ਕੋਡ ਦੀ ਸਭ ਤੋਂ ਵਧੀਆ ਲਾਈਨ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਲਿਖਦੇ ਹੀ ਨਹੀਂ। ਇਹ ਵਿਚਾਰ ਆਲਸ ਲਈ ਇੱਕ ਬਹਾਨੇ ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ਦੇ ਉਤਸ਼ਾਹ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਵਿੱਚ ਕੁਝ ਸਾਲ ਨਹੀਂ ਬਿਤਾ ਲੈਂਦੇ। ਸਾਫਟਵੇਅਰ ਲਿਖਣਾ ਉਸਾਰੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਬਾਗਬਾਨੀ ਵਾਂਗ ਵਧੇਰੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਇਸਨੂੰ ਇਕੱਲਾ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ, ਤਾਂ ਬਾਗ ਚਾਹੇ ਤੁਸੀਂ ਚਾਹੋ ਜਾਂ ਨਾ, ਵਧਦਾ ਹੀ ਹੈ। ਕੋਡ ਵੀ ਇਹੀ ਕਰਦਾ ਹੈ। ਅਸਲੀ ਕਲਾ ਇਹ ਜਾਣਨ ਵਿੱਚ ਹੈ ਕਿ ਬੀਜ ਕਦੋਂ ਬੀਜਣੇ ਬੰਦ ਕਰਨੇ ਹਨ।
ਤੁਹਾਡਾ ਕੋਡ ਇੱਕ ਦੇਣਦਾਰੀ (Liability) ਹੈ
ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਿਖੀ ਗਈ ਹਰ ਲਾਈਨ ਲਗਾਤਾਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਬਣਾਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਦੇਰ ਰਾਤ ਕਿਸੇ ਘਟਨਾ (incident) ਦੌਰਾਨ ਦੁਬਾਰਾ ਪੜ੍ਹੋਗੇ। ਤੁਸੀਂ ਇਸਦਾ ਟੈਸਟ ਉਦੋਂ ਕਰੋਗੇ ਜਦੋਂ ਤੁਹਾਡਾ framework ਇੱਕ ਮਾਈਨਰ ਵਰਜ਼ਨ ਅਪਡੇਟ ਜਾਰੀ ਕਰਦਾ ਹੈ ਜੋ string handling ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਉਦੋਂ ਡੀਬੱਗ (debug) ਕਰੋਗੇ ਜਦੋਂ production ਤੋਂ ਆਉਣ ਵਾਲੇ logs ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਨਿਕਲਦਾ। ਤੁਸੀਂ ਇਸਨੂੰ ਉਸ ਸਾਥੀ ਨੂੰ ਸਮਝਾਓਗੇ ਜੋ ਪਿਛਲੇ ਹਫ਼ਤੇ ਹੀ ਸ਼ਾਮਲ ਹੋਇਆ ਹੈ, ਜਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਬਾਰਾਂ ਮਹੀਨਿਆਂ ਬਾਅਦ ਜਦੋਂ ਉਸਦਾ ਸੰਦਰਭ (context) ਖਤਮ ਹੋ ਚੁੱਕਾ ਹੋਵੇਗਾ।
ਇਹ ਗੁੰਝਲਦਾਰ ਹੋਣ ਦੇ ਪੱਖ ਵਿੱਚ ਕੋਈ ਦਲੀਲ ਨਹੀਂ ਹੈ। ਇਹ ਜਿਓਮੈਟਰੀ (geometry) ਹੈ। ਬੱਗਸ (Bugs) ਨੂੰ ਲੁਕਣ ਲਈ ਜਗ੍ਹਾ ਚਾਹੀਦੀ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡਾ 'surface area' ਜਿੰਨਾ ਛੋਟਾ ਹੋਵੇਗਾ, ਅਸਫਲਤਾ ਦੇ ਵੜਨ ਲਈ ਉੱਥੇ ਉੱน้อย ਮੌਕੇ ਹੋਣਗੇ। ਅੱਸੀ ਲਾਈਨਾਂ ਅਤੇ ਛੇ nested conditions ਵਾਲਾ ਇੱਕ function ਨਾ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ; ਸਗੋਂ ਇਸਦੀ ਅਸਫਲਤਾ ਦੀ ਸੰਭਾਵਨਾ ਵੀ ਅੰਕੜਿਆਂ ਅਨੁਸਾਰ ਵਧੇਰੇ ਹੁੰਦੀ ਹੈ। ਸੰਜਮ (Restraint) ਦਾ ਮਤਲਬ ਕੋਸ਼ਿਸ਼ ਦੀ ਘਾਟ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਗੱਲ ਦੀ ਪਛਾਣ ਹੈ ਕਿ ਅਣਲਿਖੇ ਕੋਡ ਵਿੱਚ ਕੋਈ ਵੀ 결함 (defect) ਨਹੀਂ ਹੁੰਦਾ।
ਜਦੋਂ ਚਲਾਕੀ ਇੱਕ ਟੈਕਸ ਬਣ ਜਾਂਦੀ ਹੈ
ਕੁਝ ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਨਾਲ ਆਰਡਰ ਦੇ ਕੁੱਲ ਜੋੜ ਦੀ ਗਣਨਾ ਕਰਨ ਦੇ ਕੰਮ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ: ਡਿਸਕਾਊਂਟ ਲਾਗੂ ਕਰਨਾ, ਟੈਕਸਯੋਗ ਵਸਤੂਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ, ਅਤੇ ਹਟਾਈਆਂ ਗਈਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਛੱਡਣਾ। ਇੱਕ ਡਿਵੈਲਪਰ ਇੱਕ ਸਿੰਗਲ expression ਲਿਖਦਾ ਹੈ। ਇਹ ਇੱਕ ਗੁੰਝਲਦਾਰ filter chain ਰਾਹੀਂ ਲਿਸਟ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਇੱਕ helper library ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਨਤੀਜੇ ਨੂੰ ਇੱਕ curried reducer ਨਾਲ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਜੋੜ (sum) ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਸੰਖੇਪ ਹੈ। ਇਹ ਸ਼ਾਇਦ ਅਕਾਦਮਿਕ ਤੌਰ 'ਤੇ ਸ਼ਾਨਦਾਰ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਇਸਨੂੰ ਪੜ੍ਹਨ ਲਈ, ਤੁਹਾਨੂੰ helper library ਦੀ implicit casting, stream ਦੇ ਅੰਦਰ ਕਾਰਜਾਂ ਦੇ ਕ੍ਰਮ (order of operations), ਅਤੇ ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਸਭ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸਮਝਣਾ ਪਵੇਗਾ। ਤੁਸੀਂ ਵਿਚਕਾਰ ਕੋਈ breakpoint ਨਹੀਂ ਲਗਾ ਸਕਦੇ। ਤੁਸੀਂ ਚੇਨ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਕੋਈ log statement ਨਹੀਂ ਪਾ ਸਕਦੇ। ਕੋਡ ਪੇਜ 'ਤੇ ਛੋਟਾ ਹੈ ਪਰ ਦਿਮਾਗ 'ਤੇ ਭਾਰੀ ਹੈ।
ਦੂਜਾ ਡਿਵੈਲਪਰ ਇੱਕ ਬੇਸਿਕ ਲੂਪ (loop) ਲਿਖਦਾ ਹੈ। ਉਹ ਇੱਕ running total ਐਲਾਨਦੀ ਹੈ, ਵਸਤੂਆਂ ਰਾਹੀਂ ਫੇਰਬਦਲ (iterate) ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਰਨ ਲਈ ਕਿ ਟੈਕਸ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇੱਕ ਸਾਧਾਰਨ if statement ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਹ ਬਲਾਕ ਲੰਬਾਈ ਵਿੱਚ ਵੱਡਾ ਹੈ, ਪਰ ਇਸਦਾ ਮਕਸਦ ਸਪਸ਼ਟ ਹੈ। ਤੁਸੀਂ ਪੰਜ ਅਬਸਟਰੈਕਸ਼ਨਾਂ (abstractions) ਨੂੰ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ ਇਸਨੂੰ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਤੱਕ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਇਸਨੂੰ debugger ਵਿੱਚ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਪੂਰੇ expression ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਚੌਥੀ ਲਾਈਨ 'ਤੇ logging ਜੋੜ ਸਕਦੇ ਹੋ।
ਚਲਾਕ ਕੋਡ ਇੱਕ pull request ਵਿੱਚ ਲਗਭਗ ਦਸ ਮਿੰਟਾਂ ਲਈ ਸਮਾਰਟ ਲੱਗਦਾ ਹੈ। ਸਾਧਾਰਨ ਕੋਡ ਬੋਰਿੰਗ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਰਾਤ ਦੇ ਦੋ ਵਜੇ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ (troubleshooting) ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਤਾਂ ਬੋਰਿੰਗ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ। ਤੁਹਾਡਾ ਟੀਚਾ ਸਪਸ਼ਟਤਾ ਹੈ, ਨਾ ਕਿ ਆਪਣੀ ਬੁੱਧੀ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨਾ।
ਸਿਸਟਮਾਂ ਨੂੰ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਹੀਰੋਵਾਂ ਦੀ
ਇਹ ਸਿਧਾਂਤ ਆਰਕੀਟੈਕਚਰ (architecture) ਤੱਕ ਵਧਦਾ ਹੈ। ਇੱਕ ਚਲਾਕ ਸਿਸਟਮ ਹੱਥ ਨਾਲ ਲਿਖੇ consensus logic, ਵਿਸ਼ੇਸ਼ orchestration scripts, ਅਤੇ ਅਣਡਾਕੂਮੈਂਟੇਡ caching shortcuts 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਸਿਰਫ ਇੱਕ ਇੰਜੀਨੀਅਰ ਹੀ ਸਹੀ ਤਰ੍ਹਾਂ ਸਮਝਦਾ ਹੈ। ਉਹ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਨਹੀਂ ਚੱਲਦਾ; ਇਹ ਉਸ ਵਿਅਕਤੀ ਦੀ ਲਗਾਤਾਰ ਬੁੱਧੀ 'ਤੇ ਚੱਲਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਸੰਭਾਲ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਉਹ ਵਿਅਕਤੀ ਛੁੱਟੀ 'ਤੇ ਜਾਂਦਾ ਹੈ ਜਾਂ ਨਵੀਂ ਨੌਕਰੀ 'ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਡੋਲਣ ਲੱਗ ਪੈਂਦਾ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਸਿਸਟਮ ਢਾਂਚੇ ਅਤੇ ਸੀਮਾਵਾਂ (constraints) 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਉਹ ਅਜਿਹੇ database schemas ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਗਲਤ ਡਾਟਾ ਨੂੰ ਰੱਦ ਕਰਦੇ ਹਨ, API contracts ਜੋ ਸੀਮਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, type systems ਜੋ ਡਿਪਲਾਈਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਗਲਤੀਆਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਮੋਡਿਊਲ ਵੱਖਰੇਵੇਂ ਜੋ ਨਿਰਧਾਰਤ ਰਸਤੇ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ। ਉਹ ਸਥਿਰ ਰਹਿਣ ਲਈ ਕਿਸੇ ਬਹਾਦਰੀ (heroics) ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਥੱਕੇ ਹੋਏ ਇਨਸਾਨਾਂ ਦੇ ਸੰਪਰਕ ਵਿੱਚ ਬਚਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਹਨ, ਜੋ ਕਿ ਉਹ ਇਕਲੌਤਾ ਤਰ੍ਹਾਂ ਦੇ ਇਨਸਾਨ ਹਨ ਜੋ production ਵਿੱਚ ਸਾਫਟਵੇਅਰ ਚਲਾਉਂਦੇ ਹਨ।
AI ਵਧਾਊ ਸਮੱਸਿਆ (The AI Amplification Problem)
ਆਰਟੀਫੀਸ਼ੀਅਲ ਇੰਟੈਲੀਜੈਂਸ ਕੋਡਿੰਗ ਸਹਾਇਕ ਇਸ ਸਬਕ ਨੂੰ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਟੈਕਸਟ ਤਿਆਰ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਸਮੱਸਿਆ ਦਿਖਾਓ ਅਤੇ ਉਹ ਅਕਸਰ ਇੱਕ ਵੱਡਾ, ਗੁੰਝਲਦਾਰ ਹੱਲ ਵਾਪਸ ਕਰਨਗੇ ਜੋ ਉਹਨਾਂ ਯੂਟੀਲਿਟੀਜ਼ (utilities) ਨੂੰ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਵੈਪਰ (wrappers) ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ, ਅਜਿਹੇ edge cases ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡੋਮੇਨ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹਨ, ਅਤੇ ਉਸ ਫਰੇਮਵਰਕ ਦੇ ਵਰਜ਼ਨ ਤੋਂ ਆਈਡੀਅਮ (idioms) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਿਸ ਤੋਂ ਤੁਸੀਂ ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਹਟ ਗਏ ਸੀ। AI ਤੁਰੰਤ ਕੰਮ ਨੂੰ ਦੇਖਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਲੰਬੇ ਸਮੇਂ ਦੇ ਖਰਚੇ ਦਾ ਪ੍ਰਬੰਧਨ ਕੀਤੇ ਬਿਨਾਂ ਹਰ ਸੁਝਾਅ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਕੋਡ ਜਨਰੇਸ਼ਨ ਵਾਧੇ (inflation) ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ। ਤੁਹਾਡੀ ਰਿਪੋਜ਼ੀਟਰੀ ਅਜਿਹੇ ਕੋਡ ਨਾਲ ਭਰ ਜਾਂਦੀ ਹੈ ਜੋ ਦੇਖਣ ਵਿੱਚ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਕੰਪਾਈਲ ਹੁੰਦਾ ਹੈ, ਟੈਸਟ ਪਾਸ ਕਰਦਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਕੋਈ ਵੀ ਇਸਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦਾ। ਖ਼ਤਰਾ ਕੋਈ ਸਾਫ਼ ਦਿਖਣ ਵਾਲੀ ਸਿੰਟੈਕਸ ਐਰਰ ਨਹੀਂ ਹੈ। ਉਹ ਰਿਵਿਊ ਵਿੱਚ ਫੜ ਲਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਖ਼ਤਰਾ ਕੋਡਬੇਸ ਦੇ ਹੌਲੀ-ਹੌਲੀ ਮੋਟੇ ਹੋਣ ਦਾ ਹੈ, ਜਿੱਥੇ ਹਰ ਵੱਖਰੀ ਫਾਈਲ ਇਕੱਲੀ ਵੇਖਣ ਵਿੱਚ ਜਾਇਜ਼ ਲੱਗਦੀ ਹੈ ਪਰ ਪੂਰਾ ਸਿਸਟਮ ਕਿਸੇ ਵੀ ਇਨਸਾਨ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਸਮਾਉਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਗਤੀ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਕਿਸੇ ਵੱਡੇ ਟਕਰਾਅ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਚੀਜ਼ਾਂ ਦੇ ਸ਼ਾਂਤ ਇਕੱਠੇ ਹੋਣ ਨਾਲ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਵੀ ਡਿਲੀਟ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਉਹ ਉਸ ਚੀਜ਼ ਨੂੰ ਛੂਹਣ ਤੋਂ ਡਰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦੇ।
ਡਿਲੀਟ ਕਰਨਾ ਇੱਕ ਡਿਜ਼ਾਈਨ ਹੁਨਰ ਹੈ
ਮਹਾਨ ਇੰਜੀਨੀਅਰ ਦੂਜਿਆਂ ਨਾਲੋਂ ਤੇਜ਼ ਟਾਈਪ ਕਰਕੇ ਆਪਣੇ ਆਪ ਨੂੰ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਸਾਦਗੀ ਨੂੰ ਚੁਣ ਕੇ, ਅਤੇ ਇਕੱਠਾ ਕਰਨ ਦੀ ਬਜਾਏ ਡਿਲੀਟ ਕਰਨ ਨੂੰ ਚੁਣ ਕੇ ਜਿੱਤਦੇ ਹਨ। ਕੋਡ ਨੂੰ ਹਟਾਉਣ ਲਈ ਉਸਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਤੁਹਾਨੂੰ ਡਾਟਾ ਫਲੋ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਇਹ ਪੁਸ਼ਟੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਕਿ ਕਿਸੇ ਫੀਚਰ ਦੇ ਕੋਈ ਲੁਕੇ ਹੋਏ ਕਾਲਰਸ (callers) ਨਹੀਂ ਹਨ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਬਿਜ਼ਨਸ ਦੀਆਂ ਲੋੜਾਂ ਬਦਲ ਚੁੱਕੀਆਂ ਹਨ। ਡਿਲੀਟ ਕਰਨਾ ਜੋੜਨ ਨਾਲੋਂ ਔਖਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਲਈ ਨਿਸ਼ਚਿਤਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਟੀਮਾਂ ਅਕਸਰ ਸ਼ਿਪ ਕੀਤੇ ਫੀਚਰਾਂ ਅਤੇ ਵੱਡੀਆਂ ਪੁੱਲ ਰਿਕਵੈਸਟਾਂ ਲਿਆਉਣ ਵਾਲੇ ਮਲਟੀਪਲਾਈਅਰਾਂ ਦਾ ਜਸ਼ਨ ਮਨਾਉਂਦੀਆਂ ਹਨ। ਬਹੁਤ ਘੱਟ ਟੀਮਾਂ ਉਸ ਇੰਜੀਨੀਅਰ ਦੀ ਤਾਰੀਫ਼ ਕਰਦੀਆਂ ਹਨ ਜੋ ਚਾਰ ਹਜ਼ਾਰ ਲਾਈਨਾਂ ਦੀ ਮਰੀ ਹੋਈ ਲੌਜਿਕ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਪਰ ਉਹ ਨੈਗੇਟਿਵ ਲਾਈਨ ਕਾਊਂਟ ਅਕਸਰ ਸੰਸਥਾ ਦੇ ਭਵਿੱਖ ਲਈ ਇੱਕ ਵੱਡੀ ਸੇਵਾ ਹੁੰਦੀ ਹੈ।
ਮਹਿੰਗਾ ਹਿੱਸਾ
ਕੋਡ ਹੁਣ ਸਸਤਾ ਹੈ। ਕੋਈ ਵੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਇਸਦੇ ਪੰਨੇ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਮਹਿੰਗਾ ਸਰੋਤ ਸਪਸ਼ਟਤਾ ਹੈ। ਇੱਕ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਣ ਲਈ ਸਮੇਂ, ਸਹੀ ਫੈਸਲੇ ਅਤੇ ਸੰਜਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਸਲੀ ਇੰਜੀਨੀਅਰਿੰਗ ਐਡੀਟਿੰਗ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਡਰਾਫਟਿੰਗ ਵਿੱਚ ਨਹੀਂ।
ਘੱਟ ਲਿਖੋ। ਜ਼ਿਆਦਾ ਡਿਲੀਟ ਕਰੋ। ਸਾਦਗੀ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋ।