Ar galite pateikti pavyzdžių apie architektūrinius sprendimus, kurie pasirodė esą klaidingi arba neveiksmingi, ir paaiškinti kodėl?

Klaidingi arba neveiksmingi architektūros sprendimai Go dažnai yra susiję su netinkamu kalbos principų ir modelių taikymu:

• Per didelė monolitinė struktūra. Kai visas kodas sutelkiamas viename pakete ar faile, tai apsunkina priežiūrą ir testavimą.
• Trūksta sąsajų abstrakcijoms. Go sąsajos leidžia lengvai keisti įgyvendinimus, tačiau jei jų nenaudojama, kodas tampa standus.
• Naudojamos globalios kintamosios būsenai. Tai sukelia konkurencijos ir testavimo problemų.
• Netinkamas gorutinių valdymas. Pavyzdžiui, pradėti gorutinas be kontrolės jų užbaigimo ar be konteksto, kas sukelia išteklių nutekėjimą.
• Per didelis kanalų naudojimas ten, kur pakanka paprastų funkcijų. Kanalai yra naudingi sinchronizacijai, tačiau netinkamas jų naudojimas komplikuoja kodą.

Blogas pavyzdys — gorutinos paleidimas be konteksto ir kontrolės:

func process() {
    go func() {
        // begalinė ciklas be galimybės sustabdyti
        for {
            // darbas
        }
    }()
}

Geresnis būdas — naudoti kontekstą atšaukimui:

func process(ctx context.Context) {
    go func() {
        for {
            select {
            case <-ctx.Done():
                return
            default:
                // darbas
            }
        }
    }()
}