30 ਅਪ੍ਰੈ 2025·7 ਮਿੰਟ
ਜੌਨ ਔਸਟਰਹਾਊਟ: ਅਭਿਆਸਿਕ ਡਿਜ਼ਾਈਨ, Tcl ਅਤੇ ਜਟਿਲਤਾ ਦੀ ਲਾਗਤ
ਜੌਨ ਔਸਟਰਹਾਊਟ ਦੇ ਵਿਚਾਰ: ਅਭਿਆਸਿਕ ਸਾਫਟਵੇਅਰ ਡਿਜ਼ਾਈਨ, Tcl ਦੀ ਵਿਰਾਸਤ, Ousterhout vs Brooks ਦੀ ਚਰਚਾ, ਅਤੇ ਕਿਵੇਂ ਜਟਿਲਤਾ ਉਤਪਾਦਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ।
ਜੌਨ ਔਸਟਰਹਾਊਟ ਦੇ ਵਿਚਾਰ: ਅਭਿਆਸਿਕ ਸਾਫਟਵੇਅਰ ਡਿਜ਼ਾਈਨ, Tcl ਦੀ ਵਿਰਾਸਤ, Ousterhout vs Brooks ਦੀ ਚਰਚਾ, ਅਤੇ ਕਿਵੇਂ ਜਟਿਲਤਾ ਉਤਪਾਦਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ।
John Ousterhout ਇੱਕ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀ ਅਤੇ ਇੰਜੀਨੀਅਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਰੀਸਰਚ ਅਤੇ ਅਸਲ ਪ੍ਰਣਾਲੀਆਂ ਦੋਹਾਂ ਵਿੱਚ ਕੰਮ ਕੀਤਾ। ਉਨ੍ਹਾਂ ਨੇ Tcl ਭਾਸ਼ਾ ਬਣਾਈ, ਆਧੁਨਿਕ ਫਾਈਲ ਸਿਸਟਮਾਂ ਤੇ ਪ੍ਰਭਾਵ ਪਾਇਆ, ਅਤੇ ਫਿਰ ਦਹਾਕਿਆਂ ਦਾ ਤਜਰਬਾ ਇਕ ਸਧਾਰਣ ਪਰ ਥੋੜ੍ਹਾ ਅਸਹਜ ਦਾਵੇ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕੀਤਾ: ਜਟਿਲਤਾ ਸਾਫਟਵੇਅਰ ਦੀ ਮੁੱਖ ਵਿਰੋਧੀ ਹੈ।
ਇਹ ਸੁਨੇਹਾ ਅਜੇ ਵੀ ਟਾਈਮਲੀ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਫੀਚਰਾਂ ਜਾਂ ਕੋਸ਼ਿਸ਼ ਦੀ ਘਾਟ ਕਾਰਨ ਫੇਲ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦੀਆਂ ਪ੍ਰਣਾਲੀਆਂ (ਅਤੇ ਸੰਸਥਾਵਾਂ) ਸਮਝਣ ਵਿੱਚ ਔਖੀਆਂ, ਬਦਲਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਅਤੇ ਟੁੱਟਣ ਵਿੱਚ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਜਟਿਲਤਾ ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਧੀਮਾ ਨਹੀਂ ਕਰਦੀ। ਇਹ ਪ੍ਰੋਡਕਟ ਫੈਸਲਿਆਂ, ਰੋਡਮੇਪ ਵਿਸ਼ਵਾਸ, ਗਾਹਕ ਭਰੋਸਾ, ਘਟਨਾਵਾਂ ਦੀ ਆਵ੍ਰਿੱਤੀ, ਅਤੇ ਨੌਕਰੀ ਭਰਤੀ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ—ਕਿਉਂਕਿ onboarding ਮਹੀਨਿਆਂ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
Ousterhout ਦੀ ਫਰਮਾਬੰਦੀ ਪ੍ਰੈਕਟਿਕਲ ਹੈ: ਜਦੋਂ ਇੱਕ ਸਿਸਟਮ ਵਿਸ਼ੇਸ਼ ਕੇਸਾਂ, ਅਪਵਾਦਾਂ, ਲੁਕ੍ਹੇ ਨਿਰਭਰਤਾਵਾਂ ਅਤੇ “ਛੇਤੀ ਠੀਕ” ਫਿਕਸਾਂ ਇਕੱਠੀਆਂ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਲਾਗਤ ਸਿਰਫ਼ ਕੋਡਬੇਸ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਰਹਿੰਦੀ। ਪੂਰਾ ਪ੍ਰੋਡਕਟ ਵਿਕਸਤ ਕਰਨ ਲਈ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਫੀਚਰ ਲੰਮਾ ਸਮਾਂ ਲੈਂਦੇ ਹਨ, QA ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਰਿਲੀਜ਼ ਖ਼ਤਰਨਾਕ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਟੀਮਾਂ ਸੁਧਾਰਾਂ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੁਝ ਵੀ ਛੇੜਨ ਤੇ ਡਰ ਲਗਦਾ ਹੈ।
ਇਹ ਕੋਈ ਅਕਾਦਮਿਕ ਪਵਿੱਤਰਤਾ ਦੀ ਬੁਕਾਰ ਨਹੀਂ ਹੈ। ਇਹ ਯਾਦ ਦਿਲਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਸ਼ਾਰਟਕਟ ਦਾ ਇੱਕ ਬਿਆਜ਼ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਜਟਿਲਤਾ ਸਭ ਤੋਂ ਉੱਚ-ਦਰਜਾ ਵਾਲਾ ਕਰਜ਼ਾ ਹੈ।
ਸਿਧੀ ਪ੍ਰਯੋਗਿਕਤਾ ਲਈ (ਤੇ ਕੇਵਲ ਪ੍ਰੇਰਣਾਦਾਇਕ ਨਾ ਰਹਿਣ ਲਈ) ਅਸੀਂ Ousterhout ਦੇ ਸੁਨੇਹੇ ਨੂੰ ਤਿੰਨ ਕੋਣਾਂ ਤੋਂ ਵੇਖਾਂਗੇ:
ਇਹ ਲੇਖ ਸਿਰਫ਼ ਭਾਸ਼ਾ ਦੇ ਸ਼ੌਕੀਨਾਂ ਲਈ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਤਪਾਦ ਬਣਾਉਂਦੇ ਹੋ, ਟੀਮਾਂ ਦੀ ਅਗਵਾਈ ਕਰਦੇ ਹੋ, ਜਾਂ ਰੋਡਮੇਪ ਦਾ ਫੈਸਲਾ ਲੈਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੇ ਕਾਰਜਕਾਰੀ ਤਰੀਕੇ ਲੱਭੋਗੇ ਜੋ ਜਟਿਲਤਾ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਪਛਾਣਨ, ਇਸਨੂੰ ਸਂਸਥਿਤ ਹੋਣ ਤੋਂ ਰੋਕਣ, ਅਤੇ ਸਰਲਤਾ ਨੂੰ ਪਹਿਲ ਦਿੱਤੀ ਵਸਤੁ ਵਜੋਂ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰਨ।
ਜਟਿਲਤਾ ਕੋਡ ਦੀ ਬਹੁਲਤਾ'' ਜਾਂ ਠੇਠ ਗਣਿਤ'' ਨਹੀਂ ਹੈ। ਇਹ ਓਹ ਫਾਸਲਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਸਿਸਟਮ ਬਦਲਣ 'ਤੇ ਕਰੇਗਾ ਅਤੇ ਅਸਲ ਵਿਚ ਕੀ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਛੋਟੇ ਸੋਧ ਵੀ ਖਤਰਨਾਕ ਲੱਗਣ ਤੋਂ, ਤੁਹਾਡੇ ਲਈ ਸਿਸਟਮ ਜਟਿਲ ਹੈ—ਕਿਉਂਕਿ ਤੁਸੀਂ blast radius ਦੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਸਿਹਤਮੰਦ ਕੋਡ ਵਿੱਚ, ਤੁਸੀਂ ਇਹ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ: “ਜੇ ਅਸੀ ਇਹ ਬਦਲਾਂਗੇ, ਤਾਂ ਹੋਰ ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ?” ਜਟਿਲਤਾ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਉਹਨਾਂ ਸਵਾਲਾਂ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾ ਦਿੰਦੀ ਹੈ।
ਇਹ ਅਕਸਰ ਛੁਪਿਆ ਹੁੰਦਾ ਹੈ:
ਟੀਮਾਂ ਜਟਿਲਤਾ ਨੂੰ ਧੀਮੀ ਡਿਲਿਵਰੀ (ਜਿਆਦਾ ਸਮਾਂ ਜਾਂਚ ਲਈ), ਵਧੇਰੇ ਬੱਗ (ਕਿਉਂਕਿ ਵਿਵਹਾਰ ਅਚਾਨਕ ਹੁੰਦਾ ਹੈ), ਅਤੇ ਭੰਗਰਾਅ ਪ੍ਰਣਾਲੀਆਂ (ਬਦਲਾਅ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਅਤੇ ਸਰਵਿਸਜ਼ ਨਾਲ ਸਮਨਵਯ) ਵਜੋਂ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਹਨ। ਇਹ onboarding 'ਤੇ ਵੀ ਭਾਰ ਪਾਉਂਦੀ ਹੈ: ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ ਮਾਨਸਿਕ ਮਾਡਲ ਨਹੀਂ ਬਣਾ ਪਾਉਂਦੇ, ਇਸ ਲਈ ਉਹ ਕੋਰ ਫਲੋਜ਼ ਨੂੰ ਛੇੜਨ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਦੇ ਹਨ।
ਕੁਝ ਜਟਿਲਤਾ ਜਰੂਰੀ ਹੁੰਦੀ ਹੈ: ਬਿਜਨਸ ਨਿਯਮ, ਅਨੁਕੂਲ ਜਾਂ ਦੁਨੀਆ ਦੇ ਕੰਢੇ। ਇਹ ਹਟਾਈ ਨਹੀਂ ਜਾ ਸਕਦੀ।
ਪਰ ਬਹੁਤ ਕੁਝ ਅਕਸਿਡੈਂਟਲ ਹੁੰਦਾ ਹੈ: ਅਸਪਸ਼ਟ APIs, ਨਕਲ ਹੋਈ ਤਰੱਕੀ, “ਅਸਥਾਈ” ਫਲੈਗ ਜੋ ਸਥਾਈ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਮੌਡੀਊਲ ਜੋ ਅੰਦਰੂਨੀ ਵੇਰਵੇ ਲੀਕ ਕਰਦੇ ਹਨ। ਇਹ ਉਹ ਜਟਿਲਤਾ ਹੈ ਜੋ ਡਿਜ਼ਾਈਨ ਫੈਸਲਿਆਂ ਨੇ ਬਣਾਈ—ਅਤੇ ਇਹੀ ਉਹ ਹੈ ਜੋ ਟੀਮ ਲਗਾਤਾਰ ਘਟਾ ਸਕਦੀ ਹੈ।
Tcl ਦਾ ਨਿਰਦੇਸ਼ ਪ੍ਰਯੋਗਿਕਤਾ ਸੀ: ਸੌਫਟਵੇਅਰ ਆਟੋਮੇਸ਼ਨ ਆਸਾਨ ਬਣਾਉ, ਤੇ ਮੌਜੂਦਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ ਬਿਨਾਂ ਤਬਦੀਲ ਕਰਨ ਰਾਹ ਸੁਖਾਵੇਂ। John Ousterhout ਨੇ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਇਆ ਕਿ ਟੀਮਾਂ "ਕੁਝ ਪਰਯਾਪਤ ਪ੍ਰੋਗਰਾਮਬਿਲੀਟੀ" ਦਿ ਸਕਣ—ਫਿਰ ਉਹ ਸ਼ਕਤੀ ਯੂਜ਼ਰ, ਆਪਰੇਟਰ, QA ਜਾਂ ਜੋ ਕੋਈ ਵੀ ਵਰਕੇ-ਵਹਿਕ ਵੱਸ-ਕੰਮ ਕਰਦਾ, ਉਸ ਨੂੰ ਦੇ ਸਕਦੇ।
Tcl ਨੇ ਗਲੂ ਭਾਸ਼ਾ ਦੀ ਸੋਚ ਨੂੰ ਲੋਕਪ੍ਰਿਯਤਾ ਦਿੱਤੀ: ਇੱਕ ਛੋਟੀ, ਲਚਕੀਲੀ ਸਕ੍ਰਿਪਟਿੰਗ ਪਰਤ ਜੋ ਨੀਵੇਂ-ਨੀਵੇਂ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਜੋੜਦੀ ਹੈ ਜੋ ਤੇਜ਼, ਨੀਵੇਂ-ਪੱਧਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ। ਹਰ ਫੀਚਰ ਨੂੰ ਮੋਨੋਲਿਥ ਵਿੱਚ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੁਝ ਕਮਾਂਡ ਐਕਸਪੋਜ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਵੇਂ ਵਿਹਾਰਾਂ ਵਿੱਚ ਜੋੜਦੇ ਹੋ।
ਇਹ ਮਾਡਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਬਿਤ ਹੋਇਆ ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਨਾਲ ਮਿਲਦਾ ਸੀ। ਲੋਕ ਸਿਰਫ਼ ਉਤਪਾਦ ਨਹੀਂ ਬਣਾਉਂਦੇ; ਉਹ ਬਿਲਡ-ਸਿਸਟਮ, ਟੈਸਟ ਹਾਰਨੇਸ, ਐਡਮਿਨ ਟੂਲ, ਡੇਟਾ ਕਨਵਰਟਰ ਅਤੇ ਇੱਕ-ਵਾਰੀ ਆਟੋਮੇਸ਼ਨ ਵੀ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਸਕ੍ਰਿਪਟਿੰਗ ਪਰਤ ਉਹਨਾਂ ਕੰਮਾਂ ਨੂੰ "ਟਿਕਟ ਫਾਈਲ ਕਰਨ" ਦੀ ਥਾਂ "ਸਕ੍ਰਿਪਟ ਲਿਖੋ" ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
Tcl ਨੇ ਐਂਬੇਡਿੰਗ ਨੂੰ ਪਹਿਲ-ਸ਼੍ਰੇਣੀ ਬਣਾ ਦਿੱਤਾ। ਤੁਸੀਂ ਇੱਕ ਇੰਟਰਪ੍ਰਿਟਰ ਡਰੌਪ ਕਰ ਸਕਦੇ ਸੀ, ਇੱਕ ਸਾਫ਼ ਕਮਾਂਡ ਇੰਟਰਫੇਸ ਐਕਸਪੋਜ਼ ਕਰ ਸਕਦੇ, ਅਤੇ ਤੁਰੰਤ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਹਾਸਲ ਕਰ ਸਕਦੇ ਸੀ।
ਇਹੋ ਹੀ ਨਮੂਨਾ ਅੱਜ plugin ਸਿਸਟਮਾਂ, ਕਨਫਿਗੁਰੇਸ਼ਨ ਭਾਸ਼ਾਵਾਂ, ਐਕਸਟেনਸ਼ਨ APIs ਅਤੇ ਐਂਬੇਡਡ ਸਕ੍ਰਿਪਟਿੰਗ ਰਨਟਾਈਮਾਂ ਵਿੱਚ ਦਿੱਖਦਾ ਹੈ—ਚਾਹੇ ਸਕ੍ਰਿਪਟ ਸਿੰਟੈਕਸ Tcl ਵਰਗੀ ਹੋਵੇ ਜਾਂ ਨਹੀਂ।
ਇਸ ਨੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਡਿਜ਼ਾਈਨ ਆਦਤ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ: stable primitives (host app ਦੇ ਕੋਰ ਸਮਰੱਥਾ) ਨੂੰ ਬਦਲਣਯੋਗ composition (ਸਕ੍ਰਿਪਟ) ਤੋਂ ਵੱਖਰੇ ਰੱਖੋ। ਜਦੋਂ ਇਹ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੂਲਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਕੋਰ ਨੂੰ ਨਿਰਤਂਤਰ ਤੌਰ 'ਤੇ ਅਸਤਵਿਕ ਬਣਾਉਣ ਦੇ।
Tcl ਦੀ ਸਿੰਟੈਕਸ ਅਤੇ "ਹਰ ਚੀਜ਼ ਸਤਰ" ਮਾਡਲ ਕੁਝ ਨੂੰ ਅਸਹਜ ਲੱਗ ਸਕਦਾ ਸੀ, ਅਤੇ ਵੱਡੇ Tcl ਕੋਡਬੇਸਜ਼ ਜ਼ਿਆਦਾ ਕੰਵੇਂਸ਼ਨਾਂ ਦੇ ਬਿਨਾਂ ਸਮਝਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦੇ ਸਨ। ਜਿਥੇ ਨਵੇਂ ਪਰਿਸਥਿਤੀਆਂ ਵੱਡੀਆਂ ਸਟੈਂਡਰਡ ਲਾਇਬਰੇਰੀ, ਚੰਗੇ ਟੂਲਿੰਗ, ਅਤੇ ਵੱਡੇ ਕਮਿਊਨਿਟੀ ਦਿੱਤੀਆਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਹਟ ਗਈਆਂ।
ਇਸ ਵਿਚਾਰ ਨਾਲ ਇਹ ਨਾ ਕਿ Tcl ਦੀ ਵਿਰਾਸਤ ਮਿਟਦੀ ਹੈ: ਇਸ ਨੇ ਇਹ ਆਮ ਕਰ ਦਿੱਤਾ ਕਿ extensibility ਅਤੇ automation ਕੋਈ ਐਡ-ਆਨ ਨਹੀਂ—ਉਹ ਉਤਪਾਦੀ ਫੀਚਰ ਹਨ ਜੋ ਮੈਨਟੇਨ ਅਤੇ ਵਰਤੋਂ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਜਟਿਲਤਾ ਬਹੁਤ ਘੱਟ ਕਰ ਸਕਦੇ ਹਨ।
Tcl ਇੱਕ ਧੋਖੇਬਾਜ਼ ਤੌਰ 'ਤੇ ਸਖ਼ਤ ਵਿਚਾਰ 'ਤੇ ਬਣੀ ਸੀ: ਕੋਰ ਛੋਟਾ ਰੱਖੋ, composition ਸ਼ਕਤੀਸ਼ਾਲੀ ਬਣਾਓ, ਅਤੇ ਸਕ੍ਰਿਪਟ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ ਤਾਂ ਕਿ ਲੋਕ ਬਿਨਾਂ ਲਗਾਤਾਰ ਅਨੁਵਾਦ ਦੇ ਇਕੱਠੇ ਕੰਮ ਕਰ ਸਕਣ।
ਵੱਡੇ ਸੈੱਟ ਵਿਸ਼ੇਸ਼ਤਾਂ ਦੇ ਬਦਲੇ, Tcl ਨੇ ਕੁਝ ਮੁੱਢਲੇ primitives (ਸਤਰ, ਕਮਾਂਡ, ਸادہ ਮੁਲਾਂਕਣ ਨਿਯਮ) 'ਤੇ ਨਿਰਭਰ ਕੀਤਾ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਕਿ ਯੂਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨਗੇ।
ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਡਿਜ਼ਾਈਨਰਾਂ ਨੂੰ ਥੋੜੇ ਸੰਕਲਪਾਂ ਵੱਲ ਮੋੜਦੀ ਹੈ ਜੋ ਬਹੁਤ ਸcontexts ਵਿੱਚ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਉਤਪਾਦ ਅਤੇ API ਡਿਜ਼ਾਈਨ ਲਈ ਸਿੱਧਾ ਸਬਕ: ਜੇ ਤੁਸੀਂ 10 ਲੋੜਾਂ ਨੂੰ 2-3 ਲਗਤਾਰ ਨਿਰਮਾਣੀ ਬਲਾਕਾਂ ਨਾਲ ਹਲ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਸਰਫੇਸ ਇਲਾਕਾ ਘਟਾ ਦਿੰਦੇ ਹੋ ਜੋ ਲੋਕਾਂ ਨੂੰ ਸਿੱਖਣਾ ਪੈਂਦਾ ਹੈ।
ਸਾਫਟਵੇਅਰ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਇੱਕ ਝਾਂਸਾ ਇਹ ਹੈ ਕਿ ਬਿਲਡਰ ਦੀ ਸੌਖਿਆ ਲਈ ਓਪਟੀਮਾਈਜ਼ ਕੀਤਾ ਜਾਵੇ। ਇੱਕ ਫੀਚਰ ਲਾਗੂ ਕਰਨ ਲਈ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ (ਮੌਜੂਦਾ ਵਿਕਲਪ ਨੂੰ ਨਕਲ ਕਰੋ, ਖਾਸ ਫਲੈਗ ਜੋੜੋ, ਕੋਰਨਰ ਕੇਸ ਲਈ ਪੈਚ ਕਰ ਦੋ) ਪਰ ਉਤਪਾਦ ਨੂੰ ਵਰਤਣ ਲਈ ਔਖਾ ਬਣਾ ਦੇਵੇ।
Tcl ਦਾ ਜੋ ਜ਼ੋਰ ਸੀ ਉਹ ਵਿਰੋਧ ਹੈ: ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ ਸੁਤੰਤਰ ਰੱਖੋ, ਭਾਵੇਂ ਪਿੱਛੇ ਦੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਹੋਰ ਕੰਮ ਕਰੇ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਪ੍ਰਸਤਾਵ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਪੁੱਛੋ: ਕੀ ਇਹ ਯੂਜ਼ਰ ਨੂੰ ਯਾਦ ਰੱਖਣ ਵਾਲੇ ਸੰਕਲਪਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਂਦਾ ਹੈ ਜਾਂ ਇਸ ਵਿੱਚ ਇੱਕ ਹੋਰ ਅਪਵਾਦ ਜੋੜਦਾ ਹੈ?
ਮੀਨੀਮਲਿਜ਼ਮ ਸਿਰਫ਼ ਤਦ ਹੀ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ primitives ਸੰਗਤ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਦੋ ਕਮਾਂਡਾਂ ਇੱਕ-ਦੂਜੇ ਜਿਹੀਆਂ ਦਿੱਖਦੀਆਂ ਹਨ ਪਰ ਕਿਨਾਰੇ ਕੇਸਾਂ ਵਿੱਚ ਵੱਖਰਾ ਵਿਹਾਰ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਯੂਜ਼ਰ ਦਰਅਸਲ trivia ਯਾਦ ਕਰਨਗੇ। ਛੋਟਾ ਸੈੱਟ ਟੂਲ “ਤੇਖੇ ਧਾਰ” ਬਣ ਸਕਦਾ ਹੈ ਜਦੋਂ ਨਿਯਮ ਥੋੜ੍ਹੇ-ਥੋੜ੍ਹੇ ਤਰੀਕੇ ਨਾਲ ਵੱਖਰੇ ਹੋਣ।
ਰਸੋਈ ਨੂੰ ਸੋਚੋ: ਇੱਕ ਚੰਗੀ ਚਾਕੂ, ਪੈਨ ਅਤੇ ਓਵਨ ਤੁਹਾਡੇ ਨੂੰ ਕਈ ਖਾਣੇ ਬਣਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਗੈਡਜਿਟ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਫਲ ਦੀ ਕੱਟਾਈ ਕਰਦਾ ਹੈ, ਇੱਕ-ਵਾਰੀ ਫੀਚਰ ਹੈ—ਵਿਕਣ ਲਈ ਆਸਾਨ, ਪਰ ਰਖਣ ਲਈ ਅਣਸੁਨੀ।
Tcl ਦੀ ਫਿਲਾਸਫੀ ਚਾਕੂ ਅਤੇ ਪੈਨ ਲਈ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ: ਆਮ ਟੂਲ ਜੋ ਸੁਚੱਜੇ ਤਰੀਕੇ ਨਾਲ ਜੋੜੇ ਜਾ ਸਕਦੇ ਹਨ, ਤਾਂ ਕਿ ਹਰ ਰੈਸਪੀ ਲਈ ਇੱਕ ਨਵੀਂ ਗੇਜੇਟ ਦੀ ਲੋੜ ਨਾ ਪਵੇ।
1986 ਵਿੱਚ, Fred Brooks ਨੇ ਇੱਕ ਲੇਖ ਲਿਖਿਆ ਜਿਸਦਾ ਨਤੀਜਾ ਇਰਾਦਾ ਨਾਲ ਪ੍ਰੋਵੋਕਟਿਵ ਸੀ: ਕੋਈ ਇਕਲੋਤਾ ਤੜਕਾ—ਕੋਈ “ਚਾਂਦੀ ਦੀ ਗੋਲੀ”—ਨਹੀਂ ਜੋ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਨੂੰ ਇੱਕ ਛੱਲੇ ਵਿੱਚ ਦੋਹਰਿਆਂ ਗੁਣਾ ਤੇਜ਼, ਸਸਤਾ ਅਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸੇਮੰਦ ਬਣਾ ਦੇਵੇ।
ਉਹਦਾ ਬਿੰਦੂ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਤਰੱਕੀ ਅਸੰਭਵ ਹੈ। ਉਹ ਕਹਿ ਰਿਹਾ ਸੀ ਕਿ ਸਾਫਟਵੇਅਰ ਇੱਕ ਅਜਿਹਾ ਮਾਧਿਅਮ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਲਗਾਤਾਰ ਉਸੀ ਚੀਜ਼ ਨੂੰ ਵਿਆਖਿਆ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਾਂ ਜਿਸਨੂੰ ਅਸੀਂ ਬਣਾਉਂਦੇ ਹਾਂ। ਚੰਗੇ ਟੂਲ ਮਦਦ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਕੰਮ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੇ।
Brooks ਨੇ जਟिलਤਾ ਨੂੰ ਦੋ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ:
ਟੂਲਾਂ ਅਕਸਿਡੈਂਟਲ ਜਟਿਲਤਾ ਨੂੰ ਦਬਾ ਸਕਦੇ ਹਨ। ਸੋਚੋ ਕਿ ਅਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ ਉੱਚ-ੁ-ਪੱਧਰ ਭਾਸ਼ਾਵਾਂ, ਵਰਜ਼ਨ ਕੰਟਰੋਲ, CI, ਕੰਟੇਨਰ, ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਅਤੇ ਚੰਗੇ IDEs ਨਾਲ। ਪਰ Brooks ਦਾ ਦਾਵਾ ਸੀ ਕਿ ਜਰੂਰੀ ਜਟਿਲਤਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ, ਅਤੇ ਇਹ ਟੂਲਾਂ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀ।
ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਟੀਮਾਂ ਅਜੇ ਵੀ ਆਪਣੀ ਜ਼ਿਆਦਾਤਰ ਊਰਜਾ ਲੋੜਾਂ ਨੂੰ ਨਿਯਤ ਕਰਨ, ਸਿਸਟਮ ਇਕੱਠੇ ਕਰਨ, ਅਪਵਾਦਾਂ ਨੂੰ ਸੰਭਾਲਣ, ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਵਿਵਹਾਰ ਨੂੰ ਸਥਿਰ ਰੱਖਣ 'ਤੇ ਲਗਾਉਂਦੀਆਂ ਹਨ। ਸਤਹ ਹੋ ਸਕਦੀ ਹੈ ਬਦਲ ਜਾਵੇ (ਕਲਾਉਡ APIs ਡਿਵਾਈਸ ਡਰਾਈਵਰਾਂ ਦੀ ਥਾਂ), ਪਰ ਮੁੱਖ ਚੁਣੌਤੀ ਵਾਹੀ ਰਹਿੰਦੀ ਹੈ: ਮਨੁੱਖੀ ਲੋੜਾਂ ਨੂੰ ਠੀਕ ਤੇ ਸਹੀ, ਰਖ-ਰਖਾਵ ਯੋਗ ਵਿਹਾਰ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ।
ਇਹ ਉਹ ਟੈਨਸ਼ਨ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ Ousterhout ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ: ਜੇ ਜਰੂਰੀ ਜਟਿਲਤਾ ਹਟਾਈ ਨਹੀਂ ਜਾ ਸਕਦੀ, ਤਾਂ ਕੀ ਅਨੁਸ਼ਾਸਿਤ ਡਿਜ਼ਾਈਨ ਸਚਮੁਚ ਇਸ ਗੱਲ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ ਕਿ ਕਿੰਨੀ ਜਟਿਲਤਾ ਕੋਡ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਦੇ ਦਿਮਾਗਾਂ ਵਿੱਚ ਰਿਸ਼ਾਵਟ ਕਰਦੀ ਹੈ?
ਲੋਕ ਕਈ ਵਾਰੀ “Ousterhout vs Brooks” ਨੂੰ ਆਸ਼ਾਵਾਦ ਅਤੇ ਵਾਸਤਵਿਕਤਾ ਦੇ ਟਕਰਾਅ ਵਜੋਂ ਦਿਖਾਉਂਦੇ ਹਨ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹਨ ਨਾਲ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੈ ਕਿ ਦੋ ਅਨੁਭਵੀ ਇੰਜੀਨੀਅਰ ਇੱਕੋ ਸਮੱਸਿਆ ਦੇ ਵੱਖਰੇ ਪੱਖਾਂ ਨੂੰ ਵੇਖ ਰਹੇ ਹਨ।
Brooks ਦੀ “No Silver Bullet” ਕਹਾਣੀ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕੋਈ ਇਕਲੌਤਾ ਤਰਕੀਬ ਮੁਸ਼ਕਲ ਕੰਮ ਨੂੰ ਜੜ੍ਹ ਤੋਂ ਹਟਾ ਨਹੀਂ ਸਕਦੀ। Ousterhout ਅਕਸਰ ਇਸ ਨਾਲ ਇਨਕਾਰ ਨਹੀਂ ਕਰਦੇ।
ਉਹਦੀ ਵਿਰੋਧੀ ਹੋਰ ਵਧਦੀ ਹੈ: ਟੀਮਾਂ ਬਹੁਤ ਵਾਰ ਜਟਿਲਤਾ ਨੂੰਅਸੁਚਿਤ ਸਮਝਦੀਆਂ ਹਨ ਜਦਕਿ ਬਹੁਤ ਸਾਰਾ ਹੀ ਇੱਕ-ਆਪਸ ਵਿੱਚ ਕਰਦੇ ਫੈਸਲਿਆਂ ਕਾਰਨ ਹੋ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।
Ousterhout ਦੇ ਨਜ਼ਰੀਏ ਵਿੱਚ, ਚੰਗਾ ਡਿਜ਼ਾਈਨ ਜਟਿਲਤਾ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾ ਸਕਦਾ ਹੈ—ਨਾ ਕਿ ਸਾਫਟਵੇਅਰ ਨੂੰ "ਆਸਾਨ" ਬਣਾਉਂਦਾ, ਪਰ ਇਸਨੂੰ ਬਦਲਣ ਲਈ ਘੱਟ ਭ੍ਰਮਿਤ ਕਰਨ ਵਾਲਾ ਬਣਾ देता ਹੈ। ਇਹ ਵੱਡਾ ਦਾਵਾ ਹੈ ਕਿਉਂਕਿ ਭ੍ਰਮਤਤਾ ਹੀ ਰੋਜ਼ਾਨਾ ਕੰਮ ਨੂੰ ਧੀਮਾ ਬਣਾਉਂਦੀ ਹੈ।
Brooks ਜਿਨ੍ਹਾਂ ਨੂੰ essential difficulty ਕਹਿੰਦਾ ਹੈ, ਉਹ ਇਸ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਫਟਵੇਅਰ ਨੂੰ ਗੰਦੇ ਹਕੀਕਤੀ ਨਿਯਮਾਂ, ਰੁਕਾਵਟਾਂ ਅਤੇ ਬਦਲ ਰਹੀਆਂ ਮੰਗਾਂ ਨੂੰ ਮਾਡਲ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਚੰਗੇ ਹਥਿਆਰਾਂ ਅਤੇ ਹੋਸ਼يار ਲੋਕ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਮਿਟਾ ਨਹੀਂ ਸਕਦੇ—ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹਨਾਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹੋ।
ਦੋਹਾਂ ਵਿਚ ਵੱਧ ਸਹਿਮਤੀ ਹੈ:
"ਕੌਣ ਸਹੀ ਹੈ?" ਬਦਲੇ, ਪੁੱਛੋ: ਇਸ ਕਵਾਰਟਰ ਵਿੱਚ ਅਸੀਂ ਕਿਹੜੀ ਜਟਿਲਤਾ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹਾਂ?
ਟੀਮਾਂ ਬਾਜ਼ਾਰ ਬਦਲਾਵ ਜਾਂ ਡੋਮੇਨ ਦੀ ਮੁੱਖ ਮੁਸ਼ਕਲ ਨੂੰ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਪਰ ਉਹ ਇਹ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ ਨਵੇਂ ਫੀਚਰ ਖਾਸ ਕੇਸ ਜੋੜਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, APIs ਕਾਲਰਾਂ ਨੂੰ ਲੁਕ੍ਹੇ ਨਿਯਮ ਯਾਦ ਰੱਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਮੌਡੀਊਲ ਜਟਿਲਤਾ ਛੱਡਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਇਹ ਕਾਰਜਕਾਰੀ ਮੱਧਬਿੰਦੂ ਹੈ: ਜ਼ਰੂਰੀ ਜਟਿਲਤਾ ਨੂੰ ਸਵੀਕਾਰੋ, ਅਤੇ ਅਕਸਿਡੈਂਟਲ ਕਿਸਮ ਬਾਰੇ ਬੇਨਤੀ ਨਾਲ ਚੁਣੋ।
ਇੱਕ ਗਹਿਰਾ ਮੌਡੀਊਲ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਬਹੁਤ ਕੁਝ ਕਰਦਾ ਹੈ ਪਰ ਇੱਕ ਛੋਟਾ, ਆਸਾਨ-ਸਮਝ ਇੰਟਰਫੇਸ ਦਿੰਦਾ ਹੈ। "ਗਹਿਰਾਈ" ਉਸ ਮਾਤਰਾ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਮੌਡੀਊਲ ਤੁਹਾਡੇ ਮੱਥੇ ਤੋਂ ਘਟਾ ਦਿੰਦਾ: ਕਾਲਰਾਂ ਨੂੰ ਮੈਸੀ ਵੇਰਵਿਆਂ ਦੀ ਥੋੜ੍ਹੀ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇੰਟਰਫੇਸ ਉਹਨਾਂ ਨੂੰ ਮਜ਼ਬੂਰ ਨਹੀਂ ਕਰਦਾ।
ਇੱਕ ਥੱਲਾ ਮੌਡੀਊਲ ਇਸਦਾ ਉਲਟ ਹੈ: ਇਹ ਇੱਕ ਛੋਟਾ ਲਾਜ਼ਿਕ ਟੁਕੜਾ ਲਪੇਟ ਸਕਦਾ ਹੈ, ਪਰ complexity ਨੂੰ ਬਾਹਰ ਧੱਕ ਦਿੰਦਾ—ਕਈ ਪੈਰਾਮੀਟਰ, ਖਾਸ ਫਲੈਗ, ਲਾਜ਼ਮੀ ਕਾਲ ਕ੍ਰਮ, ਜਾਂ "ਤੁਹਾਨੂੰ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ..." ਨਿਯਮਾਂ ਰਾਹੀਂ।
ਇੱਕ ਰੈਸਟੋਰੈਂਟ ਦੀ ਸੋਚੋ। ਇੱਕ ਗਹਿਰਾ ਮੌਡੀਊਲ ਰਸੋਈ ਹੈ: ਤੁਸੀਂ ਮੀਨੂੰ ਤੋਂ "ਪਾਸਤਾ" ਮੰਗਦੇ ਹੋ ਅਤੇ ਸਮੱਗਰੀ ਚੁਣਨ, ਉਬੱਲਣ ਦੇ ਸਮਾਂ, ਜਾਂ ਪਲੇਟਿੰਗ ਦੀ ਚਿੰਤਾ ਨਹੀਂ ਕਰਦੇ।
ਥੱਲਾ ਮੌਡੀਊਲ ਉਹ ਰਸੋਈ ਹੈ ਜੋ ਤੁਹਾਡੇ ਨੂੰ ਕੱਚਾ ਸਮਾਨ ਦੇ ਕੇ 12-ਕਦਮੀ ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ ਬੇਨਤੀ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਆਪਣੀ ਪੈਨ ਲਿਆਉਣੀ ਪੈਂਦੀ ਹੈ। ਕੰਮ ਤਾਂ ਹੁੰਦਾ ਹੀ ਹੈ—ਪਰ ਇਹ ਗਾਹਕ ਤੇ ਟੇਕਨਿਕਲ ਰੂਪ ਵਿੱਚ ਸਥਾਨਾਂਤਰੀਤ ਹੋ ਗਿਆ ਹੈ।
ਜੇ ਲੇਅਰਾਂ ਕਈ ਫੈਸਲਿਆਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਚੋਣ ਵਿੱਚ ਜੋੜ ਦਿੰਦੀਆਂ ਹਨ ਤਾਂ ਵਧੀਆ ਹਨ।
ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕ ਸਟੋਰੇਜ ਲੇਅਰ ਜੋ save(order) ਨੂੰ ਐਕਸਪੋਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਅੰਦਰੋਂ ਹੀ retries, serialization, ਅਤੇ indexing ਹੱਲ ਕਰਦਾ ਹੈ, ਗਹਿਰਾ ਹੈ।
ਲੇਅਰਾਂ ਤਦ ਨੁਕਸਾਨਦਾਇਕ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਜ਼ਿਆਦਾ ਤਬਦੀਲੀਆਂ ਨਹੀਂ ਲਿਆਂਦੀਆਂ—ਜੇਕਰ ਨਵਾਂ abstraction ਵਧੇਰੇ ਕਨਫਿਗਰੇਸ਼ਨ ਜੋੜਦਾ ਹੈ ਤਾ ਜੋ ਇਹ ਘਟਾਉਂਦਾ ਨਹੀਂ—ਜਿਵੇਂ save(order, format, retries, timeout, mode, legacyMode)—ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਇਹ ਥੱਲਾ ਹੈ। ਕੋਡ "ਤਰਤੀਬ ਵਿੱਚ" ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਮਨੋ-ਭਾਰ ਹਰੇਕ ਕਾਲ ਸਾਈਟ 'ਤੇ ਪ੍ਰਭਾਵਤ ਹੁੰਦਾ ਹੈ।
useCache, skipValidation, force, legacy।ਗਹਿਰੇ ਮੌਡੀਊਲ ਸਿਰਫ਼ ਕੋਡ ਨੂੰ ਐਨਕੈਪਸੂਲੇਟ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਫੈਸਲਿਆਂ ਨੂੰ ਐਨਕੈਪਸੂਲੇਟ ਕਰਦੇ ਹਨ।
“ਚੰਗਾ” API ਕੇਵਲ ਵਡਿਆਰ ਕੁਝ ਕਰਨ ਵਾਲਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਲੋਕ ਕੰਮ ਕਰਦੇ ਹੋਏ ਦਿਲ ਤੇ ਰੱਖ ਸਕਦੇ ਹਨ।
Ousterhout ਦਾ ਡਿਜ਼ਾਈਨ ਲੈਂਸ ਤੁਹਾਨੂੰ API ਨੂੰ ਉਸ ਮਾਨਸਿਕ ਮਿਹਨਤ ਦੇ ਅਧਾਰ 'ਤੇ ਅੰਕਿਤ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਕਿੰਨੇ ਨਿਯਮ ਯਾਦ ਰੱਖਣੇ ਹਨ, ਕਿੰਨੇ ਅਪਵਾਦ ਦੀ ਪੇਸ਼ਗੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨੇ ਹਨ, ਅਤੇ ਗਲਤੀ ਨਾਲ ਗਲਤ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਕਿੰਨੀ ਆਸਾਨ ਹੈ।
ਮਨੁੱਖ-ਮਿਤਰ API ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ, ਸਥਿਰ, ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਲਈ ਮੁਸ਼ਕਲ ਹੁੰਦੇ ਹਨ।
ਛੋਟਾ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਉਹ ਘੱਟ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ—ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਰਫੇਸ ਏਰੀਆ ਕੁਝ ਸੰਕਲਪਾਂ ਵਿੱਚ ਕੇਂਦਰਤ ਹੈ ਜੋ ਬੜੀ ਛੇਤੀ ਨਾਲ ਜੋੜਦੇ ਹਨ। ਸਥਿਰ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕੋ ਹੀ ਨਤੀਜਾ ਸਾਰੇ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕੋ ਨਮੂਨੇ ਤੇ ਕੰਮ ਕਰੇ (ਪੈਰਾਮੀਟਰ, ਏਰਰ ਹੈਂਡਲਿੰਗ, ਨਾਂ, ਵਾਪਸੀ ਟਾਈਪ)। ਗਲਤ ਵਰਤੋਂ ਲਈ ਮੁਸ਼ਕਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ API ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਰਾਹੇ ਵਿੱਚ ਲੈ ਜਾਂਦੀ ਹੈ: ਸਪਸ਼ਟ invariants, ਬਾਰਡਰ 'ਤੇ ਵੈਧਤਾ, ਅਤੇ ਟਾਈਪ ਜਾਂ ਰਨਟਾਈਮ ਚੈਕ ਜੋ ਜਲਦੀ ਨਾਕਾਮੀ ਦਿਖਾਉਂਦੇ ਹਨ।
ਹਰ ਵਾਧੂ ਫਲੈਗ, ਮੋਡ, ਜਾਂ "ਸਿਰਫ਼ ਜ਼ਰੂਰਤ ਪੈਣ ਤੇ" ਕਨਫਿਗਰੇਸ਼ਨ ਸਾਰੇ ਉਪਭੋਗਤਿਆਂ ਲਈ ਟੈਕਸ ਬਣ ਜਾਂਦੇ ਹਨ। ਜੇਫਲੈਗ ਦੀ ਲੋੜ ਸਿਰਫ਼ 5% ਕਾਲਰਾਂ ਲਈ ਹੈ, ਤਾਂ 100% ਕਾਲਰਾਂ ਨੂੰ ਹੁਣ ਇਹ ਜ਼ਰੂਰ ਹੀ ਜਾਣਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਇਹ ਮੌਜੂਦ ਹੈ, ਕੀ ਉਹਨਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਜਦੋਂ ਇਹ ਹੋਰ ਵਿਕਲਪਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ ਤਾਂ ਵਿਹਾਰ ਦਾ ਕੀ ਮਤਲਬ ਹੁੰਦਾ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ APIs ਗੁਪਤ ਤੌਰ 'ਤੇ ਜਟਿਲਤਾ ਸੰਚਿਤ ਕਰਦੇ ਹਨ: ਨਾ ਕਿਸੇ ਇਕ ਕਾਲ ਵਿੱਚ, ਪਰ ਕੌਂਬੀਨੈਟੋਰਿਕਸ ਵਿੱਚ।
ਡੀਫਾਲਟ ਇੱਕ ਮੇਹਰਬਾਨੀ ਹਨ: ਉਹ ਜਿਆਦਾਤਰ ਕਾਲਰਾਂ ਨੂੰ ਫੈਸਲੇ ਛੱਡਣ ਦੀ ਆਗਿਆ ਦਿੰਦਿਆਂ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਸਮਝਦਾਰ ਵਿਹਾਰ ਦਿੰਦੇ ਹਨ। ਰਿਵਾਜ (ਇੱਕ ਸਪਸ਼ਟ ਤਰੀਕਾ) ਯੂਜ਼ਰ ਦੇ ਮਨ ਵਿੱਚ branching ਘਟਾਉਂਦੇ ਹਨ। ਨਾਮਨ ਰੀਅਲ ਕੰਮ ਕਰਦਾ ਹੈ: ਕਿਰਿਆ ਅਤੇ ਨਾਂ ਉਹ ਕੰਮ ਜੋਸ਼ਕਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ ਦੀ ਮਨਸ਼ਾ ਨੂੰ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਸਮਾਨ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਮਾਨ ਤਰੀਕੇ ਨਾਲ ਨਾਮ ਦਿਓ।
ਹੋਰ ਇੱਕ ਯਾਦ ਦਿਲਾਉਣ ਵਾਲੀ ਗੱਲ: ਅੰਦਰੂਨੀ APIs ਜਨੇਰਲ-ਪਬਲਿਕ APIs ਨਾਲੋ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ। ਬਹੁਤ ਜਟਿਲਤਾ ਪ੍ਰੋਡਕਟ ਦੇ ਪਿੱਛੇ ਰਹਿੰਦੀ ਹੈ—ਸੇਵਾ ਸੀਮਾਵਾਂ, ਸਾਂਝੇ ਲਾਇਬਰੇਰੀਆਂ, ਅਤੇ “ਹੈਲਪਰ” ਮੌਡੀਊਲ। ਉਹਨਾਂ ਇੰਟਰਫੇਸ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਾਂਗ ਦੇਖੋ, ਸਮੀਖਿਆ ਅਤੇ ਵਰਜ਼ਨਿੰਗ ਅਨੁਸ਼ਾਸਨ ਲਗਾਓ (ਦੇਖੋ ਵੀ /blog/deep-modules).
Complexity ਉਹ ਫ਼ਰਕ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਸਿਸਟਮ ਬਦਲਣ 'ਤੇ ਕਰੇਗਾ ਅਤੇ ਅਸਲ ਵਿਚ ਕੀ ਹੁੰਦਾ ਹੈ।
ਤੁਸੀਂ ਇਸਨੂੰ ਉਸ ਵੇਲੇ ਮਹਿਸੂਸ ਕਰੋ ਜਦੋਂ ਛੋਟੇ ਤਬਦੀਲੀ ਵੀ ਖਤਰਨਾਕ ਲੱਗਣ ਲੱਗ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਨਹੀਂ ਭਾਂਪ ਸਕਦੇ ਕਿ ਇਸਦਾ ਪ੍ਰਭਾਵ ਕਿੱਥੇ-ਕਿੱਥੇ ਪਵੇਗਾ (ਟੈਸਟ, ਸਰਵਿਸز, ਕਨਫਿਗ, ਗਾਹਕ ਜਾਂ ਕੰਢੀ ਮਾਮਲੇ ਜੋ ਤੁਸੀਂ ਤੋੜ ਸਕਦੇ ਹੋ)।
ਉਹ ਸੰਗੇਤ ਜੋ ਸੋਚਣ ਨੂੰ ਮਹਿੰਗਾ ਕਰਦੇ ਹਨ ਉੱਪਰ ਧਿਆਨ ਦਿਓ:
Essential complexity ਡੋਮੇਨ ਤੋਂ ਆਉਂਦੀ ਹੈ (ਕਾਨੂੰਨ, ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਕਿਨਾਰੇ, ਬਿਜਨਸ ਨਿਯਮ). ਇਸਨੂੰ ਮਿਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ—ਸਿਰਫ਼ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਾਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
Accidental complexity ਖੁਦ-ਚਲਾਕੀ ਹੈ (ਲੈਕੀ abstrakts, ਨਕਲ ਹੋਇਆ ਲਾਜ਼ਿਕ, ਬਹੁਤ ਸਾਰੇ ਮੋਡ/ਫਲੈਗ, ਅਸਪਸ਼ਟ APIs). ਇਹ ਉਹ ਹੈ ਜਿਸਨੂੰ ਟੀਮ ਡਿਜ਼ਾਈਨ ਅਤੇ ਸਰਲਤਾ ਰਾਹੀ ਘੱਟ ਕਰ ਸਕਦੀ ਹੈ।
ਇੱਕ ਗਹਿਰਾ ਮੌਡੀਊਲ ਬਹੁਤ ਕੁਝ ਕਰਦਾ ਹੈ ਪਰ ਛੋਟਾ ਤੇ ਸਥਿਰ ਇੰਟਰਫੇਸ ਦਿੰਦਾ ਹੈ। ਇਹ ਦੁਸ਼ਵਾਰੀਆਂ (ਰੀਟ੍ਰਾਈ, ਫਾਰਮੈਟ, ਕ੍ਰਮ, ਨਿਯਮ) ਨੂੰ ਅੰਦਰ ਹੀ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ ਤਾਂ ਕਿ ਕਾਲਰਾਂ ਨੂੰ ਇਹਨਾਂ ਦੀ ਚਿੰਤਾ ਨਾ ਕਰਨੀ ਪਵੇ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਟੈਸਟ: ਜੇ ਜ਼ਿਆਦਾਤਰ ਕਾਲਰ ਮੌਡੀਊਲ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਵਰਤ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਅੰਦਰੂਨੀ ਨਿਯਮ ਜਾਣੇ, ਤਾਂ ਇਹ ਗਹਿਰਾ ਹੈ; ਜੇ ਕਾਲਰਾਂ ਨੂੰ ਨਿਯਮ ਯਾਦ ਰੱਖਣੇ ਪੈਂਦੇ ਹਨ ਤਾਂ ਇਹ ਥੱਲਾ ਹੈ।
ਆਮ ਲੱਛਣ:
legacy, skipValidation, force, mode).ਅਮਲਕਾਰੀ ਨਿਯਮ:
ਜਦੋਂ ਤੁਸੀਂ "ਇੱਕ ਹੋਰ ਵਿਕਲਪ" ਜੋੜਨ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹੋ, ਪਹਿਲਾਂ ਪੁੱਛੋ ਕਿ ਕੀ ਤੁਸੀਂ ਇੰਟਰਫੇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਦਲ ਸਕਦੇ ਹੋ ਕਿ ਜ਼ਿਆਦਾਤਰ ਕਾਲਰ ਨੂੰ ਉਹ ਚੋਣ ਨਾ ਕਰਨ ਦੀ ਲੋੜ ਰਹੇ।
ਫੀਚਰ ਫਲੈਗ ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ ਲਈ ਵਰਤੋ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਕਰਜ਼ੇ ਵਾਂਗ ਸਮਝੋ ਅਤੇ ਹਟਾਉਣ ਦੀ ਯੋੜ ਰੱਖੋ:
ਲੰਬੇ ਸਮੇਂ ਰਹਿਣ ਵਾਲੇ ਫਲੈਗ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਸੋਚਣ ਵਾਲੀਆਂ “ਸਿਸਟਮਾਂ” ਦੀ ਗਿਣਤੀ ਵਧਾ ਦਿੰਦੇ ਹਨ।
ਯੋਜਨਾ ਵਿੱਚ complexity ਨੂੰ ਇੱਕ ਬਜਟ ਵਾਂਗ ਰੱਖੋ:
ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਜਟਿਲਤਾਵਾਂ ਦੀਆਂ ਵਪਾਰ-ਕਦਮ ਪਹਿਲਾਂ ਤੋਂ ਖੁੱਲ੍ਹੀਆਂ ਹੋਣ।
Tactical programming = ਇਸ ਹਫ਼ਤੇ ਲਈ ਢੁੱਕਵਾਂ: ਤੇਜ਼ ਪੈਚ, ਘੱਟ ਬਦਲਾਵ, "ship it".
Strategic programming = ਅਗਲੇ ਸਾਲ ਲਈ ਢੁੱਕਵਾਂ: ਛੋਟੇ ਰੀ-ਡਿਜ਼ਾਈਨ ਜੋ ਮੁੜ-ਮੁੜ ਆਉਂਦੇ ਬੱਗ ਹਟਾਉਂਦੇ ਹਨ ਅਤੇ ਭਵਿੱਖੀ ਕੰਮ ਘਟਾਉਂਦੇ ਹਨ।
ਇਕ ਉਦਾਹਰਣੀ ਨਿਯਮ: ਜੇ ਕੋਈ ਫਿਕਸ ਕਾਲਰ ਗਿਆਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ("ਪਹਿਲਾਂ X ਕਾਲ ਕਰੋ" ਜਾਂ "ਇਹ ਫਲੈਗ ਪ੍ਰੋਡ ਵਿੱਚ ਸਿਰਫ਼ ਸੈੱਟ ਕਰੋ"), ਤਾਂ ਤੁਹਾਨੂੰ ਮੌਡੀਊਲ ਅੰਦਰ ਉਹ ਜਟਿਲਤਾ ਲੁਕਾਉਣ ਲਈ ਸਟ੍ਰੈਟਜਿਕ ਤਬਦੀਲੀ ਚਾਹੀਦੀ ਹੈ।
Tcl ਦੀ ਸਿੱਖਿਆ: ਛੋਟੇ ਪ੍ਰਿਮਿਟਿਵਾਂ ਦਾ ਸੈੱਟ ਅਤੇ ਮਜ਼ਬੂਤ ਰਚਨਾ-ਕੁਸ਼ਲਤਾ — ਅਕਸਰ ਇੱਕ embedded “glue” ਪਰਤ.
ਆਧੁਨਿਕ ਸਮਾਨਤਾਵਾਂ:
ਲਕੜੀ ਇਹੋ: ਕੋਰ ਨੂੰ ਸਧਾਰਨ ਅਤੇ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਸਾਫ਼ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਹੋਣ ਦਿਓ।
ਅਕਸਰ ਥੱਲੇ ਮੌਡੀਊਲ'organized' ਲੱਗਦੇ ਹਨ ਪਰ ਜਟਿਲਤਾ ਹਰ ਕਾਲਰ ਵੱਲ ਬਿਮਾਰ ਕਰ ਦਿੰਦੇ ਹਨ।