Gubienie się w dużym projekcie

@DejaVu

To prawda, że te szablony potrafią nieźle się rozciągnąć i w sumie nie byłem pewny czy Ball i Box powinienem zrobić jako szablon. Spróbowałem i IMO wyszło okej. Powoli przestaje robić tak wiele szablonów bo dużo czasu na to idzie.

Zrób jedną funkcjonalność od początku do końca, pokryj testami jednostkowymi, aby mieć gwarancję, że działa i potem pójdź do kolejnej funkcjonalności.

Planuje tak właśnie te testy jednostkowe pisać, bo teraz je trochę zaniedbywałem. W każdym razie mam wrażenie, że to nie w tym jest problem.

Dużo się dowiedziałem z tego artykułu, który podlinkowałeś, chociaż nie zgadzam się z kilkoma rzeczami. Wg. mnie dokumentacja XMLowa w kodzie wygląda np. bardzo fajnie, zwłaszcza jeśli ładnie się wyświetla po najechaniu na funkcję a same doc commenty są ciemniejsze i mniej rzucające się w oczy niż te zwykłe. Są fajne toolsy do XML doców w VS i nie robi się tego tak długo.

@jankowalski25

C++ asercje są implementowane dość rozsądnie i na przykład nie rzucają wyjątków, tylko wywalają się podając nazwę pliku i numer linii

Korzystam z Microsoft Unit Test Framework. Wypada bardzo fajnie, wykonanie wszystkich testów to kwestia jednego kliknięcia a wynik dostaje w okienku Visuala.


Bardzo doceniam Wasze porady, ale myślę, że muszę wspomnieć, że raczej nie o takie coś mi chodziło. Nie chcę, żebyśmy schodzili na poboczne tematy. Mam problem z planowaniem. Idealnie dla mnie chyba by było, gdybym był w stanie w jakiejś formie zwizualizować sobie całe moje zadanie. Ciężko mi przychodzi zrozumienie samego problemu, jeśli nie mam jakiegoś obrazka przed oczami. Ja czysto teoretycznie wiem co powinienem zrobić, ale gdy nie mam ładnie tego rozrysowanego to się gubię. Nie wiem gdzie mam zacząć.

Próbowałem rysować na kartce: ciężko w ogóle zacząć, bo źle narysujesz i często kartka leci do kosza
Próbowałem programami do diagramów:
 - UML dla mnie jest nieczytelny. Wszystko wygląda tak samo a w dodatku nie pomaga zrozumieć problemu. Nie potrzebuje programu, którym projektuje klasy, bo to robię już w trakcie programowania.
 - Edytor DGML (przykład) z Visual Studio jest dla mnie świetny, bo jest czytelny... ale wszystko szlag trafia kiedy chce coś zgrupować. Nagle layout się cały wykrzacza i cały mój porządek się psuje.

Raczej chodzi mi o to, w jaki sposób Wy myślicie nad tym, co macie zaprogramować. Robicie jakieś wizualizacje? Rysujecie coś? Chyba, że przychodzi Wam to ot tak, bez projektowania.

Wg. mnie dokumentacja XMLowa w kodzie wygląda np. bardzo fajnie, zwłaszcza jeśli ładnie się wyświetla po najechaniu na funkcję a same doc commenty są ciemniejsze i mniej rzucające się w oczy niż te zwykłe. Są fajne toolsy do XML doców w VS i nie robi się tego tak długo.

Narzędzia ewoluują w czasie. Być może obecnie fajnie wygląda podpowiadany kod, ale kilka lat temu tak sytuacja nie wyglądała. Może ten artykuł warto by było trochę odświeżyć. Moje poglądy dot. testów jednostkowych też są tam trochę 'przestarzałe' i mógłbym napisać nieco więcej na ten temat z perspektywy czasu i trochę w innym tonie.

Ja schematy koncepcyjne robię na karce, a jak chcę już coś ucywilizować to korzystam z Draw.IO. Bardzo fajna aplikacja do rysowania schematów. Co mogę powiedzieć o zarządzaniu projektem...
1. Jira się przydaje - fajnie mieć zadania opisane 'co chciałbym zrobić'
2. Zrobienie wszystkich zadań z jiry - tu już zaczynają się schody bo często dodajemy zadania, które widzimy w danym momencie, ale często nie chcemy do nich podejść przez kolejne pół roku/rok. Tym samym odsiewanie zadań 'zamrożonych' jest dość istotne.
3. Planowanie projektu - jeżeli jesteś deweloperem + leaderem + product ownerem + wizjonerem produktu to niestety projekt idzie kulawo na bardziej zaawansowanym etapie prac. Jako wizjoner produktu musisz się skupić na tym jak produkt ma wyglądać -> wówczas warto spisać wizje w wordzie (lub w jakiejkolwiek innej postaci). Potem wizję warto przekonwertować na wymagania tj. 'co ma zostać zrobione z punktu widzenia funkcjonalnego'. Potem możesz zejść na poziom niżej tj. co należy zaimplementować, aby spełnić dane wymaganie i dopiero potem można zabrać się za właściwą implementację. Jak widać ścieżka od projektu do kodowania jest długa...

Draw.io też bardzo szanuje, chociaż przy nakładaniu na siebie kilku rzeczy ma problem - czasem to automatycznie grupuje czasem nie.
Powoli dochodzę do wniosku, że muszę po prostu więcej czasu poświęcić na planowanie. Przede wszystkim jednak muszę zrobić tak, żebym zawsze miał pod ręką jakąś wersję, która się kompiluje. Ciągłe dążenie do tego, by kod wreszcie się skompilował jest bardzo męczące. Zacznę chyba po prostu przy większych zadaniach robić nowe branche a potem będę mergował.

Niestety branche i merge to dokładanie sobie roboty... tym bardziej, że pracujesz sam.

Ale zawsze mam gdzieś tą wersję, gdzie wszystko ładnie działało.

To masz także bez robienia branchy.

Cóż, lepsze poznanie możliwości gita to chyba krok w dobrym kierunku. W sumie to możesz od tego zacząć. Oczywiście jeśli chcesz coś sprawdzić, to nie musisz tego robić na oryginalnym projekcie (co prawda jest reflog, ale jeśli jesteś początkujący, to lepiej eksperymentować na czymś prostym, chociażby na hello worldowych plikach tekstowych, żeby "wszystko ładnie wychodziło", a dopiero później wykonywać właściwe akcje na repozytorium).