Rozwiązywanie zadań

Techniki pomocne przy rozwiązywaniu problemów

Staraj się pisać jak najlepszy kod, ale nie poświęcaj dużej ilości czasu na jego poprawianie. Istotne jest przede wszystkim dostarczenie rozwiązania, naprawienie błędu, niż to, że jakaś linijka ma odrobinę za dużo znaków, albo masz lepszy pomysł na nazwę zmiennej. Długiem technicznym nazywamy źle napisany kod, pełen niejasnych sformułowań, ciężki do zrozumienia, który będzie trudny do zarządzania i rozwijania dla kolejnych osób pracujących w projekcie, a nawet dla samego autora. Staraj się tworzyć jak najmniejszy dług techniczny. Wyczucie, czy dany kod jest na tyle dobrze napisany przychodzi z czasem, z doświadczeniem. Początkujący mogą oprzeć się na opinii bardziej doświadczonych programistów, w procesie code review.

Bardzo ważną umiejętnością jest atakowanie problemu z wielu stron, różnymi metodami. Bardzo często dane zagadnienie programistyczne można rozwiązać na kilka różnych sposobów. Oczywiście część z nich jest niezdatna do wdrożenia, jednak kiepskie rozwiązanie jest lepsze, niż całkowity jego brak.

Czasem programista napotyka na niezwykle trudny problem do rozwiązania. Nazwijmy ten stan 'ścianą'. To zjawisko może wystąpić w przypadku nawet niezbyt trudnego problemu, który sprawia programiście kłopot.

Jeśli nie ma znikąd pomocy, i możesz na chwilę odłożyć to zadanie zacznij pracę nad zupełnie innym taskiem. Po kilku godzinach, czy dniach może przyjść ci do głowy pomysł na rozwiązanie. Jest to zjawisko podobne do przetwarzania danych w tle - programista nie zapomina całkiem o problemie, ale jednocześnie nie myśli nad nim aktywnie. Ma go 'z tyłu głowy'. Nie warto męczyć się nad jakąś przeszkodą w końcówce dnia. Zamiast przesiadywać po godzinach bez skutku, lepiej przyjść z rana z świeżą głową. Pomysł na rozwiązanie często przyjdzie wtedy w ciągu kilku minut.

Pomocne może być również cofnięcie się jeden lub więcej kroków, i zmiana podejścia na którymś w wcześniejszych etapów. Bardzo ważne (ale i trudne w wykonaniu) jest spojrzenie na problem i dotychczasowo wykonane kroki z perspektywy trzeciej osoby.

Strategia 'dziel i rządź'

Polega ona na rozbiciu dużego zadania na szereg podzadań, na których o wiele łatwiej się skoncentrować i rozwiązać. Należy rozwiązywać poszczególne podproblemy osobno, ale mając z tyłu głowy obraz całości. Jest to konieczne, żeby np. format danych zwróconych przez funkcję nadawał się jako zbiór danych wejściowych do następnej funkcji, która będzie częścią rozwiązania. Używając tę strategię zadajemy sobie w myślach pytanie: jaki następny krok powinienem wykonać, żeby rozwiązać bieżące zadanie?

Gdy idzie źle

Nie jest ujmą to, że czasem nie pracujemy z taką sprawnością, jaką my sami i inni oczekujmy. Gdy zauważysz, że masz z czymś trudność, gdy sobie z czymś nie radzisz, można wykonać szereg czynności, żeby temu zaradzić.

Przede wszystkim nie udawaj, że nie ma problemu. Nie chowaj głowy w piasek. Jeśli nie radzisz sobie z danym zadaniem, możesz częściej zwracać się z prośba o pomoc/z pytaniami do opiekuna, i innych członków zespołu. Większość ludzi chce pomagać, nawet jeśli pytający się trochę mu tym uprzykrza.

Jeśli mimo tego wciąż masz trudności, możesz porozmawiać z managerem, opiekunem projektu itp. Być może zadania, które dostałeś przerastają twoje obecne umiejętności. Lub np. masz na nie zbyt mało czasu. Być może cały projekt jest skomplikowany, trudny. Sam zespół programistyczny, czy osoby po stronie klienta mogą być źle dobrane, nie wykonywać swoich obowiązków poprawnie, co rzutuje na twoją wydajność. Zatem problem może leżeć poza tobą. Nie mniej jednak podstawową zasadą jest taka, że najpierw należy szukać przyczyny niepowodzeń w swojej osobie, nie w innych. Po rozmowie z managerem, podczas której opowiesz o swoich wątpliwościach i problemach, powinniście dojść do jakiegoś rozwiązania.

Ostatecznie, gdy rozmowy z przełożonym nic nie dały, możesz rozważyć zmianę firmy, technologii/języka programowania czy nawet porzucenie zawodu programisty. Nawet jeśli uznasz, że nie odpowiadają ci warunki w obecnej firmie nie pal za sobą mostów. Porozmawiaj szczerze z managerem/szefostwem, i rozstań się w przyjaznych warunkach. Również staraj się nie zerwać całkowicie kontaktów z programistami - są one na wagę złota.

Co jeśli masz pewny pomysł na rozwiązanie zadania, a inny programista stwierdził, że trzeba to zrobić zupełnie inaczej? Generalnie nikt nie jest nieomylny, i czasem nawet doświadczony developer może źle podejść do danego zagadnienia. Prawdopodobnie najlepiej będzie przystać na taką zamianę, ponieważ ta druga osoba (z racji większego doświadczenia niż my) może przewidzieć więcej. Nie mniej jednak powinniśmy przedyskutować temat, tzn. poprosić tego programistę o wyjaśnienie dlaczego nasze rozwiązanie jest gorsze, a jego lepsze.