2: Średnie wartości:
-- Dependency graph – wizualizacja zależności projektu jako graf (kto zależy od kogo) na podstawie go.mod
-- Go workspace support – obsługa go.work dla multi-module projektów
-- Build tags UI – wybór build tagów (//go:build linux, debug itp.) przy kompilacji
Patrzę na tę trójkę pod kątem wartości vs nakład pracy:
Dependency graph – wizualnie efektowny, ale go.mod w typowym projekcie ma 2-5 zależności. Graf z 4 nodami nie robi wrażenia. Bardziej sensowny byłby dla multi-module workspace.
Go workspace (go.work) – przydatny ale niszowy. Większość użytkowników ma jeden moduł. Nakład duży, użycie małe.
Build tags UI – to jest daily driver który jest trochę sensowy. Każdy kto buduje na Linux/Windows/ARM używa tagów. Teraz trzeba pamiętać flagę, wpisywać ręcznie w terminalu. Jeden checkbox lub dwa w kreatorze builda zmienią workflow.
Niemniej na tą chwilę nie będę wdrażał tych opcji bo się okazuje że będzie więcej rzeczy do zrobienia takich bardziej istotnych:
1. Refaktoryzacja i optymalizacja niektórych elementów kodu
2. Migracja na nowszy node
3. Dokumentacja
https://github.com/SunDUINO/SunGo-Proje ... elase/wiki
i w następnych updatach na tym się skupię by korzystanie z wtyczki było przyjemnością i jednocześnie podnosiła komfort pracy.
oczywiście ważny jest także każdy feedback od was użytkowników - bo pozwoli stworzyć wtyczkę jeszcze lepszą
Mam też pewne plany względem maskotki jaką jest gopher mianowicie chce rozszerzyć jego działania i stworzyć:
SunGo Code Review Assistant – panel który analizuje aktywny plik .go i daje konkretne wskazówki w kontekście kodu, nie tylko ogólne porady.
Ma mniej więczej działać tak ten mechanizm:
-- Czyta aktywny plik .go
-- Zwraca przegląd podzielony na kategorie: Błędy logiczne, Wydajność, Go idioms, Bezpieczeństwo, Sugestie
-- Każda uwaga pokazuje konkretną linię kodu + propozycję poprawki
-- Jeden przycisk "Fix this" → wstawia poprawkę do edytora przez applyEdit
Na początek tylko lokalna analiza przez
go vet + staticcheck + golangci-lint z ładnym UI zamiast surowego outputu terminala.
Czyli Gopher przestaje być tylko maskotką – staje się aktywnym asystentem który czyta kod.
Później z czasem może podłączę Gophera przez api do któregoś modelu LLM , choć uważam że nie jest to potrzebne.
Niemniej głównym kierunkiem rozwoju będzie samodzielne SunGO Studio, a wtyczka to taki trochę ograniczony poligon doświadczalny.
Ograniczony, bo ogranicza mnie vscode - np nie mogę zrobić interaktywnego freeView a jedynie statyczny. Np Gopher siedzi w panelu.
Co o tym sądzicie ??
