You must log in or # to comment.
Autor wpisu całkiem trafnie podsumował to, co przeszkadza mi we współczesnych narzędziach do programowania.
Bezustanne bombardowanie użytkownika strumieniem powiadomień i podpowiedzi o znikomej wartości.Najgorsze pod tym względem są oczywiście copiloty, ale mnie denerwuje obecnie nawet integracja z LSP.
Nie chcę widzieć na ekranie linijek tekstu, których nie ma fizycznie w pliku. Nie interesują mnie podczas pisania funkcji ostrzeżenia, że nie użyłem jeszcze nowej zmiennej.
Mam wrażenie, że te “feature’y” wymyślił jakiś kierownik, który miał do czynienia co najwyżej z dokumentami Worda.W tym samym czasie mechanizmy takie jak automatyczne indeksowanie kodu są w coraz gorszym stanie.
W VS Code działa to najwolniej ze wszystkich edytorów, jakich miałem okazję używać.
Myślałem, że ten problem został rozwiązany dziesięć lat temu, bo Qt Creator radził sobie z tym zadaniem naprawdę dobrze.Współczesny model interakcji z IDE sprowadza się do tego, że nieistotne informacje otrzymujesz w trybie ciągłym, ale musisz poczekać na te, których akurat potrzebujesz.
Wróciłem ostatnio we własnych projektach do vima z podstawowym kolorowaniem składni i mam wrażenie, że odpoczywam przy programowaniu.
Zastanawiam się teraz, czy to jest kwestia moich starych nawyków. Może młodsi programiści lepiej radzą sobie z tymi nowymi narzędziami a ja po prostu nie nauczyłem się korzystać z ich zalet. A może to mityczna “staroś nie radoś”…W każdym razie autor artykułu ma przemyślenia zbieżne z moimi, więc przynajmniej nie jestem sam w swojej ocenie.
Wraz z doświadczeniem niektóre narzędzia przestają być potrzebne. Szczególnie takie, które pełnią rolę odpowiednika dodatkowych kółek w rowerze lub suflerów.
Jest całkiem duży wybór edytorów i IDE. Każdy może wybrać coś dla siebie w zależności od tego czego mu potrzeba.
To bardzo indywidualna sprawa.
Większość kariery używałem prostych edytorów. Jednak bardziej z czasów GUI niż terminali.
Lubię eksperymentować, testować i sprawdzać wartość różnych koncepcji w programowaniu. Sprawdzam co jakiś czas wszystko. Od tego czy podświetlanie składni jest mi potrzebne, po to ile linii powinien mieć plik i funkcje. Jak długie warto mieć etykiety. Jak układać ich nazwy. Jakieś nowe wzorce. Robienie wszystkiego od podstaw.
Ostatnie doświadczenie są takie, że plik powinien mieć 350 linii. Jeśli ma więcej to trzeba go podzielić na wiele plików po 60 linii. Tych plików powinno być 4. Cała reszta kodu, która jest niezmienna, powinna zostać oddelegowana do biblioteki o której nie powinieneś myśleć. Powinna zawierać prawdopodobnie prymitywy, które są ci potrzebne i łączą się z platformą.
Oczywiście nie trzymam się tego skrupulatnie. Najnowszy CRUD do organizacji pracy ma 1024 linie. Założyłem przy jego pisaniu, że do robienia GUI potrzebne mi jest tylko renderowanie 2 czcionek i rysowanie prostokątów. Jego wygląd przypomina bardziej GUI z maszyn w fabryce. To chyba wpływ stażu z zeszłego roku. Praca przy tak długim pliku, zawierającym wszystkie zagadnienia nie była zbyt wydajna. Rozwijałem to na zasadzie wyzwań. Każda zachcianka była uwzględniona.
