Rozwiązywanie problemów programistycznych

Czy jak głowi się dłuższy czas nad danym problemem i dochodzi do wniosku że bez ciężkiej mozolnej pracy i kombinowania pod górkę nie osiągnie się tak łatwo pożądanego rezultatu to lepiej wybrać pierwsze działające rozwiązanie, które spełnia wasze wymagania czy starać się za wszelką cenę dopiąć swojego?

Pierwsze działające - o ile faktycznie działa.
O usprawnieniach można pomyśleć później, jeśli będą potrzebne.

Trochę dochodzi temat zarządzania czasem, spisywania pomysłów, na ile jest wyestymowana praca itd. Możesz dać działające rozwiązanie a potem refaktorować. Wiem, że nie zawsze jest to takie proste, ale nie ma wyjścia. Pamiętaj, że czasem klasyczny bruteforce jest lepszy, bo wszyscy go rozumieją niż coś co rozumie tylko twórca.

Odpowiedź taka sama jak praktycznie na każde pytanie programistyczne: to zależy. Czasem lepiej kombinować, czasem lepiej odpuścić. Wyczucie i intuicję wyrabia się z czasem i zebranym doświadczeniem. Przeanalizuj swój problem, wymagania, kontekst, cel, warunki i wtedy decyduj.

To zależy xd Zawsze warto mieć przynajmniej dwa alternatywne rozwiązania co pomaga w podjęciu decyzji

Ważne jest też pełne zrozumienie wad danego rozwiązania i planowanie pracy pod to. Jak rozwiązanie jest subiektywnie złe, ale łatwo je podmienić w przyszłości to nie mam problemu. Ważniejsze są wymagania co do interfejsu niż implementacja, bo tą drugą łatwo zmienić

pierwsze działające rozwiązanie, które spełnia wasze wymagania
dopiąć swojego

To jedno i to samo. Dopinam swego, dostarczając rozwiązanie spełniające wymagania.

Najlepiej najpierw przedyskutować to z inną osobą, bo może się okazać że wcale nie trzeba kombinować a po prostu istnieje rozwiązanie na które nie wpadłeś.
Ale jak zawsze zależy - jak bardzo beznadziejne jest to rozwiązanie i czy przewidujesz że będą z tym problemy w bardzo niedługim czasie. Oraz czy to twój projekt czy pracujesz w korpo...

Przypomniała mi się sytuacja gdy dostałem zadanie i rozwiązanie wydawało się proste, ale był jeden case przez który nie można było go użyć i całkowicie trzeba było zmienić podejście; przez parę dni się głowiłem opowiadając o tym na daily, w końcu przydzielili to zadanie innej osobie która je szybko rozwiązała, jednak oczywiście nie biorąc nawet pod uwagę tego case'a mimo że wielokrotnie i praktycznie tylko o nim mówiłem. Za chwilę zostało to znalezione przez testera jako bug który trafił do poprawienia... do mnie. Żeby go poprawić musiałem to zaorać i zrobić wszystko od początku...

I teraz z perspektywy osoby trzeciej wyglądam bardzo marnie bo nie dowiozłem taska a teraz jeszcze mam problem z wdrożeniem "małej" poprawki. Na szczęście miałem trochę czasu żeby się nad tym zastanowić i zrobiłem to szybko, ale od tamtego czasu dostałem nauczkę, że z punktu widzenia biznesu i managementu dużo lepiej widziane jest dostarczyć zadanie szybciej nawet jeśli znamy jego ułomności i potem robić poprawki jako "bugfixy" niż trzymać zadanie zbyt długo na sobie bez widocznego progresu. No i też, że czasem wystarczy mały odpoczynek od problemu i świeży umysł żeby wpaść na coś lepszego.

jest jeszcze kwestia blokowania innych osób.
Np tak troche przejaskrawione - mamy backend i teraz trzeba napisać front. Można od razu robić wersję finalną która zajmie 2 miesiące i za bardzo nie da się tego w tym czasie używać.
Można też zrobić jakiegoś potworka tylko po to aby testerzy już mogli zacząc klikać i testować transakcje.

Problemy są zajebiste, pamiętam jak np. rozwiązywałem problem porwanego robota i algorytm był z użyciem filtra cząstek.

Tak algorytmy jak je rozwiązujesz to zauważysz miejsca na optymalizację.
Ważne, żeby wiedzieć co się rozwiązuje bo wtedy znajdziesz rozwiązania i wyciągniesz z nich wnioski.

Odkąd jest internet nie trafiłem problemu gdzie nie byłbym pewien rozwiązania.

obscurity napisał(a):

Przypomniała mi się sytuacja gdy dostałem zadanie i rozwiązanie wydawało się proste, ale był jeden case przez który nie można było go użyć i całkowicie trzeba było zmienić podejście; przez parę dni się głowiłem opowiadając o tym na daily, w końcu przydzielili to zadanie innej osobie która je szybko rozwiązała, jednak oczywiście nie biorąc nawet pod uwagę tego case'a mimo że wielokrotnie i praktycznie tylko o nim mówiłem. Za chwilę zostało to znalezione przez testera jako bug który trafił do poprawienia... do mnie. Żeby go poprawić musiałem to zaorać i zrobić wszystko od początku...

