27 ਅਗ 2025·8 ਮਿੰਟ
Rob Pike ਦੀ ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ: ਸਰਲ ਟੂਲ, ਤੇਜ਼ Go ਬਿਲਡ
Rob Pike ਦੀ ਪ੍ਰੈਗਮੈਟਿਕ ਸੋਚ ਦੀ ਪੜਚੋਲ ਕਰੋ: ਸਰਲ ਟੂਲ, ਤੇਜ਼ ਬਿਲਡ ਅਤੇ ਪੜ੍ਹਨ ਯੋਗ concurrency—ਅਤੇ ਇਹ ਸੱਚੀ ਟੀਮਾਂ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨੀ ਹੈ।
Rob Pike ਦੀ ਪ੍ਰੈਗਮੈਟਿਕ ਸੋਚ ਦੀ ਪੜਚੋਲ ਕਰੋ: ਸਰਲ ਟੂਲ, ਤੇਜ਼ ਬਿਲਡ ਅਤੇ ਪੜ੍ਹਨ ਯੋਗ concurrency—ਅਤੇ ਇਹ ਸੱਚੀ ਟੀਮਾਂ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨੀ ਹੈ।
ਇਹ ਇੱਕ ਵਰਤੋਂਗਤ ਫਿਲਾਸਫੀ ਹੈ, Rob Pike ਦੀ ਜੀਵਨੀ ਨਹੀਂ। Pike ਦਾ Go 'ਤੇ ਪ੍ਰਭਾਵ ਹਕੀਕਤ ਹੈ, ਪਰ ਇੱਥੇ ਮਕਸਦ ਹੋਰ ਉਪਯੋਗੀ ਹੈ: ਉਹ ਤਰੀਕਾ ਨਾਮਿਤ ਕਰਨਾ ਜੋ ਚਤੁਰਾਈ ਦੀ ਜਗ੍ਹਾ ਨਤੀਜਿਆਂ ਲਈ ਬਣਾਉਂਦਾ ਹੈ।
"ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ" ਨਾਲ ਮੇਰਾ ਮਤਲਬ ਹੈ ਐਸੇ ਫੈਸਲਿਆਂ ਵੱਲ ਝੁਕਾਅ ਜੋ ਅਸਲੀ ਸਿਸਟਮਾਂ ਨੂੰ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਬਣਾਉਣਾ, ਚਲਾਉਣਾ ਅਤੇ ਬਦਲਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਉਹ ਟੂਲ ਅਤੇ ਡਿਜ਼ਾਈਨ ਮੁੱਲਾਂਕਣ ਕਰਦਾ ਹੈ ਜੋ ਪੂਰੇ ਟੀਮ ਲਈ friction ਘਟਾਉਂਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਜਦ ਕੋਡ ਕਿਸੇ ਦੇ ਮਨ ਵਿੱਚ ਤਾਜ਼ਾ ਨਹੀਂ ਰਹਿੰਦਾ।
ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਇਹ ਪੁੱਛਣ ਦੀ ਆਦਤ ਹੈ:
ਜੇ ਕੋਈ ਤਕਨੀਕ ਸੁੰਦਰ ਹੈ ਪਰ ਵਿਕਲਪ, ਸੰਰਚਨਾ, ਜਾਂ ਮਾਨਸਿਕ ਭਾਰ ਵਧਾਉਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਇਸਨੂੰ ਖ਼ਰਚਾ ਸਮਝਦਾ ਹੈ—ਕੋਈ ਸ਼ਾਨ-ਦਰਜਾ ਨਹੀਂ।
ਇਸ ਨੂੰ ਜ਼ਮੀਨੀ ਬਣਾਈ ਰੱਖਣ ਲਈ, ਲੇਖ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਤਿੰਨ ਸਤੰਭਾਂ 'ਤੇ ਅਧਾਰਤ ਹਨ ਜੋ Go ਦੀ ਸੰਸਕ੍ਰਿਤੀ ਅਤੇ ਟੂਲਿੰਗ ਵਿੱਚ ਵਾਰ-ਵਾਰ ਵੇਖੇ ਜਾਂਦੇ ਹਨ:
ਇਹ "ਨਿਯਮ" ਨਹੀਂ ਹਨ। ਇਹ ਚੋਣਾਂ ਕਰਨ ਵੇਲੇ ਲੋਕਰੀਆਂ ਬਣਾਉਣ ਲਈ ਇੱਕ ਲੈਂਸ ਹਨ—ਲਾਇਬ੍ਰੇਰੀਆਂ ਚੁਣਦੇ ਸਮੇਂ, ਸੇਵਾਵਾਂ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਸਮੇਂ, ਜਾਂ ਟੀਮ ਰਵਾਇਤਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਸਮੇਂ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਐੰਜਨੀਅਰ ਹੋ ਜੋ ਘੱਟ ਬਿਲਡ ਹੈਰਾਨੀਆਂ ਚਾਹੁੰਦਾ ਹੈ, ਇੱਕ ਟੈਕ ਲੀਡ ਜੋ ਟੀਮ ਨੂੰ ਇੱਕ ਰੇਖਾ 'ਤੇ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਇੱਕ ਜਿਗਿਆਸੂ ਸ਼ੁਰੂਆਤੀ ਜਿਸ ਨੂੰ ਪਤਾ ਕਰਨਾ ਹੈ ਕਿ Go ਵਾਲੇ ਲੋਕ ਸਾਦਗੀ ਬਾਰੇ ਕਿਉਂ ਹੋਰ ਬਹੁਤ ਗੱਲ ਕਰਦੇ ਹਨ—ਇਹ ਫਰੇਮਿੰਗ ਤੁਹਾਡੇ ਲਈ ਹੈ। ਤੁਹਾਨੂੰ Go ਇੰਟਰਨਲ ਦੀ ਲੋੜ ਨਹੀਂ; ਸਿਰਫ਼ ਇਹ ਜਾਣਨ ਦੀ ਰੁਚੀ ਕਿ ਰੋਜ਼ਾਨਾ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲੇ ਕਿਵੇਂ ਸ਼ਾਂਤ ਸਿਸਟਮਾਂ ਬਣਾਉਂਦੇ ਹਨ।
ਸਾਦਗੀ ਸਵਾਦ ਬਾਰੇ ਨਹੀਂ ਹੈ ("ਮੈਨੂੰ ਘੱਟ ਕੋਡ ਪਸੰਦ ਹੈ")—ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਲਈ ਇੱਕ ਉਤ্পਾਦ ਫੀਚਰ ਹੈ। Rob Pike ਦੀ ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਸਾਦਗੀ ਨੂੰ ਜੋ deliberate ਚੋਣਾਂ ਨਾਲ ਖਰੀਦਿਆ ਜਾ ਸਕਦਾ ਹੈ ਉਹ ਮੰਨਦੀ ਹੈ: ਘੱਟ moving parts, ਘੱਟ ਖਾਸ ਮਾਮਲੇ, ਅਤੇ ਘੱਟ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਦੇ ਮੌਕੇ।
ਜਟਿਲਤਾ ਹਰ ਕੰਮ ਦੇ ਕਦਮ 'ਤੇ ਟੈਕਸ ਲਗਾਉਂਦੀ ਹੈ। ਇਹ ਫੀਡਬੈਕ ਨੂੰ ਧੀਮਾ ਕਰ ਦਿੰਦੀ ਹੈ (ਲੰਮੇ ਬਿਲਡ, ਲੰਮੇ ਸਮੀਖਿਆਵਾਂ, ਲੰਮੇ ਡੀਬੱਗਿੰਗ), ਅਤੇ ਗਲਤੀਆਂ ਵਧਾ ਦਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਯਾਦ ਰੱਖਣ ਲਈ ਹੋਰ ਕਈ ਨਿਯਮ ਹਨ ਅਤੇ ਹੋਰ ਐੱਜ ਕੇਸ ਹਨ।
ਇਹ ਟੈਕ ਟੀਮ 'ਚ ਵਧਦਾ ਹੈ। ਇੱਕ "ਚਤੁਰ" ਟ੍ਰਿਕ ਜੋ ਇੱਕ ਵਿਕਾਸਕਾਰ ਦੇ ਲਈ ਪੰਜ ਮਿੰਟ ਬਚਾਉਂਦੀ ਹੈ, ਉਹ ਅਗਲੇ ਪੰਜ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਘੰਟਾ ਖ਼ਰਚ ਕਰਵਾ ਸਕਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦ ਉਹ on-call ਹੋਣ, ਥੱਕੇ ਹੋਣ ਜਾਂ ਕੋਡਬੇਸ 'ਚ ਨਵੇਂ ਹੋਣ।
ਕਈ ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਜਿਵੇਂ ਸਭ ਤੋਂ ਵਧੀਆ-ਹਾਲਾਤ ਵਿਕਾਸਕਾਰ ਹਰ ਵਕਤ ਉਪਲਬਧ ਹੋਵੇ: ਉਹ ਵਿਅਕਤੀ ਜੋ ਲੁਕੀਆਂ ਹੋਈਆਂ invariants, ਇਤਿਹਾਸਕ ਸੰਦਰਭ, ਅਤੇ ਵਰਕਅਰਾਊਂਡ ਦਾ ਇਕ ਅਜੀਬ ਕਾਰਨ ਜਾਣਦਾ ਹੋਵੇ। ਟੀਮਾਂ ਐਸੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ।
ਸਾਦਗੀ ਮੀਡੀਅਨ ਦਿਨ ਅਤੇ ਮੀਡੀਅਨ ਯੋਗਦਾਨਕর্তਾ ਲਈ optimize ਕਰਦੀ ਹੈ। ਇਹ ਬਦਲਾਵਾਂ ਕਰਨ ਨੂੰ ਸੁਰੱਖਿਅਤ, ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ, ਅਤੇ ਵਾਪਸੀ ਕਰਨ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਇੱਥੇ concurrency ਵਿੱਚ "ਪ੍ਰਭਾਵਸ਼ਾਲੀ" ਅਤੇ "ਮੈਣਟੇਨੇਬਲ" ਦਾ ਫਰਕ ਹੈ। ਦੋਹਾਂ ਸਹੀ ਹਨ, ਪਰ ਇੱਕ ਤਣਾਅ ਹੇਠ ਸੌਖਾ ਰੀਜ਼ਨ ਕਰਨ ਯੋਗ ਹੈ:
// Confusing: hard to follow, hidden coordination.
for _, job := range jobs {
go func() { do(job) }() // also a common closure gotcha
}
// Clear: explicit data flow and ownership.
for _, job := range jobs {
job := job
go func(j Job) {
do(j)
}(job)
}
"ਸਪੱਸ਼ਟ" ਵਰਜ਼ਨ ਲੰਬਾ ਹੋਣ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਇਹ ਇਰਾਦਾ ਸਪੱਸ਼ਟ ਕਰਨ ਬਾਰੇ ਹੈ: ਕਿਹੜਾ ਡੇਟਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਕਿਸ ਦੀ ਮਾਲਕੀ ਹੈ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਬਹਿੰਦਾ ਹੈ। ਉਹ ਪੜ੍ਹਨਯੋਗਤਾ ਹੀ ਹੈ ਜੋ ਮਹੀਨਿਆਂ ਵਿੱਚ ਟੀਮ ਨੂੰ ਤੇਜ਼ ਰੱਖਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਮਿੰਟਾਂ ਲਈ।
Go ਇੱਕ ਜਾਨ-ਬੁਝ ਕੇ ਦਾਅਵਾ ਕਰਦਾ ਹੈ: ਇੱਕ ਸੁਸੰਗਤ, "ਰੁੱਤੀਲਾ" ਟੂਲਚੇਨ ਪ੍ਰੋਡਕਟੀਵਟੀ ਫੀਚਰ ਹੈ। ਫਾਰਮੇਟਿੰਗ, ਬਿਲਡ, ਡੀਪੈਂਡੈਂਸੀ ਮੈਨੇਜਮੈਂਟ ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਇੱਕ ਕਸਟਮ ਸਟੈਕ ਬਣਾਉਣ ਦੀ ਥਾਂ, Go ਉਹ ਡੀਫੋਲਟ ਭੇਜਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਤੁਰੰਤ اپنا ਸਕਦੀਆਂ ਹਨ—gofmt, go test, go mod, ਅਤੇ ਇੱਕ ਬਿਲਡ ਸਿਸਟਮ ਜੋ ਮਸ਼ੀਨਾਂ 'ਤੇ ਇਕੋ ਜਿਹਾ ਵਿਹਾਰ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸਟੈਂਡਰਡ ਟੂਲਚੇਨ ਚੋਣ ਦੇ ਲੁਕਏ ਟੈਕਸ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਜਦ ਹਰ ਰਿਪੋ ਵਿੱਚ ਵੱਖ-ਵੱਖ linter, ਬਿਲਡ ਸਕ੍ਰਿਪਟ, ਅਤੇ ਰਵਾਇਤਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਸੈਟਅੱਪ, ਬਹਿਸ ਅਤੇ ਇਕ-ਵਾਰੀ ਫਿਕਸਾਂ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। Go ਦੇ ਡੀਫੋਲਟ ਨਾਲ, ਤੁਸੀਂ ਕੰਮ ਕਰਨ ਲਈ ਜ਼ਿਆਦਾ ਊਰਜਾ ਨੈਗੋਸ਼ੀਏਟ ਕਰਨ ਦੀ ਬਜਾਏ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹ ਸਥਿਰਤਾ ਫੈਸਲੇ ਥਕਾਵਟ ਨੂੰ ਵੀ ਘਟਾਉਂਦੀ ਹੈ। ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰੱਖਣਾ ਪੈਂਦਾ "ਕਿਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਕਿਹੜਾ ਫਾਰਮੇਟਰ ਹੈ?" ਜਾਂ "ਇੱਥੇ ਟੈਸਟ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਨ?" ਉਮੀਦ ਸਧਾਰਨ ਹੈ: ਜੇ ਤੁਸੀਂ Go ਜਾਣਦੇ ਹੋ, ਤੁਸੀਂ ਯੋਗਦਾਨ ਦੇ ਸਕਦੇ ਹੋ।
ਸਾਂਝੇ ਰਵਾਇਤਾਂ ਸਹਿਯੋਗ ਨੂੰ ਸੁਚਾਰੂ ਬਣਾਉਂਦੀਆਂ ਹਨ:
gofmt ਸ਼ੈਲੀ ਬਾਰੇ ਹੋਰ ਬਹਿਸ ਅਤੇ ਸ਼ੋਰ-ਭਰੇ ਡਿਫਸ ਨੂੰ ਖ਼ਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।go test ./... ਹਰ ਜਗ੍ਹਾ ਕੰਮ ਕਰਦਾ ਹੈ।go.mod ਮਨਸੂਬਾ ਦਰਜ ਕਰਦਾ ਹੈ, tribal knowledge ਨਹੀਂ।ਇਹ ਪੇਸ਼ਗੋਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਓਨਬੋਰਡਿੰਗ ਦੌਰਾਨ ਕੀਮਤੀ ਹੈ। ਨਵੇਂ ਸਾਥੀ ਕਲੋਨ ਕਰਕੇ, ਚਲਾ ਕੇ, ਅਤੇ ਬਿਨਾਂ bespoke tooling ਦੇ ਟੂਰ ਦੇ ਤੁਰੰਤ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹਨ।
ਟੂਲਿੰਗ ਸਿਰਫ਼ "ਬਿਲਡ" ਨਹੀਂ ਹੈ। ਜ਼ਿਆਦਾਤਰ Go ਟੀਮਾਂ ਵਿੱਚ, ਪ੍ਰੈਗਮੈਟਿਕ ਬੇਸਲਾਈਨ ਛੋਟੀ ਅਤੇ ਦੁਹਰਾਓਯੋਗ ਹੁੰਦੀ ਹੈ:
gofmt (ਅਤੇ ਕਦੇ-ਕਦੇ goimports)go doc ਅਤੇ ਪੈਕੇਜ ਟਿੱਪਣੀਆਂ ਜੋ ਸੁੰਦਰ ਦਸਤੀਅਾਬ ਵਿੱਚ ਰੈਂਡਰ ਹੁੰਦੀਆਂ ਹਨgo test (ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ -race ਦੇ ਨਾਲ)go mod tidy, ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ go mod vendor)go vet (ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਛੋਟੀ lint policy)ਇਸ ਸੂਚੀ ਨੂੰ ਛੋਟਾ ਰੱਖਣ ਦਾ ਮਕਸਦ ਸਮਾਜਿਕ ਹੈ ਜਿੰਨਾ ਕਿ ਤਕਨੀਕੀ: ਘੱਟ ਚੋਈਸਾਂ ਦਾ ਮਤਲਬ ਘੱਟ ਵਾਦ-ਵਿਵਾਦ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ।
ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਟੀਮ ਰਵਾਇਤਾਂ ਦੀ ਲੋੜ ਹੈ—ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਨੂੰ ਹਲਕਾ ਰੱਖੋ। ਇੱਕ ਛੋਟੀ /CONTRIBUTING.md ਜਾਂ /docs/go.md ਉਹ ਕੁਝ ਫੈਸਲੇ ਪਕੜ ਸਕਦੀ ਹੈ ਜੋ ਡੀਫੋਲਟ ਨਾਲ ਕਵਰ ਨਹੀਂ ਹੁੰਦੇ (CI ਕਮਾਂਡ, ਮਾਡਿਊਲ ਸੀਮਾਵਾਂ, ਪੈਕੇਜਾਂ ਦੇ ਨਾਮ ਰੱਖਣ ਦੇ ਨਿਯਮ)। ਮਕਸਦ ਇੱਕ ਛੋਟਾ, ਜੀਵੰਤ ਰੇਫਰੈਂਸ ਹੈ—ਨ ਕਿ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪੁਸਤਕ।
"ਤੇਜ਼ ਬਿਲਡ" ਸਿਰਫ਼ ਕੈਂਪਾਈਲੇਸ਼ਨ ਦੇ ਸਕਿੰਟ ਘਟਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਹੈ ਤੇਜ਼ ਫੀਡਬੈਕ: "ਮੈਂ ਬਦਲਾਅ ਕੀਤਾ" ਤੋਂ "ਮੈਨੂੰ ਪਤਾ ਲੱਗਿਆ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ/ਨਹੀਂ ਕਰਦਾ" ਤੱਕ ਦਾ ਸਮਾਂ। ਇਸ ਲੂਪ ਵਿੱਚ ਕੁਝ ਹੋਰ ਵੀ ਸ਼ਾਮਿਲ ਹਨ: ਕੰਪਾਇਲੇਸ਼ਨ, ਲਿੰਕ, ਟੈਸਟ, linter, ਅਤੇ CI ਤੋਂ ਸਿਗਨਲ ਮਿਲਣ ਦਾ ਵੈਟ ਸਮਾਂ।
ਜਦ ਫੀਡਬੈਕ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ, ਇੰਜੀਨੀਅਰ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ ਕਰਦੇ ਹਨ। ਤੁਸੀਂ ਵਧੇਰੇ incremental commits, ਘੱਟ "ਮੇਗਾ-PRs", ਅਤੇ ਘੱਟ ਸਮਾਂ ფੈਸਲਾ ਕਰਨ ਲਈ ਬਦਲਾਅ ਦੀ ਡੀਬੱਗਿੰਗ ਦੇਖੋਗੇ।
ਤੇਜ਼ ਲੂਪ ਲੋਕਾਂ ਨੂੰ ਅਕਸਰ ਟੈਸਟ ਚਲਾਉਣ ਉਤਸ਼ਾਹਤ ਕਰਦੇ ਹਨ। ਜੇ go test ./... ਚਲਾਉਣਾ ਸਸਤਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਲੋਕ ਪਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਸਮੀਖਿਆ ਕਮੈਂਟ ਜਾਂ CI ਫੇਲ ਤੋਂ ਬਾਅਦ। ਸਮੇਂ ਨਾਲ, ਇਹ ਵਰਤਾਰੂ ਵਾਧਾ ਕਰਦਾ ਹੈ: ਘੱਟ ਟੁੱਟੇ ਬਿਲਡ, ਘੱਟ "ਲਾਈਨ ਰੋਕੋ" ਪਲ ਅਤੇ ਘੱਟ ਕੰਟੈਕਸਟ-ਸਵਿੱਚਿੰਗ।
ਧੀਮੇ ਲੋਕਲ ਬਿਲਡ ਸਿਰਫ਼ ਸਮਾਂ ਖ਼ਰਚ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਆਦਤਾਂ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਲੋਕ ਟੈਸਟਿੰਗ ਨੂੰ ਰੋਕ ਦਿੰਦੇ ਹਨ, ਬਦਲਾਅ ਨੂੰ ਬੈਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾ ਮਾਨਸਿਕ ਸਟੇਟ ਨੂੰ ਆਪਣੀ ਸਿਰ 'ਚ ਰੱਖਦੇ ਹਨ। ਇਹ ਖਤਰਾ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਫੇਲਿਉਰਾਂ ਦੀ ਪਹਚਾਣ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ।
ਧੀਮੀ CI ਹੋਰ ਲਾਗਤ ਜੋੜਦਾ ਹੈ: ਕਿਊ ਸਮਾਂ ਅਤੇ "ਡੈਡ ਟਾਈਮ"। ਇੱਕ 6-ਮਿੰਟ ਪਾਈਪਲਾਈਨ ਵੀ 30 ਮਿੰਟ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਇਹ ਹੋਰ ਨੌਕਰੀਆਂ ਦੇ ਪਿੱਛੇ ਫਸਿਆ ਹੋਇਆ ਹੈ, ਜਾਂ ਜੇ ਫੇਲਿਉਰ ਉਸ ਵੇਲੇ ਆਂਦੇ ਹਨ ਜਦ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ਕੰਮ 'ਤੇ ਗਏ ਹੋ। ਨਤੀਜਾ ਹੈ ਟੁੱਟੀ-ਫੈਲੂ, ਵੱਧ ਰੀਵਰਕ, ਅਤੇ ਵਿਚਾਰ ਤੋਂ ਮਰਜ ਤੱਕ ਲੰਬੇ ਲੀਡ ਟਾਈਮ।
ਤੁਸੀਂ ਬਿਲਡ ਸਪੀਡ ਨੂੰ ਕਿਸੇ ਹੋਰ ਇੰਜੀਨੀਅਰਿੰਗ ਨਤੀਜੇ ਵਾਂਗ ਸੰਭਾਲ ਸਕਦੇ ਹੋ ਇਹ ਕੁਝ ਸਧਾਰਨ ਨੰਬਰ ਟ੍ਰੈਕ ਕਰਕੇ:
ਅਜੇ ਵੀ ਹਲਕਾ ਮਾਪਨ—ਹਫਤਾਵਾਰੀ ਰਿਕਾਰਡ ਕੀਤਾ—ਟੀਮਾਂ ਨੂੰ ਰੈਗ੍ਰੈਸ਼ਨ ਜਲਦੀ ਪਕੜਨ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ ਸੁਧਾਰਨ ਲਈ ਕਾਰਨ ਦਿਖਾਉਂਦਾ ਹੈ। ਤੇਜ਼ ਬਿਲਡ ਨਿਰਮਲਤਾ ਨਹੀਂ; ਇਹ ਧਿਆਨ, ਗੁਣਵੱਤਾ, ਅਤੇ ਗਤੀ 'ਤੇ ਰੋਜ਼ਾਨਾ ਗੁਣਾ ਬਢਾਉਂਦੇ ਹਨ।
Concurrency abstract ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਮਨੁੱਖੀ ਬੋਲ ਵਿੱਚ ਵਰਣਨ ਨਹੀਂ ਕਰਦੇ: ਉਡੀਕ, ਸਮਨਵਯ, ਅਤੇ ਸੰਚਾਰ।
ਇੱਕ ਰੈਸਟੋਰੈਂਟ ਵਿੱਚ ਕਈ ਆਰਡਰ ਇੱਕੱਠੇ ਚੱਲ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਕਿਚਨ ਇਹ ਨਹੀਂ ਹੈ ਕਿ "ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਇੱਕ ਸਮੇਂ 'ਤੇ" ਹੋ ਰਹੀਆਂ ਹਨ, ਬਲਕਿ ਇਹ ਕੰਮਾਂ ਨੂੰ ਸੰਭਾਲ ਰਿਹਾ ਹੈ ਜੋ ਸਮਾਂ ਵੱਡਾ ਕਰਦੀਆਂ ਹਨ—ਸਮੱਗਰੀ, ਓਵਨ, ਜਾਂ ਇਕ ਦੂਜੇ ਉੱਤੇ ਉਡੀਕ ਕਰਨ। ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਟੀਮ ਕਿਵੇਂ ਕੋਆਰਡੀਨੇਟ ਕਰਦੀ ਹੈ ਤਾਂ ਕਿ ਆਰਡਰ ਮਿਲੇ-ਜੁਲੇ ਨਾ ਹੋਣ ਅਤੇ ਕੰਮ ਦੁਹਰਾਇਆ ਨਾ ਜਾਵੇ।
Go concurrency ਨੂੰ ਐਸੇ ਤਰੀਕੇ ਨਾਲ ਸੋਝੀਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕੋਡ ਵਿੱਚ ਸਿੱਧਾ ਪ੍ਰਗਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਸਨੂੰ ਇਕ ਪਜ਼ਲ ਬਣਾਉਣ ਦੇ।
ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ goroutines ਜਾਦੂ ਹਨ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਉਹ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਲਈ ਛੋਟੇ ਹਨ, ਅਤੇ channels "ਕੌਣ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ" ਦੀ ਕਹਾਣੀ ਦਿੱਖਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਇਹ ਨारा ਘੱਟ-ਜ਼ਿਆਦਾ ਇੱਕ ਹਦਾਇਤ ਹੈ ਜੋ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਜੇ ਕਈ goroutines ਇੱਕੋ ਸਾਂਝੀ ਡੇਟਾ ਢਾਂਚੇ ਵਿੱਚ ਹੱਥ ਲਾਉਂਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਟਾਈਮਿੰਗ ਅਤੇ ਲਾਕਸ ਬਾਰੇ ਸੋਚਣਾ ਪਵੇਗਾ। ਜੇ ਦੁਆਰਾ ਉਹ ਮੁੱਲ ਚੈਨਲ ਰਾਹੀਂ ਭੇਜੇ ਜਾਂ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਮਾਲਕੀ ਸਪੱਸ਼ਟ ਰੱਖ ਸਕਦੇ ਹੋ: ਇੱਕ goroutine ਉਤਪਾਦਨ ਕਰਦਾ, ਦੂਜਾ ਖਪਤ ਕਰਦਾ, ਅਤੇ ਚੈਨਲ ਹੱਥ-ਮਾਰਨੀ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਅਪਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਪ੍ਰੋਸੈਸ ਕਰਨੀਆਂ ਹਨ:
ਇੱਕ ਪਾਈਪਲਾਈਨ ਫਾਈਲ ID ਪੜ੍ਹਦਾ, ਇੱਕ ਵਰਕਰ ਪੂਲ ਉਹਨਾਂ ਨੂੰ ਸਮਕਾਲੀ ਤੌਰ 'ਤੇ ਪਾਰਸ ਕਰਦਾ, ਅਤੇ ਆਖਰੀ ਪੜਾਅ ਨਤੀਜੇ ਲਿਖਦਾ।
ਰੱਦਗੀ ਉਸ ਵੇਲੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ ਜਦ ਯੂਜ਼ਰ ਟੈਬ ਬੰਦ ਕਰ देता ਹੈ ਜਾਂ ਕੋਈ ਬੇਨਤੀ timeouts ਹੋ ਜਾਂਦੀ ਹੈ। Go ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ context.Context ਸੇਜਾ ਰਾਹੀਂ ਸਾਰੇ ਪੜਾਅਾਂ ਵਿੱਚ ਫੈਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਵਰਕਰ ਤੁਰੰਤ ਰੁਕ ਸਕਦੇ ਹਨ ਜਦ ਸੰਦਰਭ ਡਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਮਹਿੰਗੇ ਕੰਮ "ਸਿਰਫ਼ ਇਸ ਲਈ ਜਾਰੀ ਰਹਿਣ"।
ਨਤੀਜਾ ਉਹ concurrency ਹੈ ਜੋ ਇੱਕ ਵਰਕਫਲੋ ਵਰਗੀ ਪੜ੍ਹੀ ਜਾ ਸਕਦੀ ਹੈ: ਇਨਪੁਟ, ਹੈਂਡਆਫ਼, ਅਤੇ ਰੋਕਣ ਦੀਆਂ ਸ਼ਰਤਾਂ—ਜਿਆਦਾ ਮਨੁੱਖਾਂ ਵਿਚਕਾਰ ਸਹਿਯੋਗ ਵਰਗਾ, ਨਾ ਕਿ ਸਾਂਝੀ ਸਟੇਟ ਦੀ ਭੂਤਲ ਭੁੱਲਭੁੱਲੈਯਾ।
Concurrency ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦ "ਕੀ ਹੋਵੇਗਾ" ਅਤੇ "ਕਿੱਥੇ ਹੋਵੇਗਾ" ਅਸਪੱਸ਼ਟ ਹੁੰਦੇ ਹਨ। ਮਕਸਦ ਚਤੁਰਾਈ ਦਿਖਾਉਣਾ نہیں—ਇਹ ਅਗਲੇ ਪਾਠਕ ਲਈ ਫਲੋ ਸਪੱਸ਼ਟ ਕਰਨਾ ਹੈ (ਅਕਸਰ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ ਖੁਦ)।
ਸਪੱਸ਼ਟ ਨਾਮਕਰਨ concurrency ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ। ਜੇ ਇੱਕ goroutine ਲਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ, ਤਾਂ ਫੰਕਸ਼ਨ ਨਾਂਮ ਇਹ ਵਿਆਖਿਆ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਉਂ ਇਹ ਮੌਜੂਦ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ: fetchUserLoop, resizeWorker, reportFlusher। ਇਸਨੂੰ ਛੋਟੇ ਫੰਕਸ਼ਨਾਂ ਨਾਲ ਜੋੜੋ ਜੋ ਇੱਕ ਹੀ ਕਦਮ ਕਰਦੇ ਹਨ—ਪੜ੍ਹੋ, ਤਬਦੀਲ ਕਰੋ, ਲਿਖੋ—ਤਾਂ ਕਿ ਹਰ goroutine ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸਾਫ਼ ਹੋਵੇ।
ਇੱਕופרਦਾਈ ਆਦਤ "wiring" ਨੂੰ "work" ਤੋਂ ਵੰਡਣਾ ਹੈ: ਇੱਕ ਫੰਕਸ਼ਨ ਚੈਨਲ, contexts, ਅਤੇ goroutines ਸੈਟਅਪ ਕਰਦਾ; worker ਫੰਕਸ਼ਨਸ ਅਸਲ ਬਿਜ਼ਨੈਸ ਲLogic ਕਰਦੇ ਹਨ। ਇਸ ਨਾਲ ਜੀਵਨਕਾਲ ਅਤੇ ਸ਼ਟਡਾਊਨ ਬਾਰੇ ਸੋਚਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਅਨਬਾਊਂਡਡ concurrency ਆਮ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਤਰੀਕੇ ਨਾਲ fail ਹੁੰਦੀ ਹੈ: memory ਵਧਦੀ ਹੈ, queue ਭਰ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸ਼ਟਡਾਊਨ ਗੰਢਲਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਬੇਟਰ ਹੈ ਬਾਊਂਡਡ ਕਿਊਜ਼ (buffered channels with a defined size) ਤਾ ਕਿ backpressure ਸਪੱਸ਼ਟ ਹੋਵੇ।
context.Context ਨੂੰ lifetime ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਵਰਤੋਂ, ਅਤੇ timeout ਨੂੰ API ਦਾ ਹਿੱਸਾ ਮੰਨੋ:
ਜਦ ਤੁਸੀਂ ਡੇਟਾ " Moving" ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਘਟਨਾਵਾਂ ਨੂੰ coordinate ਕਰ ਰਹੇ ਹੋ (fan-out workers, pipelines, cancellation signals), ਤਾਂ channels ਪੜ੍ਹਨ ਲਈ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ। ਜਦ ਤੁਸੀਂ ਛੋਟੇ critical sections ਨਾਲ ਸਾਂਝੀ ਰਾਜ ਦੀ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹੋ ਤਾਂ mutexes ਪੜ੍ਹਨ ਲਈ ਵਧੀਆ ਹੁੰਦੇ ਹਨ।
ਨਿਯਮ: ਜੇ ਤੁਸੀਂ struct ਨੂੰ ਮਿਉਟੇਟ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਚੈਨਲ ਰਾਹੀਂ "ਕਮਾਂਡ" ਭੇਜ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਲਾਕ ਬਿਹਤਰ ਹੋ ਸਕਦੀ ਹੈ।
ਮਾਡਲ ਮਿਲਾਪੀਡ ਕਰਨਾ ਠੀਕ ਹੈ। ਇੱਕ ਸਿੱਧਾ sync.Mutex ਇੱਕ ਮੈਪ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੋਰ ਪੜ੍ਹਨਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਬਜਾਏ ਕਿ ਇੱਕ ਵਿਆਪਕ "map owner goroutine" ਬਣਾਉਣ ਅਤੇ request/response ਚੈਨਲ। ਇੱਥੇ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਦਾ ਅਰਥ ਉਹੀ ਹੈ ਕਿ ਸੰਦ ਚੁਣੋ ਜੋ ਕੋਡ ਨੂੰ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਰੱਖੇ—ਅਤੇ concurrency ਸੰਰਚਨਾ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਰੱਖੋ।
Concurrency ਬੱਗ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੋਰ-ਸ਼राबਾ ਨਾਲ fail ਨਹੀਂ ਹੁੰਦੇ। ਜਿਆਦातर ਉਹ "ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ ਚੱਲਦਾ ਹੈ" ਟਾਈਮਿੰਗ ਨਾਲ ਛੁਪੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਲੋਡ ਹੇਠ, ਢੀਢੀ CPU 'ਤੇ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਰੀਫੈਕਟਰ ਲਾਭ ਬਾਦ surface ਹੁੰਦੇ ਹਨ।
Leaks: ਗੋਰੂਟੀਨ ਜੋ ਕਦੇ ਬੰਦ ਨਹੀਂ ਹੁੰਦੇ (ਅਕਸਰ ਕਿਉਂਕਿ ਕੋਈ ਚੈਨਲ ਤੋਂ ਪੜ੍ਹਦਾ ਨਹੀਂ, ਜਾਂ ਇੱਕ select ਅੱਗੇ ਨਹੀਂ ਵੱਧ ਸਕਦਾ)। ਇਹ ਸਦਾ-ਨਹੀਂ ਕਰਾਸ ਕਰਦੇ—ਪਰ memory ਅਤੇ CPU ਵਰਤੋਂ ਹੌਲੀ-ਹੌਲੀ ਵਧਦੀ ਹੈ।
Deadlocks: ਦੋ (ਜਾਂ ਵੱਧ) goroutines ਜੋ ਇਕ ਦੂਜੇ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ। ਆਮ ਉਦਾਹਰਨ ਹੈ ਇੱਕ ਲਾਕ ਰੱਖਦਿਆਂ ਹੋਏ ਉਹ ਚੈਨਲ 'ਤੇ ਭੇਜਣਾ ਜੋ ਦੂਜੇ goroutine ਨੂੰ ਲਾਕ ਜ਼ਰੂਰਤ ਹੈ।
Silent blocking: ਕੋਈ ਕੋਡ ਬਿਨਾਂ panic ਕੀਤੇ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਕ unbuffered channel send ਜਿਸਦਾ ਕੋਈ receiver ਨਹੀਂ, ਇੱਕ ਚੈਨਲ 'ਤੇ receive ਜੋ ਕਦੇ close ਨਹੀਂ ਹੁੰਦਾ, ਜਾਂ ਇੱਕ select ਜਿਸ ਵਿੱਚ default/timeout ਨਹੀਂ—ਇਹ ਸਭ diff ਵਿੱਚ "ਠੀਕ" ਦਿਸ ਸਕਦੇ ਹਨ।
Data races: ਸਾਂਝੀ ਸਥਿਤੀ ਬਿਨਾਂ synchronization ਦੇ ਪਹੁੰਚੀ ਜਾ ਰਹੀ। ਇਹ ਖ਼ਤਰਨਾਕ ਹਨ ਕਿਉਂਕਿ ਇਹ ਮਹੀਨਿਆਂ ਤੱਕ tests ਨੂੰ ਪਾਸ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਇੱਕ ਵਾਰੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ।
Concurrent ਕੋਡ interleavings 'ਤੇ ਨਿਰਭਰ ਹੈ ਜੋ PR ਵਿੱਚ ਦਿੱਖ ਨਹੀਂ ਰਹਿੰਦੀਆਂ। ਇੱਕ ਰਿਵਿਊਅਰ ਇੱਕ ਸਾਫ goroutine ਅਤੇ ਇੱਕ ਚੈਨਲ ਵੇਖ ਸਕਦਾ ਹੈ, ਪਰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਇਹ ਸਾਬਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ: "ਕੀ ਇਹ goroutine ਸਦਾ ਰੁਕੇਗੀ?", "ਕੀ ਹਮੇਸ਼ਾ ਕੋਈ receiver ਹੋਵੇਗਾ?", "ਜੇ ਅਪਸਟਰੀਮ ਰੱਦ ਕਰ ਦੇਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?", "ਜੇ ਇਹ ਕਾਲ ਬਲੌਕ ਕਰਦੀ ਹੈ ਤਾਂ?" ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ (ਬਫਰ ਆਕਾਰ, ਐਰਰ ਰਾਹ, ਜਲਦੀ ਰਿਟਰਨ) ਧਾਰਨਾਵਾਂ ਨੂੰ ਅਮਾਨਯੋਗ ਕਰ ਸਕਦੇ ਹਨ।
ਟਾਈਮਆਊਟ ਅਤੇ ਰੱਦਗੀ (context.Context) ਵਰਤੋ ਤਾਂ ਕਿ آپਰੇਸ਼ਨ ਦੇ ਕੋਲ ਇੱਕ ਸਪੱਸ਼ਟ ਐਸਕੇਪ ਹੈ।
ਬਾਉਂਡਰੀਜ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਟ੍ਰਕਚਰਡ ਲੌਗਿੰਗ ਜੋੜੋ (start/stop, send/receive, cancel/timeout) ਤਾਂ ਕਿ ਰੁਕਾਵਟਾਂ ਦੀ ਤਸ਼ਖੀਸ ਹੋ ਸਕੇ।
CI ਵਿੱਚ race detector ਚਲਾਓ (go test -race ./...) ਅਤੇ concurrency ਨੂੰ ਦਬਾਉਣ ਵਾਲੇ ਟੈਸਟ ਲਿਖੋ (ਦੁਹਰਾਏ ਚਲਾਉੋ, parallel tests, ਸਮੇਂ-ਬੱਧ assertions)।
ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਸਪਸ਼ਟਤਾ ਖਰੀਦਦਾ ਹੈ ਦੁਨੀਆਂ ਨੂੰ "ਆਗਿਆ ਦਾ ਸਮੂਹ" ਸੰਜੋਗਣ ਨਾਲ। ਇਹ ਸੌਦਾ ਹੈ: ਘੱਟ ਤਰੀਕੇ ਕਰਨ ਦੇ ਮਤਲਬ ਘੱਟ ਅਚਾਨਕ ਘਟਨਾਵਾਂ, ਤੇਜ਼ ਓਨਬੋਰਡਿੰਗ, ਅਤੇ ਅਧਿਕ ਪੇਸ਼ਗੋਈਯੋਗ ਕੋਡ। ਪਰ ਇਹ ਵੀ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਕਦੇ-ਕਦੇ ਏਹ ਮਹਿਸੂਸ ਕਰੋਗੇ ਕਿ ਤੁਸੀਂ ਇੱਕ ਹੱਥ ਪਿੱਛੇ ਬੰਨ੍ਹ ਕੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ।
API ਅਤੇ ਪੈਟਰਨ। ਜਦ ਇਕ ਟੀਮ ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਪੈਟਰਨਾਂ 'ਤੇ ਸਟੈਂਡਰਡ ਕਰਦੀ ਹੈ (ਏਕ ਲੌਗਿੰਗ ਤਰੀਕਾ, ਏਕ config ਸਟਾਈਲ, ਏਕ HTTP ਰਾਊਟਰ), ਤਾਂ ਕਿਸੇ ਖਾਸ ਨੱਚੇ ਲਈ "ਸਭ ਤੋਂ ਵਧੀਆ" ਲਾਇਬ੍ਰੇਰੀ ਸ਼ਾਇਦ ਅਨੁਮਤ ਨਾ ਹੋਵੇ। ਇਹ ਨਿਰਾਸ਼ਜਨਕ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਟੂਲ ਕੁਝ ਸਮਾਂ ਬਚਾ ਸਕਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਐੱਜ ਕੇਸਾਂ ਵਿੱਚ।
ਜਨੈਰਿਕ ਅਤੇ ਅਭਿਅਾਸ਼ਤਾਂ। Go ਦੇ generics ਮੱਦਦਗਾਰ ਹਨ, ਪਰ ਇੱਕ ਪ੍ਰੈਗਮੈਟਿਕ ਸਭਿਆਚਾਰ ਫਿਰ ਵੀ ਜਟਿਲ ਟਾਈਪ ਹਾਇਰਾਰਕੀ ਅਤੇ ਮੈਟਾ-ਪ੍ਰੋਗਰਾਮਿੰਗ 'ਤੇ ਸਕੈਪਟਿਕ ਰਹੇਗਾ। ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਪਾਰਿਸਥਿਤਕ ਤੰਤਰਾਂ ਤੋਂ ਆ ਰਹੇ ਹੋ ਜਿੱਥੇ ਭਾਰੀ ਅਭਿਅਾਸ਼ਤਾਂ ਆਮ ਹਨ, ਤਾਂ konkreਤ ਅਤੇ ਸਪਸ਼ਟ ਕੋਡ ਲਈ ਪਸੰਦ ਤੁਹਾਨੂੰ ਦੁਹਰਾਉ ਸੂਝ ਸਕਦੀ ਹੈ।
ਆਰਕੀਟੈਕਚਰ ਚੋਣਾਂ। ਸਾਦਗੀ ਅਕਸਰ ਤੁਹਾਨੂੰ ਸਧਾਰਨ ਸੇਵਾ ਸੀਮਾਵਾਂ ਅਤੇ ਸਧਾਰਨ ਡੇਟਾ ਸਟ੍ਰਕਚਰਾਂ ਵੱਲ ਧੱਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਬਹੁਤ কਨਫਿਗਰੇਬਲ ਪਲੇਟਫਾਰਮ ਜਾਂ ਫਰੇਮਵਰਕ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ "ਉਸਨੂੰ ਰੁੱਤੀਲਾ ਰੱਖੋ" ਨਿਯਮ ਲਚੀਲਾਪਨ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦਾ ਹੈ।
ਇਕ ਹਲਕਾ ਟੈਸਟ ਵਰਤੋ ਪਹਿਲਾਂ ਵੱਖਰਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਅਪਵਿਗਿਆਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਨਿਰਧਾਰਿਤ ਪ੍ਰਯੋਗ ਵਜੋਂ ਸਮਝੋ: ਕਾਰਨ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਸਕੋਪ ਸੀਮਤ ਰਹੇ (ਇੱਕ ਹੀ ਪੈਕੇਜ/ਸੇਵਾ), ਅਤੇ ਵਰਤੋਂ ਦੇ ਨਿਯਮ ਲਿਖੋ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਮੁੱਖ ਰਵਾਇਤਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਜੋ ਟੀਮ ਫੇਰ ਵੀ ਇੱਕ ਆਮ ਮਾਨਸਿਕ ਮਾਡਲ ਸਾਂਝਾ ਕਰੇ—ਭਾਵੇਂ ਕੁਝ ਵਜੀਹਤ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਹੱਲ ਹੋਣ।
ਤੇਜ਼ ਬਿਲਡ ਅਤੇ ਸਰਲ ਟੂਲਿੰਗ ਸਿਰਫ਼ ਡਿਵੈਲਪਰ ਸੁਵਿਧਾ ਨਹੀਂ—ਉਹ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪਿੰਗ ਅਤੇ ਮੁੜ-ਪੁਸਤਕ ਰਿਕੋਵਰੀ 'ਤੇ ਅਸਰ ਪਾਂਦੀ ਹੈ।
ਜਿਸ ਕੋਡਬੇਸ ਦੀ ਬਿਲਡ ਤੇਜ਼ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ, ਟੀਮਾਂ CI ਵਧੇਰੇ ਚਲਾ ਕੇ, ਸ਼ਾਖਾਵਾਂ ਛੋਟੀਆਂ ਰੱਖ ਕੇ, ਅਤੇ ਇंटीਗਰੇਸ਼ਨ ਮਸਲਿਆਂ ਨੂੰ ਜਲਦੀ ਠੀਕ ਕਰਕੇ deploy ਸਮੇਂ "ਅਚਾਨਕ" ਫੇਲ ਹੋਣ ਘਟਾ ਦਿੰਦੀਆਂ ਹਨ।
ਇਹ ਚਲਾਉਣੀ ਲਾਭ ਖਾਸ ਕਰਕੇ ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਦੌਰਾਨ ਸਪਸ਼ਟ ਹੈ। ਜੇ rebuild, test, ਅਤੇ package ਕਰਨ ਵਿਚ ਮਿੰਟ ਲੱਗਦੇ ਹਨ ਘੰਟਿਆਂ ਦੀ ਥਾਂ, ਤਾਂ ਤੁਸੀਂ ਤੁਰੰਤ ਸੀਧਾ-ਸੰਪਾਦਨ ਕਰ ਸਕਦੇ ਹੋ ਜਦ ਸੰਦੇਰਭ ਤਾਜ਼ਾ ਹੋ। ਇਹ "ਹਟ ਪੈਚ" ਦਾ ਪ੍ਰੇਰਣਾ ਵੀ ਘਟਾਉਂਦਾ ਹੈ ਜੋਂਕਿ ਪੂਰੀ ਤਸਦੀਕ ਕੀਆ ਬਿਨਾਂ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਹੱਲ ਲਾਇਆ ਨਾ ਜਾਵੇ।
ਇੰਸੀਡੈਂਟਾਂ ਨੂੰ ਅਕਸਰ ਚਤੁਰਾਈ ਨਾਲ ਨਹੀਂ ਸਮਝਾਇਆ ਜਾਂਦਾ; ਉਹ ਸਮਝਣ ਦੀ ਗਤੀ ਨਾਲ ਹੱਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਛੋਟੇ, ਪੜ੍ਹਨਯੋਗ ਮੋਡੀਊਲਜ਼ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ 'ਚ ਮਦਦ ਕਰਦੇ ਹਨ: ਕੀ ਬਦਲਿਆ? ਬੇਨਤੀ ਕਿੱਥੇੋਂ ਲੰਘਦੀ ਹੈ? ਇਹ ਕਿਹੜੇ ਹਿੱਸੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ?
Go ਦੀ explicitness ਪਸੰਦ (ਅਤੇ overly magical build ਤਰਤੀਬਾਂ ਤੋਂ ਬਚਣਾ) ਆਮ ਤੌਰ 'ਤੇ ਐਸੇ ਆਰਟਿਫੈਕਟ ਅਤੇ ਬਾਈਨਰੀਜ਼ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜੋ ਨਿਰੀਖਣ ਅਤੇ ਦੁਬਾਰਾ ਤੈਨਾਤ ਕਰਨ ਲਈ ਸਿੱਧੇ ਹਨ। ਉਹ ਸਾਦਗੀ 2 ਵਜੇ ਨੂੰ debug ਕਰਨ ਵਾਸਤੇ ਘੱਟ moving parts ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰੈਗਮੈਟਿਕ ਚਲਾਉਣੀ ਸੈਟਅੱਪ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:
ਇਹ ਸਭ ਕੁਝ ਹਰ ਇੱਕ ਲਈ ਇੱਕ-ਸਾਈਜ਼-ਫਿੱਟ-ਸਭ ਨੂੰ ਨਹੀਂ। ਨਿਯੰਤਰਤ ਵਾਤਾਵਰਨ, legacy ਪਲੇਟਫਾਰਮ, ਅਤੇ ਬਹੁਤ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾ ਭਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਲੋੜ ਹੋਵੇ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਸਾਦਗੀ ਅਤੇ ਗਤੀ ਨੂੰ ਭਰੋਸੇਯੋਗਤਾ ਫੀਚਰ ਵਜੋਂ ਦੇਖੋ—ਸਿਰਫ਼ ਸੁੰਦਰਤਾ ਵਜੋਂ ਨਹੀਂ।
ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਇਹ ਰੋਜ਼ਾਨਾ ਆਦਤਾਂ ਵਿੱਚ ਦਿੱਸਦੀ ਹੈ—ਨ ਕਿ ਕੇਵਲ ਇੱਕ ਮਨਾਂਫੈਰ 'ਚ। ਮਕਸਦ "decision tax" ਨੂੰ ਘਟਾਉਣਾ (ਕਿਹੜਾ ਟੂਲ? ਕਿਹੜੀ ਸੰਰਚਨਾ?) ਅਤੇ ਸਾਂਝੇ ਡੀਫੋਲਟ ਵਧਾਉਣਾ (ਇੱਕ ਤਰੀਕਾ format, test, build, ਅਤੇ ship ਕਰਨ ਦਾ)।
1) ਫਾਰਮੇਟਿੰਗ ਨੂੰ ਇੱਕ ਗੈਰ-ਹਲਤਕਾਰੀ ਡੀਫੋਲਟ ਬਣਾਓ।
gofmt (ਅਤੇ ਈਚ-ਕਦੇ goimports) ਅਪਣਾ ਕੇ ਅਤੇ ਇਸਨੂੰ ਆਟੋਮੈਟਿਕ ਬਣਾਓ: ਏਡਿਟਰ-ਆਨ-ਸੇਵ ਨਾਲ ਅਤੇ pre-commit ਜਾਂ CI ਚੈੱਕ ਨਾਲ। ਇਹ ਬਾਈਕਸ਼ੇਡਿੰਗ ਨੂੰ ਦੂਰ ਕਰਨ ਅਤੇ ਡਿਫਸ ਨੂੰ ਸਮਝਣਯੋਗ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹੈ।
2) ਲੋਕਲ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟਾਂ ਚਲਾਉਣ ਦਾ ਇੱਕ ਮਿਆਰ ਬਣਾਓ।
ਇੱਕ ਇਕੱਲੀ ਕਮਾਂਡ ਚੁਣੋ ਜੋ ਲੋਕ ਯਾਦ ਰੱਖ ਸਕਣ (go test ./... ਉਦਾਹਰਨ ਲਈ)। ਇਸਨੂੰ CONTRIBUTING ਗਾਈਡ ਵਿੱਚ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਵਾਧੂ ਜਾਂਚਾਂ (lint, vet) ਜੋੜੋ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਰੱਖੋ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਕਰ ਦਿਓ।
3) CI ਨੂੰ ਉਹੀ ਵਰਕਫਲੋ ਦਰਸਾਓ—ਫਿਰ ਗਤੀ ਲਈ Optimize ਕਰੋ।
CI ਨੂੰ ਉਹ ਹੀ ਕੋਰ ਕਮਾਂਡ(ਆਂ) ਚਲਾਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਵਿਕਾਸਕਾਰ ਲੋਕਲ 'ਤੇ ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਵਾਧੂ ਗੇਟ ਜੋ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਚਾਹੀਦੇ ਹਨ। ਇਕ ਵਾਰੀ ਇਹ ਸਥਿਰ ਹੋ ਜਾਏ, ਤੇਜ਼ੀ 'ਤੇ ਧਿਆਨ ਦਿਓ: dependencies cache ਕਰੋ, ਹਰ ਨੌਕਰੀ 'ਤੇ ਸਭ ਕੁਝ ਮੁੜ-ਬਿਲਡ ਕਰਨ ਤੋਂ ਬਚੋ, ਅਤੇ ਧੀਮੇ suite ਨੂੰ ਵੱਖ-ਵੱਖ ਖੰਡਾਂ ਵਿੱਚ ਵੰਡੋ ਤਾਂ ਕਿ ਫੀਡਬੈਕ ਤੇਜ਼ ਰਹੇ। ਜੇ ਤੁਸੀਂ CI ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਟੀਮ ਲਈ pricing/limits ਪਾਰਦਰਸ਼ੀ ਰੱਖੋ (see /pricing).
ਜੇ ਤੁਸੀਂ Go ਦੇ ਛੋਟੇ ਡੀਫੋਲਟਾਂ ਦੀ ਪਸੰਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਉਮੀਦ ਕਰਨ ਯੋਗ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹੀ ਭਾਵ Koder.ai ਵਿੱਚ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
Koder.ai ਇਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਵੱਧ-ਵੱਧ ਤੇਜ਼ੀ ਨਾਲ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦਾ—ਪਰ ਫਿਰ ਵੀ ਇੰਜੀਨੀਅਰਿੰਗ ਏਸਕੇਪ ਹੈਚਜ਼ ਜਿਵੇਂ source code export, deployment/hosting, ਅਤੇ snapshots with rollback ਨੂੰ ਰੱਖਦਾ ਹੈ।স্টੈਕ ਚੋਣਾਂ ਇਰਾਦੇ ਨਾਲ ਰਾਏਬਧ ਹਨ (ਵੈੱਬ 'ਤੇ React, ਬੈਕਐਂਡ 'ਤੇ Go + PostgreSQL, ਮੋਬਾਈਲ ਲਈ Flutter), ਜੋ ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ "ਟੂਲਚੇਨ ਫੈਲਾਅ" ਘਟਾ ਸਕਦੇ ਹਨ ਅਤੇ ਵਿਚਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਸਮੇਂ iteration ਨੂੰ ਕਸਕਦਾਰ ਰੱਖ ਸਕਦੇ ਹਨ।
ਯੋਜਨਾ ਬਣਾਉਣ ਦਾ ਮੋਡ ਵੀ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਅਗਾਂਹ ਲਿਆਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਿਸਟਮ ਦਾ ਸਭ ਤੋਂ ਸਰਲ ਆਕਾਰ ਤੇਕਰਾਰ ਕਰ ਕੇ ਫਿਰ ਹੌਲੀ-ਹੌਲੀ ਤੇਜ਼ ਫੀਡਬੈਕ ਨਾਲ ਲਾਗੂ ਕਰੋ।
ਤੁਹਾਨੂੰ ਨਵੀਆਂ ਮੀਟਿੰਗਾਂ ਦੀ ਲੋੜ ਨਹੀਂ—ਸਿਰਫ਼ ਕੁਝ ਹਲਕੇ ਮੈਟ੍ਰਿਕਸ ਜੋ ਤੁਸੀਂ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਟ੍ਰੈਕ ਕਰ ਸਕਦੇ ਹੋ:
ਹਰ ਮਹੀਨੇ 15 ਮਿੰਟ ਲਈ ਇਹਨਾਂ ਨੂੰ ਮੁੜ-ਵਿੱਚਾਰੋ। ਜੇ ਨੰਬਰ ਖਰਾਬ ਹੋ ਰਹੇ ਹਨ, ਤਾਂ ਹੋਰ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਵਰਕਫਲੋ ਨੂੰ ਸਰਲ ਕਰੋ।
ਜਿਆਦਾ ਟੀਮ ਵਰਕਫਲੋ ਵਿਚਾਰਾਂ ਅਤੇ ਉਦਾਹਰਣਾਂ ਲਈ, ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ ਰੀਡਿੰਗ ਲਿਸਟ ਰੱਖੋ ਅਤੇ /blog ਤੋਂ ਪੋਸਟਾਂ ਰੋਟੇਟ ਕਰੋ।
ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਇੱਕ ਨਾਰਾ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਰੋਜ਼ਾਨਾ ਕੰਮ ਕਰਨ ਦਾ ਸਮਝੌਤਾ ਹੈ: ਮਨੁੱਖੀ ਸਮਝ ਅਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ ਲਈ optimize ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਤਿੰਨ ਸਤੰਭ ਯਾਦ ਰੱਖਣੇ ਹੋਣ, ਤਾਂ ਇਹ ਰਹਿਣ:
ਇਹ ਫਿਲਾਸਫੀ ਖੁਦ-ਮਕਸਦ ਲਈ ਮਿੰਮਿਮਾਲਿਜ਼ਮ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਸੋਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰਨ ਬਾਰੇ ਹੈ ਜੋ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਾ ਆਸਾਨ ਹੋਵੇ: ਘੱਟ moving parts, ਘੱਟ "ਖਾਸ ਮਾਮਲੇ" ਅਤੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਕਿਸੇ ਹੋਰ ਨੇ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ ਘੱਟ ਅਚਾਨਕ ਘਟਨਾਵਾਂ।
ਇੱਕ ਇਕੱਲਾ, ਸਪੱਸ਼ਟ ਕਦਮ ਚੁਣੋ—ਛੋਟਾ ਪਰ ਅਰਥਪੂਰਨ:
ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ/ਬਾਅਦ ਲਿਖੋ: ਬਿਲਡ ਟਾਈਮ, ਚੈਕ ਚਲਾਉਣ ਲਈ ਕਦਮਾਂ ਦੀ ਗਿਣਤੀ, ਜਾਂ ਇੱਕ ਰਿਵਿਊਅਰ ਨੂੰ ਬਦਲਾਅ ਸਮਝਣ ਲਈ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ। ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਉਸ ਵੇਲੇ ਵਿਸ਼ਵਾਸ ਕਮਾਉਂਦੀ ਹੈ ਜਦ ਇਹ ਮੌਜੂਦ ਨੰਬਰਾਂ ਨਾਲ ਪਰਖੀ ਜਾ ਸਕੇ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਗਹਿਰਾਈ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਅਧਿਕਾਰਕ Go ਬਲੌਗ 'ਤੇ tooling, build performance, ਅਤੇ concurrency patternਾਂ ਬਾਰੇ ਪੋਸਟਾਂ ਵੇਖੋ, ਅਤੇ Go ਦੇ ਰਚਿਆਕਾਰਾਂ ਅਤੇ ਮੈਨਟੇਨਰਾਂ ਦੀਆਂ ਜਨਤਕ ਟਾਕਾਂ ਦੀ ਖੋਜ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ heuristic ਦੇ ਰੂਪ ਵਿੱਚ ਲਵੋ: ਐਸੇ ਸਿਧਾਂਤ ਜੋ ਤੁਸੀਂ ਲਾਗੂ ਕਰੋ, ਨਾ ਕਿ ਕਠੋਰ ਨਿਯਮ।
"ਸਿਸਟਮ ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ" ਉਹ ਰੁਝਾਨ ਹੈ ਜੋ ਐਸੇ ਫੈਸਲੇ ਵੱਲ ਝੁਕਾਅ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲੀ ਸਿਸਟਮਾਂ ਨੂੰ ਤਿਆਰ, ਚਲਾਉਣ ਅਤੇ ਸਮਾਂ-ਦਬਾਅ ਹੇਠ ਬਦਲਣ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਇਹ ਪੁੱਛਣਾ ਹੈ ਕਿ ਕੀ ਇਹ ਚੋਣ ਰੋਜ਼ਾਨਾ ਵਿਕਾਸ ਨੂੰ ਸੁਧਾਰੇਗੀ, ਉਤਪਾਦ ਵਿੱਚ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਨੂੰ ਘਟਾਏਗੀ, ਅਤੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਵੀ ਸਮਝਣ ਯੋਗ ਰਹੇਗੀ—ਖਾਸ ਕਰਕੇ ਕਿਸੇ ਨਵੇਂ ਆਉਣ ਵਾਲੇ ਵਿਕਾਸਕਾਰ ਲਈ।
ਜਟਿਲਤਾ ਲਗਭਗ ਹਰ ਕਾਰਵਾਈ 'ਤੇ ਟੈਕਸ ਲਗਾਉਂਦੀ ਹੈ: ਸਮੀਖਿਆ, ਡੀਬੱਗਿੰਗ, ਓਨਬੋਰਡਿੰਗ, ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ, ਅਤੇ ਛੋਟੇ ਬਦਲਾਵਾਂ ਭੀਤ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਰਨ।
ਇੱਕ ਚਤੁਰ ਤਕਨੀਕ ਜੋ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਲਈ ਕੁਝ ਮਿੰਟ ਬਚਾਉਂਦੀ ਹੈ, ਬਾਕੀ ਟੀਮ ਲਈ ਘੰਟਿਆਂ ਦਾ ਖ਼ਰਚਾ ਬਣ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਵਿਕਲਪ, ਐੱਜ ਕੇਸ ਅਤੇ ਮਾਨਸਿਕ ਭਾਰ ਵਧਦਾ ਹੈ।
ਸਟੈਂਡਰਡ ਟੂਲਚੇਨ "ਫੈਸਲੇ ਦੇ ਓਵਰਹੈਡ" ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਜੇ ਹਰ ਰਿਪੋ ਵਿੱਚ ਵੱਖਰੇ ਸਕ੍ਰਿਪਟ, ਫਾਰਮੇਟਰ ਅਤੇ ਰਿਵਾਜ਼ ਹੋਣ, ਤਾਂ ਸੈਟਅੱਪ ਅਤੇ ਬਹਿਸ ਵਿਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
Go ਦੇ defaults (ਜਿਵੇਂ gofmt, go test, ਅਤੇ modules) ਵਰਕਫਲੋ ਨੂੰ ਪੇਸ਼ਗੀ ਬਣਾ ਦਿੰਦੇ ਹਨ: ਜੇ ਤੁਸੀਂ Go ਜਾਣਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਫੌਰਨ ਹੀ ਯੋਗਦਾਨ ਦੇ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਕਿਸੇ ਕਸਟਮ ਟੂਲਚੇਨ ਨੂੰ ਸਿੱਖਣ ਦੇ।
ਇੱਕ ਸਾਂਝਾ ਫਾਰਮੇਟਰ ਜਿਵੇਂ gofmt ਅੰਦਾਜ਼ ਬਾਰੇ ਵਿਵਾਦ ਅਤੇ ਸ਼ੋਰ-ਭਰੇ ਡਿਫਸ ਨੂੰ ਦੂਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਮੀਖਿਆਵਾਂ ਵਿਵਹਾਰ ਅਤੇ ਸਹੀਤਾ 'ਤੇ ਕੇਂਦਰਤ ਰਹਿੰਦੀ ਹਨ।
ਪ੍ਰਯੋਗਿਕ ਰੋਲਆਊਟ:
ਤੇਜ਼ ਬਿਲਡ ਮਿਆਦ ਘਟਾਉਂਦਾ ਹੈ ਸਮਾਂ: "ਮੈਂ ਬਦਲਾਅ ਕੀਤਾ" ਤੋਂ "ਮੈਨੂੰ ਪਤਾ ਲੱਗਿਆ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ" ਤੱਕ। ਇਹ ਛੋਟੇ ਕਮਿਟਸ ਅਤੇ ਵੱਧ ਜ਼ਰੂਰੀ ਟੈਸਟਿੰਗ ਨੂੰ ਉਤਸ਼ਾਹਤ ਕਰਦਾ ਹੈ ਅਤੇ "ਮੇਗਾ-PRs" ਘਟਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਚੈਕ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਤਾਂ ਲੋਕ ਟੈਸਟਿੰਗ ਨੂੰ ਮੁਲਤਵੀ ਨਹੀਂ ਰੱਖਦੇ ਅਤੇ ਫਿਰ ਵੱਖ-ਵੱਖ ਬਦਲਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਡੀਬੱਗ ਕਰਨ ਦੀ ਲੋੜ ਘਟਦੀ ਹੈ।
ਕੁਝ ਅੰਕੜੇ ਜੋ ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਅਤੇ ਡਿਲਿਵਰੀ ਗਤੀ ਨਾਲ ਸਿੱਧੇ ਜੁੜੇ ਹਨ:
ਇਨ੍ਹਾਂ ਨਾਲ ਰੈਗ੍ਰੈਸ਼ਨ ਨੂੰ ਜਲਦੀ ਪਤਾ ਲਗਦਾ ਹੈ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ ਸੁਧਾਰਨ ਲਈ ਕੰਮ ਦੀ ਸਹਾਇਤਾ ਮਿਲਦੀ ਹੈ।
ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਬੇਸਲਾਈਨ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ:
gofmtgo test ./...go vet ./...go mod tidyਫਿਰ CI ਨੂੰ ਉਹੇ ਕਮਾਂਡਾਂ mirror ਕਰੋ ਜੋ ਵਿਕਾਸਕਾਰ ਲੋਕਲ ਤੇ ਚਲਾਉਂਦੇ ਹਨ। CI ਵਿੱਚ ਅਜਿਹੇ ਕਦਮਾਂ ਤੋਂ ਬਚੋ ਜੋ ਲੈਪਟੌਪ 'ਤੇ ਨਹੀਂ ਹੁੰਦੇ; ਇਹ ਫੇਲਿਉਰਾਂ ਨੂੰ ਡਾਇਅਗਨੋਜ਼ ਕਰਨ ਯੋਗ ਅਤੇ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਕੰਮ ਕਰਦਾ" ਤਰ੍ਹਾਂ ਦੀ ਦਲਮੀਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਅਮੂਮਨ ਸਮੱਸਿਆਵਾਂ ਸ਼ਾਮਿਲ ਹਨ:
ਉਪਾਇ ਜੋ ਮੁੱਲ ਦਿੰਦੇ ਹਨ:
ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾ ਫਲੋ ਜਾਂ ਘਟਨਾਵਾਂ ਦੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਨੂੰ ਪ੍ਰਗਟ ਕਰ ਰਹੇ ਹੋ (ਪਾਈਪਲਾਈਨ, ਵਰਕਰ ਪੂਲ, fan-out/fan-in, ਕੈਂਸਲੇਸ਼ਨ ਸਿਗਨਲ), ਤਾਂ ਚੈਨਲ ਬਿਹਤਰ ਪੜ੍ਹਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ ਛੋਟੀ ਨਾਜ਼ੁਕ ਸੰਖੇਪ ਖੇਤਰਾਂ ਨਾਲ ਸਾਂਝੀ ਸਥਿਤੀ ਦੀ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ_mutexes_ ਵਧੀਆ ਹਨ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ struct ਨੂੰ ਮਿਉਟੇਟ ਕਰਨ ਲਈ ਚੈਨਲ ਰਾਹੀਂ "ਕਮਾਂਡ" ਭੇਜ ਰਹੇ ਹੋ, ਤਾਂ sync.Mutex ਸਾਫ਼ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰੈਗਮੈਟਿਜ਼ਮ ਦਾ ਮਤਲਬ ਹੈ ਉਹ ਸੰਦ ਚੁਣੋ ਜੋ ਪਾਠਕ ਲਈ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਰਹੇ।
ਜਦੋਂ ਮੌਜੂਦਾ ਮਿਆਰ ਖਰਾਬ ਦਿਖਾਈ ਦੇਵੇ (ਪ੍ਰਦਰਸ਼ਨ, ਸਹੀਤਾ, ਸੁਰੱਖਿਆ, ਜਾਂ ਮਾਰਨਟੇਨਸ ਦਰਦ), ਤਾਂ ਹੀ ਕੋਈ ਛੁੱਟ ਦਿੱਤੀ ਜਾਏ—ਸਿਰਫ਼ ਨਵੇਂ ਟੂਲ ਦੇ ਸ਼ੌਕ ਲਈ ਨਹੀਂ।
ਇੱਕ ਹਲਕਾ "ਅਪਵਿਭਾਜਨ ਟੈਸਟ":
ਜੇ ਤੁਸੀਂ ਅੱਗੇ ਵਧਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਪੈਕੇਜ/ਸੇਵਾ ਤੱਕ ਸੀਮਤ ਰੱਖੋ, ਵਾਜਬ ਤਰੀਕੇ ਨਾਲ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਅਤੇ ਮੁੱਖ ਕਨਵੈਂਸ਼ਨਾਂ ਨੂੰ ਬਣੇ ਰਹਿਣ ਦਿਓ ਤਾਂ ਜੋ ਓਨਬੋਰਡਿੰਗ ਸਹੀ ਰਹੇ।
context.Context ਪਾਸ ਕਰੋ ਅਤੇ ਕੈਂਸਲੇਸ਼ਨ ਦਾ ਆਦਰ ਕਰੋ।go test -race ./... ਚਲਾਓ।