Po pierwsze, zdaję sobie sprawę, że to pytanie może być nieco długie i niejasne i przepraszam za to. Jest to prawdopodobnie podstawowy problem z krótką nazwą dla każdego, kto go „rozumie”, ale ponieważ brakuje mi w tym względzie, proszę o wyrozumiałość przy opisywaniu problemu.
Programowałem w ten czy inny sposób, odkąd miałem około 11 lat. Oznacza to, że głównie od samego początku uczyłem się wszystkiego. Uzyskałem wykształcenie techniczne, ale nie wyłącznie informatyki (ukończyłem studia z inżynierii fotonicznej). Oczywiście mieliśmy kursy programowania, ale były to dla mnie głównie podstawowe rzeczy i nie nauczyłem się zbyt wielu nowych rzeczy. Ciągle kształciłem się po drodze z radości i zawsze wiedziałem, że będę kontynuował karierę programistyczną, ale wszystkie moje projekty były wtedy dość małe. Nie miałem problemu z utrzymaniem ich w pamięci i utrzymaniem ich.
Teraz uważam się za lidera w zespole, ale nie w środowisku korporacyjnym - pracuję dla uniwersytetu opracowując oprogramowanie naukowe (w C ++) do zastosowań inżynieryjnych. Nagle projekt staje się (relatywnie) duży i przez większość czasu nie mogę się nim skupić. Tracę dużo czasu i wysiłku głównie na dwie rzeczy:
- Kiedy muszę wrócić do części kodu, nad którą nie pracowałem przez jakiś czas, mam trudności z zapamiętaniem, jak to działało. Spędzam dużo czasu przeglądając pliki nagłówkowe odpowiednich klas i czytając komentarze, które umieszczałem po drodze w plikach źródłowych. Chciałbym mieć jakąś formę „schematu”, którą mógłbym łatwiej dostrzec i odzyskać obraz;
- Kiedy wprowadzam zmiany, czasami zdaję sobie sprawę, że to, co próbuję zrobić, psuje rzeczy gdzie indziej (lub, co gorsza, pojawia się tylko w czasie wykonywania jako niespodzianka). Cofam się i zaczynam robić to inaczej, tylko po to, by przekonać się, że zaniedbałem wpływ na jakiś inny komponent. Chciałbym mieć jakiś „schemat architektury”, w którym mogłem zobaczyć, jak się to robi, jak to, co próbuję zrobić, wpłynie na inne komponenty i sposób, w jaki szczegółowo planuję, zanim zacznę wdrażać zmiany.
Większość ludzi, z którymi pracuję, ma podobne historie jak moja - silną orientację techniczną i czasem świetne umiejętności, ale bez możliwości zorganizowania swojej pracy. Jednak ich projekty są zwykle znacznie mniejsze niż moje, więc jakoś sobie z tym radzą. W każdym razie oznacza to dla mnie, że jestem sam i nie mam z kogo uczyć się dobrych praktyk.
Wziąłem podyplomowe szkolenie z zarządzania IT i chociaż uważam, że jest to całkiem satysfakcjonujące, jest ono skierowane głównie do nie-programistów, ucząc o metodologii zarządzania projektami, szacunkach budżetu / harmonogramu, architekturze przedsiębiorstwa itp. - a nie o projektowaniu i planowaniu jako takim. Zgadza się, ja też próbuję się tego nauczyć. Oczywiście wprowadzono niektóre narzędzia (takie jak UML) i typy procesów tworzenia oprogramowania (kaskadowe, iteracyjne, zwinne ...), ale oczywiście nie są one zbyt szczegółowe i trudno mi zdecydować, co powinienem wybrać i użyć ( i do jakiego stopnia).
Czytałem wiele pytań i odpowiedzi na temat projektowania oprogramowania na SO - wiele jest na temat robienia tego przy użyciu tego lub tego konkretnego narzędzia lub metodologii, a jeśli byłbym przekonany, że dokumentacja UML rozwiąże moje problemy - wybrałbym to i zacznij go używać. Ale niektórzy przysięgają, inni twierdzą, że jest to bezużyteczne. Szukam odpowiedzi na wyższym poziomie abstrakcji - czy są sposoby na rozwiązanie dwóch moich problemów i jak to robisz osobiście? Czego powinienem się nauczyć, aby móc to zrobić, być może bez powiązania z jednym konkretnym narzędziem? Te pojawiają się i znikają od czasu do czasu, i spodziewam się, że ich zastosowanie różni się w zależności od rodzaju projektu.
Bardzo dziękuję za czytanie, ale nie byłem w stanie powiedzieć, co mam na myśli w skrócie (brak doświadczenia w projektowaniu oprogramowania i słownictwa).