From 6ac9e91e8614ed0762f5f171c15b4b2824aafe78 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Adrian=20Scripc=C4=83?= Date: Mon, 8 Nov 2021 15:19:44 +0200 Subject: [PATCH] Update README_ro.md --- README_ro.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README_ro.md b/README_ro.md index 0078d413..00286f85 100644 --- a/README_ro.md +++ b/README_ro.md @@ -17,17 +17,17 @@ Traduceri: ## General -Aceasta este o structură de bază pentru aplicațiile Go. Nu este un standard oficial definit de echipa Go; însă reprezintă un set de structuri/modele comune folosite de-a lungul timpului în aplicațiile din ecosistemul Go. Unele sunt mai populare decât altele. Sunt prezente și îmbunătățiri, cu directoare specifice unei aplicații de mari dimensiuni. +Aceasta este o structură de bază pentru aplicațiile Go. Nu este un standard oficial definit de echipa Go, însă reprezintă un set de structuri/modele comune folosite de-a lungul timpului în aplicațiile din ecosistemul Go. Unele sunt mai populare decât altele. Sunt prezente și îmbunătățiri, cu directoare specifice unei aplicații de mari dimensiuni. -Dacă încerci să înveți Go sau să creezi un PoC/proiect hobby aceasta structură este excesivă. Începe cu ceva foarte simplu (un fișier `main.go` e de ajuns). Pe măsură ce proiectul crește ține minte că va fi nevoie să îl structurezi, altfel te vei trezi cu mult cod spagettă și dependințe/state-uri globale greu de întreținut. Când sunt mai mulți oameni care lucrează la proiect, vei avea nevoie de o structură și mai bună. Din acest motiv este important să introduci un mod comun de gestionare a librăriilor/package-urilor. Când ai un proiect open-source, când știi că alte proiecte importă codul din proiectul tău, e important să ai module (packages) private (internal). Clonează acest repo și ține doar ce ai nevoie. Doar pentru că e acolo, nu înseamnă că trebuie să îl folosești. Aceste standarde nu sunt folosite în toate proiectele Go, nici măcar cel comun `vendor` nu este universal. +Dacă încerci să înveți Go sau să creezi un PoC/proiect hobby, aceasta structură este excesivă. Începe cu ceva foarte simplu (un fișier `main.go` e de ajuns). Pe măsură ce proiectul crește ține minte că va fi nevoie să îl structurezi, altfel te vei trezi cu mult cod spagetti și dependențe/stări globale greu de întreținut. Când sunt mai mulți oameni care lucrează la proiect vei avea nevoie de o structură și mai bună. Din acest motiv este important să introduci un mod comun de gestionare a librăriilor/pachetelor. Când ai un proiect open-source sau știi că alte proiecte importă codul din proiectul tău, este important să ai module (packages) private (internal). Clonează acest repertoriu (repository) și ține doar ce ai nevoie. Doar pentru că ceva este prezent nu înseamnă că trebuie să îl folosești. Aceste standarde nu sunt folosite în toate proiectele Go, nici măcar cel comun `vendor` nu este universal. -De la apariția Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) sunt gata de producție (production mode). Folosește [`Go Modules`](https://blog.golang.org/using-go-modules) doar dacă nu ai un motiv specific de a nu le folosești. Dacă nu vrei să le folosești atunci nu este nevoie să te gândești la $GOPATH și unde să îți plasezi proiectul. Fișierul `go.mod` din repo-ul tău asumă că proiectul îți este hostat pe Github, însă asta nu e o necesitate. Calea (path) modulelor poate fi orice, însă primul modul component ar trebui să aibă un punct în numele său (versiunea curentă Go nu o mai cere explicit însă dacă folosești o versiune mai veche nu fi surprins dacă primești erori la compilare). Vezi problemele [`37554`](https://github.com/golang/go/issues/37554) și [`32819`](https://github.com/golang/go/issues/32819) dacă vrei să afli mai multe. +De la apariția Go 1.14 [`Modulele Go`](https://github.com/golang/go/wiki/Modules) sunt compatibile cu modelul de producție (production mode). Folosește [`Modulele Go`](https://blog.golang.org/using-go-modules) doar dacă nu ai un motiv specific de a nu le folosi. Dacă nu vrei să le folosești atunci nu este nevoie să te gândești la `$GOPATH` și unde să îți plasezi proiectul. Fișierul `go.mod` din repertoriul tău asumă că proiectul îți este hostat pe Github, însă asta nu e o necesitate. Calea (path) modulelor poate fi oricare, însă primul modul component ar trebui să aibă un punct în numele său (versiunea curentă Go nu o mai cere explicit însă dacă folosești o versiune mai veche nu fi surprins dacă primești erori la compilare). Vezi problemele [`37554`](https://github.com/golang/go/issues/37554) și [`32819`](https://github.com/golang/go/issues/32819) dacă vrei să afli mai multe. Această structură este intenționat generică și nu își dorește să impună un standard în gestiunea modulelor Go. -Această structură este un efort al comunității. Deschide o problemă (issue) dacă observi o nouă structură sau consideri că una existentă ar trebui actualizată. +Această structură este un efort al comunității. Postează o problemă (issue) dacă observi o nouă structură sau consideri că una existentă ar trebui actualizată. -Dacă ai nevoie de ajutor cu denumirile, formatare, stilare vezi [`gofmt`](https://golang.org/cmd/gofmt/) și [`golint`](https://github.com/golang/lint). Ar fi bine să citești și aceste linii de ghidare în vederea stilării codului Go: +Dacă ai nevoie de ajutor cu denumiri, formatare, stilizare, vezi [`gofmt`](https://golang.org/cmd/gofmt/) și [`golint`](https://github.com/golang/lint). Ar fi bine să citești și aceste recomandări în vederea stilizării codului Go: * https://talks.golang.org/2014/names.slide * https://golang.org/doc/effective_go.html#names * https://blog.golang.org/package-names