Ludzie zachowują się czasem tak, jakby w ogóle cię nie słuchali i jakby mieli totalnie wyj***.

Z drugiej strony warto spojrzeć też na siebie i swój sposób komunikacji.

Ja zauważyłem, że np. za mało elaboruję. Mówię ogólne stwierdzenia typu jest dużo długu technicznego, przydałby się refaktor. I często jest to odbierane jako narzekanie czy feedback (masz rację, dzięki za cenny feedback, dobra sugestia, zgadzam się, ale potem nikt z tym nic nie robi). Niestety o pewnych rzeczach trzeba mówić dłużej i tłumaczyć ludziom, nagłaśniać jako ważną sprawę, argumentować. I wymyślić szkielet/pomysł rozwiązania, bo inaczej nikomu się nie będzie chciało ruszyć d**y, żeby cokolwiek z tym zrobić dalej.

Jeszcze jest tak, że jak ktoś robi task, to jest to jego odpowiedzialność. Więc jak robię zadanie i jest mi ciężko, ponieważ dostrzegam ważne problemy X, Y, Z, to jak sygnalizuję to, to jest to odbierane jako jakieś tam moje problemy z taskiem (nawet jeśli są to obiektywne problemy). Więc jak potem ktoś inny będzie kontynuował ten task albo będzie robić podobny, to po prostu oleje te kwestie X, Y, Z, bo przecież to nie są jego problemy. Szczególnie jeśli to jakiś junior/mid, który chce się wykazać.

Ludzie zachowują się czasem tak, jakby w ogóle cię nie słuchali i jakby mieli totalnie wyj***.

Faktycznie tak się zachowują - ściślej mówiąc, mają naprawdę wyj***.

Więc jak robię zadanie i jest mi ciężko, ponieważ dostrzegam ważne problemy X, Y, Z

Słowo klucz - dupokrytka! Albo nawet kilka. Nie ma gadania, nie ma nagłaśniania ważnych spraw, nie ma argumentowania bez ticketa. Najpierw ticket. Spisać wszystkie potencjalne problemy, ryzyka, sugestie - tak ultra dokładnie, tak żeby nikt nie miał się czego przyczepić. I najlepiej jeszcze wydrukować na prawdziwym papierze i zabrać do domu, nie zaszkodzi. I wtedy dopiero można cokolwiek działać. Wspominać na spotkaniach, suszyć głowę liderom. A potem olać i zapomnieć. Jak szambo wybije - to przynajmniej cię nie pobrudzi.

obscurity napisał(a):

Przypomniała mi się sytuacja gdy dostałem zadanie i rozwiązanie wydawało się proste, ale był jeden case przez który nie można było go użyć i całkowicie trzeba było zmienić podejście; przez parę dni się głowiłem opowiadając o tym na daily, w końcu przydzielili to zadanie innej osobie która je szybko rozwiązała, jednak oczywiście nie biorąc nawet pod uwagę tego case'a mimo że wielokrotnie i praktycznie tylko o nim mówiłem. Za chwilę zostało to znalezione przez testera jako bug który trafił do poprawienia... do mnie. Żeby go poprawić musiałem to zaorać i zrobić wszystko od początku...

I teraz z perspektywy osoby trzeciej wyglądam bardzo marnie bo nie dowiozłem taska a teraz jeszcze mam problem z wdrożeniem "małej" poprawki. Na szczęście miałem trochę czasu żeby się nad tym zastanowić i zrobiłem to szybko, ale od tamtego czasu dostałem nauczkę, że z punktu widzenia biznesu i managementu dużo lepiej widziane jest dostarczyć zadanie szybciej nawet jeśli znamy jego ułomności i potem robić poprawki jako "bugfixy" niż trzymać zadanie zbyt długo na sobie bez widocznego progresu. No i też, że czasem wystarczy mały odpoczynek od problemu i świeży umysł żeby wpaść na coś lepszego.

Po to jest przycisk Reject w pull requestach, żeby do takich sytuacji nie dochodziło.

LukeJL napisał(a):

Ja zauważyłem, że np. za mało elaboruję. Mówię ogólne stwierdzenia typu jest dużo długu technicznego, przydałby się refaktor. I często jest to odbierane jako narzekanie czy feedback (masz rację, dzięki za cenny feedback, dobra sugestia, zgadzam się, ale potem nikt z tym nic nie robi). Niestety o pewnych rzeczach trzeba mówić dłużej i tłumaczyć ludziom, nagłaśniać jako ważną sprawę, argumentować. I wymyślić szkielet/pomysł rozwiązania, bo inaczej nikomu się nie będzie chciało ruszyć d**y, żeby cokolwiek z tym zrobić dalej.

Zamiast gadać trzeba po prostu tworzyć w backlogu taski z opisem problemu i sugerowanym rozwiązaniem, albo chociaż kierunkiem, w którym chcemy podążać.